- Arch-general - lists.archlinux.org

Re: [arch-general] [arch-dev-public] dropping flashplugin x86_64
by Loui Chang 15 Jun '10

15 Jun '10

On Tue 15 Jun 2010 18:23 +0200, Thomas Bächler wrote: > Am 15.06.2010 18:22, schrieb Andreas Radke: > > Am Tue, 15 Jun 2010 19:12:38 +0300 > > schrieb Ionuț Bîru <biru.ionut(a)gmail.com>: > >> the current x86_64 version of flashplugin has security problems and > >> adobe dropped/temporally closed x86_64 releases. > >> > >> How do we manage this situation? > >> Only dropping from repo? > >> Should we submit an empty package? > >> Suggest our users to remove their package if they consider security > >> important? > > > > We should post a news item about this so the users may decide to remove > > it or keep it. Another option could be shipping a dummy empty -1.1 pkg > > for x86_64 with a small post.install msg. > > I'll keep this installed despite the security problem. Combined with > flashblock, I can at least watch youtube this way. Force-removing it by > a dummy update is something I don't want. Yeah forced removal is not the Arch Way. An announcement would be much better.

1 0

[arch-general] How do I get Battlefield 2 with Steam running under Wine?
by Jordan Windsor 14 Jun '10

14 Jun '10

I've tried: bin32-wine(AUR), bin32-wine-suse(AUR) & bin32-wine(Arch Gaming Repo) Here's the output of running Steam under Wine and selecting to run Battlefield 2 through Steam http://pastebin.com/Aea4takn Thanks.

3 5

[arch-general] Rsync Dolphin
by Nilesh Govindarajan 14 Jun '10

14 Jun '10

Hi, I think many of you might be knowing that nautilus can be configured to read/write files in rsync. Is there some way to do the same in dolphin ? -- Nilesh Govindarajan Facebook: http://www.facebook.com/nilesh.gr Twitter: http://twitter.com/nileshgr Website: http://www.itech7.com Cheap and Reliable VPS Hosting: http://j.mp/arHk5e

1 0

Re: [arch-general] [arch-dev-public] When to remove provides/conflicts/replaces?
by Emmanuel Benisty 13 Jun '10

13 Jun '10

On Sun, Jun 13, 2010 at 6:18 PM, Thomas Bächler <thomas(a)archlinux.org> wrote: > Am 13.06.2010 13:17, schrieb Allan McRae: >> On 13/06/10 20:50, Thomas Bächler wrote: >>> Am 13.06.2010 12:43, schrieb Allan McRae: >>>> Hi, >>>> >>>> Do we have any guidelines on when to remove the >>>> provides/conflicts/replaces arrays from a PKGBUILD? In other words, >>>> what is the oldest system we support updating from? >>> >>> kernel26 still has replaces=('kernel24'), although I think updating from >>> a system that still supported kernel24 will be impossible without major >>> problems. >>> >>> I don't think there was ever a guideline on removing these, other than a >>> vague "when it makes sense". >>> >> >> OK. I thought about this when looking at the coreutils PKGBUILD: >> >> provides=('mktemp') >> conflicts=('mktemp') >> replaces=('sh-utils' 'fileutils' 'textutils' 'mktemp') >> >> The mktemp replacement was done in early 2008 and the >> fileutils/textutils/mktemp would probably have been done in 2003. >> >> Clearly the replacement of packages from 2003 is unnecessary, but I am >> not sure about 2008 so I will leave those in at the moment. > > I'd say you can definitely get rid of the provides and conflicts. There > is probably no package depending on mktemp anymore. If there is one, it > should be considered a bug. > > I'd leave the replaces in for mktemp at least, a system from early 2008 > might still be upgraded. > > Just FTR: $ spacman -Su Password: :: Starting full system upgrade... warning: dmenu: local (4.1.1-1) is newer than extra (4.0-2) warning: firefox: local (3.7a6-1) is newer than extra (3.6.3-1) warning: procinfo-ng: local (2.0.304-2) is newer than core (2.0.304-1) warning: schedtool: local (1.3.0-1) is newer than extra (1.2.9-2) resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: quilt: requires mktemp

4 4

[arch-general] Bad Magic Number in Superblock - Any trick for Arch or for new kernels?
by David C. Rankin 13 Jun '10

13 Jun '10

Guys, I have a disk on a arch box that has gone south. No prior warning, no smart errors, no nothing. Granted the drive is 5-6 years old, so a complete crater is not out of the question. The situation: On reboot - grub 22 error boot arch install cd 2009-08, cannot mount drive partition table shows 1 partition /dev/hda1 (PATA drive) (should be 3) (I can't put my hands on the saved 'fdisk -l' data, it's somewhere) gparted 0.46 (0.44 wont work) - loads, but only shows a single partition fsck -> Gives the bad magic number in superblock error, tries backup same error Booted without issue for over a year From the looks of it, the drive scattered. But my question is "Is there something with all the recent kernel changes that would require troubleshooting this drive error in a different way than usual?" I know there have been a lot of changes in moving modules into the kernel, but I don't know what got moved (if anything related to drives), or how it might affect my troubleshooting. Before I add the drive to the heap of drives in my 'dead drive box' are there any other silver bullets I should try to try and resurrect the drive? (Data isn't an issue, it's all backed up :-) What say the gurus? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

5 11

Re: [arch-general] [arch-dev-public] [signoff] gettext-0.18.1.1-1
by Tobias Powalowski 13 Jun '10

13 Jun '10

Am Donnerstag 10 Juni 2010 schrieb Andrea Scarpino: > On Wednesday 09 June 2010 21:43:06 Tobias Powalowski wrote: > > Hi bump to latest version, > > > > please signoff both arches, > > signoff x86_64 anyone i686? -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] [signoff] pcmciautils-017-1
by Tobias Powalowski 13 Jun '10

13 Jun '10

Hi guys, bump to latest version, please signoff both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 1

[arch-general] Fixes for alot of PKGBUILDs
by Christopher Rogers 12 Jun '10

12 Jun '10

I have fixes for alot of packages in extra and community. you can find the fixes here: http://github.com/godane/abs-source/tree/my-fixes its best to 'git clone git://github.com/godane/abs-source.git' without quotes. Do a 'git diff abs-20100611 my-fixes' without quotes to see the fixes i added to them. You can ignore aumix-gtk since it was updated. Also all texlive-*-doc url are broken. There url is you guys so i didn't bother to fix those. I hope this helps.

4 4

Re: [arch-general] [signoff] mpfr-3.0.0-1, gcc-4.5.0-6 and libmpc-0.8.2-2
by Attila 12 Jun '10

12 Jun '10

At Samstag, 12. Juni 2010 14:53 Pierre Schmitz wrote: >> Was that ever fixed in our gcc? > > No, the last working gcc was 4.4 ... > I guess it will be fixed when some mainstream distros switch to gcc 4.5 I hope nobody is getting angry about it but i have one question: Is there a additional benefit that we stepped even "very" early to the next gcc? >From my feeling, which is not an analyze, with every gcc update something breaks and there be at example such disadvantages: 1. Without the bigger distros, which have more manpower, everyone here has to create the patch by himself. At the first look this sounds as that you will do this only if you have too much time.-) 2. I think that the most application or toolkit developpers use at the moment gcc 4.4 and so it would be not a wonder that their own tests been perfect with this version and not 4.5. Or to ask it in another way: What is the disadvantage in the case of gcc to wait until the bigger player in the market makes the step too? Is there realy one or more application which benefits from it or can be compiled only with this newer version of gcc? For me it would be enough to have 4.5 in a gcc-next package and make the step with the other distros. But this be only my 2c. See you, Attila

1 0

[arch-general] ALSTF (Arch Linux Security Task Force)?
by Marek Kozlowski 12 Jun '10

12 Jun '10

:-) I've found such a topic when browsing the Wiki: http://wiki.archlinux.org/index.php/Security_Task_Force Well, sound like a very smart idea. IMHO it's a thing that makes a distro more 'prestigious' -- it's quite difficult to convince someone to using a distro for something more than just a testing workstation if it's security is, let's say... 'unknown'. Unfortunately there *are* some regressions in the upstream that make the latest stable releases vulnerable. In fact it's the main reason that prevents my faculty from switching from Gentoo and log-time compilations to simple and KISS-ing Arch. Any work toward ALSTF in the recent past? Best regards, Marek

3 2