Re: [arch-general] sudoers file change - not much on dev list - reason for changes?
On Wed, 2010-09-08 at 03:25 +0100, Mario Figueiredo wrote: I confess I'm baffled as to why upstream did this change, why it was needed and if it actually was needed. I can't seem to find anything about it in the online changelog either. Seems something completely arbitrary. Or an oversight. Or a mistake. I'm baffled by the fact that people make a huge issue about a comment for a possible configuration in /etc/sudoers. The change doesn't introduce anything, it just adds an example of something you could possibly implement. This is actually the same reason why I'm annoyed by bugreports that request a different order of comments or examples in the kernel26 PKGBUILD for configuration. IMHO we should just remove that completely and not care about such things, I mean... I don't add #add --enable-xcb to enable XCB in the cairo PKGBUILD either.
[arch-general] [signoff] xfsprogs-3.1.3-1
Hi bump to latest version, please signoff both arches, thanks 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] distributed bugtracking?
On Wed, Sep 8, 2010 at 22:48, Aaron Schaefer aa...@elasticdog.com wrote: On Wed, Sep 8, 2010 at 12:47 PM, Dieter Plaetinck die...@plaetinck.be wrote: anyone knows this? http://bugseverywhere.org/be/show/HomePage the concept looks great, although i don't know anything about the implementation/usage. There's quite a few things out there with this same idea: - Ditz (http://ditz.rubyforge.org/) - TicGit (http://wiki.github.com/schacon/ticgit/) - git-issues (http://github.com/jwiegley/git-issues) ...etc. I love the idea of distributed bug tracking, but haven't really messed around with too many of them myself to offer more of an opinion. They've been around for a while though. I've used BE for a tiny little project, but then it was more of a todo-list rather than a proper bugtracker. I'd love to hear from people who've used it in larger projects. As a personal, per-project todo-list manager it was all right. I'm just not still sure whether it should go into the project repo itself, or be standalone. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
Re: [arch-general] [arch-dev-public] [signoff] xz 4.999.9beta_174_g41bc-1
On 09.09.2010 11:55, Pierre Schmitz wrote:
this will hopefully the last update of xz for some time. :-) Maybe this
is a sign for the final 5.0 version to be near. I am now using the (very
strange) upstream versioning scheme.
That's just git describe.
tag-commits since tagged commit-last commit id (short format)
signoff x86_64
--
Florian Pritz -- {flo,bluewi...@server-speed.net
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] [signoff] xz 4.999.9beta_174_g41bc-1
On 9 September 2010 13:02, Florian Pritz bluew...@server-speed.net wrote:
On 09.09.2010 11:55, Pierre Schmitz wrote:
this will hopefully the last update of xz for some time. :-) Maybe this
is a sign for the final 5.0 version to be near. I am now using the (very
strange) upstream versioning scheme.
That's just git describe.
tag-commits since tagged commit-last commit id (short format)
signoff x86_64
--
Florian Pritz -- {flo,bluewi...@server-speed.net
Signoff i686
--
Guillaume
[arch-general] 'Local mirror' page was removed from wiki
Page Local mirros was removed from wiki by this reason: - It is generally frowned upon to create a local mirror due the bandwidth that is required. There is not a good reason to create a local mirror, since one of the alternatives below will likely meet your needs. - I think it's very useful ability, and why this page was removed... i don't know. It's silly. If anyone else think it must be return - maybe we should do it? P.S. A lot of guys agreed with me this morning, so i think many people want this article back. --
Re: [arch-general] [arch-dev-public] [signoff] xz 4 .999.9beta_174_g41bc-1
On Thu, 09 Sep 2010 13:02:02 +0200, Florian Pritz bluew...@server-speed.net wrote: On 09.09.2010 11:55, Pierre Schmitz wrote: this will hopefully the last update of xz for some time. :-) Maybe this is a sign for the final 5.0 version to be near. I am now using the (very strange) upstream versioning scheme. That's just git describe. tag-commits since tagged commit-last commit id (short format) Sure but I don't get why not creating just another tag here. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] 'Local mirror' page was removed from wiki
On Thu, Sep 9, 2010 at 3:40 PM, Fess killall_hum...@lavabit.com wrote: Page Local mirros was removed from wiki by this reason: - It is generally frowned upon to create a local mirror due the bandwidth that is required. There is not a good reason to create a local mirror, since one of the alternatives below will likely meet your needs. - I think it's very useful ability, and why this page was removed... i don't know. It's silly. If anyone else think it must be return - maybe we should do it? P.S. A lot of guys agreed with me this morning, so i think many people want this article back. -- I agree with the reasoning, I disagree with the content removal. : D
Re: [arch-general] 'Local mirror' page was removed from wiki
On Thu, 9 Sep 2010 15:55:35 +0300, Evangelos Foutras foutre...@gmail.com wrote: On Thu, Sep 9, 2010 at 3:40 PM, Fess killall_hum...@lavabit.com wrote: Page Local mirros was removed from wiki by this reason: - It is generally frowned upon to create a local mirror due the bandwidth that is required. There is not a good reason to create a local mirror, since one of the alternatives below will likely meet your needs. - I think it's very useful ability, and why this page was removed... i don't know. It's silly. If anyone else think it must be return - maybe we should do it? P.S. A lot of guys agreed with me this morning, so i think many people want this article back. -- I agree with the reasoning, I disagree with the content removal. : D See https://bbs.archlinux.org/viewtopic.php?id=103987 The original article was just wrong and causing us problems. Feel free to add an improved one. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] 'Local mirror' page was removed from wiki
On 09/09/10 14:11, Pierre Schmitz wrote: On Thu, 9 Sep 2010 15:55:35 +0300, Evangelos Foutras foutre...@gmail.com wrote: On Thu, Sep 9, 2010 at 3:40 PM, Fesskillall_hum...@lavabit.com wrote: Page Local mirros was removed from wiki by this reason: - It is generally frowned upon to create a local mirror due the bandwidth that is required. There is not a good reason to create a local mirror, since one of the alternatives below will likely meet your needs. - I think it's very useful ability, and why this page was removed... i don't know. It's silly. If anyone else think it must be return - maybe we should do it? P.S. A lot of guys agreed with me this morning, so i think many people want this article back. -- I agree with the reasoning, I disagree with the content removal. : D See https://bbs.archlinux.org/viewtopic.php?id=103987 The original article was just wrong and causing us problems. Feel free to add an improved one. If the script was broken or it caused problems it wouldn't hurt to state what these problems. Correct me if I'm something here but I have idea what these problems were. If the script caused problems then what stops someone creating their own script that works the same way? IMHO the text posted is likely worse than what was there before since it just makes a bunch of claims with no info.
Re: [arch-general] Pacman's superslow
On Wed, Sep 8, 2010 at 10:34 PM, Dan McGee dpmc...@gmail.com wrote: On Wed, Sep 8, 2010 at 11:57 AM, Nilesh Govindarajan li...@itech7.com wrote: I have an OpenVZ VPS running arch. For some reason pacman is superslow, and I'm not allowed to create/use loopback devices. pacman-optimize takes nearly 5 minutes per run, no matter the last run was just a minute ago. Unhelpful++ * Filesystem * Block device configuration * Total RAM, free -m output * uptime load avg numbers -Dan FS: Reiserfs (/dev/simfs / 30 GB usrquota grpquota) 512 MB RAM, normally only 256 used. Load Average ~ 1-5 (Instant) -- Regards, Nilesh Govindarajan Facebook: http://www.facebook.com/nilesh.gr Twitter: http://twitter.com/nileshgr Website: http://www.itech7.com VPS Hosting: http://www.itech7.com/a/vps
Re: [arch-general] Pacman's superslow
On Thu, Sep 9, 2010 at 8:43 AM, Nilesh Govindarajan li...@itech7.com wrote: On Wed, Sep 8, 2010 at 10:34 PM, Dan McGee dpmc...@gmail.com wrote: On Wed, Sep 8, 2010 at 11:57 AM, Nilesh Govindarajan li...@itech7.com wrote: I have an OpenVZ VPS running arch. For some reason pacman is superslow, and I'm not allowed to create/use loopback devices. pacman-optimize takes nearly 5 minutes per run, no matter the last run was just a minute ago. Unhelpful++ * Filesystem * Block device configuration * Total RAM, free -m output * uptime load avg numbers -Dan FS: Reiserfs (/dev/simfs / 30 GB usrquota grpquota) 512 MB RAM, normally only 256 used. Load Average ~ 1-5 (Instant) This is neither `free -m` output or `uptime` output. Buffers and cache values are important, thus the original request. At least I don't have time to debug issues when I don't get the *full* details I ask for. `df -h` would be good too, but I'm not going to waste my time here unless you offer some help and at least attempt to look into this on your own. With a load average between 1 and 5, I'm guessing you have several tasks high on disk I/O. I would recommend digging into `vmstat` and `iotop -o` output and doing debugging of your own. -Dan
Re: [arch-general] [PATCH 1/2] kill_everything: Reduce number of -f tests
Thomas Bächler tho...@archlinux.org wrote: Am 08.09.2010 06:16, schrieb Victor Lowther: On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisner d...@falconindy.com wrote: Instead of checking for the existance of a file in /var/run/daemons on every iteration, handle the null case by setting nullglob. The shopt call is done inside a subshell as to not bother the environment since we may be going to runlevel 1 only temporarily. I thought about just enabling nullglobs and extglobs unconditionally in functions, but decided that was too likely to get objections no matter how unlikely breakage was. :) As for nullglob, I do think it is useful and enabling it might be useful in so many places - I didn't even know this option, it would have been useful for me before. I am in favor of enabling nullglob in function and dropping that subshell. Sounds good to me - nullglob is useful in general, and enabling it should not break anything else in the initscripts package. Do we need extglob anywhere? I don't think so. I will take a look. -- Sent from my Nexus One with K-9 Mail. Please excuse my brevity.
Re: [arch-general] [arch-dev-public] The Great Python Rebuild of 2010 begins
On Thu, Sep 9, 2010 at 4:22 PM, Pierre Schmitz pie...@archlinux.de wrote:
On Sun, 29 Aug 2010 18:05:47 +0200, Pierre Schmitz
pie...@archlinux.de wrote:
On Mon, 30 Aug 2010 00:48:06 +1000, Allan McRae al...@archlinux.org
wrote:
Just a reminder for people to look at their packages and rebuild them
for this. We seem to of stalled majorly...
Do you think a community-staging would be helpful? I could commit the
needed changes to dbscripts and devtools; I'd like to do a new release
soon anyway.
FYI: support for community-staging was added to devtools 0.9.10 and
dbscripts.
--
Pierre Schmitz, https://users.archlinux.de/~pierre
That's great news. I made copies of my stable chroots for i686 and
x86_64 and enabled the {,community-}staging repos in them, per Ionuț's
suggestion. I'm guessing once the community-staging repository is
created on sigurd, we should be able to upload community rebuilds
there. Right?
Re: [arch-general] [PATCH 1/2] kill_everything: Reduce number of -f tests
On 09/09/10 16:19, Victor Lowther wrote: Thomas Bächlertho...@archlinux.org wrote: Am 08.09.2010 06:16, schrieb Victor Lowther: On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisnerd...@falconindy.com wrote: Instead of checking for the existance of a file in /var/run/daemons on every iteration, handle the null case by setting nullglob. The shopt call is done inside a subshell as to not bother the environment since we may be going to runlevel 1 only temporarily. I thought about just enabling nullglobs and extglobs unconditionally in functions, but decided that was too likely to get objections no matter how unlikely breakage was. :) As for nullglob, I do think it is useful and enabling it might be useful in so many places - I didn't even know this option, it would have been useful for me before. I am in favor of enabling nullglob in function and dropping that subshell. Sounds good to me - nullglob is useful in general, and enabling it should not break anything else in the initscripts package. Do we need extglob anywhere? I don't think so. I will take a look. I don't see anywhere in the initscripts that has this issue but you might want to take a look at dotglob for the future, because with nullglob you break the behaviour of commands that work like ls. i.e `ls *.ext` etc. would result in ls being passed an argument '*.ext' in the event that *.ext doesn't match anything. With nullglob set, no argument gets passed and you end up with just `ls` which is likely to cause subtle bugs.
Re: [arch-general] Pacman's superslow
Okay, sorry about that. Here's the relevant stuff: uptime: 22:04:53 up 26 days, 17:16, 1 user, load average: 0.03, 0.01, 0.00 Now it doesn't seem to touch even 1. free -m: total used free sharedbuffers cached Mem: 512251260 0 0 0 -/+ buffers/cache:251260 Swap:0 0 0 df -h: FilesystemSize Used Avail Use% Mounted on /dev/simfs 30G 11G 20G 37% / udev 10M 8.0K 10M 1% /dev none 256M 0 256M 0% /dev/shm -- Regards, Nilesh Govindarajan Facebook: http://www.facebook.com/nilesh.gr Twitter: http://twitter.com/nileshgr Website: http://www.itech7.com VPS Hosting: http://www.itech7.com/a/vps
Re: [arch-general] [arch-dev-public] The Great Python Rebuild of 2010 begins
On Thu, 9 Sep 2010 18:57:18 +0300, Evangelos Foutras
foutre...@gmail.com wrote:
On Thu, Sep 9, 2010 at 4:22 PM, Pierre Schmitz pie...@archlinux.de wrote:
On Sun, 29 Aug 2010 18:05:47 +0200, Pierre Schmitz
pie...@archlinux.de wrote:
On Mon, 30 Aug 2010 00:48:06 +1000, Allan McRae al...@archlinux.org
wrote:
Just a reminder for people to look at their packages and rebuild them
for this. We seem to of stalled majorly...
Do you think a community-staging would be helpful? I could commit the
needed changes to dbscripts and devtools; I'd like to do a new release
soon anyway.
FYI: support for community-staging was added to devtools 0.9.10 and
dbscripts.
--
Pierre Schmitz, https://users.archlinux.de/~pierre
That's great news. I made copies of my stable chroots for i686 and
x86_64 and enabled the {,community-}staging repos in them, per Ionuț's
suggestion.
Or you could just use staging-i686-build which comes with devtools.
I'm guessing once the community-staging repository is
created on sigurd, we should be able to upload community rebuilds
there. Right?
Someone also needs to adjust the cron job that syncs the repo from
sigurd to gerolde.
--
Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] [PATCH 1/2] kill_everything: Reduce number of -f tests
Nathan Wayde kum...@konnichi.com wrote: On 09/09/10 16:19, Victor Lowther wrote: Thomas Bächlertho...@archlinux.org wrote: Am 08.09.2010 06:16, schrieb Victor Lowther: On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisnerd...@falconindy.com wrote: Instead of checking for the existance of a file in /var/run/daemons on every iteration, handle the null case by setting nullglob. The shopt call is done inside a subshell as to not bother the environment since we may be going to runlevel 1 only temporarily. I thought about just enabling nullglobs and extglobs unconditionally in functions, but decided that was too likely to get objections no matter how unlikely breakage was. :) As for nullglob, I do think it is useful and enabling it might be useful in so many places - I didn't even know this option, it would have been useful for me before. I am in favor of enabling nullglob in function and dropping that subshell. Sounds good to me - nullglob is useful in general, and enabling it should not break anything else in the initscripts package. Do we need extglob anywhere? I don't think so. I will take a look. I don't see anywhere in the initscripts that has this issue but you might want to take a look at dotglob for the future, because with nullglob you break the behaviour of commands that work like ls. i.e `ls *.ext` etc. would result in ls being passed an argument '*.ext' in the event that *.ext doesn't match anything. With nullglob set, no argument gets passed and you end up with just `ls` which is likely to cause subtle bugs. Sounds like another reason to never parse the output of ls in a shell script ( not that I needed more). -- Sent from my Nexus One with K-9 Mail. Please excuse my brevity.
[arch-general] [PATCH] Remove 'Add your preferred servers here' comments
These comments were removed from the default pacman.conf, so let's remove them from these default configuration files as well. --- pacman-extra.conf|5 - pacman-multilib.conf |6 -- pacman-staging.conf |7 --- pacman-testing.conf |5 - 4 files changed, 0 insertions(+), 23 deletions(-) diff --git a/pacman-extra.conf b/pacman-extra.conf index 911c23d..3a5d875 100644 --- a/pacman-extra.conf +++ b/pacman-extra.conf @@ -58,23 +58,18 @@ Architecture = auto # after the header, and they will be used before the default mirrors. #[testing] -## Add your preferred servers here, they will be used first #Include = /etc/pacman.d/mirrorlist [core] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [extra] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist #[community-testing] -## Add your preferred servers here, they will be used first #Include = /etc/pacman.d/mirrorlist [community] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist # An example of a custom package repository. See the pacman manpage for diff --git a/pacman-multilib.conf b/pacman-multilib.conf index 7e0f1d7..8dfd584 100644 --- a/pacman-multilib.conf +++ b/pacman-multilib.conf @@ -58,27 +58,21 @@ Architecture = auto # after the header, and they will be used before the default mirrors. #[testing] -## Add your preferred servers here, they will be used first #Include = /etc/pacman.d/mirrorlist [core] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [extra] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist #[community-testing] -## Add your preferred servers here, they will be used first #Include = /etc/pacman.d/mirrorlist [community] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [multilib] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist # An example of a custom package repository. See the pacman manpage for diff --git a/pacman-staging.conf b/pacman-staging.conf index 14323d5..f015e63 100644 --- a/pacman-staging.conf +++ b/pacman-staging.conf @@ -58,31 +58,24 @@ Architecture = auto # after the header, and they will be used before the default mirrors. [staging] -## Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [testing] -## Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [core] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [extra] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [community-staging] -## Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [community-testing] -## Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [community] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist # An example of a custom package repository. See the pacman manpage for diff --git a/pacman-testing.conf b/pacman-testing.conf index 048e4f7..910e0bc 100644 --- a/pacman-testing.conf +++ b/pacman-testing.conf @@ -58,23 +58,18 @@ Architecture = auto # after the header, and they will be used before the default mirrors. [testing] -## Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [core] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [extra] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [community-testing] -## Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist [community] -# Add your preferred servers here, they will be used first Include = /etc/pacman.d/mirrorlist # An example of a custom package repository. See the pacman manpage for -- 1.7.2.3
[arch-general] IRC OPs
HI, Is it possible an IRC OP can contact me off list? Cheers Callum
Re: [arch-general] IRC OPs
On 09/09/2010 10:09 PM, Callum Scott wrote: HI, Is it possible an IRC OP can contact me off list? Cheers Callum sure, what's up? -- Ionuț
[arch-general] Removing HAL
Hi list. Few days ago I've succesfully installed arch. It was booting really fast first time (i.e. without gnome, networkmanager, etc). After installing GNOME and some daemons, adding them to the rc.conf, the system now takes 30-40 seconds to load. I heard that HAL daemon takes a lot of time during boot and it's functionality can be replaced by udev. How could I completely remove HAL and still use GNOME without troubles? Is it possible? I have: - GNOME 2.30 - xorg 1.8 - hal 0.5 -- 2b || !2b
