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