Is there no maintaince on udev anymore?

On Tue, 26 Aug 2008 13:27:32 -0700, Xavier wrote:

On Tue, Aug 26, 2008 at 6:46 PM, Amanai wrote:

...

Is there no maintaince on udev anymore?

Could you be even more obscure?

Are you simply referring to the fact that udev 119 is outdated? Did you at least try the latest version on your system and can confirm it works? And what are the advantages of the latest release? And do you have problems with the current packaged version? If so, which ones?

I hope you can answer all these questions, which should have been present in your original mail ...

I was just wondering, it is outdated and I didn't see any udev release updates anymore. That's all. There is no problem with the latest version, it works. Does Archlinux not try to be always up to date, soon us possible?

On Tue, Aug 26, 2008 at 10:35 PM, Amanai wrote:

I was just wondering, it is outdated and I didn't see any udev release updates anymore. That's all.

There is no problem with the latest version, it works.

Cool, so what is so exciting in the latest version?

On Tue, Aug 26, 2008 at 10:49 PM, Roman Kyrylych wrote:

I wouldn't say there are *exciting* changes (these are rare for this type of software) but here are the latest changes v125 - http://lwn.net/Articles/291028/ v126 - http://lwn.net/Articles/292596/

I think udev wasn't updated mostly because Tobias who used to maintain it took vacation from Arch to enjoy the life. So not having new versions of udev is temporary.

Thanks for the link. The arch version is actually 119, so the previous changes could be of interest too : http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog

On Tue, Aug 26, 2008 at 3:35 PM, Amanai wrote:

On Tue, 26 Aug 2008 13:27:32 -0700, Xavier wrote:

...

On Tue, Aug 26, 2008 at 6:46 PM, Amanai wrote:

...

Is there no maintaince on udev anymore?

Could you be even more obscure?

Are you simply referring to the fact that udev 119 is outdated? Did you at least try the latest version on your system and can confirm it works? And what are the advantages of the latest release? And do you have problems with the current packaged version? If so, which ones?

I hope you can answer all these questions, which should have been present in your original mail ...

I was just wondering, it is outdated and I didn't see any udev release updates anymore. That's all.

There is no problem with the latest version, it works. Does Archlinux not try to be always up to date, soon us possible?

This is my fault. I grabbed maintainership of udev when Tobias took a vacation, and real life has hit me like a sack of bricks, so I have little time these days to do much. This Wed afternoon I plan on running through all my outdated packages and updating them. I will make udev a priority. Cheers, Aaron

On Wed, Aug 27, 2008 at 3:30 PM, Thomas Bächler wrote:

Aaron Griffin schrieb:

...

On Tue, Aug 26, 2008 at 3:35 PM, Amanai wrote:

...

On Tue, 26 Aug 2008 13:27:32 -0700, Xavier wrote:

...

On Tue, Aug 26, 2008 at 6:46 PM, Amanai wrote:

...

Is there no maintaince on udev anymore?

This is my fault. I grabbed maintainership of udev when Tobias took a vacation, and real life has hit me like a sack of bricks, so I have little time these days to do much.

This Wed afternoon I plan on running through all my outdated packages and updating them. I will make udev a priority.

Cheers, Aaron

Udev is a ton of work. Right now, we use a mix of udev upstream rules and our own rules, and we should probably switch to upstream rules as much as possible. But that means lots of testing and stuff and lots of reading rules and see if they are right for Arch. And of course, updating klibc-udev to the same state as udev. I wanted to do it once, then didn't have the time.

Basically, that's why the faster the better. I could be a tester if there is one to test.

On Thu, Aug 28, 2008 at 6:30 PM, Xavier wrote:

Missing Makedepends --------------------- xosd --> 'xmms' flac --> 'xmms'

Repo Hierarchy for Makedepends -------------------------------- core/iputils depends on extra/jade core/madwifi-utils depends on extra/sharutils core/e2fsprogs depends on extra/bc core/ca-certificates depends on extra/ruby core/madwifi depends on extra/sharutils

I just read one comment from Thomas : http://bugs.archlinux.org/task/6841#comment32155 Is it fine for core package to have makedepends in extra? What about extra and community (the xmms makedepends above)? The second would mean core and extra repos can't be checked properly on their own..

Circular Dependencies ----------------------- glibc>bash>readline>ncurses>glibc db>coreutils>shadow>pam>db eclipse-ecj>gcc-gcj>eclipse-ecj

What about this, are cycles accepted too? There is also a bug report for that : FS#9177 Especially the glibc->bash dep does not make sense. For scriptlet to work properly, you need to have a base system installed anyway .. I don't know enough about the other packages to tell which other deps are questionable.

On Fri, 29 Aug 2008, bardo wrote:

On Fri, Aug 29, 2008 at 4:01 PM, Xavier wrote:

...

I just read one comment from Thomas : http://bugs.archlinux.org/task/6841#comment32155

Is it fine for core package to have makedepends in extra? What about extra and community (the xmms makedepends above)? The second would mean core and extra repos can't be checked properly on their own..

Another related BR is http://bugs.archlinux.org/task/10930, which Roman closed this morning.

So this in fact means that official repos are hierarchical: core -> extra -> community. I have to make clear I have no problems with it, I just want a confirmation. As far as I knew the difference between extra and community (excluding the obvious package popularity) was only in the maintainers. If this is true, then there's no problem for cross dependencies between extra and community, but it seems I was wrong.

My opinion is that core should be completely independent from the rest. Extra and community, au contraire, shouldn't have this constraint., they are not meant to be a basic package set. I don't l'ike cross dependencies, they force a *user* to enable a different repo, but I think cross makedepends are fine, since they only affect packagers. See the BR I linked above... pulseaudio's users won't be able to use native audacious support because the packager didn't have it installed. It is our duty to provide as many features as possible (as long as they're included in the vanilla package), and pulseaudio defaults as enabled in audacious, but isn't built in our package. That's why I think makedepends are fine, otherwise some TU's work will look like it's broken while it's not.

Corrado

Packages in extra shouldn't makedepends or depends on packages from community. Xmms is an exception. The person who initially moved it to community didn't checked if it was required by other packages in extra. As I maintain xmms in community and am a dev, we decided not to bother moving xmms back in extra. Plus, it is only required as a makedepends. At least, that's the current state of things. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2008/8/29 Xavier :

On Thu, Aug 28, 2008 at 6:30 PM, Xavier wrote:

...

Missing Makedepends --------------------- xosd --> 'xmms' flac --> 'xmms'

Repo Hierarchy for Makedepends -------------------------------- core/iputils depends on extra/jade core/madwifi-utils depends on extra/sharutils core/e2fsprogs depends on extra/bc core/ca-certificates depends on extra/ruby core/madwifi depends on extra/sharutils

While I think it's generally better to have makedepends in the same repo - I think these packages should not be moved into Core just because they are makedepends, because we will pollute Core with packages that don't fit there. -- Roman Kyrylych (Роман Кирилич)