[00:00] Chipzz: iirc they did which was what sparked this stupid renaming GB -> GiB and giving the hd marketing people their GB back [00:02] marketing stinks :P [00:04] slangasek: hey, I have a question about this comment of yours... https://bugs.edge.launchpad.net/ubuntu/+source/lsb/+bug/203169/comments/12 [00:04] Launchpad bug 203169 in sysklogd ""status" function for init scripts" [Wishlist,In progress] [00:15] ogra, infinity: How about http://heh.fi/tmp/initramfs-tools-compcache.diff [00:17] he return of the export line :) [00:17] ke012817 < infinity> ion_: Remove the source from your hook script, and add an export to mkinitramfs. [00:17] ke012858 < infinity> ion_: Well, export it if you need it during mkinitramfs. [00:17] I’m hearing two opposite instructions here. :-) [00:18] huh ? [00:18] well, i use conf.d with te ltsp scripts and it gets sourced correctly without adding any extra export commands [00:19] and i see initramfs.conf being sourced by mkinitramfs [00:19] To hooks? [00:19] mkinitramfs only seems to export specific variables for hooks. [00:20] If you set one of those variables in conf.d, it works in hooks. [00:20] and why did you switch to m4 now ? [00:20] * ogra would really prefer a set of plain shell scripts [00:21] To make the hook script clearer. Having templates for shell scripts in a shell script was a bit nasty, having to do stuff like '"$foo" ... '"'"'bar'"'"' ... "$baz"' etc. [00:21] and i must admit i liked the former aproach a lot more [00:22] even though it breaks with every setup we have in that tree the modprobe.d looked extremely clever ... i just didnt like how you created it and that it isnt a script like we have for everything else [00:26] ogra: How about http://heh.fi/tmp/initramfs-tools-compcache.diff [00:28] why not just use shell commands ? [00:28] instead of m4 [00:29] just use a here document [00:29] pitti: around? [00:30] I can do that. I just though it’s a bit annoying and error-prone having to escape the sed stuff to a shell variable. [00:30] t [00:31] i dont think you need "mkdir -p "$DESTDIR"/scripts/init-top" [00:31] thats a structure you can rely on being there since we're inside the package that carries this dir [00:32] make < ogra: http://heh.fi/tmp/initramfs-tools-compcache.diff [00:36] and infinity might be right that the export is needed ... which i'd consider a bug though, but i see the functions clling the hooks are sourced before the config [00:36] kirkland: what's the question? [00:37] slangasek: i think lamont helped solve it with me in #ubuntu-server [00:37] hmm, ok :) [00:37] slangasek: i think something like this will work: status_of_proc /usr/sbin/named bind9 && exit 0 || exit $? [00:38] kirkland: status_of_proc /usr/sbin/named bind9; exit $? should be equal [00:38] kirkland: er, usually you would just do "status_of_proc /usr/sbin/named bind9" when the script is running under set -e [00:38] Oh, sorry. Didn’t consider set -e. [00:38] hence the comment that it's redundant [00:38] ion_, i like it a lot :) [00:39] slangasek: right, but only 1 of the 9 packages i've touched has the init script running set -e [00:39] I’m squeamish about the k→K change, but oh well... [00:39] slangasek: relying on -e to catch you is also bad [00:39] slangasek: ideally, i'd like to keep the construct/call as identical as possible for consistency [00:39] I'm a proponent of being explicit [00:39] ion_, can you add some linebreaks to: +if [ "\$1" = prereqs ]; then exit 0; fi [00:39] lamont: why is it bad when writing init scripts and good when writing maintainer scripts? [00:39] ogra: Will do. How about the equivalent thing in the generated script? [00:40] heh [00:40] slangasek: there's a specific difference between "we got an error" and "we're supposed to return non-zero status now" [00:40] kirkland: ok, then I suppose that works, but I just think it shows up how all code that's not set -e is inherently ugly, and the lsb init script spec is therefore evil for forbidding its use :) [00:40] lamont: well, there's that, yes [00:40] not in the value returned, but in the scratch my head figuring out if it's an error or not case [00:40] i missed the one at the top, that *was* the generated script one :) [00:41] right, so in this case that construction makes a certain amount of sense [00:41] ion_, so yes, that too [00:41] ogra: Diff updated. [00:41] (either put all ifs in one liners or none of them :) ) [00:42] ion_, perfect ... now compare that with what we had in the beginning ... thats simple, clean and beautiful code :) [00:42] slangasek: here's the samba one... http://pastebin.ubuntu.com/26066/ [00:43] Yeah [00:43] kirkland: is this status_of_proc being pushed up to Debian, so I can commit that to the Debian Samba package too? :) [00:43] sooo ... lets see what we can do about the export .... if i can get infinity's attention :) [00:43] A modprobe.d file could be generated exactly alike, but i’m okay with generating a script instead. :-) [00:43] ogra: I’ll reboot now and check that it actually works. :-) [00:44] slangasek: being pushed, yes... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483285 [00:44] Debian bug 483285 in lsb-base "lsb-base: lsb status_of_proc() function" [Wishlist,Open] [00:44] ion_, thats actually a god idea :) [00:44] *good even [00:44] kirkland: ok, cool [00:44] slangasek: maintainer agreed to it in principle, cites "adding functionality would break the spirit [00:44] of the freeze, but I'll plan on getting status_of_proc() into unstable [00:44] soon after that migration happens (hopefully soon)" [00:45] slangasek: i'll ping him again and see how that's coming along... [00:45] slangasek: as a DD yourself, what freeze is he talking about, and when might that freeze end? [00:45] that would be the freeze for lenny [00:45] which is going to last, um, a fair few months [00:46] but I don't think this change should be a problem under the freeze [00:48] mathiaz: dunno if you follow pkg-openldap-devel, but the source package name in Debian has just (and finally) switched from openldap2.3 to openldap; I suggest we follow suit for intrepid [00:48] hmmm, anyone know how to discover the firefox-default-profile, as in this path for example: ~/.mozilla/firefox/83lemdbc.default/extensions/{000a9d1c-beef-4f90-9363-039d445309b8} [00:48] ogra: Yeah, it works. [00:48] slangasek: good, i was kinda thinking the same thing... just a new function, no modified existing functionality [00:49] ion_, wonderful [00:49] slangasek: let me update the debian bug with an updated patch [00:49] I want to install the components of an extension manually via a .deb and a .rpm but not sure how to discover the firefox profile [00:49] can you try again with dropping the export [00:49] mathiaz: i.e., get it done while the merge is still otherwise trivial [00:49] slangasek: if you think adding a comment in support would help, I'd appreciate it [00:49] slangasek: yop - I followed that [00:50] mathiaz: cool [00:50] slangasek: you renamed it to openldap \o/ - it has been accepted today IIRC - so we can merge it soon [00:50] slangasek: also noticed that samba 3.2 has been uploaded to unstable [00:51] mathiaz: how are things going on the cn=config front? [00:51] mathiaz: eh, if 3.2 is anywhere other than experimental right now, then I screwed up badly :) [00:51] slangasek: hm - good question - I've started to look at the code and wraped by around it [00:51] ogra: Nope, doesn’t work. [00:51] % zcat /boot/initrd.img-2.6.26-3-generic | strings | grep compcache [00:51] # An empty value - compcache isn't used, or added to the initramfs at all. [00:52] slangasek: hm - I must have overlooked the samba upload then [00:52] slangasek: I noticed that things were commited to the experimental branch [00:52] we have one bug in 3.0 (the security-update-regression that jdstrand identified) that we want to get pushed into testing before dropping 3.2 in unstable, and I think upstream also has a bug in how they're putting together libsmbclient.a that I want to fix [00:52] ion_, ok, imho it should [00:53] slangasek: wrt to openldap, I've got some working code, but I'm kind of not sure how to structure the whole thing [00:53] slangasek: so I'd like to have your feedback on it [00:53] ogra: Perhaps just add export -a to mkinitramfs. [00:53] no [00:53] mathiaz: ok - should we schedule some time to sit down for that? [00:53] slangasek: which brings another question - what is the impact on the lenny freeze on that work ? [00:53] slangasek: definitely [00:53] can you try moving the two lines below "# For dependency ordered mkinitramfs hook scripts." under the config stuff [00:54] in mkinitrmafs [00:54] slangasek: is there a chance that the cnconfig stuff will accepted in lenny (which means in the intrepid timeframe IIUC) ? [00:54] that way the functions shooud have access to the vars [00:54] mathiaz: because openldap builds library packages, it will need to go through the Debian release team as a freeze exception, but I believe this is only nominally an exception at this point [00:54] mathiaz: if we could get something into unstable this month, that would certainly be ok wrt the lenny timeline, I think [00:55] ogra: How about the equivalent of for hook in hooks/*; do ( . "$hook" ); done? That is, source all hooks in a subshell. [00:55] slangasek: ok - I plan to submit my work to the debian maintainer list as soon as I've got something [00:55] ogra: Ok, i’ll take a look at that. [00:55] slangasek: to get some feedback [00:56] ion_, i think thats what run_scripts does [00:56] slangasek: one of the thing I'd like to get done is to be able to ship slapd.scripts-common in the package and provide scripts to perform common config operations [00:56] slangasek: such as loading new schemas or adding a new directory database [00:57] slangasek: that's the whole point of having the cn=config backend enabled [00:57] ogra: Moving those lines below the config stuff didn’t make it work. [00:57] ok [00:57] then we need to keep the export :/ [00:57] slangasek: but then things get complicated really quickly [00:58] slangasek: that's why I'd like to discuss that and get your input on that [00:58] mathiaz: well, slapd.scripts-common still has to be embedded in the preinst, because shipping it in the package doesn't make it available until after the package is unpacked [00:58] mathiaz: so if you have a use case for calling those functions from outside maintainer scripts, shipping it is fine, just as long as you don't expect to refactor too aggressively :) [00:59] (for my part, I want to see the shell library shrink down to nothing over the next few releases, which is one reason I want cn=config in lenny :) [00:59] slangasek: ok - I try not to refactor to much [01:00] slangasek: I've taken the approach of adding cn=config support to existing functions in slapd.scripts-common [01:00] ogra: Nope, call_scripts doesn’t use . [01:00] run_* [01:01] oh, right, call_ [01:01] sorry [01:02] It would be a bit hairy, though, since hooks check $1 for prereqs. [01:02] slangasek: I think I'll keep working on the scripts this week and we should schedule a call at the begining of next week to go over my work [01:02] that sounds good [01:02] Could be done with something like ( set -- prereqs; . $hook ) for prereqs and ( set --; . $hook ) for running the hook, though. [01:03] mathiaz: what about the cn=config thing? [01:03] mathiaz: I'm using that feature in debian for munin monitoring [01:03] right, i was expecting the scripts to inherit the vars from the calling script if we re-order ... the export is the best thing otherwise [01:04] so lets just keep it [01:05] Chipzz: I'm working on adding cn=config support to the package [01:06] Chipzz: so that a default install of slapd in intrepid will use cn=config instead of slapd.conf [01:06] Chipzz: and we'll also support upgrading from slapd.conf to cn=config [01:06] ah k [01:07] mathiaz: could you look into getting this into munin? http://wiki.ruberg.no/index.php/Munin_LDAP_plugins [01:07] Chipzz: you'd better file a bug about this [01:08] Chipzz: the chance this get lost will be higher here ;) [01:08] can do [01:08] file a bug in debian, ubuntu or both? [01:09] Chipzz: debian is the best place IMO [01:09] ion_, so how about making a debdiff from that so your name is in the changelog ... ? [01:09] ogra: Will do. [01:36] slangasek: patch for samba status attached to: https://bugs.edge.launchpad.net/ubuntu/+source/sysklogd/+bug/203169 [01:36] Launchpad bug 203169 in sysklogd ""status" function for init scripts" [Wishlist,In progress] [01:37] slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/sysklogd/+bug/203169/comments/27 === nxvl_ is now known as nxvl [01:43] ok this channel looks more appropriate for this :) [01:43] does this patch look good? http://launchpadlibrarian.net/15898720/python-apt_0.7.4ubuntu7.2.debdiff [01:47] Bug #244093 [01:47] Launchpad bug 244093 in python-apt "Checking security repository in Updates adds deb line to Third-Party Software" [Undecided,In progress] https://launchpad.net/bugs/244093 [01:47] oh, sorry, forgot to mention that [01:48] savvas: debdiff is attached. Security Team will see it. [01:48] that was quick, thanks emgent! [01:49] i don't have to do anything for the moment right? [01:49] *anything else [01:50] savvas: just subsribe in this bug last uploader. [01:52] emgent: to subscribe the maintainer of the package? [01:53] savvas: you can subscribe ubuntu-main-sponsor [01:54] but Michael Vogt is APT Master :) [01:54] it said it will notify the maintainer [01:54] ah ubuntu-main-sponsor, I'll do that [01:55] - ubuntu-main-sponsors Ubuntu Sponsors for main [01:55] this one emgent ? [01:55] savvas: true. [01:55] but i suggest to subscribe Michael Vogt too.. [01:56] done and done! [01:56] now wait :) [01:56] I think his nick is mvo at launchpad, hopefully that's correct [01:57] him will review it [01:57] mvo, sure. [01:57] this package fixing is fun! :) [01:58] kirkland: you may wish to tie that in to Debian bug #488275 [01:58] Debian bug 488275 in samba "samba and winbind: initscript miss 'status' option" [Wishlist,Open] http://bugs.debian.org/488275 [02:03] slangasek: sure, you bet [02:26] i go to sleep, night people [02:27] ogra: Is the comment i added to the COMPCACHE_SIZE documentation ok? http://heh.fi/tmp/initramfs-tools_0.92bubuntu3.debdiff [02:28] ogra: I uploaded a version of compcache package that handles the initramfs-tools change correctly: it doesn’t include an initramfs hook anymore and it puts the setting to /usr/share/initramfs-tools/conf-hooks.d/compcache [02:28] ogra: ...to REVU [02:30] you should (sorry for tht) probably rename it again [02:30] like compcache-tools ... [02:30] i.e. take fuse as example here [02:31] Hm, tools/utils is a bit strange for a package that doesn’t contain anything in $PATH. But i guess there’s no better choice. [02:31] Should i go with tools or utils? :-) [02:31] compcache-config ? [02:32] no idea ... but just calling it compcache somewhat doesnt seem to fit [02:33] I think i’ll go with -config, even though it contains modprobe.d and udev/rules.d files in addition to the debconf stuff. [02:33] And an init script. [02:33] Unless there are better ideas. :-) [02:35] probably LaserJock has one :) [02:35] ogra: one what? [02:36] laserjock: A name for the package compcache-FOO, which contains debconf magic to configure the size as well as init, modprobe.d and udev/rules.d scripts. :-) [02:36] tools? utils? config? None of them seems to fit exactly. :-) [02:37] compcache-setup? [02:37] Not bad. [02:37] I’ll use -setup. [02:37] yeah, i knew it :) [02:38] ogra: so I haven't gone to uni for 10 years for nothing?!?! :-) [02:39] you can cut out little presents to sell on flea markets with lasers and the like as well, i know :) [02:40] LaserJock, so how is life ? [02:42] ogra: hmmm, busy :-) [02:42] yeah, same here [02:42] ogra: getting closer to being done though [02:43] heh, me too ... [02:43] should be done before next UDS [02:43] i'm just building whats supposed to become the final cmpc image for hardy [02:43] (yeah, my calendar revolves around Ubuntu development cycles) [02:43] hey and its even in the US [02:43] ogra: oh awesome, newer kernel? [02:43] so we'll meet :) [02:44] I hope [02:44] -19.something yes [02:44] I'll try it out once you're finished [02:44] i'm still struggling with the display driver though [02:44] :( [02:44] they insist on using their hacked up i810 [02:44] ah [02:45] but thats two versions behind ours (which is outdated as well) [02:45] I just have problem with wanting to download all kinds of goodies and filling the drive [02:45] yeah, not much i can do about that though [02:45] i could do the sme as metasys if i were evil ... [02:45] no, it's already quite amazing how much you've shrunk it [02:46] they link /usr/bin/rpm to /dev/null there [02:46] kees: I know that -rt kernels are in universe, but I kinda thought we get -security updates for free with them. seems -19 for -rt doesn't exist. will it? [02:46] ogra: umm, ewww [02:46] well, you wont fill up the system with apps :) [02:47] I suppose [02:47] no idea about -rt, sorry [02:47] jdstrand: uhhhh... I thought they were part of the upload? [02:47] ogra: Windows had a good way of doing that, just run out of memory so the installer dies [02:47] kees: apt-cache search linux-image|grep 19 [02:48] linux-image-rt still points to -18 [02:49] LaserJock, well, but kill the device a minute in advance by trying to bring up a ppup about low diskspace :) [02:49] *popup [02:50] Package: linux-image-rt [02:50] Depends: linux-image-2.6.24-19-rt, linux-ubuntu-modules-2.6.24-19-rt [02:50] * jdstrand scratches head [02:50] jdstrand: I mean, I see the older package info to, but -19 is there for me [02:50] what's with my local debmirror... [02:50] me too [02:52] jdstrand: I see three versions of linux-image-rt in my hardy repo: 2.6.24.16.18 2.6.24.18.20 2.6.24.19.21 [02:52] kees: hmm, I see it on all the machines except the one actually using -rt. sorry for the noise [02:53] np. I wonder what that machine is doing? [02:53] ogra: Ok, http://heh.fi/tmp/initramfs-tools_0.92bubuntu3.debdiff updated and compcache-setup uploaded to REVU. [02:54] meh, -updates for main and restricted, but not universe. I'm a dolt [02:54] ion_, err, updated ? [02:54] ion_, i uploaded it 10mins ago :) [02:54] ogra: “< ion_> ogra: Is the comment i added to the COMPCACHE_SIZE documentation ok?” – updated the comment. [02:55] oh, k [03:25] kees: fun-- looks like ruby1.9 did not build on i386 or lpia-- test_copy_stream_rbuf() hung :/ [03:25] (intrepid) [03:25] kees: all other archs built fine [03:25] kees: I'll try to see what's happening tomorrow [03:26] heh: Build killed with signal 15 after 150 minutes of inactivity [03:26] I think there was a discussion about that here some time ago. Didn’t really follow it, though. [03:29] ion_: if you are responding to me, I was the last person to talk about it in here :) === gaurdro is now known as MenschenFleisch [03:30] Heh, ok [04:16] if I send email to launchpad to update a bug, does it have to be signed? [04:16] and where does it go, and all that [04:16] * lamont goes off to find the right wiki page [04:19] lamont: If you are changing status/assignments etc, I think it has to be signed. For general comments only, no it doesn't need to be signed. [04:19] I wanna make it say FixCommitted [04:19] lamont: Then you need to sign the message. [04:19] and then drop that into a commit hook [04:20] and if I have to sign it, maybe I don't care enough yet [04:21] er, you rpobably need to sign all mails, no? [04:21] why not set it up to sign by default? [04:21] lamont: https://help.launchpad.net/BugTrackerEmailInterface [04:22] Hobbsee: hence the maybe I don't care enough... I have to sign tags, not every commit [04:23] kirkland: oh, I didn't realize you were using pidof, or else I hadn't thought through the implications at the time I knew this; if you read the bug log, you'll see that I'm vetoing that as an implementation for the Debian Samba package [04:24] slangasek: ah - what was the objection [04:24] ? [04:24] slangasek: i recently switched to using /bin/pidof [04:24] slangasek: i was previously using pidofproc() which has a more sophisticated mechanism for obtaining the pid from pidfiles [04:24] lamont: that it doesn't respect PID files [04:24] slangasek: however, pidofproc() uses "kill -0" to see if a daemon is active [04:25] it violates the spirit of Debian policy's guidelines on init scripts [04:25] (but not the letter, since the letter says nothing about a 'status' arg :) [04:25] slangasek: which only works if you're the process owner or root [04:25] kirkland: not respecting pid files is bad [04:28] Upstart will void the need for pid files. \o/ [04:28] not respecting pid files would be a bug against the status function for at least some packages, which would be therefore a bug against lsb-release [04:28] ion_: bullcrap [04:28] or how will you handle having two instances of a daemon? [04:29] How about having two Upstart job instances? :-) [04:29] maybe [04:29] :-/ [04:29] now tell me how the control command that uses signals tells how to communicate with the daemon? [04:29] IOW. where did you move the pid file with upstart? [04:30] Doesn’t the daemon provide a socket you can talk to, or a D-Bus API or something equivalent? [04:30] (there are admins who prefer to run bind without the control port, and just have rndc use kill to talk to it...) [04:30] for those admins, the API is "kill" [04:31] They’re free to use PID files. [04:31] Or query the PID from Upstart, or whatever. [04:32] kirkland: anyway, I'll take the fix we put together, and if you switch to ignoring pidfiles, I'll either remove status, or file a bug against lsb-release [04:32] and I don't see that there's a need for non-root to query a daemon status [04:33] lamont: um.... [04:33] well, it's a bug [04:33] or maybe I'll just not admit to 'status' being there in the usage. [04:33] lamont: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=30;filename=lsb.483285.diff;att=1;bug=483285 ... that doesn't yet respect pidfiles [04:33] yeah - I know [04:34] i can add that tomorrow [04:34] i'm absolutely burnt out on this one today :-S [04:34] it was a "please fix it before he accepts it, or it'll be broken and you'll be back begging him to take another change..." [04:34] kirkland: understood [04:35] I'm about to crawl into bed myself [04:35] lamont: okay... i'll ping you tomorrow then [04:40] hrm... time to go read up on how to get procmail to delete a header from certain mail messages that it receives [04:41] because reply-to: $LIST is just plain stupid and wrong [04:41] (and no, not an ubuntu list) [04:54] * TheMuso kicks dmraid upstream. 1) *PLEASE* include Makefile.am/configure.in/ac files in your tarball 2) Even though you statically link a library, *PLEASE* use a soname in the event the library is built as a dynamic library!! [04:55] Hrm I take it b ack, configure.in is included, but no Makefile.am files. :S [05:01] if I upload a ...-2~build1 version, will the autosyncer simply overwrite it with -2 once that shows up in debian? [05:04] lamont: for intrepid, or? [05:04] yeah [05:04] lamont: isn't that a moot point? the autosyncer has already been turned off for intrepid [05:04] trying to hop-skip around the fact that it's NEW in debian [05:05] true [05:05] 'twas more one of making sure that MoM wouldn't object. :) [05:12] hrm ok it does have a soname. [05:14] TheMuso: so, umm, why are you kicking upstream again? :-) [05:16] there. bind9_9.5.0.dfsg.P1-2~build1 uploaded to intrepid. g'night. [05:29] LaserJock: No Makefile.am files is enough::) The shared library is not named/symlinked properly when copied into place, and its easier to change Makefile.am than hack Makefile.in to do it. [06:24] Note to self: read the tens of previous notes to self about buying an UPS. === BenC1 is now known as BenC [07:01] good morning [07:03] Morning dholbach. [07:03] hi TheMuso [07:03] TheMuso: thanks for your reply [07:03] dholbach: You're welcome === ion__ is now known as ion_ [07:25] Good morning [07:25] Howdy [08:04] tjaalton, tseliot: new nvidia-glx working perfectly here with current intrepid (new X.org) [08:05] (-173) [08:05] pitti: great :-) [08:06] hey pitti [08:06] good morning seb128! [08:06] pitti: :-) [08:07] bryce: hi ;) [08:07] pitti: great, I'll install it too [08:07] ..shortly [08:07] tseliot: heya [08:09] hi seb128! [08:09] hey dholbach [08:09] dholbach: getting ready for your holidays? ;-) [08:09] yeah :) [08:09] lots of other stuff left to do still :) [08:09] how's Istanbul? [08:12] great, I'm sure you would like it [08:12] definitely :) [08:13] seb128: the night they stole my camper bus I was looking at the map and figuring out how best to get to Istanbul with the bus :-) [08:13] lol [08:13] so... yeah - I'd love to go there at some stage [08:14] a bit warm in the afternoon to my taste [08:14] but I very much look forward to India :) [08:14] but otherwise lot of typical places, sunny weather, GUADEC is great [08:14] and nice to see everybody there again [08:15] seb128: does mvo get any vegetarian food? :) [08:15] he seems to be happy so far [08:15] we had to go to several restaurants to find something good for him but we managed [08:18] seb128: talking about vegetarians always reminds me of this one Tintin comic where Captain Haddock uses "Vegetarian" as an insult :-) [08:18] dholbach: mvo sends you a hug [08:18] ;-) [08:18] hug him back for me :) [08:20] http://www3.sympatico.ca/brooksdr/haddock/main.htm :-) [08:29] dholbach, is there a word of more than three syllables that Haddock didn't use as an insult? :) [08:30] Billions of blistering barnacles! [08:37] hey [08:37] is there any known intel issue on intrepid? [08:37] the user gets an error about dri2 which couldn't be loaded [08:37] and then a stacktrace [08:38] X and then libfb.so [08:38] and then libexa.so [08:38] let's try XAA [08:38] seb128: dist-upgrade harder :) [08:38] dri2 is not enabled yet due to lack of memory manager in libdrm [08:38] seb128: I had the same yesterday (I think, anyway), X.org crashed [08:38] pitti: tricky to connect to wireless network using only command line tools [08:39] seb128: do you have 2:2.3.2-2ubuntu2? [08:41] pitti: not sure but he switched to XAA and that works, I guess he will upgrade next [08:42] the error is cosmetic [08:43] um, the DRI2 error.. [08:44] alright [08:44] thanks guys, have to go now, see you later [08:45] it's already fixed upstream so that it won't complain if the xserver is built without dri2 [08:45] ie. it won't try to load it === slangasek changed the topic of #ubuntu-devel to: soft freeze for intrepid alpha-2 | Ubuntu 8.04.1 released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [09:29] ArneGoetje, i saw that the new language pack export is there. did you already upload new langpacks to PPA that i can test or should i do my QA on the langpack tarball? [09:37] asac: you can use the PPA; they get new packages as soon as Rosetta exports them [09:38] asac: theoretically it should have built new ones last night [09:42] hello [09:42] pitti: for hardy the cronjob runs on thursday and sunday [09:43]