| tjaalton | whoa, i386 built \o/ | 00:08 |
|---|---|---|
| mjg59 | tjaalton: \o/ | 00:09 |
| tjaalton | what the.. why is the lpia* lrm's versioned -7-lpia* | 00:10 |
| tjaalton | grrrr | 00:12 |
| tjaalton | I don't remember having to touch the rules too | 00:13 |
| tjaalton | why the hell did I miss that | 00:15 |
| 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:24 |
| tjaalton | rtg: sorry for the delay, hopefully it's ok now | 00:25 |
| === asac_ is now known as asac | ||
| === TheMuso_ is now known as TheMuso | ||
| herman | hey! The autor of aufs is juliank? | 08:31 |
| kraut | moin | 08:46 |
| Kano | hi rtg | 10:13 |
| 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:14 |
| 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:27 |
| tjaalton | ? | 10:28 |
| Kano | i mean for dkms | 10:29 |
| tjaalton | I haven't played with dkms at all | 10:30 |
| Kano | hmm then it was somebody else with a similar nick | 10:31 |
| tjaalton | tseliot | 10:31 |
| Kano | exactly | 10:31 |
| Kano | but it really seems pretty interesting that dkms | 10:32 |
| Kano | btw. dkms in ubuntu has en error | 13:12 |
| Kano | the uninstall trigger can not work | 13:12 |
| Kano | wrong parsed | 13:13 |
| 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:15 |
| Kano | i think nobody REALLY tested remove | 13:17 |
| Kano | btw. why is only uninstall and not remove triggered? | 13:17 |
| Kano | do you think somebody installs it again | 13:18 |
| Kano | http://kanotix.com/files/thorhammer/updates/dkms/ | 13:20 |
| Kano | that works now | 13:20 |
| Kano | rtg: http://article.gmane.org/gmane.linux.alsa.devel/51536 | 13:23 |
| Kano | did you see this | 13:23 |
| 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:39 |
| tseliot | tjaalton: either you or someone else | 14:40 |
| tseliot | di | 14:40 |
| tseliot | did | 14:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| * 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:47 |
| 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:48 |
| tseliot | tjaalton: why do the nvidia packages suggest nvidia-settings when there's no nvidia-settings in the repos? | 14:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| tseliot | tjaalton: ok, I'll just make sure that EnvyNG installs that package instead of building its own nvidia-settings | 14:53 |
| Kano | remove is definitely cleaner | 14:54 |
| tjaalton | tseliot: yeah, I think it's wise to use the one that has sources | 14:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| tjaalton | that release is for some professional setup | 14:59 |
| 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:00 |
| mdomsch | Kano, I"ll fix this up and let superm1 help me get it uploaded | 15:02 |
| Kano | fine | 15:02 |
| 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:16 |
| Kano | mdomsch: did you test what happens when you execute remove and it is the last entry | 15:17 |
| 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:18 |
| mdomsch | Kano, no such option at present | 15:21 |
| mdomsch | hence uninstall; with remove at uninstall of the package with the source | 15:21 |
| Kano | well maybe tell upstream to add this option | 15:22 |
| Kano | somethink like --keep-source or so | 15:22 |
| 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:24 |
| 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:25 |
| Kano | when you dont need it, pretty funny | 15:26 |
| tseliot | tjaalton: there's a broken link in /usr/lib/xorg/modules/ . Ok, let's fix it. | 15:27 |
| tjaalton | tseliot: yeah, thanks for spotting *headdesk* | 15:31 |
| tjaalton | moving it made it work, I'll upload a new version ASAP | 15:31 |
| tseliot | tjaalton: great | 15:34 |
| * tseliot tries the new fix in EnvyNG | 15:39 | |
| tjaalton | uploaded | 15:40 |
| tjaalton | luckily the binaries were not published yet | 15:41 |
| 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:56 |
| Kano | i bacially only compile a custom flavour without d-i modules | 15:57 |
| rtg | Kano: patches will be considered | 15:57 |
| 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 | 15:58 |
| rtg | Kano: the kernel has something like that, the disable_d_i flag for flavours that don't have any d-i bits. | 16:01 |
| Kano | rtg: well i modify both packages usually to compile only the kanotix flavour | 16:02 |
| 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:03 |
| Kano | rtg: could you update aufs in the meantime ;) | 16:04 |
| rtg | zul: xen doesn't build with the -9 kernel. (nor does -rt) | 17:20 |
| zul | rtg: ill take a look | 17:23 |
| rtg | zul: I also just dropped a note to the kernel-team ml. | 17:24 |
| zul | rtg: where did it fail? | 18:32 |
| rtg | zul: somewhere in the compile phase. | 18:32 |
| zul | oh...ok.... | 18:33 |
| === macd_ is now known as macd | ||
| zul | rtg: fixed locally | 20:09 |
| rtg | beam me up scotty | 20:10 |
| zul | can I just send you the patch? | 20:13 |
| zul | ie put it somewhere you can get it | 20:13 |
| rtg | zul: yes - just announce a git pull. | 20:14 |
| zul | ok... | 20:14 |
| j4k4 | hi folks | 20:50 |
| tseliot | tjaalton: why doesn't fglrx-kernel-source contain 7.1.0 in its version while the other fglrx packages do? | 20:56 |
| tseliot | if it's not an error I'll make Envy compliant with this as well | 20:58 |
| tjaalton | tseliot: I'm not sure.. | 21:07 |
| tseliot | tjaalton: having a consistent version scheme in the fglrx driver would be of help | 21:08 |
| tseliot | would it be possible to make its version as it was before? | 21:09 |
| tjaalton | what do you mean "as it was before"? it's been like that for some time (releaseversion+kernelversion) | 21:13 |
| tseliot | something like 1:7.1.0-8-02+2.6.24.7- etc. | 21:16 |
| tseliot | like xorg-driver-fglrx | 21:16 |
| tseliot | which means xorgversion+releaseversion+kernelversion | 21:17 |
| tjaalton | imho the xorgversion part should be dropped instead | 21:18 |
| tseliot | tjaalton: ok, but can it be dropped for all the fglrx packages? | 21:19 |
| tjaalton | maybe some time | 21:19 |
| 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:20 |
| 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:21 |
| tseliot | yes, I know | 21:22 |
| tseliot | but now it seems to be no longer the case | 21:22 |
| === j4k4 is now known as j4k0 | ||
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| tseliot | I'll make EnvyNG's package compliant with Ubuntu's version scheme then... *sigh* | 21:41 |
| 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:46 |
| tseliot | I'll make sure it's all compatible with Ubuntu | 21:47 |
| * j4k3b makes a launchpad page | 21:58 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!