[00:08] <tjaalton> whoa, i386 built \o/
[00:09] <mjg59> tjaalton: \o/
[00:10] <tjaalton> what the.. why is the lpia* lrm's versioned -7-lpia*
[00:12] <tjaalton> grrrr
[00:13] <tjaalton> I don't remember having to touch the rules too
[00:15] <tjaalton> why the hell did I miss that
[00:24] <tjaalton> dpkg-parsechangelog | grep ^Version | sed 's/.*-//;s/\..*//'
[00:24] <tjaalton> that would get the abiver from the version string, like I thought it would do :)
[00:25] <tjaalton> rtg: sorry for the delay, hopefully it's ok now
[08:31] <herman> hey! The autor of aufs is juliank?
[08:46] <kraut> moin
[10:13] <Kano> hi rtg 
[10:14] <Kano> just saw an interesting commit for the kernel. do you work on dmraid45?
[10:14] <Kano> also please update aufs when you update the rest
[10:27] <Kano> tjaalton: MAKE[0]="make SYSSRC=\${kernel_source_dir} module IGNORE_XEN_PRESENCE=1"
[10:27] <Kano> is that YOUR big trick ;)
[10:27] <Kano> very simple to find that on your own
[10:28] <tjaalton> ?
[10:29] <Kano> i mean for dkms
[10:30] <tjaalton> I haven't played with dkms at all
[10:31] <Kano> hmm then it was somebody else with a similar nick
[10:31] <tjaalton> tseliot
[10:31] <Kano> exactly
[10:32] <Kano> but it really seems pretty interesting that dkms
[13:12] <Kano> btw. dkms in ubuntu has en error
[13:12] <Kano> the uninstall trigger can not work
[13:13] <Kano> wrong parsed
[13:15] <tjaalton> Kano: you mean the lrm package?
[13:15] <Kano> arch=`echo "$line" | awk '{print $4}' | sed 's/:$//'`
[13:15] <Kano> no the debian/kernel_prerm.d_dkms
[13:15] <Kano> : not ,
[13:15] <tjaalton> ok
[13:15] <tjaalton> phew..
[13:17] <Kano> i think nobody REALLY tested remove
[13:17] <Kano> btw. why is only uninstall and not remove triggered?
[13:18] <Kano> do you think somebody installs it again
[13:20] <Kano> http://kanotix.com/files/thorhammer/updates/dkms/
[13:20] <Kano> that works now
[13:23] <Kano> rtg: http://article.gmane.org/gmane.linux.alsa.devel/51536
[13:23] <Kano> did you see this
[14:39] <tseliot> tjaalton: why did you remove this lines from the debian/rules of the lrm?
[14:39] <tseliot> export DH_COMPAT=4
[14:39] <Kano> tseliot: did you find the uninstall error in dkms
[14:39] <tjaalton> tseliot: I did?
[14:40] <tseliot> tjaalton: either you or someone else
[14:40] <tseliot> di
[14:40] <tseliot> did
[14:41] <tseliot> Kano: uninstall error?
[14:41] <Kano> well try to delete a kernel
[14:41] <Kano> then uninstall should be triggered
[14:41] <Kano> but instead you get an error
[14:41] <Kano> because of a stupid typo...
[14:42] <Kano> maybe you could even trigger remove, not only uninstall
[14:42] <Kano> http://kanotix.com/files/thorhammer/updates/dkms/
[14:42] <Kano> fixed version there
[14:43] <Kano> or check /etc/kernel/prerm.d/dkms
[14:43] <tseliot> so the problem affects DKMS itself, doesn't it?
[14:43] <Kano> only the debian packageing
[14:43] <Kano> it is in the debian dir
[14:43] <Kano> : not , in arch line
[14:44] <Kano> is the fix
[14:44] <tseliot> did you file a bugreport about this?
[14:44] <Kano> nope
[14:44] <tjaalton> tseliot: that's not exported in gutsy either, and first time I touched lrm was in November ;)
[14:44] <Kano> i uploaded it to my repository, that is faster *g*
[14:45] <Kano> also this is -5 not -4 directly form dell's website
[14:45] <tseliot> tjaalton: ok, maybe the problem affects only the packaging scripts I use for Envy. I just wanted to make sure that it didn't break the lrm
[14:46] <tseliot> Kano: I would like the get the fix into hardy
[14:46] <mdomsch> Kano, what's my typo?
[14:46] <tjaalton> tseliot: k
[14:47]  * mdomsch is upstream for DMKS
[14:47] <mdomsch> DKMS
[14:47] <tseliot> tjaalton: thanks for your prompt reply, as usual ;)
[14:47] <Kano> mdomsch: arch=`echo "$line" | awk '{print $4}' | sed 's/:$//'`
[14:47] <Kano> not
[14:47] <Kano> sed 's/:$//'`
[14:47] <Kano> sed 's/,$//'`
[14:47] <Kano> i mean
[14:48] <tjaalton> tseliot: well, I wanted to be sure about it
[14:48] <Kano> mdomsch: how about using remove instead of uninstall in that file?
[14:49] <tseliot> tjaalton: why do the nvidia packages suggest nvidia-settings when there's no nvidia-settings in the repos?
[14:50] <tjaalton> tseliot: it's in NEW
[14:50] <tjaalton> hmm, actually it should be accepted
[14:50] <mdomsch> Kano, it should be uninstall; we don't want to nuke the driver for any other kernels present
[14:51] <Kano> mdomsch: it would not nuke it
[14:51] <Kano> but it keeps the binary
[14:51] <mdomsch> ok, I see the bug, fixed now in my tree
[14:51] <tseliot> tjaalton: aah, as I removed nvidia-settings from Envy's packaging scripts as well. Ok, I'll wait for the package to be approved.
[14:52] <mdomsch> ah, we're specifying kernel and arch
[14:52] <mdomsch> ok, remove it is.
[14:52] <tjaalton> tseliot: binaries are built, but needs a push
[14:52] <tjaalton> same for the lrm btw
[14:53] <tseliot> tjaalton: ok, I'll just make sure that EnvyNG installs that package instead of building its own nvidia-settings
[14:54] <Kano> remove is definitely cleaner
[14:54] <tjaalton> tseliot: yeah, I think it's wise to use the one that has sources
[14:55] <tseliot> Kano: I gave you credit for reporting the problem (and the solution) about xen kernels in Envy's changelog :-)
[14:55] <tseliot> thanks again
[14:56] <Kano> tjaalton: did you see that new thing in 171.05 called nvidia-smi?
[14:56] <Kano> i dont know what to do with it but it is there...
[14:57] <Kano> works only with 171.05
[14:57]  * tseliot reboots and tries the new DKMS patch with a xen kernel
[14:57] <tjaalton> Kano: what is it?
[14:57] <Kano> no idea
[14:59] <tjaalton> that release is for some professional setup
[15:00] <Kano> well it works too for others ;)
[15:00] <tjaalton> yes, but no changes for them
[15:00] <Kano> well i like to try all ;)
[15:02] <mdomsch> Kano, I"ll fix this up and let superm1 help me get it uploaded
[15:02] <Kano> fine
[15:16] <tjaalton> oh crap, moving libglx turned out to be a bad ide
[15:16] <tjaalton> +a
[15:16] <tseliot> tjaalton: I was about to report it
[15:17] <Kano> mdomsch: did you test what happens when you execute remove and it is the last entry
[15:18] <tjaalton> I can't understand why it doesn't load it from the right path when you have nvidia
[15:18] <mdomsch> Kano, not yet
[15:18] <Kano> mdomsch: in that case you can only use uninstall or is there an option to leave the source?
[15:21] <mdomsch> Kano, no such option at present
[15:21] <mdomsch> hence uninstall; with remove at uninstall of the package with the source
[15:22] <Kano> well maybe tell upstream to add this option
[15:22] <Kano> somethink like --keep-source or so
[15:24] <tseliot> tjaalton: this line makes a dead symlink:
[15:24] <tseliot> usr/lib/xorg/modules/libglx.so.@@VERSION@@ usr/lib/xorg/modules/libglx.so
[15:24] <mdomsch> that's going to mess up packages with prebuilt binaries in them
[15:24] <mdomsch> I'm going to leave it as uninstall
[15:24] <tseliot> tjaalton: in nvidia-glx.links.in
[15:24] <Kano> mdomsch: i like that feature to create debs
[15:25] <mdomsch> yeah
[15:25] <tjaalton> tseliot: oh
[15:25] <Kano> for my new nvidia script i basically write the conf file, add it, then create deb and install the deb
[15:25] <Kano> then the module is compiled and you could even uninstall nvidia-dkms..
[15:26] <Kano> when you dont need it, pretty funny
[15:27] <tseliot> tjaalton: there's a broken link in /usr/lib/xorg/modules/ . Ok, let's fix it.
[15:31] <tjaalton> tseliot: yeah, thanks for spotting *headdesk*
[15:31] <tjaalton> moving it made it work, I'll upload a new version ASAP
[15:34] <tseliot> tjaalton: great
[15:39]  * tseliot tries the new fix in EnvyNG
[15:40] <tjaalton> uploaded
[15:41] <tjaalton> luckily the binaries were not published yet
[15:56] <Kano> rtg: can you change the lum package that it compiles without disabling d-i als when debian/d-i/kernel-versions is empty
[15:57] <Kano> i bacially only compile a custom flavour without d-i modules
[15:57] <rtg> Kano: patches will be considered
[15:58] <Kano> rules.d/2-binary-arch.mk:#binary-arch: binary-debs binary-udebs
[15:58] <Kano> rules.d/2-binary-arch.mk:binary-arch: binary-debs
[15:58] <Kano> thats a stupid hack
[15:58] <Kano> better would be when binary-udebs would not break when the file is empty
[16:01] <rtg> Kano: the kernel has something like that, the disable_d_i flag for flavours that don't have any d-i bits.
[16:02] <Kano> rtg: well i modify both packages usually to compile only the kanotix flavour
[16:03] <rtg> Kano: send a lum patch to the kernel-team mailing list that works for both of us and I'll consider it. In the meantime, I've got my hands full with some other issues.
[16:04] <Kano> rtg: could you update aufs in the meantime ;)
[17:20] <rtg> zul: xen doesn't build with the -9 kernel. (nor does -rt)
[17:23] <zul> rtg: ill take a look
[17:24] <rtg> zul: I also just dropped a note to the kernel-team ml.
[18:32] <zul> rtg: where did it fail?
[18:32] <rtg> zul: somewhere in the compile phase.
[18:33] <zul> oh...ok....
[20:09] <zul> rtg: fixed locally
[20:10] <rtg> beam me up scotty
[20:13] <zul> can I just send you the patch?
[20:13] <zul> ie put it somewhere you can get it
[20:14] <rtg> zul: yes - just announce a git pull. 
[20:14] <zul> ok...
[20:50] <j4k4> hi folks
[20:56] <tseliot> tjaalton: why doesn't fglrx-kernel-source contain 7.1.0 in its version while the other fglrx packages do?
[20:58] <tseliot> if it's not an error I'll make Envy compliant with this as well
[21:07] <tjaalton> tseliot: I'm not sure..
[21:08] <tseliot> tjaalton: having a consistent version scheme in the fglrx driver would be of help
[21:09] <tseliot> would it be possible to make its version as it was before?
[21:13] <tjaalton> what do you mean "as it was before"? it's been like that for some time (releaseversion+kernelversion)
[21:16] <tseliot> something like 1:7.1.0-8-02+2.6.24.7- etc.
[21:16] <tseliot> like xorg-driver-fglrx
[21:17] <tseliot> which means xorgversion+releaseversion+kernelversion
[21:18] <tjaalton> imho the xorgversion part should be dropped instead
[21:19] <tseliot> tjaalton: ok, but can it be dropped for all the fglrx packages?
[21:19] <tjaalton> maybe some time
[21:20] <infinity> It was, historically, part of the complete version.
[21:20] <tseliot> tjaalton: this is causing problems with Envy :-/
[21:20] <infinity> When we switched from Xorg 7.0 to Xorg 7.1, but the fglrx version didn't bump.
[21:21] <tseliot> infinity: would a change break anything?
[21:21] <infinity> There had to be a way to bump the version of the package, despite the fglrx version not changing.
[21:21] <infinity> tseliot: fglrx had two modules shipped (one for 7.0, one for 7.1), and when we changed the packages to use the 7.1 version, the binaries needed a new version.
[21:22] <tseliot> yes, I know
[21:22] <tseliot> but now it seems to be no longer the case
[21:22] <infinity> This is all, perhaps, "historical" now, though I imagine the exact same thing happening again with a new Xorg ABI change some day.
[21:23] <tseliot> infinity: I see your point, however all I'm asking is consistency between all the fglrx packages
[21:23] <tjaalton> right, it's not long ago when they didn't know what version to use (8.41x -> 7.01 -> 8.42? -> 8-01 ..)
[21:24] <tseliot> having all either with or without the Xversion
[21:24] <infinity> I'm not sure how it looks these days, but fglrx-source used to ship both Xorg ABI drivers in it, hence why it didn't include the Xorg version.
[21:25] <tseliot> tjaalton: yes, ATI adopted the same version scheme as their Windows Catalyst driver
[21:25] <infinity> Granted, I haven't touched lrm for a couple of years (thank god), so I'm not sure how much of my hackish packaging lives on...
[21:25] <tjaalton> infinity: :)
[21:25] <tseliot> hehehe
[21:25] <tjaalton> tseliot: the driver itself still thinks its 8.4xxx
[21:26] <tseliot> tjaalton: yes, if you extract the installer you get something like 8.45
[21:26] <tseliot> but the "official" version is 8-02
[21:27] <tseliot> at least this is (more or less) what they told me in the mailing list of ATI
[21:27] <tseliot> as I'm a beta tester
[21:41] <tseliot> I'll make EnvyNG's package compliant with Ubuntu's version scheme then... *sigh*
[21:46] <tjaalton> tseliot: I think the cleanup is best left after hardy
[21:46] <tjaalton> +to be 
[21:46] <tseliot> tjaalton: no problem, I'm hacking on ATI's packaging scripts now
[21:47] <tseliot> I'll make sure it's all compatible with Ubuntu
[21:58]  * j4k3b makes a launchpad page