Re: [arch-general] Still Glibc problems
On 07/20/2012 04:45 PM, Baho Utot wrote: > On 07/20/2012 12:46 PM, Tom Gundersen wrote: >> On Jul 20, 2012 6:08 PM, "Baho Utot" wrote: >>> On 07/20/2012 10:47 AM, Tom Gundersen wrote: On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans wrote: > There's nothing on this system that hasn't come from either AUR or the > official arch repositories, so I don't know why I'm having any problems >> at all :-( I have seen people having problems because they installed packages from repos that they no longer have active (typically multilib), make sure to either remove any "stale" packages or re-enable any repos so you get all the most recent updates. >>> >>> I had a desktop system hosed that only packages in core, extra and >> community installed. >> >> I never heard of anyone actually hosing their system without using --force. >> What happened? (I'm assuming you don't use testing?). >> >> -t > > No I didn't use testing. > Followed the news release..rebootedsystem borked. > > > > Tom, Baho, After Updating 3 boxes and created 3 new arch chroots, you do have manual intervention required in just about every case if you have ever used mkinitcpio to rebuild initramfs (leaves old module trees in /lib/modules) or if you have ever used virtualbox (old vb modules left in /lib/modules/misc or /lib/modules/kernel/misc) udev-compat is also a problem. Just pacman -R that. Then after you do the initial pacman -Syu --ignore glibc, you need to manually pick though lib and make sure there is _nothing_ but glibc files in it. (no empty dirs, no links, no nothing) Then you can do the final pacman -Syu Also, if you attempt to create or update an arch chroot -- make sure you have no stale repos in pacman.conf. The install will fail and half your system will be mounted under the chroot dir. There is no way to update an arch chroot with the glibc 2.15->2.16 update. Just create a new one. Hope some of this helps.. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
Op 21 jul. 2012 01:13 schreef "Manolo Martínez" het volgende: > > > OK. I'll subscribe to arch-dev-public, then. I think it would be good if > the "mailing lists" page at archlinux.org explained what one is to > expect from each mailing list, and maybe recommend which mailing lists > to follow, like you just did. I usually just check the online archives for that list every now and then. Mainly when there are 'special' updates, sometimes just curiousity. Mvg, Guus
Re: [arch-general] Still Glibc problems
D. R. Evans [2012.07.20 1541 -0600]: > Norbert Zeh said the following at 07/19/2012 06:08 PM : > > > > > Well, the filesystem instructions are older and applied at the time the > > glibc > > upgrade was not an issue yet. Combining the two instructions, I would > > guess the > > following should work: > > > > pacman -Syu --ignore filesystem --ignore glibc > > OK. > > > pacman -S --force filesystem --ignore glibc > > OK. > > > pacman -Sd > > OK. FWIW, the list of packages was: > > attica binutils boost-libs eclipse eclipse-cdt faac ffmpeg gcc > gcc-libs gnutls grep gstreamer0.10-bad-plugins icu jedit kdebase-runtime > kdelibs libcups libgl liblrdf libmp4v2 libproxy libtool libva linux > mesa mkinitcpio openjdk6 pcre poppler poppler-glib qt raptor soprano > swig xine-lib xorg-server-xephyr > > > pacman -Su > > > > Not OK: > > > [root@shack n7dr]# pacman -Su > > :: Starting full system upgrade... > > resolving dependencies... > > looking for inter-conflicts... > > > > Targets (1): glibc-2.16.0-2 > > > > Total Installed Size: 33.94 MiB > > Net Upgrade Size: 0.83 MiB > > > > Proceed with installation? [Y/n] > > (1/1) checking package integrity > > > > [##] > > 100% > > (1/1) loading package files > > > > [##] > > 100% > > (1/1) checking for file conflicts > > > > [##] > > 100% > > error: failed to commit transaction (conflicting files) > > glibc: /lib exists in filesystem > > Errors occurred, no packages were upgraded. I got the same error at that point. What this means is that you either have some unowned (by any package) files in /lib (/lib/modules/* is a good candidate) or you have some other packages (most likely from AUR) owning files under /lib. The wiki page explains well how to look for them. At least, I followed those instructions and managed to identify the packages that blocked the upgrade. The key here really seems to be to make sure that glibc is the only package which at this point owns anything under /lib. I think in my case it also helped to uninstall some packages and reinstall them after the glibc upgrade. Keep pushing, you're almost there ;) Cheers, Norbert
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 07/20/12 at 10:45pm, Tom Gundersen wrote: > On Fri, Jul 20, 2012 at 9:37 PM, Manolo Martínez > wrote: > > On 07/20/12 at 09:31pm, Florian Pritz wrote: > >> On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez > >> wrote: > >> > On 07/20/12 at 02:56pm, Daniel Wallace wrote: > >> > > All of those changes were discussed by the devs on arch-dev-public > >> > > >> > I, for one, thought that running archlinux responsibly only committed me > >> > to subscribing to and reading arch-announce and -general. If I need to > >> > read -dev-public too I will, but it'd be good to be explicit about this. > >> > >> You don't have to read arch-dev-public if you just want to use Arch, but > >> your original question was about the reasoning behind the move and that > >> information is available in the mailing list archives. > > > > No, apparently you do need to know why and how these things are done even > > if you just > > want to use Arch and don't plan to develop for it. That's a lesson I learnt > > around here anyway. > > The aim is that reading the news items should be enough to deal with > any update. If you want notifications in advance of future plans or if > you want to understand the reasoning behind certain changes, then > following arch-dev-public should be enough. arch-general is typically > for user discussions, and not so much for development discussions. > OK. I'll subscribe to arch-dev-public, then. I think it would be good if the "mailing lists" page at archlinux.org explained what one is to expect from each mailing list, and maybe recommend which mailing lists to follow, like you just did. Thanks, Manolo
Re: [arch-general] python needs /usr/include/?
On Sat, Jul 21, 2012 at 12:25 AM, Rodrigo Rivas wrote: > On Fri, Jul 20, 2012 at 8:32 PM, Christian Hesse wrote: > >> Hello everybody, >> >> I am creating live media and want to reduce size. After >> removing /usr/include/ wicd fails to start because of a missing header >> file. >> > > Do you know which one is trying to read? > If not, you could try running it with `strace` to see what it is looking > for: > Replying to myself, the file it reads is `/usr/include/python2.7/pyconfig.h` (for python2). You can see the relevant code in the deeps of the initialization routines of the python library, sysconfig.py: # load the installed pyconfig.h: config_h = get_config_h_filename() try: with open(config_h) as f: parse_config_h(f, vars) except IOError, e: msg = "invalid Python installation: unable to open %s" % config_h if hasattr(e, "strerror"): msg = msg + " (%s)" % e.strerror raise IOError(msg) It seems to be used to discover the configuration of the current python installation. Just copying this file to your live media should be enough to make it happy. Or alternatively, you might modify the sysconfig.py to read the file from other place (`/usr/lib/python2.7` for example). -- Rodrigo
Re: [arch-general] python needs /usr/include/?
On Fri, Jul 20, 2012 at 8:32 PM, Christian Hesse wrote: > Hello everybody, > > I am creating live media and want to reduce size. After > removing /usr/include/ wicd fails to start because of a missing header > file. > Do you know which one is trying to read? If not, you could try running it with `strace` to see what it is looking for: -- Rodrigo
Re: [arch-general] Still Glibc problems
On 07/20/2012 12:46 PM, Tom Gundersen wrote: On Jul 20, 2012 6:08 PM, "Baho Utot" wrote: On 07/20/2012 10:47 AM, Tom Gundersen wrote: On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans wrote: There's nothing on this system that hasn't come from either AUR or the official arch repositories, so I don't know why I'm having any problems at all :-( I have seen people having problems because they installed packages from repos that they no longer have active (typically multilib), make sure to either remove any "stale" packages or re-enable any repos so you get all the most recent updates. I had a desktop system hosed that only packages in core, extra and community installed. I never heard of anyone actually hosing their system without using --force. What happened? (I'm assuming you don't use testing?). -t No I didn't use testing. Followed the news release..rebootedsystem borked.
Re: [arch-general] Still Glibc problems
Norbert Zeh said the following at 07/19/2012 06:08 PM : > > Well, the filesystem instructions are older and applied at the time the glibc > upgrade was not an issue yet. Combining the two instructions, I would guess > the > following should work: > > pacman -Syu --ignore filesystem --ignore glibc OK. > pacman -S --force filesystem --ignore glibc OK. > pacman -Sd OK. FWIW, the list of packages was: attica binutils boost-libs eclipse eclipse-cdt faac ffmpeg gcc gcc-libs gnutls grep gstreamer0.10-bad-plugins icu jedit kdebase-runtime kdelibs libcups libgl liblrdf libmp4v2 libproxy libtool libva linux mesa mkinitcpio openjdk6 pcre poppler poppler-glib qt raptor soprano swig xine-lib xorg-server-xephyr > pacman -Su > Not OK: > [root@shack n7dr]# pacman -Su > :: Starting full system upgrade... > resolving dependencies... > looking for inter-conflicts... > > Targets (1): glibc-2.16.0-2 > > Total Installed Size: 33.94 MiB > Net Upgrade Size: 0.83 MiB > > Proceed with installation? [Y/n] > (1/1) checking package integrity > > [##] > 100% > (1/1) loading package files > > [##] > 100% > (1/1) checking for file conflicts > > [##] > 100% > error: failed to commit transaction (conflicting files) > glibc: /lib exists in filesystem > Errors occurred, no packages were upgraded. > [root@shack n7dr]# Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
Re: [arch-general] Still Glibc problems
Tom Gundersen said the following at 07/20/2012 02:41 PM : > On Fri, Jul 20, 2012 at 10:36 PM, D. R. Evans wrote: >> Norbert Zeh said the following at 07/20/2012 12:27 PM : >> >>> think the reason why you are having a much more serious issue is that it >>> seems >>> you haven't updated your system in a long time. So now you're running into >> >> Approximately a month, I believe. Certainly not a whole lot longer. I don't >> regard that as a long time, but perhaps in the arch world it is. But since >> the >> box I'm upgrading often goes a couple of months without even being powered >> up, >> it would be hard to upgrade more frequently. > > No, a month is not a long time. I would have thought more than half a > year (which is still not awfully long, but would mean you would be hit Definitely nothing even close to that. I do note that, as I mentioned, /var/run and /var/lock were symlinks, which I think is a change from about six months ago. I'm about to try the suggested sequence: > pacman -Syu --ignore filesystem --ignore glibc > pacman -S --force filesystem --ignore glibc > pacman -Sd > pacman -Su and we'll see what happens. Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On Fri, Jul 20, 2012 at 9:37 PM, Manolo Martínez wrote: > On 07/20/12 at 09:31pm, Florian Pritz wrote: >> On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez >> wrote: >> > On 07/20/12 at 02:56pm, Daniel Wallace wrote: >> > > All of those changes were discussed by the devs on arch-dev-public >> > >> > I, for one, thought that running archlinux responsibly only committed me >> > to subscribing to and reading arch-announce and -general. If I need to >> > read -dev-public too I will, but it'd be good to be explicit about this. >> >> You don't have to read arch-dev-public if you just want to use Arch, but >> your original question was about the reasoning behind the move and that >> information is available in the mailing list archives. > > No, apparently you do need to know why and how these things are done even if > you just > want to use Arch and don't plan to develop for it. That's a lesson I learnt > around here anyway. The aim is that reading the news items should be enough to deal with any update. If you want notifications in advance of future plans or if you want to understand the reasoning behind certain changes, then following arch-dev-public should be enough. arch-general is typically for user discussions, and not so much for development discussions. -t
Re: [arch-general] Still Glibc problems
On Fri, Jul 20, 2012 at 10:36 PM, D. R. Evans wrote: > Norbert Zeh said the following at 07/20/2012 12:27 PM : > >> think the reason why you are having a much more serious issue is that it >> seems >> you haven't updated your system in a long time. So now you're running into > > Approximately a month, I believe. Certainly not a whole lot longer. I don't > regard that as a long time, but perhaps in the arch world it is. But since the > box I'm upgrading often goes a couple of months without even being powered up, > it would be hard to upgrade more frequently. No, a month is not a long time. I would have thought more than half a year (which is still not awfully long, but would mean you would be hit by the problem explained in http://allanmcrae.com/2012/07/updating-arch-linux-from-a-core-install/). Anyway, I didn't mean to imply that you have to update at a certain frequency, just to offer a possible explanation why you are seeing problems that relatively few other people are seeing. -t
Re: [arch-general] Still Glibc problems
Norbert Zeh said the following at 07/20/2012 12:27 PM : > think the reason why you are having a much more serious issue is that it seems > you haven't updated your system in a long time. So now you're running into Approximately a month, I believe. Certainly not a whole lot longer. I don't regard that as a long time, but perhaps in the arch world it is. But since the box I'm upgrading often goes a couple of months without even being powered up, it would be hard to upgrade more frequently. Maybe I made a mistake putting arch on it, if arch really does have to be upgraded more frequently than that. I was unaware that that was a consideration. I've never used a "rolling release" distribution before, and perhaps I shouldn't have done so on the machine in question. I (naïfly) thought that the package manager system would automagically take care of everything regardless of how many updates needed to be applied. Computers... even after all this time, still a learning experience. Even when I don't want them to be. Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
[arch-general] glibc 2.15 -> glibc 2.16 New Build Failures (scope primarily) Expected??
Guys, After going though the usrlib/glibc update and creating a new archroot for building, I am getting build failures in trinity k3b and k9copy. Both packages built without error on 7/14 prior to my update. Following update I experience the following: k3b: summary: k3bffmpegwrapper.cpp:131:63: error: 'dump_format' was not declared in this scope k9copy: summary: k9avidecode.h:35:91: error: 'AVFormatParameters' has not been declared Two questions (1) are new build failures expected as the result of glibc 2.15 -> 2.16 update that require source updates; (2) is anyone else experiencing this on project they are working with? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Still Glibc problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/12 07:47, Tom Gundersen wrote: > On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans > wrote: >> There's nothing on this system that hasn't come from either AUR >> or the official arch repositories, so I don't know why I'm having >> any problems at all :-( > > I have seen people having problems because they installed packages > from repos that they no longer have active (typically multilib), > make sure to either remove any "stale" packages or re-enable any > repos so you get all the most recent updates. > This is one thing I found I had to do. It's certainly fast enough. I just removed these packages prior to the upgrade and reinstalled them afterwards. Once the sym-link for /lib is in place, everything lands in the right place. - -- David Benfell benf...@parts-unknown.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQCb36AAoJELT202JKF+xpe9MQAJatGuaBy5xCXeeTsxJTisZp uUQQNxrlj7ChsNgSLn97ebdZUBCYNsBwKvYQYrpOaR7mct/Wnco7NmzflH5QgWb5 D2mG4UQFhALEXeSLdSn09+Cfl/T1FJTiBmUHdwuTC1s3GykKX4r/ev9VhC9FBqXL mttQJfoNiq73CasWz1L9LcRzXwD4HCkH/Cnf5arxGFMcJfVyVVzzq9Z1V8ZKXh78 qYl2+uI6ZAis9/QB9b1JDjUnTdJbcNMOMXTmhdgh+MqmE6lNADflRgMwyTm8xoIG 9e3/ljNsya+SarAnanC8f8B7Xb+wpN+UymM6OE4FXc50S9R8LeAvb7RyM9WaqP7k rBOelqmqzIeM/yqInUKm9aVxmic7OMNpv88Nzh02LTpFPWM9dQkRXGRvxIYuHAJM U3r7po6CyW6yR3wG3ErOojGJ22Bq989f7QVSRYjGyDPUmIYfn8ijd5TxZgtotft3 k3Z50CWt4Ww1psGmEJyP6ZXFFH6rT9j3IPhqh6cmaQYmHsQm7MQx5t6lDV7eB/BA wuA45uTcbuH4+AChBy50yoEy+8bkco59v0qVPOpKMubFL8qXELnVhSUaRwvcs5C9 jAu80fFO3l8/oE5z+ZqkSEzRiy0sxxHphfvPBjEAWM2PpQBSrzTA9BS4EyTJiF2q MlyA6npY9x5Uz8SwQK5O =WaCS -END PGP SIGNATURE-
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
Op vrijdag 20 juli 2012 22:06:31 schreef Arvid Warnecke: > On Fri, Jul 20, 2012 at 03:52:34PM -0400, Daniel Wallace wrote: > > On Fri, Jul 20, 2012 at 09:53:01PM +0200, Arvid Warnecke wrote: > > > On Fri, Jul 20, 2012 at 09:27:22AM +0200, Ike Devolder wrote: > > > > could you try the same with the long lived branch of nvidia utils and > > > > drivers? > > > > > > > > these are at version 295.59 > > > > > > > > nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 > > > > nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604 > > > > > > > > fist build utils, then driver > > > > > > Is there an ideal way of replacing nvidia by nvidia-ll? > > > I build the utils, but am not able to install it, because the actually > > > installed nvidia requires the other nvidia-utils. > > > > remove the ones that are already installed, and then finish building > > and installing the new ones > > That results in removing 41 packages depending on nvidia and > nvidia-utils. Any better way? building in chroot or follow the following steps without rebooting: 1) build 'nvidia-utils-ll' 2) remove 'nvidia' 3) install 'nvidia-utils-ll' 4) build 'nvidia-ll' 5) install 'nvidia-ll' and that should do it and not get you to remove many packages --Ike signature.asc Description: This is a digitally signed message part.
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
On Fri, Jul 20, 2012 at 03:52:34PM -0400, Daniel Wallace wrote: > On Fri, Jul 20, 2012 at 09:53:01PM +0200, Arvid Warnecke wrote: > > On Fri, Jul 20, 2012 at 09:27:22AM +0200, Ike Devolder wrote: > > > could you try the same with the long lived branch of nvidia utils and > > > drivers? > > > > > > these are at version 295.59 > > > > > > nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 > > > nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604 > > > > > > fist build utils, then driver > > > > > Is there an ideal way of replacing nvidia by nvidia-ll? > > I build the utils, but am not able to install it, because the actually > > installed nvidia requires the other nvidia-utils. > > > remove the ones that are already installed, and then finish building > and installing the new ones That results in removing 41 packages depending on nvidia and nvidia-utils. Any better way? -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]--- pgpk4b97aTYW1.pgp Description: PGP signature
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
On Fri, Jul 20, 2012 at 09:53:01PM +0200, Arvid Warnecke wrote: > Hello Ike, > > On Fri, Jul 20, 2012 at 09:27:22AM +0200, Ike Devolder wrote: > > Op vrijdag 20 juli 2012 08:05:33 schreef Arvid Warnecke: > > > I have already been used to not beeing able to suspend my MacBook Pro > > > since the buggy nvidia version which came with 3.4.x kernel. But as of > > > the latest updates which brought kernel 3.4.5-1 I am not able to use > > > pm-hibernate anymore. > > > When looking into /var/log/pm-suspend.log it seems that hibernating went > > > well: lots of "success" messages and no errors. But when I then start > > > the MacBook again it does not resume but boots normally. fsck detects > > > that disks haven't been unmounted orderly, recovers journal and I am > > > back to a fresh booted system then. > > > > > > Any ideas what might be causing this issue? More fresh bugs in nvidia > > > 302.17-3? > > > > > could you try the same with the long lived branch of nvidia utils and > > drivers? > > > > these are at version 295.59 > > > > nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 > > nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604 > > > > fist build utils, then driver > > > Is there an ideal way of replacing nvidia by nvidia-ll? > I build the utils, but am not able to install it, because the actually > installed nvidia requires the other nvidia-utils. > > ┌─[ madhatter(archBookPro):~/builds/nvidia-ll ] > └──╼ makepkg -sf > > > ==> Making package: nvidia-ll 295.59-2 (Fr 20. Jul 21:51:18 CEST 2012) > ==> Checking runtime dependencies... > ==> Installing missing dependencies... > error: target not found: nvidia-utils-ll=295.59 > ==> ERROR: 'pacman' failed to install missing dependencies. > > The utils are build, but not installed yet. > > > Hmpf, > Arvid > > -- > [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] > [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] > ---[ ThreePiO was right: Let the Wookiee win. ]--- remove the ones that are already installed, and then finish building and installing the new ones pgpt7m5kyVYS0.pgp Description: PGP signature
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
Hello Ike, On Fri, Jul 20, 2012 at 09:27:22AM +0200, Ike Devolder wrote: > Op vrijdag 20 juli 2012 08:05:33 schreef Arvid Warnecke: > > I have already been used to not beeing able to suspend my MacBook Pro > > since the buggy nvidia version which came with 3.4.x kernel. But as of > > the latest updates which brought kernel 3.4.5-1 I am not able to use > > pm-hibernate anymore. > > When looking into /var/log/pm-suspend.log it seems that hibernating went > > well: lots of "success" messages and no errors. But when I then start > > the MacBook again it does not resume but boots normally. fsck detects > > that disks haven't been unmounted orderly, recovers journal and I am > > back to a fresh booted system then. > > > > Any ideas what might be causing this issue? More fresh bugs in nvidia > > 302.17-3? > > > could you try the same with the long lived branch of nvidia utils and drivers? > > these are at version 295.59 > > nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 > nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604 > > fist build utils, then driver > Is there an ideal way of replacing nvidia by nvidia-ll? I build the utils, but am not able to install it, because the actually installed nvidia requires the other nvidia-utils. ┌─[ madhatter(archBookPro):~/builds/nvidia-ll ] └──╼ makepkg -sf ==> Making package: nvidia-ll 295.59-2 (Fr 20. Jul 21:51:18 CEST 2012) ==> Checking runtime dependencies... ==> Installing missing dependencies... error: target not found: nvidia-utils-ll=295.59 ==> ERROR: 'pacman' failed to install missing dependencies. The utils are build, but not installed yet. Hmpf, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]--- pgpzbfUMO4F4o.pgp Description: PGP signature
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On Fri, Jul 20, 2012 at 3:37 PM, Manolo Martínez wrote: > On 07/20/12 at 09:31pm, Florian Pritz wrote: >> On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez >> wrote: >> > On 07/20/12 at 02:56pm, Daniel Wallace wrote: >> > > All of those changes were discussed by the devs on arch-dev-public >> > >> > I, for one, thought that running archlinux responsibly only committed me >> > to subscribing to and reading arch-announce and -general. If I need to >> > read -dev-public too I will, but it'd be good to be explicit about this. >> >> You don't have to read arch-dev-public if you just want to use Arch, but >> your original question was about the reasoning behind the move and that >> information is available in the mailing list archives. > > No, apparently you do need to know why and how these things are done even if > you just > want to use Arch and don't plan to develop for it. That's a lesson I learnt > around here anyway. > > Manolo Just to chime in here, I hadn't updated my system in about 6 months and was able to get past the /lib bump without reading the ML threads just fine. The news article linking to the wiki page was plenty.
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 07/20/12 at 09:31pm, Florian Pritz wrote: > On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez > wrote: > > On 07/20/12 at 02:56pm, Daniel Wallace wrote: > > > All of those changes were discussed by the devs on arch-dev-public > > > > I, for one, thought that running archlinux responsibly only committed me > > to subscribing to and reading arch-announce and -general. If I need to > > read -dev-public too I will, but it'd be good to be explicit about this. > > You don't have to read arch-dev-public if you just want to use Arch, but > your original question was about the reasoning behind the move and that > information is available in the mailing list archives. No, apparently you do need to know why and how these things are done even if you just want to use Arch and don't plan to develop for it. That's a lesson I learnt around here anyway. Manolo
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez wrote: > On 07/20/12 at 02:56pm, Daniel Wallace wrote: > > All of those changes were discussed by the devs on arch-dev-public > > I, for one, thought that running archlinux responsibly only committed me > to subscribing to and reading arch-announce and -general. If I need to > read -dev-public too I will, but it'd be good to be explicit about this. You don't have to read arch-dev-public if you just want to use Arch, but your original question was about the reasoning behind the move and that information is available in the mailing list archives. > > In my previous e-mail I also raised the point of having a roadmap for upgrades > that require user intervention. I'd like to know if that'd be > feasible; I think it would be useful. Likely not going to happen. Just update every few weeks rather than months and you'll have the same problems as everyone else (which will be described in the news posts) rather than more than one at a time, but even that isn't really that hard to resolve (see Allan's blog post[1] about upgrading from the super old core ISO) [1]: http://allanmcrae.com/2012/07/updating-arch-linux-from-a-core-install/ signature.asc Description: PGP signature
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 07/20/12 at 02:56pm, Daniel Wallace wrote: > All of those changes were discussed by the devs on arch-dev-public > > filesystem -> > http://mailman.archlinux.org/pipermail/arch-dev-public/2012-June/023014.html > > grub -> > http://mailman.archlinux.org/pipermail/arch-dev-public/2012-June/023147.html > > /lib -> usr/lib -> > http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html > > There are also discussions there about what will happen and when stuff > breaks like the pacman bug when usr lib was in testing, most of that > happens that I, for one, thought that running archlinux responsibly only committed me to subscribing to and reading arch-announce and -general. If I need to read -dev-public too I will, but it'd be good to be explicit about this. In my previous e-mail I also raised the point of having a roadmap for upgrades that require user intervention. I'd like to know if that'd be feasible; I think it would be useful. Manolo --
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On Fri, Jul 20, 2012 at 02:41:44PM -0400, Manolo Martínez wrote: > On 07/20/12 at 03:27pm, Norbert Zeh wrote: > > I > > think the reason why you are having a much more serious issue is that it > > seems > > you haven't updated your system in a long time. So now you're running into > > dealing with two slightly tricky upgrades (filesystem + glibc) at the same > > time. > > I've had no problems with filesystem, /lib -> /usr/lib or, today, grub > -> grub2. I have at best a tenuous grasp of the issues involved in these > three changes, so I can only consider myself very lucky that I'm not in the > quandary others seem to be. > > I know, though, of enthusiastic archers who have resented the > problems that have resulted from some of these changes, and feel less > enthusiastic about archlinux now. I guess there is an inherent tension > between the rolling-distro concept and KISS: if you want an up-to-date > system you are bound to change things that work (which is hardly KISS). > > I was wondering if the following could be useful to minimize the impact > of these, more trepidant pacman -Syu's: archlinux could publish a > roadmap of user-intervention upgrades well in advance: we will do this > in Q1, that in Q2, and that other thing in Q3. This way users could, for > example, plan their upgrades so as not to have to deal with two such > problematic migrations at the same time. > > It would also be nice to know a bit more of the rationale behind the > moves. I'm sure that they are all for the best, and I trust arch > decision-makers (and one can find out more about the changes by reading > blogs and forum discussions), but still it'd be good to have a small FAQ > posted to > arch-general before each of the biggish moves. > > Manolo All of those changes were discussed by the devs on arch-dev-public filesystem -> http://mailman.archlinux.org/pipermail/arch-dev-public/2012-June/023014.html grub -> http://mailman.archlinux.org/pipermail/arch-dev-public/2012-June/023147.html /lib -> usr/lib -> http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html There are also discussions there about what will happen and when stuff breaks like the pacman bug when usr lib was in testing, most of that happens that pgp1MIj0DfBON.pgp Description: PGP signature
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 07/20/2012 12:41 PM, Manolo Martínez wrote: > It would also be nice to know a bit more of the rationale behind the > moves. I'm sure that they are all for the best, and I trust arch > decision-makers (and one can find out more about the changes by reading > blogs and forum discussions), but still it'd be good to have a small FAQ > posted to > arch-general before each of the biggish moves. > I don't know how it can get any more transparent. Most of the discussion and defense (if necessary) happens on arch-dev-public. Then there is usually some mention on arch-general, and always announcements. Look at the past three announcements: filesystem, /lib, and grub2. It's all there. It's rare that you can actually hose your system to a point where you can't fix it from the install image and using pacman -r or setting up a chroot. signature.asc Description: OpenPGP digital signature
[arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 07/20/12 at 03:27pm, Norbert Zeh wrote: > I > think the reason why you are having a much more serious issue is that it seems > you haven't updated your system in a long time. So now you're running into > dealing with two slightly tricky upgrades (filesystem + glibc) at the same > time. I've had no problems with filesystem, /lib -> /usr/lib or, today, grub -> grub2. I have at best a tenuous grasp of the issues involved in these three changes, so I can only consider myself very lucky that I'm not in the quandary others seem to be. I know, though, of enthusiastic archers who have resented the problems that have resulted from some of these changes, and feel less enthusiastic about archlinux now. I guess there is an inherent tension between the rolling-distro concept and KISS: if you want an up-to-date system you are bound to change things that work (which is hardly KISS). I was wondering if the following could be useful to minimize the impact of these, more trepidant pacman -Syu's: archlinux could publish a roadmap of user-intervention upgrades well in advance: we will do this in Q1, that in Q2, and that other thing in Q3. This way users could, for example, plan their upgrades so as not to have to deal with two such problematic migrations at the same time. It would also be nice to know a bit more of the rationale behind the moves. I'm sure that they are all for the best, and I trust arch decision-makers (and one can find out more about the changes by reading blogs and forum discussions), but still it'd be good to have a small FAQ posted to arch-general before each of the biggish moves. Manolo
[arch-general] python needs /usr/include/?
Hello everybody,
I am creating live media and want to reduce size. After
removing /usr/include/ wicd fails to start because of a missing header file.
Is this expected behavior? I thought /usr/include/ is only needed for
compilation and not as runtime dependency.
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}
Re: [arch-general] Still Glibc problems
D. R. Evans [2012.07.20 0827 -0600]: > Norbert Zeh said the following at 07/19/2012 06:08 PM : > > > > > Well, the filesystem instructions are older and applied at the time the > > glibc > > upgrade was not an issue yet. Combining the two instructions, I would > > guess the > > following should work: > > > > pacman -Syu --ignore filesystem --ignore glibc > > pacman -S --force filesystem --ignore glibc > > pacman -Sd > > Incidentally, this is quite a long list. > https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest > that the list will contain only a few items, but the actual number is of the > order a couple of dozen packages. > > > pacman -Su > > > > Note that I did not try this, but it seems to be the logical combination of > > the > > two. Maybe one of the developers can chime in and confirm that this is the > > right strategy. > > I am rather reticent to try something untested, especially when I see the > --force option in use. So yes, PLEASE, can a developer address this issue so > that I can have more confidence that I won't end up with a hosed system. > > (I am very puzzled as to why this is happening at all. This is not a system to > which anything fancy has ever been done. If I'm having this problem, I don't > know why lots of others aren't seeing it too.) I got a fairly long list of packages I had to ignore in the first run, too, and I had a few unowned files in /lib I had to clean out. It all worked very well following the instructions on the wiki, though. So no complaints at all. I think the reason why you are having a much more serious issue is that it seems you haven't updated your system in a long time. So now you're running into dealing with two slightly tricky upgrades (filesystem + glibc) at the same time. I upgrade packages very frequently. So I dealt with the filesystem upgrade a few weeks ago, and all went smoothly. Having an up-to-date filesystem package, the upgrade of glibc was also fairly straightforward, even if it involved quite a bit of manual intervention. I think the lesson to be learned here is that not upgrading packages on an arch box for a long time is not the best idea, and I think most arch users do upgrade quite frequently. Cheers, Norbert
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
Op vrijdag 20 juli 2012 17:11:12 schreef Arvid Warnecke: > Hello, > > On Fri, Jul 20, 2012 at 04:14:35PM +0200, Ike Devolder wrote: > > Op vrijdag 20 juli 2012 16:11:43 schreef Lukáš Jirkovský: > > > On 20 July 2012 09:27, Ike Devolder wrote: > > > > could you try the same with the long lived branch of nvidia utils and > > > > drivers? > > > > > > > > these are at version 295.59 > > > > > > > > nvidia-ll: https://aur.archlinux.org/packages.php?ID`602 > > > > nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID`604 > > > > > > > > fist build utils, then driver > > I will try that. Do they work with the current kernel? yes they do 3.4.6 just works fine > I have already > been thinking about downgrading the nvidia package to nvidia-295.53-1, > which seems to be the last version from the official repository whithout > such issues. > > > > nouveau or vesa would be probably even better, because this way we > > > could better track down what is causing it (kernel or nvidia binary > > > driver). > > I can try to do so, too. I moved to nvidia from the nouveau because I > had to disable acceleration on nouveau because of the graphics board in > my Macbook Pro. Seemed to be a well known issue. > > Cheers, > Arvid --Ike signature.asc Description: This is a digitally signed message part.
Re: [arch-general] Still Glibc problems
Op 20 jul. 2012 16:21 schreef "D. R. Evans" het volgende: > > Guus Snijders said the following at 07/20/2012 04:13 AM : [...] > > If i understand correctly, the symlinks for /var/run and /var/lock are > > there already. > > Yes. > > > > > If fileystem is not yet upgraded, what might just work is to restore > > I don't know what you mean by "the filesystem is not yet upgraded". My apologies, i meant the package filesystem there. I understand now that in your current situation a forced install of the package filesystem would be safe. I guess it would be wise to wait with the glibc package until everything else is updated and the box rebooted (just to be sure). I'm not a big fan of rebooting, but in this case ;-) Hope that helpes. Mvg, Guus
Re: [arch-general] Still Glibc problems
On Jul 20, 2012 6:08 PM, "Baho Utot" wrote: > > On 07/20/2012 10:47 AM, Tom Gundersen wrote: >> >> On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans wrote: >>> >>> There's nothing on this system that hasn't come from either AUR or the >>> official arch repositories, so I don't know why I'm having any problems at all :-( >> >> I have seen people having problems because they installed packages >> from repos that they no longer have active (typically multilib), make >> sure to either remove any "stale" packages or re-enable any repos so >> you get all the most recent updates. > > > I had a desktop system hosed that only packages in core, extra and community installed. I never heard of anyone actually hosing their system without using --force. What happened? (I'm assuming you don't use testing?). -t
Re: [arch-general] Still Glibc problems
On 07/20/2012 10:47 AM, Tom Gundersen wrote: On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans wrote: There's nothing on this system that hasn't come from either AUR or the official arch repositories, so I don't know why I'm having any problems at all :-( I have seen people having problems because they installed packages from repos that they no longer have active (typically multilib), make sure to either remove any "stale" packages or re-enable any repos so you get all the most recent updates. I had a desktop system hosed that only packages in core, extra and community installed.
Re: [arch-general] Still Glibc problems
On 07/20/2012 10:27 AM, D. R. Evans wrote: Norbert Zeh said the following at 07/19/2012 06:08 PM : Well, the filesystem instructions are older and applied at the time the glibc upgrade was not an issue yet. Combining the two instructions, I would guess the following should work: pacman -Syu --ignore filesystem --ignore glibc pacman -S --force filesystem --ignore glibc pacman -Sd Incidentally, this is quite a long list. https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest that the list will contain only a few items, but the actual number is of the order a couple of dozen packages. pacman -Su Note that I did not try this, but it seems to be the logical combination of the two. Maybe one of the developers can chime in and confirm that this is the right strategy. I am rather reticent to try something untested, especially when I see the --force option in use. So yes, PLEASE, can a developer address this issue so that I can have more confidence that I won't end up with a hosed system. (I am very puzzled as to why this is happening at all. This is not a system to which anything fancy has ever been done. If I'm having this problem, I don't know why lots of others aren't seeing it too.) Doc I had this problem on the few remaining arch desktop boxes that I admin. I fixed those by installing Fedora 17, the server boxes were "fixed" by my own distro...LFS and pacman-3.3.3 as the package manager.
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
Hello, On Fri, Jul 20, 2012 at 10:40:21AM +0300, Mantas Mikulėnas wrote: > On Fri, Jul 20, 2012 at 9:05 AM, Arvid Warnecke wrote: > > When looking into /var/log/pm-suspend.log it seems that hibernating went > > well: lots of "success" messages and no errors. But when I then start > > the MacBook again it does not resume but boots normally. fsck detects > > that disks haven't been unmounted orderly, recovers journal and I am > > back to a fresh booted system then. > I just have to ask: do you still have the "resume" hook and the > related option in kernel command line? I remember this happening when > I accidentally lost mine a few weeks earlier. > I removed the option from the kernel command line when I noticed that it does not seem to solve my issues. And I have few changes in /etc/acpi/handler.sh which made hibernating possible when closing the lid in the first place: button/lid) case "$3" in close) echo "LID closed!">/dev/tty5 #vbetool dpms off #pm-suspend pm-hibernate ;; open) echo "LID opened!">/dev/tty5 xset -display :0 dpms force on ;; esac ;; Cheers, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]--- pgp9aeGBbrrmd.pgp Description: PGP signature
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
Hello, On Fri, Jul 20, 2012 at 04:14:35PM +0200, Ike Devolder wrote: > Op vrijdag 20 juli 2012 16:11:43 schreef Lukáš Jirkovský: > > On 20 July 2012 09:27, Ike Devolder wrote: > > > could you try the same with the long lived branch of nvidia utils and > > > drivers? > > > > > > these are at version 295.59 > > > > > > nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 > > > nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604 > > > > > > fist build utils, then driver > > > I will try that. Do they work with the current kernel? I have already been thinking about downgrading the nvidia package to nvidia-295.53-1, which seems to be the last version from the official repository whithout such issues. > > nouveau or vesa would be probably even better, because this way we > > could better track down what is causing it (kernel or nvidia binary > > driver). > > I can try to do so, too. I moved to nvidia from the nouveau because I had to disable acceleration on nouveau because of the graphics board in my Macbook Pro. Seemed to be a well known issue. Cheers, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]--- pgp7khZT734BW.pgp Description: PGP signature
Re: [arch-general] Still Glibc problems
On Fri, Jul 20, 2012 at 4:27 PM, D. R. Evans wrote: > Norbert Zeh said the following at 07/19/2012 06:08 PM : > >> >> Well, the filesystem instructions are older and applied at the time the glibc >> upgrade was not an issue yet. Combining the two instructions, I would guess >> the >> following should work: >> >> pacman -Syu --ignore filesystem --ignore glibc [and ignore any other >> packages that block the upgrade] >> pacman -S --force filesystem --ignore glibc >> pacman -Sd Looks good to me. > Incidentally, this is quite a long list. > https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest > that the list will contain only a few items, but the actual number is of the > order a couple of dozen packages. That's surprising that it is so many, however, it appears you haven't updated this system in some time which might explain that it is different to what most people are seeing. -t
Re: [arch-general] Still Glibc problems
On Fri, Jul 20, 2012 at 4:21 PM, D. R. Evans wrote: > There's nothing on this system that hasn't come from either AUR or the > official arch repositories, so I don't know why I'm having any problems at > all :-( I have seen people having problems because they installed packages from repos that they no longer have active (typically multilib), make sure to either remove any "stale" packages or re-enable any repos so you get all the most recent updates. Lastly, AUR is user-maintained so could contain anything at all (i.e. it is not surprising that they are causing problems). I'd suggest just removing all packages from the AUR for the time being, and once the update has succeeded you can reinstall them. -t
Re: [arch-general] Still Glibc problems
On Fri, Jul 20, 2012 at 12:13 PM, Guus Snijders wrote: > I'm a bit confused at this point if filesystem is now upgraded or not. > If i understand correctly, the symlinks for /var/run and /var/lock are > there already. You should always have the symlink, regardless of whether or not filesystem is up-to-date (read the news item again, it is explained there). The difference is that with the new filesystem package, the symlinks are owned by the package as they should be, rather than not having any owner at all. To check if your pacakge is up-to-date, you can simply do "pacman -Qi filesystem" and it will tell you. > If fileystem is not yet upgraded, what might just work is to restore > the previous state: > delete /var/run and /var/lock (the symlinks), re-create them as > directories and then install filesystem again. > That way the situation is exactly as filesystem expects and the > upgrade should go smoothly without --force. This seems wrong. Please re-read the filesystem news announcement. There should never be any reason to replace the symlinks by directories, that will not help at all. Notice that if you are in the situation that you have to force a filesystem upgrade, make sure you force only that, and nothing else (in particular not glibc). > I /think/ the same goes for glibc, although i'm not sure about that one. > If /lib is already a symlink but the package doesn't install, the > safest procedure would appear to be something like: > - boot from livecd > - mount the local filesystems > - delete the /lib symlink and create the /lib directory > - use pacmans's --root parameter to update glibc No point in creating a /lib directory. If you are booting from a live-cd, all you should have to do is: uninstall all pacakges that cause file-conflicts; delete (or move out of the way) all files that are not owned by any packages and cause file conflicts; install glibc; and finally reinstall whatever packages you had to remove (though if you had to remove them that probably means that there is something wrong with them, all official packages have been updated to not need removing). > Both are untested, though. I suggest to anyone who still have problems, to first try the guide on the wiki, if that does not work, find one of the guides on the forum (but first check that other commenters are confirming that they are correct). -t
Re: [arch-general] Still Glibc problems
Norbert Zeh said the following at 07/19/2012 06:08 PM : > > Well, the filesystem instructions are older and applied at the time the glibc > upgrade was not an issue yet. Combining the two instructions, I would guess > the > following should work: > > pacman -Syu --ignore filesystem --ignore glibc > pacman -S --force filesystem --ignore glibc > pacman -Sd Incidentally, this is quite a long list. https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib seems to suggest that the list will contain only a few items, but the actual number is of the order a couple of dozen packages. > pacman -Su > > Note that I did not try this, but it seems to be the logical combination of > the > two. Maybe one of the developers can chime in and confirm that this is the > right strategy. I am rather reticent to try something untested, especially when I see the --force option in use. So yes, PLEASE, can a developer address this issue so that I can have more confidence that I won't end up with a hosed system. (I am very puzzled as to why this is happening at all. This is not a system to which anything fancy has ever been done. If I'm having this problem, I don't know why lots of others aren't seeing it too.) Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
Re: [arch-general] Still Glibc problems
Guus Snijders said the following at 07/20/2012 04:13 AM : > > I'm a bit confused at this point if filesystem is now upgraded or not. Your confusion can't possibly be as great as mine :-) There's nothing on this system that hasn't come from either AUR or the official arch repositories, so I don't know why I'm having any problems at all :-( > If i understand correctly, the symlinks for /var/run and /var/lock are > there already. Yes. > > If fileystem is not yet upgraded, what might just work is to restore I don't know what you mean by "the filesystem is not yet upgraded". Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
Op vrijdag 20 juli 2012 16:11:43 schreef Lukáš Jirkovský: > On 20 July 2012 09:27, Ike Devolder wrote: > > could you try the same with the long lived branch of nvidia utils and > > drivers? > > > > these are at version 295.59 > > > > nvidia-ll: https://aur.archlinux.org/packages.php?ID`602 > > nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID`604 > > > > fist build utils, then driver > > > > --Ike > > nouveau or vesa would be probably even better, because this way we > could better track down what is causing it (kernel or nvidia binary > driver). > > Lukas Well in my case the suspend to ram problems are gone when using the long lived branch nvidia drivers, the new ones don't come back up --Ike signature.asc Description: This is a digitally signed message part.
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
On 20 July 2012 09:27, Ike Devolder wrote: > > could you try the same with the long lived branch of nvidia utils and drivers? > > these are at version 295.59 > > nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 > nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604 > > fist build utils, then driver > > --Ike nouveau or vesa would be probably even better, because this way we could better track down what is causing it (kernel or nvidia binary driver). Lukas
Re: [arch-general] Virtualbox-modules are again busted with new testing kernel
2012/7/20 Ionut Biru : > On 07/20/2012 01:56 PM, fredbezies wrote: >> Well, looks like Ionut Biru forget to rebuild virtualbox modules. Both >> vboxdrv and vboxnetflt cannot be loaded. >> >> A rebuild of virtualbox-modules fixed it :) >> > > I did not forget, Tobias just doesn't use staging and proper todo lists > to coordinate the rebuilds. > > -- > Ionuț > Bad Tobias so. Thanks for the rebuild ! -- Frederic Bezies fredbez...@gmail.com
Re: [arch-general] Updating AUR package with pacman
On Thu, Jul 19, 2012 at 6:44 PM, Thorsten Jolitz wrote: > Packer must be new somehow, did not hear about it before (only about > yaourt). The thread is 2.5 years old https://bbs.archlinux.org/viewtopic.php?id=88115 and the wiki https://wiki.archlinux.org/index.php/AUR_Helpers lists some other helpers too.
Re: [arch-general] Virtualbox-modules are again busted with new testing kernel
On 07/20/2012 01:56 PM, fredbezies wrote: > Well, looks like Ionut Biru forget to rebuild virtualbox modules. Both > vboxdrv and vboxnetflt cannot be loaded. > > A rebuild of virtualbox-modules fixed it :) > I did not forget, Tobias just doesn't use staging and proper todo lists to coordinate the rebuilds. -- Ionuț signature.asc Description: OpenPGP digital signature
[arch-general] Virtualbox-modules are again busted with new testing kernel
Well, looks like Ionut Biru forget to rebuild virtualbox modules. Both vboxdrv and vboxnetflt cannot be loaded. A rebuild of virtualbox-modules fixed it :) -- Frederic Bezies fredbez...@gmail.com
Re: [arch-general] Still Glibc problems
2012/7/20 David Benfell : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/19/12 16:42, D. R. Evans wrote: >> >> pacman -Syu --ignore filesystem && pacman -S filesystem --force >> >> >> >> and that gives: >> >> >> >> error: failed to commit transaction (conflicting files) glibc: /lib >> exists in filesystem Errors occurred, no packages were upgraded. >> >> >> > Somebody will need to clarify the precise syntax. But it looks to me > like you can't just ignore filesystem here; you also need to ignore > glibc, then--I think--do the glibc upgrade without the --force option > following the filesystem upgrade. I'm a bit confused at this point if filesystem is now upgraded or not. If i understand correctly, the symlinks for /var/run and /var/lock are there already. If fileystem is not yet upgraded, what might just work is to restore the previous state: delete /var/run and /var/lock (the symlinks), re-create them as directories and then install filesystem again. That way the situation is exactly as filesystem expects and the upgrade should go smoothly without --force. I /think/ the same goes for glibc, although i'm not sure about that one. If /lib is already a symlink but the package doesn't install, the safest procedure would appear to be something like: - boot from livecd - mount the local filesystems - delete the /lib symlink and create the /lib directory - use pacmans's --root parameter to update glibc Both are untested, though. On the bright side, i know from experience that it's fairly simple to completely reinstall Arch (had a bad HDD once). mvg, Guus
Re: [arch-general] haveged and Secure Cryptography
> Does anyone know if haveged significantly affects things like > truecrypt, cryptsetup, RSA, or SSL if you happen to leave the daemon > running for long periods of time? I'm sure that it's always going to > be "random enough", but I often make use of Archlinux in forensic > environments involving encrypted disks and files or transferring > things over SSL, so I do need to know if there is even a theoretical > weakness in my environment in case my tools and methodologies are > called into question. If your task uses /dev/random then it blocks on low entropy conditions. I believe that is the only time haveged fills the pool. So the question becomes If my device needs lots of entropy is haveged as strong or stronger than the Linux RNG and does or can haveged be made to collect randomness when idle. This fired across the android list recently and gives with it's references an idea of weaknesses in the Linux RNG. Were these weaknesses happening at times of pool exhaustion or generally, I wonder? https://factorable.net/paper.html OpenBSD a year or two ago actually made all their random devices link to the one because it incorporates haveged like functionality and more and with it's RC4 cipher multiplies it to hundreds of megabytes of good random data per second. -- Why not do something good every day and install BOINC.
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
On Fri, Jul 20, 2012 at 9:05 AM, Arvid Warnecke wrote: > When looking into /var/log/pm-suspend.log it seems that hibernating went > well: lots of "success" messages and no errors. But when I then start > the MacBook again it does not resume but boots normally. fsck detects > that disks haven't been unmounted orderly, recovers journal and I am > back to a fresh booted system then. I just have to ask: do you still have the "resume" hook and the related option in kernel command line? I remember this happening when I accidentally lost mine a few weeks earlier. -- Mantas Mikulėnas
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
Op vrijdag 20 juli 2012 08:05:33 schreef Arvid Warnecke: > Hello, > > I have already been used to not beeing able to suspend my MacBook Pro > since the buggy nvidia version which came with 3.4.x kernel. But as of > the latest updates which brought kernel 3.4.5-1 I am not able to use > pm-hibernate anymore. > When looking into /var/log/pm-suspend.log it seems that hibernating went > well: lots of "success" messages and no errors. But when I then start > the MacBook again it does not resume but boots normally. fsck detects > that disks haven't been unmounted orderly, recovers journal and I am > back to a fresh booted system then. > > I already looked up the wiki about pm-utils and found something about > adding 'acpi_sleep=nonvs' in /boot/grub/menu.lst. Issues mentioned there > with kernel versions around 2.6, which seems to be long time ago now. I > tried it anyway, but with no effect at all. > > Any ideas what might be causing this issue? More fresh bugs in nvidia > 302.17-3? > > TIA, > Arvid > > -- > [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] > [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] > ---[ ThreePiO was right: Let the Wookiee win. ]--- could you try the same with the long lived branch of nvidia utils and drivers? these are at version 295.59 nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604 fist build utils, then driver --Ike signature.asc Description: This is a digitally signed message part.
