Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On Tue, Jun 7, 2011 at 11:47 PM, Tom Gundersen t...@jklm.no wrote: I didn't mention this explicitly, as this upgrade is not supposed to remove net-tools, so in principle ifconfig should still work. Maybe this should be added to the announcement (the fact that net-tools will still be there). -- Cédric Girard
Re: [arch-general] [signoff] kernel26-lts 2.6.32.41-2
Am Dienstag 07 Juni 2011 schrieb Tobias Powalowski: Latest LTS kernel is in testing, please signoff for both arches - synced with .39 config and enabled the ftracers https://bugs.archlinux.org/task/24404 greetings tpowa anynone? -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
[arch-general] [signoff] jfsutils-1.1.15-1
New in 1.1.15 - 2011-03-04 * Several fixes for large filesystems where 64-bit variables are needed * Fix incorrect size check on directories * Make the timestamp format consisten Please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On 07-06-2011 22:46, Patrick Burroughs wrote: The new replacement for ifconfig is 'ip'; 'ip link show' is equivalent to the old 'ifconfig', without arguments. I don't see the current assigned IP when doing 'ip link show' so I don't see how that is equivalent to using only ifconfig without arguments. As a side note, at first glance it seems 'ip' needs a lot more typing than ifconfig needs, at least for the stuff I use more often. -- Mauro Santos
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On 06/08/11 at 02:30pm, Mauro Santos wrote: On 07-06-2011 22:46, Patrick Burroughs wrote: The new replacement for ifconfig is 'ip'; 'ip link show' is equivalent to the old 'ifconfig', without arguments. I don't see the current assigned IP when doing 'ip link show' so I don't see how that is equivalent to using only ifconfig without arguments. 'ip addr show' is the command you want. -- Byron Clark
Re: [arch-general] Reboot - Versioned Kernel Installs
I would really like to the kernel that is being replaced kept as a backup. If the latest kernel breaks your hardware, or something else goes wrong, I'd like to have the option of using the kernel that was just replaced, because it's known to work. I wouldn't want more than one old version of the kernel, though. Also, although the -lts kernel is good for this, it isn't intended to solve this problem, and isn't always a perfect fit. For instance, my new laptop has UEFI-related issues that are only being addressed in the *very* latest kernels. I'm not sure -lts would boot for me, but I know that my *current* kernel boots; seems a pity to throw it out it straight away on upgrade, before I can test that the new kernel boots OK... Paul On Monday 06 June 2011 18:23:50 Tom Gundersen wrote: On Mon, Jun 6, 2011 at 6:22 PM, Tavian Barnes taviana...@tavianator.com wrote: I have kernel26-lts installed as a backup kernel, and this is all that's really necessary for rolling back broken kernel updates. I've been bitten by a BTRFS bug once and rolled back with -lts no problem. -1 from me on keeping multiple kernel versions installed; I really like that arch doesn't keep 6 old kernels around. I agree. The reason I am against keeping old kernels around is that we would not be able to test user space against all the possible combinations, so it would not be a good idea to suggest that we do (we do try to support all sorts of self-compiled kernels, but at least if you compile your own kernel it is pretty obvious that it will not be as well tested as the official ones). One possibility would be to do like upstream does and always rename the previous kernel to .old. That should keep the last known working kernel around while making it clear that it should not be relied on for day-to-day use (and that it will get overwritten on the next kernel upgrade so these things won't get old). That said, I'm not involved with packaging the kernel, so if you want anything to change with how it is packaged (maybe after this discussion is over), it would be best to file a feature request on FS. Cheers, Tom
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On 06/08/2011 01:41 AM, Tom Gundersen wrote: Yes, documentation should be updated. Help with this is very much appreciated! I will personally start working on this once the release is out (time permitting). Hey Tom, what help do you need with the documentation?
Re: [arch-general] Reboot - Versioned Kernel Installs
On 06/08/2011 04:12 PM, Paul Gideon Dann wrote: I would really like to the kernel that is being replaced kept as a backup. If the latest kernel breaks your hardware, or something else goes wrong, I'd like to have the option of using the kernel that was just replaced, because it's known to work. I wouldn't want more than one old version of the kernel, though. Also, although the -lts kernel is good for this, it isn't intended to solve this problem, and isn't always a perfect fit. For instance, my new laptop has UEFI-related issues that are only being addressed in the *very* latest kernels. I'm not sure -lts would boot for me, but I know that my *current* kernel boots; seems a pity to throw it out it straight away on upgrade, before I can test that the new kernel boots OK... Paul If you want this, implement it! I have seen some discussions about it and it always tend to users wanting feature X or Y, but didn't commit to it. protip: iirc there are some threads about this on the mailing list, the forums and the bugtracker, start gathering info there. good luck! On Monday 06 June 2011 18:23:50 Tom Gundersen wrote: On Mon, Jun 6, 2011 at 6:22 PM, Tavian Barnestaviana...@tavianator.com wrote: I have kernel26-lts installed as a backup kernel, and this is all that's really necessary for rolling back broken kernel updates. I've been bitten by a BTRFS bug once and rolled back with -lts no problem. -1 from me on keeping multiple kernel versions installed; I really like that arch doesn't keep 6 old kernels around. I agree. The reason I am against keeping old kernels around is that we would not be able to test user space against all the possible combinations, so it would not be a good idea to suggest that we do (we do try to support all sorts of self-compiled kernels, but at least if you compile your own kernel it is pretty obvious that it will not be as well tested as the official ones). One possibility would be to do like upstream does and always rename the previous kernel to .old. That should keep the last known working kernel around while making it clear that it should not be relied on for day-to-day use (and that it will get overwritten on the next kernel upgrade so these things won't get old). That said, I'm not involved with packaging the kernel, so if you want anything to change with how it is packaged (maybe after this discussion is over), it would be best to file a feature request on FS. Cheers, Tom -- Jelle van der Waa
Re: [arch-general] Reboot - Versioned Kernel Installs
On Wed, Jun 8, 2011 at 4:41 PM, Jelle van der Waa je...@vdwaa.nl wrote: On 06/08/2011 04:12 PM, Paul Gideon Dann wrote: I would really like to the kernel that is being replaced kept as a backup. If the latest kernel breaks your hardware, or something else goes wrong, I'd like to have the option of using the kernel that was just replaced, because it's known to work. I wouldn't want more than one old version of the kernel, though. Also, although the -lts kernel is good for this, it isn't intended to solve this problem, and isn't always a perfect fit. For instance, my new laptop has UEFI-related issues that are only being addressed in the *very* latest kernels. I'm not sure -lts would boot for me, but I know that my *current* kernel boots; seems a pity to throw it out it straight away on upgrade, before I can test that the new kernel boots OK... Paul If you want this, implement it! I have seen some discussions about it and it always tend to users wanting feature X or Y, but didn't commit to it. protip: iirc there are some threads about this on the mailing list, the forums and the bugtracker, start gathering info there. Implementing this should be almost trivial, it's just a patch to kernel26.install. I think if someone wants to see this feature, the best way would be to post a patch to arch-proje...@archlinux.org. -t
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On Wed, Jun 8, 2011 at 3:30 PM, Mauro Santos registo.maill...@gmail.com wrote: On 07-06-2011 22:46, Patrick Burroughs wrote: The new replacement for ifconfig is 'ip'; 'ip link show' is equivalent to the old 'ifconfig', without arguments. I don't see the current assigned IP when doing 'ip link show' so I don't see how that is equivalent to using only ifconfig without arguments. As a side note, at first glance it seems 'ip' needs a lot more typing than ifconfig needs, at least for the stuff I use more often. You should use just use ip addr rather than ifconfig (which saves you one character ;-) ). -t
Re: [arch-general] Reboot - Versioned Kernel Installs
On Wednesday 08 June 2011 15:45:21 Tom Gundersen wrote: On Wed, Jun 8, 2011 at 4:41 PM, Jelle van der Waa je...@vdwaa.nl wrote: If you want this, implement it! I have seen some discussions about it and it always tend to users wanting feature X or Y, but didn't commit to it. protip: iirc there are some threads about this on the mailing list, the forums and the bugtracker, start gathering info there. Implementing this should be almost trivial, it's just a patch to kernel26.install. I think if someone wants to see this feature, the best way would be to post a patch to arch-proje...@archlinux.org. That's true; I'll try to find some time to do this in the next week or so, if someone doesn't beat me to it. I was just expecting to contribute to the discussion regarding the best way to deal with kernel upgrades, but if you think this patch would be accepted, I'd be happy to provide it. Paul
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On Wed, Jun 8, 2011 at 4:17 PM, mangust m4ng...@gmail.com wrote: On 06/08/2011 01:41 AM, Tom Gundersen wrote: Yes, documentation should be updated. Help with this is very much appreciated! I will personally start working on this once the release is out (time permitting). Hey Tom, what help do you need with the documentation? Thanks for offering to help! We should find the places in the wiki that suggest using the old net-tools configuration options in rc.conf, and see if the use-cases they are describing can be replaced by our new syntax, or by upgrading to netcfg. If so, we should update the documentation to reflect this. Otherwise, we leave it as it is, as net-tools will still be supported. Possibly, we should add a comment that net-tools needs to be installed for it to work. Cheers, Tom
Re: [arch-general] Reboot - Versioned Kernel Installs
On Wed, Jun 8, 2011 at 4:54 PM, Paul Gideon Dann pdgid...@gmail.com wrote: On Wednesday 08 June 2011 15:45:21 Tom Gundersen wrote: On Wed, Jun 8, 2011 at 4:41 PM, Jelle van der Waa je...@vdwaa.nl wrote: If you want this, implement it! I have seen some discussions about it and it always tend to users wanting feature X or Y, but didn't commit to it. protip: iirc there are some threads about this on the mailing list, the forums and the bugtracker, start gathering info there. Implementing this should be almost trivial, it's just a patch to kernel26.install. I think if someone wants to see this feature, the best way would be to post a patch to arch-proje...@archlinux.org. That's true; I'll try to find some time to do this in the next week or so, if someone doesn't beat me to it. I was just expecting to contribute to the discussion regarding the best way to deal with kernel upgrades, but if you think this patch would be accepted, I'd be happy to provide it. Cool! I'd be in favor of the patch, but I don't know if it will be accepted (I'm not the maintainer). At least you'll get the attention of the right people :) -t
[arch-general] pacman tries to install nvidia drivers?
Hello all, I don't have an nvidia graphics card: $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) Yet when I try to update (with -Syyu just to be sure), I get: $ sudo pacman -Syyu :: Synchronising package databases... core 37.9K 96.0K/s 00:00:00 [##] 100% extra 469.7K 855.7K/s 00:00:01 [##] 100% community 439.4K3.6M/s 00:00:00 [##] 100% multilib 25.0K 888.7K/s 00:00:00 [##] 100% :: Starting full system upgrade... resolving dependencies... warning: dependency cycle detected: warning: lib32-gcc-libs will be installed before its gcc-libs-multilib dependency looking for inter-conflicts... :: nvidia-utils and libgl are in conflict. Remove libgl? [y/N] y error: failed to prepare transaction (could not satisfy dependencies) :: intel-dri: requires libgl=7.10.2 Why does pacman try to install nvidia-utils for me? I have intel-dri installed and my graphics work fine. I assume the dependency cycle is unrelated... Thanks, John K Pate http://homepages.inf.ed.ac.uk/s0930006/ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: [arch-general] pacman tries to install nvidia drivers?
On 06/08/2011 06:43 PM, John K Pate wrote: Hello all, Why does pacman try to install nvidia-utils for me? I have intel-dri installed and my graphics work fine. I assume the dependency cycle is unrelated... Thanks, maybe https://bugs.archlinux.org/task/24608 ? -- Ionuț
Re: [arch-general] pacman tries to install nvidia drivers?
On 06/08/2011 05:43 PM, John K Pate wrote: Hello all, I don't have an nvidia graphics card: $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) Yet when I try to update (with -Syyu just to be sure), I get: $ sudo pacman -Syyu :: Synchronising package databases... core 37.9K 96.0K/s 00:00:00 [##] 100% extra 469.7K 855.7K/s 00:00:01 [##] 100% community 439.4K3.6M/s 00:00:00 [##] 100% multilib 25.0K 888.7K/s 00:00:00 [##] 100% :: Starting full system upgrade... resolving dependencies... warning: dependency cycle detected: warning: lib32-gcc-libs will be installed before its gcc-libs-multilib dependency looking for inter-conflicts... :: nvidia-utils and libgl are in conflict. Remove libgl? [y/N] y error: failed to prepare transaction (could not satisfy dependencies) :: intel-dri: requires libgl=7.10.2 Why does pacman try to install nvidia-utils for me? I have intel-dri installed and my graphics work fine. I assume the dependency cycle is unrelated... Thanks, John K Pate http://homepages.inf.ed.ac.uk/s0930006/ Probably this bug https://bugs.archlinux.org/task/24608 -- Jelle van der Waa
Re: [arch-general] pacman tries to install nvidia drivers?
Probably this bug https://bugs.archlinux.org/task/24608 Oh yes, it's exactly that. I removed luxrender (which I've ended up not using) and the update goes through fine. Thanks, John K Pate http://homepages.inf.ed.ac.uk/s0930006/ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On Wed, Jun 8, 2011 at 4:54 PM, Tom Gundersen t...@jklm.no wrote: You should use just use ip addr rather than ifconfig (which saves you one character ;-) ). No both can be 5 keystrokes: ipspaceatab ifcotab Yes this message was completely unuseful! :p -- Cédric Girard
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
Tom Gundersen (2011-06-08 16:54): On Wed, Jun 8, 2011 at 3:30 PM, Mauro Santos registo.maill...@gmail.com wrote: On 07-06-2011 22:46, Patrick Burroughs wrote: The new replacement for ifconfig is 'ip'; 'ip link show' is equivalent to the old 'ifconfig', without arguments. I don't see the current assigned IP when doing 'ip link show' so I don't see how that is equivalent to using only ifconfig without arguments. As a side note, at first glance it seems 'ip' needs a lot more typing than ifconfig needs, at least for the stuff I use more often. You should use just use ip addr rather than ifconfig (which saves you one character ;-) ). -t Or, rather, ip a for addreses and link status (like /sbin/ifconfig) ip r for routes (like /sbin/route) -- -- Rogutės Sparnuotos
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On 9 June 2011 01:57, Rogutės Sparnuotos rogu...@googlemail.com wrote: Or, rather, ip a for addreses and link status (like /sbin/ifconfig) ip r for routes (like /sbin/route) Nice. If only it displayed RX/TX bytes as well, I would totally not miss ifconfig. :) (*Secretly hopes that someone will point out how this is done.* :3)
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On 8 June 2011 20:13, Evangelos Foutras foutre...@gmail.com wrote: On 9 June 2011 01:57, Rogutės Sparnuotos rogu...@googlemail.com wrote: Or, rather, ip a for addreses and link status (like /sbin/ifconfig) ip r for routes (like /sbin/route) Nice. If only it displayed RX/TX bytes as well, I would totally not miss ifconfig. :) (*Secretly hopes that someone will point out how this is done.* :3) Actually wait, it does that with 'ip -s link'. :p However, I would prefer a more human-friendly output (e.g. in MiB/GiB/etc. instead of just bytes).
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On 06/08/2011 04:57 PM, Tom Gundersen wrote: On Wed, Jun 8, 2011 at 4:17 PM, mangust m4ng...@gmail.com wrote: On 06/08/2011 01:41 AM, Tom Gundersen wrote: Yes, documentation should be updated. Help with this is very much appreciated! I will personally start working on this once the release is out (time permitting). Hey Tom, what help do you need with the documentation? Thanks for offering to help! We should find the places in the wiki that suggest using the old net-tools configuration options in rc.conf, and see if the use-cases they are describing can be replaced by our new syntax, or by upgrading to netcfg. If so, we should update the documentation to reflect this. Otherwise, we leave it as it is, as net-tools will still be supported. Possibly, we should add a comment that net-tools needs to be installed for it to work. Cheers, Tom No problem! I'll search the Wiki for this information and will update it. Cheers, mangust
Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
On Wed, Jun 8, 2011 at 7:33 PM, mangust m4ng...@gmail.com wrote: On 06/08/2011 04:57 PM, Tom Gundersen wrote: On Wed, Jun 8, 2011 at 4:17 PM, mangust m4ng...@gmail.com wrote: On 06/08/2011 01:41 AM, Tom Gundersen wrote: Yes, documentation should be updated. Help with this is very much appreciated! I will personally start working on this once the release is out (time permitting). Hey Tom, what help do you need with the documentation? Thanks for offering to help! We should find the places in the wiki that suggest using the old net-tools configuration options in rc.conf, and see if the use-cases they are describing can be replaced by our new syntax, or by upgrading to netcfg. If so, we should update the documentation to reflect this. Otherwise, we leave it as it is, as net-tools will still be supported. Possibly, we should add a comment that net-tools needs to be installed for it to work. Cheers, Tom No problem! I'll search the Wiki for this information and will update it. Great! Thanks! -t
Re: [arch-general] Reboot - Versioned Kernel Installs
On Wed, Jun 8, 2011 at 11:00 PM, Tom Gundersen t...@jklm.no wrote: On Wed, Jun 8, 2011 at 4:54 PM, Paul Gideon Dann pdgid...@gmail.com wrote: On Wednesday 08 June 2011 15:45:21 Tom Gundersen wrote: On Wed, Jun 8, 2011 at 4:41 PM, Jelle van der Waa je...@vdwaa.nl wrote: If you want this, implement it! I have seen some discussions about it and it always tend to users wanting feature X or Y, but didn't commit to it. protip: iirc there are some threads about this on the mailing list, the forums and the bugtracker, start gathering info there. Implementing this should be almost trivial, it's just a patch to kernel26.install. I think if someone wants to see this feature, the best way would be to post a patch to arch-proje...@archlinux.org. That's true; I'll try to find some time to do this in the next week or so, if someone doesn't beat me to it. I was just expecting to contribute to the discussion regarding the best way to deal with kernel upgrades, but if you think this patch would be accepted, I'd be happy to provide it. Cool! I'd be in favor of the patch, but I don't know if it will be accepted (I'm not the maintainer). At least you'll get the attention of the right people :) -t Such a patch would also have to copy the modules (which aren't under kernel26's 'purview'). For example, nvidia gets upgraded on a major version kernel update, the old kernel which has been renamed doesn't 'work' graphically anymore.
Re: [arch-general] Reboot - Versioned Kernel Installs
Am Thu, 9 Jun 2011 06:36:08 +0800 schrieb Oon-Ee Ng ngoonee.t...@gmail.com: Such a patch would also have to copy the modules (which aren't under kernel26's 'purview'). For example, nvidia gets upgraded on a major version kernel update, the old kernel which has been renamed doesn't 'work' graphically anymore. Just for keeping an old kernel image as a fallback keeping the modules, too, isn't necessary. The old kernel image is just to get the system booted to being able to repair the system (downgrading the kernel package again or whatever). The modules shouldn't be necessary for this. Nevertheless I would suggest not to keeping an old kernel version when upgrading the kernel. I'm using Arch Linux for about 4 years now and before then I was using Gentoo for about 6 years. I never had one single issue with a kernel upgrade particularly not such an issue which caused a boot failure. If this really happens - in the very rare cases - then it's always possible to boot from a LiveCD. If someone is really so afraid he can easily install kernel26-lts or another kernel package and, of course, he definitely shouldn't use the [testing] repo. I don't see a real reason for keeping an old kernel image after an update. Just KISS. Heiko
[arch-general] Reporting for [extra] packages?
Hi, I need to file a bug against unison, which is in the extra repo, and was wondering whether I just put it under Arch Linux or perhaps Community Packages in the bug tracker? Cheers. P.S. It looks like it was compiled with the testing repo enabled: % unison --help unison: /lib/libc.so.6: version `GLIBC_2.14' not found (required by unison) -- Simon Perry (aka Pezz)
Re: [arch-general] Reporting for [extra] packages?
On 9 June 2011 04:03, Simon Perry a...@sanxion.net wrote: Hi, I need to file a bug against unison, which is in the extra repo, and was wondering whether I just put it under Arch Linux or perhaps Community Packages in the bug tracker? Arch Linux is the correct project to file this bug under. Community Packages is used exclusively for packages in [community].
Re: [arch-general] Reporting for [extra] packages?
On 09/06/11, Evangelos Foutras wrote: | Arch Linux is the correct project to file this bug under. Community | Packages is used exclusively for packages in [community]. Thanks mate, bug created. I've now noticed that when filling out a report you can select the extra repo when classifying the report. :) -- Simon Perry (aka Pezz)
[arch-general] network error empathy
Hi everybody I have trouble connecting to msn through empathy, the other protocols work fine (msn irc facebook), when trying to connect network error. If someone could help me, thanx from Colombia -- Carlos Alberto Ospina E. Linux User #506652
