| calc | Chipzz: iirc they did which was what sparked this stupid renaming GB -> GiB and giving the hd marketing people their GB back | 00:00 |
|---|---|---|
| Chipzz | marketing stinks :P | 00:02 |
| kirkland | 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 |
| ubottu | Launchpad bug 203169 in sysklogd ""status" function for init scripts" [Wishlist,In progress] | 00:04 |
| ion_ | ogra, infinity: How about http://heh.fi/tmp/initramfs-tools-compcache.diff | 00:15 |
| ogra | he return of the export line :) | 00:17 |
| ion_ | ke012817 < infinity> ion_: Remove the source from your hook script, and add an export to mkinitramfs. | 00:17 |
| ion_ | ke012858 < infinity> ion_: Well, export it if you need it during mkinitramfs. | 00:17 |
| ion_ | I’m hearing two opposite instructions here. :-) | 00:17 |
| ogra | huh ? | 00:18 |
| ogra | well, i use conf.d with te ltsp scripts and it gets sourced correctly without adding any extra export commands | 00:18 |
| ogra | and i see initramfs.conf being sourced by mkinitramfs | 00:19 |
| ion_ | To hooks? | 00:19 |
| ion_ | mkinitramfs only seems to export specific variables for hooks. | 00:19 |
| ion_ | If you set one of those variables in conf.d, it works in hooks. | 00:20 |
| ogra | and why did you switch to m4 now ? | 00:20 |
| * ogra would really prefer a set of plain shell scripts | 00:20 | |
| ion_ | 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 |
| ogra | and i must admit i liked the former aproach a lot more | 00:21 |
| ogra | 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:22 |
| ion_ | ogra: How about http://heh.fi/tmp/initramfs-tools-compcache.diff | 00:26 |
| ogra | why not just use shell commands ? | 00:28 |
| ogra | instead of m4 | 00:28 |
| ogra | just use a here document | 00:29 |
| nxvl | pitti: around? | 00:29 |
| ion_ | 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 |
| ion_ | t | 00:30 |
| ogra | i dont think you need "mkdir -p "$DESTDIR"/scripts/init-top" | 00:31 |
| ogra | thats a structure you can rely on being there since we're inside the package that carries this dir | 00:31 |
| ogra | make <<E being <<EOF .... we usually use EOF everywhere makes it easier to keep the overview :) | 00:32 |
| ion_ | ogra: http://heh.fi/tmp/initramfs-tools-compcache.diff | 00:35 |
| ogra | 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 |
| slangasek | kirkland: what's the question? | 00:36 |
| kirkland | slangasek: i think lamont helped solve it with me in #ubuntu-server | 00:37 |
| slangasek | hmm, ok :) | 00:37 |
| kirkland | slangasek: i think something like this will work: status_of_proc /usr/sbin/named bind9 && exit 0 || exit $? | 00:37 |
| ion_ | kirkland: status_of_proc /usr/sbin/named bind9; exit $? should be equal | 00:38 |
| slangasek | kirkland: er, usually you would just do "status_of_proc /usr/sbin/named bind9" when the script is running under set -e | 00:38 |
| ion_ | Oh, sorry. Didn’t consider set -e. | 00:38 |
| slangasek | hence the comment that it's redundant | 00:38 |
| ogra | ion_, i like it a lot :) | 00:38 |
| kirkland | slangasek: right, but only 1 of the 9 packages i've touched has the init script running set -e | 00:39 |
| ion_ | I’m squeamish about the k→K change, but oh well... | 00:39 |
| lamont | slangasek: relying on -e to catch you is also bad | 00:39 |
| kirkland | slangasek: ideally, i'd like to keep the construct/call as identical as possible for consistency | 00:39 |
| lamont | I'm a proponent of being explicit | 00:39 |
| ogra | ion_, <nitpick>can you add some linebreaks to: +if [ "\$1" = prereqs ]; then exit 0; fi</nitpick> | 00:39 |
| slangasek | lamont: why is it bad when writing init scripts and good when writing maintainer scripts? | 00:39 |
| ion_ | ogra: Will do. How about the equivalent thing in the generated script? | 00:39 |
| ogra | heh | 00:40 |
| lamont | slangasek: there's a specific difference between "we got an error" and "we're supposed to return non-zero status now" | 00:40 |
| slangasek | 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 |
| slangasek | lamont: well, there's that, yes | 00:40 |
| lamont | not in the value returned, but in the scratch my head figuring out if it's an error or not case | 00:40 |
| ogra | i missed the one at the top, that *was* the generated script one :) | 00:40 |
| slangasek | right, so in this case that construction makes a certain amount of sense | 00:41 |
| ogra | ion_, so yes, that too | 00:41 |
| ion_ | ogra: Diff updated. | 00:41 |
| ogra | (either put all ifs in one liners or none of them :) ) | 00:41 |
| ogra | ion_, perfect ... now compare that with what we had in the beginning ... thats simple, clean and beautiful code :) | 00:42 |
| kirkland | slangasek: here's the samba one... http://pastebin.ubuntu.com/26066/ | 00:42 |
| ion_ | Yeah | 00:43 |
| slangasek | kirkland: is this status_of_proc being pushed up to Debian, so I can commit that to the Debian Samba package too? :) | 00:43 |
| ogra | sooo ... lets see what we can do about the export .... if i can get infinity's attention :) | 00:43 |
| ion_ | A modprobe.d file could be generated exactly alike, but i’m okay with generating a script instead. :-) | 00:43 |
| ion_ | ogra: I’ll reboot now and check that it actually works. :-) | 00:43 |
| kirkland | slangasek: being pushed, yes... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483285 | 00:44 |
| ubottu | Debian bug 483285 in lsb-base "lsb-base: lsb status_of_proc() function" [Wishlist,Open] | 00:44 |
| ogra | ion_, thats actually a god idea :) | 00:44 |
| ogra | *good even | 00:44 |
| slangasek | kirkland: ok, cool | 00:44 |
| kirkland | slangasek: maintainer agreed to it in principle, cites "adding functionality would break the spirit | 00:44 |
| kirkland | of the freeze, but I'll plan on getting status_of_proc() into unstable | 00:44 |
| kirkland | soon after that migration happens (hopefully soon)" | 00:44 |
| kirkland | slangasek: i'll ping him again and see how that's coming along... | 00:45 |
| kirkland | slangasek: as a DD yourself, what freeze is he talking about, and when might that freeze end? | 00:45 |
| slangasek | that would be the freeze for lenny | 00:45 |
| slangasek | which is going to last, um, a fair few months | 00:45 |
| slangasek | but I don't think this change should be a problem under the freeze | 00:46 |
| slangasek | 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 |
| Nubae | 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 |
| ion_ | ogra: Yeah, it works. | 00:48 |
| kirkland | slangasek: good, i was kinda thinking the same thing... just a new function, no modified existing functionality | 00:48 |
| ogra | ion_, wonderful | 00:49 |
| kirkland | slangasek: let me update the debian bug with an updated patch | 00:49 |
| Nubae | 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 |
| ogra | can you try again with dropping the export | 00:49 |
| slangasek | mathiaz: i.e., get it done while the merge is still otherwise trivial | 00:49 |
| kirkland | slangasek: if you think adding a comment in support would help, I'd appreciate it | 00:49 |
| mathiaz | slangasek: yop - I followed that | 00:49 |
| slangasek | mathiaz: cool | 00:50 |
| mathiaz | slangasek: you renamed it to openldap \o/ - it has been accepted today IIRC - so we can merge it soon | 00:50 |
| mathiaz | slangasek: also noticed that samba 3.2 has been uploaded to unstable | 00:50 |
| slangasek | mathiaz: how are things going on the cn=config front? | 00:51 |
| slangasek | mathiaz: eh, if 3.2 is anywhere other than experimental right now, then I screwed up badly :) | 00:51 |
| mathiaz | slangasek: hm - good question - I've started to look at the code and wraped by around it | 00:51 |
| ion_ | ogra: Nope, doesn’t work. | 00:51 |
| ion_ | % zcat /boot/initrd.img-2.6.26-3-generic | strings | grep compcache | 00:51 |
| ion_ | # An empty value - compcache isn't used, or added to the initramfs at all. | 00:51 |
| mathiaz | slangasek: hm - I must have overlooked the samba upload then | 00:52 |
| mathiaz | slangasek: I noticed that things were commited to the experimental branch | 00:52 |
| slangasek | 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 |
| ogra | ion_, ok, imho it should | 00:52 |
| mathiaz | 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 |
| mathiaz | slangasek: so I'd like to have your feedback on it | 00:53 |
| ion_ | ogra: Perhaps just add export -a to mkinitramfs. | 00:53 |
| ogra | no | 00:53 |
| slangasek | mathiaz: ok - should we schedule some time to sit down for that? | 00:53 |
| mathiaz | slangasek: which brings another question - what is the impact on the lenny freeze on that work ? | 00:53 |
| mathiaz | slangasek: definitely | 00:53 |
| ogra | can you try moving the two lines below "# For dependency ordered mkinitramfs hook scripts." under the config stuff | 00:53 |
| ogra | in mkinitrmafs | 00:54 |
| mathiaz | slangasek: is there a chance that the cnconfig stuff will accepted in lenny (which means in the intrepid timeframe IIUC) ? | 00:54 |
| ogra | that way the functions shooud have access to the vars | 00:54 |
| slangasek | 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 |
| slangasek | mathiaz: if we could get something into unstable this month, that would certainly be ok wrt the lenny timeline, I think | 00:54 |
| ion_ | ogra: How about the equivalent of for hook in hooks/*; do ( . "$hook" ); done? That is, source all hooks in a subshell. | 00:55 |
| mathiaz | slangasek: ok - I plan to submit my work to the debian maintainer list as soon as I've got something | 00:55 |
| ion_ | ogra: Ok, i’ll take a look at that. | 00:55 |
| mathiaz | slangasek: to get some feedback | 00:55 |
| ogra | ion_, i think thats what run_scripts does | 00:56 |
| mathiaz | 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 |
| mathiaz | slangasek: such as loading new schemas or adding a new directory database | 00:56 |
| mathiaz | slangasek: that's the whole point of having the cn=config backend enabled | 00:57 |
| ion_ | ogra: Moving those lines below the config stuff didn’t make it work. | 00:57 |
| ogra | ok | 00:57 |
| ogra | then we need to keep the export :/ | 00:57 |
| mathiaz | slangasek: but then things get complicated really quickly | 00:57 |
| mathiaz | slangasek: that's why I'd like to discuss that and get your input on that | 00:58 |
| slangasek | 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 |
| slangasek | 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:58 |
| slangasek | (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 |
| mathiaz | slangasek: ok - I try not to refactor to much | 00:59 |
| mathiaz | slangasek: I've taken the approach of adding cn=config support to existing functions in slapd.scripts-common | 01:00 |
| ion_ | ogra: Nope, call_scripts doesn’t use . | 01:00 |
| ogra | run_* | 01:00 |
| ogra | oh, right, call_ | 01:01 |
| ogra | sorry | 01:01 |
| ion_ | It would be a bit hairy, though, since hooks check $1 for prereqs. | 01:02 |
| mathiaz | 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 |
| slangasek | that sounds good | 01:02 |
| ion_ | Could be done with something like ( set -- prereqs; . $hook ) for prereqs and ( set --; . $hook ) for running the hook, though. | 01:02 |
| Chipzz | mathiaz: what about the cn=config thing? | 01:03 |
| Chipzz | mathiaz: I'm using that feature in debian for munin monitoring | 01:03 |
| ogra | 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:03 |
| ogra | so lets just keep it | 01:04 |
| mathiaz | Chipzz: I'm working on adding cn=config support to the package | 01:05 |
| mathiaz | Chipzz: so that a default install of slapd in intrepid will use cn=config instead of slapd.conf | 01:06 |
| mathiaz | Chipzz: and we'll also support upgrading from slapd.conf to cn=config | 01:06 |
| Chipzz | ah k | 01:06 |
| Chipzz | mathiaz: could you look into getting this into munin? http://wiki.ruberg.no/index.php/Munin_LDAP_plugins | 01:07 |
| mathiaz | Chipzz: you'd better file a bug about this | 01:07 |
| mathiaz | Chipzz: the chance this get lost will be higher here ;) | 01:08 |
| Chipzz | can do | 01:08 |
| Chipzz | file a bug in debian, ubuntu or both? | 01:08 |
| mathiaz | Chipzz: debian is the best place IMO | 01:09 |
| ogra | ion_, so how about making a debdiff from that so your name is in the changelog ... ? | 01:09 |
| ion_ | ogra: Will do. | 01:09 |
| kirkland | slangasek: patch for samba status attached to: https://bugs.edge.launchpad.net/ubuntu/+source/sysklogd/+bug/203169 | 01:36 |
| ubottu | Launchpad bug 203169 in sysklogd ""status" function for init scripts" [Wishlist,In progress] | 01:36 |
| kirkland | slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/sysklogd/+bug/203169/comments/27 | 01:37 |
| === nxvl_ is now known as nxvl | ||
| savvas | ok this channel looks more appropriate for this :) | 01:43 |
| savvas | does this patch look good? http://launchpadlibrarian.net/15898720/python-apt_0.7.4ubuntu7.2.debdiff | 01:43 |
| emgent | Bug #244093 | 01:47 |
| ubottu | 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 |
| savvas | oh, sorry, forgot to mention that | 01:47 |
| emgent | savvas: debdiff is attached. Security Team will see it. | 01:48 |
| savvas | that was quick, thanks emgent! | 01:48 |
| savvas | i don't have to do anything for the moment right? | 01:49 |
| savvas | *anything else | 01:49 |
| emgent | savvas: just subsribe in this bug last uploader. | 01:50 |
| savvas | emgent: to subscribe the maintainer of the package? | 01:52 |
| emgent | savvas: you can subscribe ubuntu-main-sponsor | 01:53 |
| emgent | but Michael Vogt is APT Master :) | 01:54 |
| savvas | it said it will notify the maintainer | 01:54 |
| savvas | ah ubuntu-main-sponsor, I'll do that | 01:54 |
| savvas | - ubuntu-main-sponsors Ubuntu Sponsors for main | 01:55 |
| savvas | this one emgent ? | 01:55 |
| emgent | savvas: true. | 01:55 |
| emgent | but i suggest to subscribe Michael Vogt too.. | 01:55 |
| savvas | done and done! | 01:56 |
| emgent | now wait :) | 01:56 |
| savvas | I think his nick is mvo at launchpad, hopefully that's correct | 01:56 |
| emgent | him will review it | 01:57 |
| emgent | mvo, sure. | 01:57 |
| savvas | this package fixing is fun! :) | 01:57 |
| slangasek | kirkland: you may wish to tie that in to Debian bug #488275 | 01:58 |
| ubottu | Debian bug 488275 in samba "samba and winbind: initscript miss 'status' option" [Wishlist,Open] http://bugs.debian.org/488275 | 01:58 |
| kirkland | slangasek: sure, you bet | 02:03 |
| emgent | i go to sleep, night people | 02:26 |
| ion_ | ogra: Is the comment i added to the COMPCACHE_SIZE documentation ok? http://heh.fi/tmp/initramfs-tools_0.92bubuntu3.debdiff | 02:27 |
| ion_ | 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 |
| ion_ | ogra: ...to REVU | 02:28 |
| ogra | you should (sorry for tht) probably rename it again | 02:30 |
| ogra | like compcache-tools ... | 02:30 |
| ogra | i.e. take fuse as example here | 02:30 |
| ion_ | 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 |
| ion_ | Should i go with tools or utils? :-) | 02:31 |
| ogra | compcache-config ? | 02:31 |
| ogra | no idea ... but just calling it compcache somewhat doesnt seem to fit | 02:32 |
| ion_ | 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 |
| ion_ | And an init script. | 02:33 |
| ion_ | Unless there are better ideas. :-) | 02:33 |
| ogra | probably LaserJock has one :) | 02:35 |
| LaserJock | ogra: one what? | 02:35 |
| ion_ | 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 |
| ion_ | tools? utils? config? None of them seems to fit exactly. :-) | 02:36 |
| LaserJock | compcache-setup? | 02:37 |
| ion_ | Not bad. | 02:37 |
| ion_ | I’ll use -setup. | 02:37 |
| ogra | yeah, i knew it :) | 02:37 |
| LaserJock | ogra: so I haven't gone to uni for 10 years for nothing?!?! :-) | 02:38 |
| ogra | you can cut out little presents to sell on flea markets with lasers and the like as well, i know :) | 02:39 |
| ogra | LaserJock, so how is life ? | 02:40 |
| LaserJock | ogra: hmmm, busy :-) | 02:42 |
| ogra | yeah, same here | 02:42 |
| LaserJock | ogra: getting closer to being done though | 02:42 |
| ogra | heh, me too ... | 02:43 |
| LaserJock | should be done before next UDS | 02:43 |
| ogra | i'm just building whats supposed to become the final cmpc image for hardy | 02:43 |
| LaserJock | (yeah, my calendar revolves around Ubuntu development cycles) | 02:43 |
| ogra | hey and its even in the US | 02:43 |
| LaserJock | ogra: oh awesome, newer kernel? | 02:43 |
| ogra | so we'll meet :) | 02:43 |
| LaserJock | I hope | 02:44 |
| ogra | -19.something yes | 02:44 |
| LaserJock | I'll try it out once you're finished | 02:44 |
| ogra | i'm still struggling with the display driver though | 02:44 |
| LaserJock | :( | 02:44 |
| ogra | they insist on using their hacked up i810 | 02:44 |
| LaserJock | ah | 02:44 |
| ogra | but thats two versions behind ours (which is outdated as well) | 02:45 |
| LaserJock | I just have problem with wanting to download all kinds of goodies and filling the drive | 02:45 |
| ogra | yeah, not much i can do about that though | 02:45 |
| ogra | i could do the sme as metasys if i were evil ... | 02:45 |
| LaserJock | no, it's already quite amazing how much you've shrunk it | 02:45 |
| ogra | they link /usr/bin/rpm to /dev/null there | 02:46 |
| jdstrand | 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 |
| LaserJock | ogra: umm, ewww | 02:46 |
| ogra | well, you wont fill up the system with apps :) | 02:46 |
| LaserJock | I suppose | 02:47 |
| ogra | no idea about -rt, sorry | 02:47 |
| kees | jdstrand: uhhhh... I thought they were part of the upload? | 02:47 |
| LaserJock | ogra: Windows had a good way of doing that, just run out of memory so the installer dies | 02:47 |
| jdstrand | kees: apt-cache search linux-image|grep 19 | 02:47 |
| jdstrand | linux-image-rt still points to -18 | 02:48 |
| ogra | LaserJock, well, but kill the device a minute in advance by trying to bring up a ppup about low diskspace :) | 02:49 |
| ogra | *popup | 02:49 |
| kees | Package: linux-image-rt | 02:50 |
| kees | Depends: linux-image-2.6.24-19-rt, linux-ubuntu-modules-2.6.24-19-rt | 02:50 |
| * jdstrand scratches head | 02:50 | |
| kees | jdstrand: I mean, I see the older package info to, but -19 is there for me | 02:50 |
| jdstrand | what's with my local debmirror... | 02:50 |
| kees | me too | 02:50 |
| kees | 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 |
| jdstrand | kees: hmm, I see it on all the machines except the one actually using -rt. sorry for the noise | 02:52 |
| kees | np. I wonder what that machine is doing? | 02:53 |
| ion_ | ogra: Ok, http://heh.fi/tmp/initramfs-tools_0.92bubuntu3.debdiff updated and compcache-setup uploaded to REVU. | 02:53 |
| jdstrand | meh, -updates for main and restricted, but not universe. I'm a dolt | 02:54 |
| ogra | ion_, err, updated ? | 02:54 |
| ogra | ion_, i uploaded it 10mins ago :) | 02:54 |
| ion_ | ogra: “< ion_> ogra: Is the comment i added to the COMPCACHE_SIZE documentation ok?” – updated the comment. | 02:54 |
| ogra | oh, k | 02:55 |
| jdstrand | kees: fun-- looks like ruby1.9 did not build on i386 or lpia-- test_copy_stream_rbuf() hung :/ | 03:25 |
| jdstrand | (intrepid) | 03:25 |
| jdstrand | kees: all other archs built fine | 03:25 |
| jdstrand | kees: I'll try to see what's happening tomorrow | 03:25 |
| jdstrand | heh: Build killed with signal 15 after 150 minutes of inactivity | 03:26 |
| ion_ | I think there was a discussion about that here some time ago. Didn’t really follow it, though. | 03:26 |
| jdstrand | ion_: if you are responding to me, I was the last person to talk about it in here :) | 03:29 |
| === gaurdro is now known as MenschenFleisch | ||
| ion_ | Heh, ok | 03:30 |
| lamont | if I send email to launchpad to update a bug, does it have to be signed? | 04:16 |
| lamont | and where does it go, and all that | 04:16 |
| * lamont goes off to find the right wiki page | 04:16 | |
| TheMuso | 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 |
| lamont | I wanna make it say FixCommitted | 04:19 |
| TheMuso | lamont: Then you need to sign the message. | 04:19 |
| lamont | and then drop that into a commit hook | 04:19 |
| lamont | and if I have to sign it, maybe I don't care enough yet | 04:20 |
| Hobbsee | er, you rpobably need to sign all mails, no? | 04:21 |
| Hobbsee | why not set it up to sign by default? | 04:21 |
| Hobbsee | lamont: https://help.launchpad.net/BugTrackerEmailInterface | 04:21 |
| lamont | Hobbsee: hence the maybe I don't care enough... I have to sign tags, not every commit | 04:22 |
| slangasek | 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:23 |
| lamont | slangasek: ah - what was the objection | 04:24 |
| lamont | ? | 04:24 |
| kirkland | slangasek: i recently switched to using /bin/pidof | 04:24 |
| kirkland | slangasek: i was previously using pidofproc() which has a more sophisticated mechanism for obtaining the pid from pidfiles | 04:24 |
| slangasek | lamont: that it doesn't respect PID files | 04:24 |
| kirkland | slangasek: however, pidofproc() uses "kill -0" to see if a daemon is active | 04:24 |
| slangasek | it violates the spirit of Debian policy's guidelines on init scripts | 04:25 |
| slangasek | (but not the letter, since the letter says nothing about a 'status' arg :) | 04:25 |
| kirkland | slangasek: which only works if you're the process owner or root | 04:25 |
| lamont | kirkland: not respecting pid files is bad | 04:25 |
| ion_ | Upstart will void the need for pid files. \o/ | 04:28 |
| lamont | 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 |
| lamont | ion_: bullcrap | 04:28 |
| lamont | or how will you handle having two instances of a daemon? | 04:28 |
| ion_ | How about having two Upstart job instances? :-) | 04:29 |
| lamont | maybe | 04:29 |
| kirkland | :-/ | 04:29 |
| lamont | now tell me how the control command that uses signals tells how to communicate with the daemon? | 04:29 |
| lamont | IOW. where did you move the pid file with upstart? | 04:29 |
| ion_ | Doesn’t the daemon provide a socket you can talk to, or a D-Bus API or something equivalent? | 04:30 |
| lamont | (there are admins who prefer to run bind without the control port, and just have rndc use kill to talk to it...) | 04:30 |
| lamont | for those admins, the API is "kill" | 04:30 |
| ion_ | They’re free to use PID files. | 04:31 |
| ion_ | Or query the PID from Upstart, or whatever. | 04:31 |
| lamont | 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 |
| lamont | and I don't see that there's a need for non-root to query a daemon status | 04:32 |
| kirkland | lamont: um.... | 04:33 |
| lamont | well, it's a bug | 04:33 |
| lamont | or maybe I'll just not admit to 'status' being there in the usage. | 04:33 |
| kirkland | 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 |
| lamont | yeah - I know | 04:33 |
| kirkland | i can add that tomorrow | 04:34 |
| kirkland | i'm absolutely burnt out on this one today :-S | 04:34 |
| lamont | 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 |
| lamont | kirkland: understood | 04:34 |
| lamont | I'm about to crawl into bed myself | 04:35 |
| kirkland | lamont: okay... i'll ping you tomorrow then | 04:35 |
| lamont | hrm... time to go read up on how to get procmail to delete a header from certain mail messages that it receives | 04:40 |
| lamont | because reply-to: $LIST is just plain stupid and wrong | 04:41 |
| lamont | (and no, not an ubuntu list) | 04:41 |
| * 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:54 | |
| TheMuso | Hrm I take it b ack, configure.in is included, but no Makefile.am files. :S | 04:55 |
| lamont | if I upload a ...-2~build1 version, will the autosyncer simply overwrite it with -2 once that shows up in debian? | 05:01 |
| Hobbsee | lamont: for intrepid, or? | 05:04 |
| lamont | yeah | 05:04 |
| Hobbsee | lamont: isn't that a moot point? the autosyncer has already been turned off for intrepid | 05:04 |
| lamont | trying to hop-skip around the fact that it's NEW in debian | 05:04 |
| lamont | true | 05:05 |
| lamont | 'twas more one of making sure that MoM wouldn't object. :) | 05:05 |
| TheMuso | hrm ok it does have a soname. | 05:12 |
| LaserJock | TheMuso: so, umm, why are you kicking upstream again? :-) | 05:14 |
| lamont | there. bind9_9.5.0.dfsg.P1-2~build1 uploaded to intrepid. g'night. | 05:16 |
| TheMuso | 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. | 05:29 |
| ion_ | Note to self: read the tens of previous notes to self about buying an UPS. | 06:24 |
| === BenC1 is now known as BenC | ||
| dholbach | good morning | 07:01 |
| TheMuso | Morning dholbach. | 07:03 |
| dholbach | hi TheMuso | 07:03 |
| dholbach | TheMuso: thanks for your reply | 07:03 |
| TheMuso | dholbach: You're welcome | 07:03 |
| === ion__ is now known as ion_ | ||
| pitti | Good morning | 07:25 |
| ion_ | Howdy | 07:25 |
| pitti | tjaalton, tseliot: new nvidia-glx working perfectly here with current intrepid (new X.org) | 08:04 |
| pitti | (-173) | 08:05 |
| tseliot | pitti: great :-) | 08:05 |
| seb128 | hey pitti | 08:06 |
| pitti | good morning seb128! | 08:06 |
| bryce | pitti: :-) | 08:06 |
| tseliot | bryce: hi ;) | 08:07 |
| tjaalton | pitti: great, I'll install it too | 08:07 |
| tjaalton | ..shortly | 08:07 |
| bryce | tseliot: heya | 08:07 |
| dholbach | hi seb128! | 08:09 |
| seb128 | hey dholbach | 08:09 |
| seb128 | dholbach: getting ready for your holidays? ;-) | 08:09 |
| dholbach | yeah :) | 08:09 |
| dholbach | lots of other stuff left to do still :) | 08:09 |
| dholbach | how's Istanbul? | 08:09 |
| seb128 | great, I'm sure you would like it | 08:12 |
| dholbach | definitely :) | 08:12 |
| dholbach | 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 |
| seb128 | lol | 08:13 |
| dholbach | so... yeah - I'd love to go there at some stage | 08:13 |
| seb128 | a bit warm in the afternoon to my taste | 08:14 |
| dholbach | but I very much look forward to India :) | 08:14 |
| seb128 | but otherwise lot of typical places, sunny weather, GUADEC is great | 08:14 |
| seb128 | and nice to see everybody there again | 08:14 |
| dholbach | seb128: does mvo get any vegetarian food? :) | 08:15 |
| seb128 | he seems to be happy so far | 08:15 |
| seb128 | we had to go to several restaurants to find something good for him but we managed | 08:15 |
| dholbach | seb128: talking about vegetarians always reminds me of this one Tintin comic where Captain Haddock uses "Vegetarian" as an insult :-) | 08:18 |
| seb128 | dholbach: mvo sends you a hug | 08:18 |
| seb128 | ;-) | 08:18 |
| dholbach | hug him back for me :) | 08:18 |
| dholbach | http://www3.sympatico.ca/brooksdr/haddock/main.htm :-) | 08:20 |
| liw | dholbach, is there a word of more than three syllables that Haddock didn't use as an insult? :) | 08:29 |
| ion_ | Billions of blistering barnacles! | 08:30 |
| seb128 | hey | 08:37 |
| seb128 | is there any known intel issue on intrepid? | 08:37 |
| seb128 | the user gets an error about dri2 which couldn't be loaded | 08:37 |
| seb128 | and then a stacktrace | 08:37 |
| seb128 | X and then libfb.so | 08:38 |
| seb128 | and then libexa.so | 08:38 |
| seb128 | let's try XAA | 08:38 |
| pitti | seb128: dist-upgrade harder :) | 08:38 |
| bryce | dri2 is not enabled yet due to lack of memory manager in libdrm | 08:38 |
| pitti | seb128: I had the same yesterday (I think, anyway), X.org crashed | 08:38 |
| seb128 | pitti: tricky to connect to wireless network using only command line tools | 08:38 |
| pitti | seb128: do you have 2:2.3.2-2ubuntu2? | 08:39 |
| seb128 | pitti: not sure but he switched to XAA and that works, I guess he will upgrade next | 08:41 |
| tjaalton | the error is cosmetic | 08:42 |
| tjaalton | um, the DRI2 error.. | 08:43 |
| seb128 | alright | 08:44 |
| seb128 | thanks guys, have to go now, see you later | 08:44 |
| tjaalton | it's already fixed upstream so that it won't complain if the xserver is built without dri2 | 08:45 |
| tjaalton | ie. it won't try to load it | 08:45 |
| === 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 | ||
| asac_the_3rd | 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:29 |
| pitti | asac: you can use the PPA; they get new packages as soon as Rosetta exports them | 09:37 |
| pitti | asac: theoretically it should have built new ones last night | 09:38 |
| undef | hello | 09:42 |
| ArneGoetje | pitti: for hardy the cronjob runs on thursday and sunday | 09:42 |
| pitti | 0 2 * * 3,0 | 09:43 |
| pitti | doesn't that mean 2am on Sunday and Wednesdays? | 09:43 |
| ArneGoetje | pitti: oh, sorry... :) | 09:43 |
| === dholbach_ is now known as dholbach | ||
| siretart | slangasek: I have a new xine-lib upload ready (new upstream version, but no so-bump) that contains 2 security issues. I assume that security fixes do not qualify to break the freeze, is that right? | 09:58 |
| slangasek | siretart: if they're severe security issues, I think it probably should break the freeze | 09:59 |
| siretart | they are LP: #235904 and LP: #218652 | 10:00 |
| siretart | bug #235904 and bug #218652 | 10:00 |
| slangasek | it's 2am, you won't get a very good analysis from me of whether they're severe, sorry :) | 10:00 |
| ubottu | Launchpad bug 235904 in xine-lib "[CVE-2008-1878] Inadequate bounds checking in the NES Sound Format (NSF) demuxer" [Undecided,Fix committed] https://launchpad.net/bugs/235904 | 10:00 |
| ubottu | Launchpad bug 218652 in xine-lib "CVE-2008-1686: Multiple speex implementations insufficient boundary checks" [Undecided,In progress] https://launchpad.net/bugs/218652 | 10:00 |
| siretart | okay. then I'll stay better on the safe way and wait until the alpha-2 release | 10:01 |
| asac | pitti: somehow the langpacks from last night didnt update the mozilla.tar.gz | 10:07 |
| asac | at least looking at install.rdf suggests that its not from the new tarball | 10:07 |
| pitti | what's the version? | 10:07 |
| asac | pitti: oh sorry | 10:07 |
| * pitti looks at the logs | 10:07 | |
| asac | let me check something else | 10:07 |
| pitti | asac: hm, the log looks good | 10:08 |
| cjwatson | woo! live CD built, even if it's 80MB oversized. now I can stand a chance of debugging ubiquity | 10:09 |
| pitti | 80! | 10:10 |
| pitti | cjwatson: ah, due to recommends, I suppose? | 10:10 |
| asac | pitti: do you still have the the sources lying on rookery or somewhere? | 10:11 |
| asac | especially the unpacked translation dir? | 10:11 |
| pitti | asac: yes, they are always there, /srv/language-packs.ubuntu.com/hardy-proposed/ | 10:11 |
| pitti | those are the language-pack-* source packages unpacked | 10:11 |
| pitti | asac: which translation dir? | 10:11 |
| asac | pitti: yes, but where is the unpacked translation tarball you used? | 10:12 |
| pitti | asac: I don't keep that, I remove it after processing | 10:12 |
| pitti | just download it again on rookery if you need it, it's fast | 10:12 |
| asac | pitti: i have the one here locally | 10:13 |
| asac | pitti: its just that the install.rdf in the mozilla.tar.gz is still the old one ... which i cannot find anywhere in the new tarball :( | 10:13 |
| asac | e.g. the tarball i locally downloaded has <maxVersion>1.9.0.*</maxVersion> | 10:13 |
| asac | but the langpacks in PPA have 1.9 | 10:14 |
| asac | let me check the sources you pointed me too ... not that i grabbed the wrong ones from ppa | 10:14 |
| * asac runs xpi processor manually on rookery | 10:21 | |
| cjwatson | pitti: yes | 10:24 |
| cjwatson | (almost certainly) | 10:24 |
| ogra | cjwatson, so, i set the compcache spec to imlemented ... the initramfs chages landed yesterday night, what value would you suggest to use for the start ? (i think we should start to use it on the liveCD asap to determine the best value for it there) | 10:33 |
| ogra | *implemeted even | 10:33 |
| asac | pitti: i have the feeling that you didnt use the latest update tarball | 10:33 |
| asac | pitti: the result are good here | 10:33 |
| asac | https://translations.edge.launchpad.net/ubuntu/hardy/+language-packs | 10:33 |
| asac | which one did you pull? | 10:33 |
| asac | Delta language pack: 2008-07-08 23:01:42 CEST | 10:34 |
| pitti | I always wget https://translations.launchpad.net/ubuntu/hardy/+latest-delta-language-pack | 10:34 |
| asac | pitti: look at the page | 10:34 |
| asac | maybe its broken? | 10:34 |
| asac | under current language packs | 10:34 |
| asac | there is Delta pack: none yet | 10:34 |
| pitti | 1:8.04+20080705 | 10:35 |
| asac | hmm ... no the one i get through that url is good | 10:35 |
| pitti | hm, that's indeed not the most current one | 10:35 |
| asac | strange | 10:35 |
| pitti | seems that +latest-delta-language-pack gave me the second-latest :-( | 10:35 |
| asac | the latest url redirects to: | 10:35 |
| asac | https://launchpadlibrarian.net/15901351/ubuntu-hardy-translations-update.tar.gz | 10:35 |
| asac | the direct link gives: | 10:36 |
| asac | http://launchpadlibrarian.net/15901351/ubuntu-hardy-translations-update.tar.gz | 10:36 |
| pitti | that seems correct | 10:36 |
| asac | thats the same .... maybe a delay? | 10:36 |
| pitti | apparently not so at 2 am | 10:36 |
| asac | yeah ok. | 10:36 |
| lool | Is someone from the intrepid alpha 2 release team up? | 10:36 |
| asac | pitti: let me blacklist a few more before you rerun ;) ... let you know in a few minutes | 10:36 |
| pitti | lool: please just toss concrete questions to slangasek and me | 10:36 |
| lool | xkeyboard-config's upstream prepared a patch for LP #246834 and wants me to try to get it in alpha 2 | 10:37 |
| ubottu | Launchpad bug 246834 in xkeyboard-config "No support for for Mac-like keyboard layouts with extra characters" [Undecided,Fix committed] https://launchpad.net/bugs/246834 | 10:37 |
| lool | pitti: Wasn't sure whom to ping at this time of the day | 10:37 |
| pitti | asac: ok, I was just about to rerun; standing by then | 10:37 |
| lool | pitti: Upstream says the attached debdiff is safe as it only adds a new keyboard implementation behind a mode which was already defined anyway | 10:37 |
| lool | And pushes to try to get the fix in alpha 2 | 10:37 |
| lool | I don't think it should affect anyone, but since we're in soft freeze, I'm checking whether it's reasonnable to upload | 10:38 |
| pitti | lool: looks ok to me | 10:38 |
| lool | Ok, will push | 10:38 |
| ogra | why oh why dont we have an upstream bzr branch anywhere for initramfs-tools (or am i just blind) | 10:48 |
| asac | pitti: ok. i think the blacklisting is good now. its amazing how many new translations have been started :) | 10:49 |
| asac | pitti: i am doing one test run here now and let you know | 10:49 |
| pitti | ArneGoetje: the builds should have been settled now, so call for testing can go out | 10:54 |
| cjwatson | ogra: http://code.google.com/p/compcache/wiki/CompilingAndUsing says "default size of 25%" so how about that? | 10:55 |
| cjwatson | ogra: I agree it's a good idea to start using it as soon as possible | 10:55 |
| ogra | cjwatson, well, 256M + 25% = 320M ... does that sound like it suffices ? | 10:56 |
| * ogra doesnt know the current ubiquity reqs | 10:57 | |
| ion_ | That’s not what the 25% means. | 10:57 |
| ogra | its adding 64M swap, no ? | 10:57 |
| ogra | at least it does that here using the default | 10:57 |
| ion_ | Say, it happens to compress whatever pages are swapped to the compcache with a ratio of 2:1. In that case, a full compcache of 64 MiB has allocated 32 MiB of RAM. Thus, you’ve gained 32 MiB of extra capacity. | 10:59 |
| cjwatson | ogra: bear in mind that ubiquity currently starts up with no swap; it surely won't make it worse :) | 10:59 |
| ogra | yeah, indeed its a matter of data and compression rate | 10:59 |
| === ara_ is now known as ara | ||
| lool | Hmm I can't branch casper | 11:00 |
| * cjwatson tries to find the bugs that have been filed on the subject | 11:00 | |
| lool | On hardy I get: KnitCorrupt: Knit 9e/x_%254datt_%255aimmerman_%253cmatt.zimmerman%40canonical.com%253e_%2553un_%254dar_13_00%253a51%253a19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21 | 11:00 |
| ion_ | On a swapless system, you might even consider something like 100% or 150%. | 11:00 |
| lool | I guess I can check it out instead | 11:00 |
| ogra | ion_, but with the default i geta 64M swap device on a 256M system here ... | 11:00 |
| cjwatson | lool: I think I've seen that before, but not been able to solve it. Could you ask the bzr guys for help as to what we should do? | 11:00 |
| lool | Sure | 11:00 |
| cjwatson | ogra: bug 193552 suggests cache size of 128000 | 11:04 |
| ubottu | Launchpad bug 193552 in ubiquity "Support 256MB machines in Ubiquity." [Undecided,Confirmed] https://launchpad.net/bugs/193552 | 11:04 |
| ogra | ok | 11:04 |
| ogra | lets start with that ... | 11:04 |
| cjwatson | I'm reassigning that bug over to livecd-rootfs for now, but maybe it's casper? | 11:04 |
| cjwatson | I guess it should be casper, re-reassigned | 11:05 |
| ogra | nah, livecd-rootfs should create te conf.d file | 11:05 |
| ion_ | conf-hooks.d file, i think | 11:05 |
| ogra | nope | 11:05 |
| cjwatson | ogra: you sure? I don't like having too much stuff in livecd-rootfs | 11:05 |
| ion_ | Judging from comments in mkinitramfs | 11:05 |
| ogra | /usr/share/initramfs-tools/conf.d/ | 11:05 |
| cjwatson | why not have casper output that? | 11:06 |
| ogra | because you need to regenerate the initramfs for it to take effect | 11:06 |
| ion_ | conf.d: for boot scripts, they land on initramfs. Deprecated for hook config. | 11:06 |
| ion_ | conf-hooks.d: for, well, hooks :-) | 11:06 |
| asac | pitti: ok ... please rerun | 11:06 |
| cjwatson | ogra: which casper does | 11:07 |
| pitti | asac: started | 11:07 |
| ogra | ion_, we made it a initramfs.conf option ... the system dir for the overrides is /usr/share/initramfs-tools/conf.d/ (the admin override dir would be /etc/initramfs-tools/conf.d/) | 11:07 |
| ion_ | ogra: mkinitramfs sources all of /e/i/conf.d, /u/s/i/conf.d and /u/s/i/hooks-conf.d. Please see the comments in mkinitramfs. | 11:08 |
| ion_ | It seems very clear to me that you’re supposed to use hooks-conf.d for something that a hook uses, not a script. | 11:08 |
| ogra | ion_, well, i will stick to the implementaition :) | 11:08 |
| ogra | which currently uses initramfs.conf | 11:09 |
| ogra | lets not make it extra complicated :) | 11:09 |
| ion_ | Huh? | 11:09 |
| ion_ | You’re supposed to override initramfs.conf options affecting hooks in hooks-conf.d and ones affecting scripts in conf.d. As simple as that. :-) | 11:10 |
| ogra | the feature is documented in intramfs.conf | 11:10 |
| ogra | the override dirs for that file apply | 11:10 |
| ion_ | The manpage seems to be out of sync with the implementation. | 11:10 |
| ogra | we made it a global var so lets use the global config | 11:11 |
| ogra | (hooks-conf.d would come into play if you wouldnt have the export i think) | 11:11 |
| ion_ | Both are sourced by mkinitramfs the same way currently, but hooks-conf.d files aren’t copied to initramfs because they only affect hooks. | 11:12 |
| ion_ | If you use conf.d, you just end up with an unnecessary file in the initramfs. | 11:13 |
| ion_ | Otherwise the behavior is exactly the same. | 11:13 |
| ogra | i dont end up with an unnecessary file | 11:13 |
| ogra | if that file is there i *use* compcache ... | 11:14 |
| ogra | if its missing i dont | 11:14 |
| ion_ | If the file overrides COMPCACHE_SIZE, it’s unnecessary in initramfs. | 11:14 |
| ogra | very easy | 11:14 |
| ogra | COMPCACHE_SIZE in initramfs.conf is only for manual user edits and for doumentation ... no tool or imagebuilder we use will modify it directly | 11:15 |
| ion_ | None of the files installed to the initramfs by the hook use COMPCACHE_SIZE. | 11:15 |
| ogra | a tool creating an image is supposed to drop a one liner file into one of the conf.d dirs that just contains COMPCACHE_SIZE with a value | 11:16 |
| ion_ | No, hooks-conf.d :-) | 11:16 |
| ogra | ion_, feel free to use hooks-conf.d in compcache-setup | 11:16 |
| ion_ | I am. | 11:16 |
| ogra | fine with me :) | 11:16 |
| ArneGoetje | pitti: already went out | 11:16 |
| pitti | nice, thanks | 11:17 |
| ion_ | I’m just pointing out that if you don’t, you just end up using a deprecated feature and having an extra, unneeded file in the initramfs. | 11:17 |
| ogra | ion_, i dont | 11:17 |
| ogra | the file is needed if i want to use compcache ... it wont exist if i dont want to use compcache | 11:18 |
| ogra | so there is no unneeded file | 11:18 |
| ion_ | You put conf.d/foo which contains ‘COMPCACHE_SIZE=...’ into initramfs. NOTHING within the initramfs uses that variable. | 11:18 |
| ogra | the compcache hook does as soon as the initramfs is regenerated | 11:19 |
| ion_ | The hook uses it outside initramfs while creating an initramfs. | 11:19 |
| ogra | which is done by either the image build tool or in liveCD case by casper at package install time | 11:19 |
| ion_ | The hook is not installed to the initramfs, or called from within the initramfs. | 11:20 |
| ogra | it is if the var is set | 11:20 |
| ogra | as soon as you regen the image with it | 11:20 |
| ogra | which is exactly what we do | 11:20 |
| ogra | casper will drop the conf.d file in place and run update-initramfs | 11:20 |
| ogra | after that compcache is used | 11:21 |
| ogra | cjwatson, i actually prefer livecd-rootfs simply due to the fact that UME or UNR might use it but not use casper, so we have a guaranteed central place o set it up | 11:22 |
| ogra | s/o/to/ | 11:22 |
| ogra | for all kind of imagebuilds we do | 11:23 |
| ion_ | update-initramfs calls mkinitramfs, which sources initramfs.conf, conf.d and hooks-conf.d, all of these from the *filesystem*, not *initramfs* and then runs the hooks. The compcache hook parses COMPCACHE_SIZE and installs a script to initramfs that loads the compcache module with a precomputed kilobyte amount. That script doesn’t use COMPCACHE_SIZE, this installing the conf file to initramfs is useless. Whenever update-initramfs is called, the compcache ... | 11:24 |
| ion_ | ... hook gets COMPCACHE_SIZE from the normal filesystem, not from within the initramfs. I don’t know how to put this any clearer: there’s absolutely no need to install the conf.d file to the initramfs, and putting the COMPCACHE_SIZE to conf.d instead of hooks-conf.d is deprecated, as the comments within mkinitramfs clearly say. | 11:24 |
| ion_ | A future version of mkinitramfs might very well stop sourcing conf.d | 11:25 |
| ogra | ion_, all scripts we use i have ever seen use conf.d for consistency i want to eep it there it doesnt make *any* difference where the file is as long as the var is there during update-initramfs | 11:25 |
| ogra | ion_, we are upstream of initramfs-tols | 11:26 |
| ogra | *tools | 11:26 |
| cjwatson | ogra: it's still the wrong place, I'm afraid; livecd-rootfs should do as few things as possible itself - it's just supposed to copy all the bits in place and do the minimum necessary tweaks | 11:26 |
| cjwatson | ogra: we *were* upstream of initramfs-tools, but that is not realistically the case any longer | 11:26 |
| ogra | cjwatson, hmm, k | 11:26 |
| ogra | cjwatson, so who is ... Keybuk is stating that every time i talk to him and advised me often to give that as answer to debian people | 11:27 |
| cjwatson | functionally, Debian is the upstream | 11:27 |
| ogra | ok | 11:27 |
| * ogra makes a mental note about that :) | 11:27 | |
| cjwatson | this is clear from the current changelog | 11:27 |
| cjwatson | I have no problem with us making our historical contributions to initramfs-tools prominent, but we don't gain anything by claiming we're doing something we aren't | 11:28 |
| ion_ | “Add /usr/share/initramfs-tools/conf-hooks.d for hook options on mkinitramfs run. Do not land in initramfs.” maks@debian.org in initramfs-tools 0.91 | 11:28 |
| ion_ | mkinitramfs: # FIXME: deprecated those settings on mkinitramfs run | 11:30 |
| ion_ | # these conf dirs are for boot scripts and land on initramfs | 11:30 |
| ogra | ion_, as long as both works i really dont care but i want to keep consistency with othe scripts (ltsp drops the config into conf.d as i belive other netboot setups do as well) | 11:30 |
| ion_ | They’re obviously intending to *fix* sourcing conf.d within mkinitramfs. :-) | 11:30 |
| ion_ | When they do, everything that drops settings for *hooks* to conf.d breaks. | 11:31 |
| ogra | they dont atm, right ? | 11:31 |
| ion_ | At the moment, conf.d are still sourced in mkinitramfs. | 11:31 |
| ogra | right | 11:31 |
| ion_ | To future-proof the files, better move them to conf-hooks.d | 11:31 |
| ogra | if they drop that and we merge that we will have more to fix | 11:31 |
| ogra | cjwatson, sorry i tend to look at the wrong changelog ... the curse of being stuck on hardy :/ i see what you mean looking at intrepid ... | 11:35 |
| lool | cjwatson: #246880 and http://launchpadlibrarian.net/15905205/bzr.txt for the log of the IRC conversation trying to recover this branch; didn't succeed sadly | 11:39 |
| lool | cjwatson: If you need access to the bzr tree, you might be able to work on it using alioth's bzr | 11:39 |
| lool | I prefer not touching it though | 11:39 |
| lool | I only had a trivial typo to fix which doesn't solve any real life bug | 11:39 |
| cjwatson | lool: no, I've already got it and it works fine for me | 11:43 |
| cjwatson | though I think that might be a checkout | 11:43 |
| cjwatson | lool: sorry, I see I implied that it was preventing me from working on it - it isn't | 11:44 |
| cjwatson | lool: a checkout works just fine | 11:44 |
| cjwatson | lool: any reason why you would ever not want to use a checkout for it? I hardly ever use real branches of trunk-type things on bazaar.launchpad.net | 11:44 |
| lool | cjwatson: I almost always branch things from LP | 11:45 |
| cjwatson | why? | 11:45 |
| cjwatson | that just means you have to remember to push :) | 11:45 |
| lool | It allows me to act consistently from all my bzr repos | 11:45 |
| pitti | cjwatson: interesting; I almost never use checkouts | 11:45 |
| lool | I simply never think "is this a checkout or a branch?" I always act on them like it's a branch | 11:46 |
| cjwatson | checkouts are brilliant, I use them all the time | 11:46 |
| lool | I know I have to push and pull | 11:46 |
| cjwatson | when I create a branch, I try to push it somewhere and bind it as soon as possible | 11:46 |
| * TheMuso prefers branching, in the event he has to uncommit/revert a revision./ | 11:46 | |
| cjwatson | thereby turning it into a checkout | 11:46 |
| Mithrandir | thekorn: you can uncommit from checkouts too | 11:46 |
| lool | Yeah, I also tend to do "commit commit commit test push" | 11:46 |
| pitti | I like the speed of local branches, and the possibility to uncommit without punishment, as well as saying "this becomes real work now, let's redeclare this as a branch" | 11:46 |
| lool | Not "test commit test commit" | 11:46 |
| TheMuso | Mithrandir: Right, wasn't aware of that. | 11:47 |
| cjwatson | I've been annoyed too many times by "other developer forgot to push" | 11:47 |
| cjwatson | so I intentionally structure my workflow to avoid even accidentally inflicting that on others, as far as possible | 11:47 |
| lool | Perhaps that's something to solve at the "building a package which has a .bzr" level? | 11:47 |
| lool | For instance we could check whether the current tree is a .bzr, whether it's bound or not, and if not whether it's up-to-date | 11:48 |
| siretart | lool: do you know an example package that creates several binary packages, some of them containing shared libs and each of them has a seperate shlibs file? (and preferably uses debhelper) | 11:50 |
| lool | siretart: Don't use .shlibs file, simply call dh_makeshlibs with -V on each package | 11:50 |
| ogra | cjwatson, how do you uncommit in such a setup ? | 11:51 |
| lool | (don't use -V alone of course) | 11:51 |
| siretart | you mean like: `for p in ${packages; do dh_makeshlibs -p${p} ....; done`? | 11:52 |
| * ogra os a typo prone person and likes to be able to roll back changelog entries to fix a typo ... | 11:52 | |
| ogra | :) | 11:52 |
| ogra | s/os/is/ | 11:52 |
| lool | siretart: Something like this, yes | 11:52 |
| cjwatson | ogra: (a) test and diff carefully before commit so I generally don't have to (b) if it's quick, hope that nobody happened to have pulled/updated in the few seconds between commit and "oh shit" (c) you can always just commit a correction | 11:52 |
| cjwatson | but (a) is the most important. Apply care! | 11:52 |
| lool | siretart: If it's for ffmpeg, you need separate calls as the binary package names are not standard and differ per binary package name you act on | 11:52 |
| ogra | i do for the code ... but often dont for the commit entry | 11:52 |
| cjwatson | if you know you're typo-prone, that's the first step | 11:53 |
| lool | IOW it's not a shlib dep on the current package | 11:53 |
| cjwatson | also I use debcommit so I generally write commit text in debian/changelog, not in bzr ci -m | 11:53 |
| siretart | lool: okay. I'm just reading dh_makeshlibs, and I wanted to check if my conclusions are right. thanks | 11:53 |
| pitti | I just often seem to recognize too late that I shuold have started a feature branch instead of doing large work in trunk | 11:53 |
| ogra | pitti, same here | 11:53 |
| ogra | but as you say then its to late anyway ... do better next time :) | 11:54 |
| pitti | yeah, debcommit FTW | 11:54 |
| siretart | (and yes, of course it is ffmpeg ;) | 11:54 |
| lool | Makes me think that another reason I use branches is to allow me to bzr branch the tip which I might not have commit access to or might not want to commit to, then push to my own lp:~lool namespace and tell someone to pull from it | 11:54 |
| lool | siretart: The last dh_makeshlibs example is the one you want | 11:55 |
| lool | dh_makeshlibs -V ’libfoobar1 (>= 1.0)’ | 11:55 |
| lool | Wow I just tried to work from a bzr lightweight checkout and even bzr diff required network UI | 11:57 |
| lool | *IO | 11:57 |
| lool | debcommit -n will hence also wait for IO | 11:58 |
| cjwatson | oh, I don't use *lightweight* checkouts | 11:58 |
| cjwatson | that seems like excessive self-inflicted-pain in most cases | 11:59 |
| lool | I can't checkout casper in any other way sadly | 11:59 |
| lool | You might be luckily reusing an older checkout you had around | 11:59 |
| cjwatson | yes, I've had this for years | 12:05 |
| cjwatson | right, intrepid desktop fails to boot. /me cracks knuckles and dives in | 12:08 |
| pitti | cjwatson: shot in the dark> current kernel doesn't ship unionfs, might that be it? | 12:20 |
| cjwatson | nothing to do with unionfs afaics | 12:22 |
| * pitti crawls back into his hole then | 12:23 | |
| tjaalton | pitti: about nvidia; how should the latest "current" nvidia-glx-xxx be upgraded to nvidia-glx-{xxx+N}? | 12:25 |
| tjaalton | by apt I mean | 12:25 |
| pitti | tjaalton: I thought we didn't want to ship arbitrary names any mroe? | 12:26 |
| tjaalton | pitti: they have versions now (-71, -96, -173, -177) | 12:26 |
| pitti | i. e. once you install a version, you stay wit it? | 12:26 |
| tjaalton | but shouldn't the latest one be just 'nvidia-glx' then? | 12:27 |
| pitti | tjaalton: right, but wasn't the precise idea of those to avoid automatically upgrading to newer versions? | 12:27 |
| tjaalton | pitti: ah, ok. maybe :) | 12:27 |
| ogra | pitti, cjwatson err, didnt we switch to aufs anyway ? | 12:27 |
| cjwatson | ogra: yes. | 12:28 |
| cjwatson | (hence why unionfs is not important) | 12:28 |
| tjaalton | pitti: it would make sense for the "legacy" versions, but for those who want the latest.. | 12:28 |
| ogra | good ... i was worried i had misunderstood :) | 12:28 |
| cjwatson | in any case debugging without seeing the errors is a bit of a mug's game :) | 12:28 |
| pitti | tjaalton: well, if something like this still makes sense, I see those options: (1) build a -latest metapackage, (2) if N+1 is compatible, just keep the package name (slightly confusing, I know), or (3) call the latest version "-latest" instead of -VERSION | 12:28 |
| pitti | tjaalton: but since upstream keeps breaking compatibility, users shouldn't *want* to always get the latest, no? | 12:29 |
| pitti | tjaalton: however, I do see that we need some mechanism to deprecate a particualr version; we can't maintain all of them forever | 12:29 |
| pitti | tjaalton: I think that's where the update-manager hook kicks in (or the debconf note for those using apt-get) | 12:30 |
| pitti | tjaalton: this suspiciously reminds me about the PackageSeries: discussion I had for kernel modules... (https://wiki.ubuntu.com/DesktopTeam/Specs/KernelAbiPackageHandling) | 12:31 |
| tjaalton | pitti: the only problem I see with not having VERSION in the latest package is that the libs and modules could get out of sync. but, that's solved by dkms right? | 12:33 |
| tjaalton | since it builds the modules for all the kernels the users happens to have | 12:33 |
| tjaalton | it's just that on upgrade the user has to be notified that a reboot is in order | 12:36 |
| tjaalton | and these are mainly issues during development | 12:36 |
| ogra | http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/annotate/519?file_id=x_Matt_Zimmerman_<matt.zimmerman%40canonical.com>_Sun_Mar_13_00%3A51%3A19_2005_1366.40 | 12:40 |
| cjwatson | pitti: can we make it Kernel-Version instead? that's already in use for udebs | 12:40 |
| * ogra scratches head | 12:40 | |
| ogra | (thats what i get clicking casper.init in the web UI on the casper LP branch) | 12:42 |
| === ember_ is now known as ember | ||
| ogra | hmm, the same for the whole caspermon subdir ... | 12:45 |
| ogra | i wonder if thats a branch issue or LP bug | 12:45 |
| cjwatson | the branch is dodgy, see lool's problems above | 12:47 |
| ogra | ah, k ... was on my way to #launchpad already :) | 12:48 |
| * ogra ponders how to add compcahe to casper ... we surely dont want it on all casper sessions by default | 12:49 | |
| ogra | (which would indeed be the easy task) | 12:49 |
| cjwatson | ogra: I'd have thought it should depend on the amount of system memory somehow | 12:50 |
| cjwatson | if you have 1GB, you probably don't want it | 12:50 |
| stgraber | ogra: what about something like: amount of memory RAM+SWAP must be = 512MB for the Live environement. Then use compcache to achieve that (if possible) | 12:52 |
| ogra | stgraber, compcache in intramfs as we implemented it is en/disabled at initramfs generation ... if you disable it we dont want any traces of it in the initramfs to save space ... so i need to enable it by default and dynamically set or unset the var in an extra script ... | 12:54 |
| ogra | i'm wondering about the extra script atm :) | 12:54 |
| ogra | i know what to do in there :) | 12:55 |
| ogra | the prob is that we need compcache as early as possible (init-top) so the casper detection has to happen before init-top ... casper itself only starts at premount to process scripts ... | 12:57 |
| ion_ | Btw, since udev currently starts at premount, that’s when compcache actually gets running. udev could be moved to an earlier state, or anything in premount that requires compcache to be running could just prereq udev. | 12:59 |
| cjwatson | there is nothing to stop casper installing an init-top script | 12:59 |
| ogra | i think as soon as udev is run by upstart that will change | 12:59 |
| cjwatson | and it seems to make complete sense to me to have casper do this in init-top, since it's fiddling with initramfs configuration | 13:00 |
| ogra | cjwatson, apart from my resistance to add so much code :) | 13:00 |
| ogra | i dont want to add bloat ;) | 13:00 |
| cjwatson | this isn't bloat | 13:01 |
| cjwatson | and it should be very little code | 13:01 |
| ogra | ion_, ouch, we need a sequence number for the init-top script | 13:01 |
| ogra | its currently just called compcache .... | 13:01 |
| * ogra goes fixing and makes that 20compcache | 13:02 | |
| ion_ | ogra: Huh? zcat /boot/initrd.img-2.6.26-3-generic | cpio -t | grep init-top doesn’t print any number prefixes. | 13:03 |
| ogra | cjwatson, well, my initial idea was a one liner :) compared to that everything is bloat ... but i didnt take dynamic detection into account for casper here | 13:03 |
| ion_ | I thought the prereqs functionality was used instead of a static ordering. | 13:03 |
| ogra | ion_, look at casper :) | 13:03 |
| cjwatson | ogra: more relevantly, look at /usr/share/initramfs-tools/scripts/init-top/ | 13:04 |
| ogra | we'll add init-top as dir to it and have a 10compcache_detect or so .,.. | 13:04 |
| cjwatson | -> no sequence numbers | 13:04 |
| cjwatson | at some point initramfs-tools might change upstream to require that, but it's not there yet | 13:04 |
| ogra | ah, k | 13:05 |
| cjwatson | better to be consistent within the directory than consistent with other directories | 13:05 |
| ogra | well, casper uses it all over the place | 13:05 |
| lamont | and it doesn't do sequence numbers because it actually does dependencies, and doens't need them | 13:05 |
| lamont | (them == sequence numbers) | 13:05 |
| cjwatson | ogra: in its own directories; but it shouldn't do so in init-top, right now | 13:06 |
| ogra | right ... still, we have them everywhere in casper ... seems sane to me to follow the general plot ... and if only for better readability | 13:06 |
| cjwatson | I don't know how to make this any more clear | 13:06 |
| cjwatson | follow the existing practice for init-top | 13:06 |
| cjwatson | not for scripts/casper-* | 13:06 |
| ogra | ok | 13:06 |
| cjwatson | you don't want to mix two different means of resolving ordering within the one directory | 13:07 |
| cjwatson | that way lies utter madness | 13:07 |
| ion_ | Seems to me that if the sh running the initramfs code *happens* to return the entires in a numerical order on init-top/* and the dependency ordering doesn’t *happen* to shuffle their order either, you’re lucky that day. :-) | 13:08 |
| * ogra sighs ... thats making it a lot more complicated :/ the compcache scrit wnt know anything about casper ... | 13:09 | |
| ogra | so we need to dynamically create the PREREQ line | 13:09 |
| ogra | during initramfs build :( | 13:09 |
| ion_ | Are you going to move udev to init-top, btw? | 13:10 |
| ogra | udev will move to upstart soon as i understood scott | 13:10 |
| ion_ | Alright, it will be awesome if we already have upstart-in-initramfs for intrepid. | 13:11 |
| ion_ | ’ll | 13:11 |
| ogra | thats the plan ... | 13:11 |
| ogra | i also think in casper its not overly important to have it as early as on 48M systems ... since our main obective is to make room for the desktop session so whenever udev runs in initramfs wil be fine for a start | 13:13 |
| ogra | it will get more important on 32M ltsp clients or other devices on teh edge with low ram etc ... where you actually require it for booting | 13:14 |
| tjaalton | pitti: would it be ok to fix the intel problems with compiz for alpha2? | 13:18 |
| tjaalton | pitti: a patch for mesa & intel | 13:19 |
| doko | is there a reliable way to add/remove a slave link to an alternative with changing the default for the alternative itself? | 13:22 |
| tjaalton | pitti: sorry, only mesa should be changed. there's also bug 246835 which means that one patch against intel should/could be dropped | 13:28 |
| ubottu | Launchpad bug 246835 in xserver-xorg-video-intel "Check pitch patch should be removed, done differently in upstream source already" [Undecided,New] https://launchpad.net/bugs/246835 | 13:28 |
| cjwatson | soft freeze, so it's at your discretion | 13:29 |
| tjaalton | cjwatson: ok, I think it's worth it. thanks | 13:30 |
| sja | hello, all! may be its offtop. exists driver for webcam logitech eye312 ? thanx | 13:42 |
| azeem | sja: please ask in #ubuntu | 13:44 |
| sja | azeem, its no real :) 1312 members... okey | 13:45 |
| sja | please, say who i can install driver PATA for Geode AMD. my sysmet is not bootable. | 13:52 |
| Pici | sja: This channel is for development, not for support, please ask in #ubuntu, thanks. | 13:53 |
| cjwatson | we don't ship drivers in separate packages (at least mostly, and certainly not in this kind of case) - if it's not shipped as part of the kernel, it's a kernel bug | 13:53 |
| cjwatson | sigh | 13:53 |
| bluefoxicy | BenC: ping, are you ben collins? | 14:43 |
| bluefoxicy | https://blueprints.launchpad.net/ubuntu/intrepid <-- shows compcache as 'implemented' and compcache-usage as 'Drafting', yet both seem to describe the usage of compcache ... ? | 14:44 |
| BenC | bluefoxicy: heh, yes | 14:57 |
| BenC | bluefoxicy: Well, compcache is in the kernel now, but I'm not sure if it's being used on the CD yet | 14:57 |
| === thekorn_ is now known as thekorn | ||
| ogra | BenC, i'm just fixing the intiramfs scripts | 15:07 |
| ogra | bluefoxicy, ^^^ | 15:07 |
| ogra | a patch to use compcache according to the spec landed yesterday | 15:07 |
| pitti | tjaalton: hm, how intrusive is it? if you tested it on an intel and perhaps an nvidia card and it works, I'm fine with it | 15:27 |
| tjaalton | pitti: actually it proved to be harder than I thought so it'll have to wait a proper fix which means post-alpha2 | 15:33 |
| pitti | tjaalton: you still dropped the patch, so that was independent from the mesa fix? | 15:34 |
| tjaalton | pitti: yes, that was independent | 15:34 |
| pitti | infinity: rejecting your procps upload from hardy-proposed, there is no bug reference in the changelog | 15:43 |
| ion_ | benc: What’s the status of getting rid of versioned kernel packages, btw? | 16:18 |
| cjwatson | I thought that was just the source packages, which are done | 16:18 |
| ion_ | I mean the last-known-boot thing. | 16:19 |
| ion_ | Uh, last-good-boot | 16:19 |
| * dholbach couldn't boot any of the new kernels in KVM yet :-( | 16:21 | |
| dholbach | so I couldn't check out the new shiny feature yet | 16:21 |
| stgraber | dholbach: just use real HW :) (or VirtualBox with i386 isos) | 16:23 |
| dholbach | other than that I'm fairly happy with KVM :) | 16:24 |
| BenC | ion_: after some testing of last-good-boot, hopefully within a few weeks | 16:28 |
| ion_ | benc: Neat | 16:29 |
| ion_ | benc: Is there going to be a mechanism that keeps the modules of the currently running kernel available until the next reboot even though the kernel image is upgraded? | 16:31 |
| kirkland | slangasek: regarding the issue that you raised about the lsb-base status_of_proc() function not accounting for pidfiles, I have a new patch that addresses this. i'd appreciate your review, when you get a chance. see: https://bugs.edge.launchpad.net/ubuntu/+source/lsb/+bug/246735 | 16:31 |
| ubottu | Launchpad bug 246735 in lsb "status_of_proc() calls pidofproc() which calls kill, requiring ownership privileges on the process" [Medium,Fix released] | 16:32 |
| pitti | dholbach: I'm accepting the kvm SRU for hardy right now (which claims to enable booting of .26) | 16:32 |
| ion_ | benc: Something like... have the kernel image package install the modules to /lib/modules/blah.new; have the postinst replace /lib/modules/blah with if the ABI matches and do nothing otherwise; have a very early init script move /lib/modules/blah.new over /lib/modules/blah if blah.new exists. | 16:34 |
| dholbach | pitti: ah! :) | 16:34 |
| pitti | dholbach: testing appreciated, please give feedback to bug 243677 | 16:35 |
| ubottu | Launchpad bug 243677 in kvm "intrepid kernel 2.6.26-2-generic (amd64) won't boot as kvm guest" [High,In progress] https://launchpad.net/bugs/243677 | 16:35 |
| * dholbach hugs pitti and soren | 16:35 | |
| dholbach | sure will | 16:35 |
| dholbach | has it built already? has it built already? has it built already? | 16:35 |
| pitti | dholbach: no! not yet! still no! | 16:37 |
| BenC | ion_: that's something I haven't considered yet...on non-abi updates, that doesn't matter much, but for ABI bumps, it gets tricky | 16:37 |
| ion_ | benc: Or perhaps copy /lib/modules/blah to /lib/modules/current (with hardlinks) on startup and do something to make the system use /lib/modules/current from that point on. | 16:37 |
| ion_ | benc: Perhaps patch modprobe to try /lib/modules/current first and then fallback to /lib/modules/whatever-the-package-installs, and have an early init script rm -fr /lib/modules/current.temp, cp -al /lib/modules/whatever-the-package-installs /lib/modules/current.temp and bind-mount current.temp as current (to make sure a ‘current’ of another kernel doesn’t exist at /lib/modules/current at any time). | 16:42 |
| ion_ | benc: I’m just throwing random ideas around as they come, there probably are much better solutions. :-) | 16:43 |
| BenC | ion_: way to complicated, especially for lrm/third-party modules/dkms | 16:43 |
| ion_ | Yeah... | 16:43 |
| ion_ | benc: Perhaps have the package install the modules to /lib/modules/2.6.xx-ABIVER while making sure 2.6.xx-the_previous_ABIVER is not automatically deleted on upgrade, and have a maintenance script (an init script or a cron job) delete the older trees from /lib/modules that aren’t running. | 16:47 |
| ogra | ion_, so i have ade the code changes to the init-top script that it accepts a global COMPCACHE_PREREQ variable (that we can export from casper) for filing the prereq value and added a SKIP_COMPCACHE variable as well that makes the script die if nonzero ... since you seem to be good in finding out stuff and i'm out of ideas, any idea how to get the SKIP_COMPCACHE value handed over from one init-top script to the other ? | 16:48 |
| ogra | s/ade/made/ | 16:48 |
| BenC | ion_: That's slightly complex too...and racey | 16:48 |
| ogra | just exporting seems to be ignored | 16:49 |
| ion_ | ogra: Write it to a file and source it from the other scripts perhaps? | 16:49 |
| ogra | uh, ugly | 16:49 |
| ogra | but could work indeed :) | 16:49 |
| ion_ | I’ll hibernate. Have been awake for >22 hours. (That’s 66 millifortnights for our friends using the imperial units.) | 16:51 |
| * ogra had a 3h nap in the last 48h :) | 16:52 | |
| ion_ | Heh | 16:52 |
| jdstrand | slangasek: maybe I missed it, but what is the mechanism to update the pam conffiles (in PAMConfigFrameworkSpec)? | 17:29 |
| jdstrand | eg, pam-foo gets installed, drops its input file into /usr/share, then what? | 17:31 |
| slangasek | kirkland: aiee, you sent me to edge and everything is mirrored! :) | 17:34 |
| kirkland | slangasek: ? | 17:34 |
| cjwatson | yeah, they flipped the UI around recently | 17:35 |
| kirkland | slangasek: oh, hmm, sorry | 17:35 |
| slangasek | kirkland: your url for the lsb bug; it's to edge, which I don't normally use, and I can't find anything in the UI :-) | 17:35 |
| kirkland | i think i'm going to drop from launchpad-beta | 17:35 |
| kirkland | it's a PITA to edit every LP url I paste every day | 17:35 |
| cjwatson | I wonder if it's possible to write a firefox extension that munges the URLs on the way out | 17:36 |
| kirkland | or, rather, the LP guys should have edge detect that you're not a member of launchpad-beta-testers and redirect to the normal site | 17:36 |
| kirkland | bah | 17:36 |
| jdstrand | slangasek: oh-- I did miss it: "...multiselect debconf interface, invoked by means of a script..." | 17:36 |
| slangasek | jdstrand: ok :-) | 17:36 |
| * slangasek backspaces over his explanation, since it's apparently a repeat :) | 17:37 | |
| * kirkland says adios to edge.launchpad.net | 17:37 | |
| jdstrand | slangasek: I might add that auth-client-config does a pretty good job of handling user changes. I don't know if that is something you'd like to use, or maybe look at the logic and see if there is something there for you to get inspired from | 17:37 |
| slangasek | jdstrand: that sounds like it might be useful, thanks. Though given the language constraints, I guess it'd have to be transcribed for use | 17:38 |
| * jdstrand notes that the script of which slangasek speaks of is likely going to be pretty similar to auth-client-config | 17:38 | |
| jdstrand | slangasek: right | 17:39 |
| jdstrand | slangasek: and why is python installed by default in Debian? you should *totally* work on that ;) | 17:39 |
| jdstrand | s/is/isn't/ | 17:39 |
| slangasek | jdstrand: because perl is Enough? :) | 17:39 |
| Tm_T | I thought dash is enough | 17:39 |
| slangasek | ... ew? | 17:40 |
| jdstrand | I used to be a perl addict, but I;ve seen the light | 17:40 |
| slangasek | kirkland: well, if you're happy with returning 100 when the process exists and you can't kill it, then I'm happy too, though it seems to me that using ps would be a more robust solution for addressing your own concerns | 17:58 |
| ogra | Amaranth, merci | 17:58 |
| kirkland | slangasek: can you give me your suggested ps|grep line? | 17:59 |
| Amaranth | ogra: you removed my tabs :( | 17:59 |
| ogra | i did ? | 17:59 |
| Amaranth | you changed it all to 4 spaces :P | 17:59 |
| slangasek | kirkland: "ps `cat $pidfile` >/dev/null; echo $?" should do it, shouldn't it? | 18:00 |
| kirkland | slangasek: and would you suggest that in addition to the kill check? | 18:00 |
| ogra | Amaranth, yeah, thats how proper py code looks like :) | 18:00 |
| kirkland | slangasek: in place of the grep for "Operation not permitted" ? | 18:00 |
| slangasek | kirkland: that covers all the cases that kill -0 does, as well as the case where the process exists but isn't killable | 18:00 |
| slangasek | kirkland: I would suggest that as a complete replacement for the kill -0 check; is there some reason kill -0 is useful? | 18:01 |
| slangasek | i.e., something that it checks for that you can't check with ps? | 18:01 |
| kirkland | slangasek: i'm not a fan of the kill -0, but i'm apprehensive about changing something so fundamental and pervasively used as pidofproc() | 18:01 |
| slangasek | (the one caveat is that ps is in the procps package) | 18:01 |
| cjwatson | tabs vs. 4 spaces> http://www.python.org/dev/peps/pep-0008/ | 18:02 |
| slangasek | right, then using kill -0 with ps as a fallback is probably safer | 18:02 |
| * cjwatson wonders if that should be referenced from policy | 18:02 | |
| kirkland | slangasek: right <enter mumbly complaints about how much lsb sucks here> | 18:02 |
| slangasek | heh | 18:02 |
| Amaranth | cjwatson: 4 spaces is still evil :P | 18:03 |
| liw | it's evil, but its' the RIGHT kind of evil | 18:03 |
| kirkland | slangasek: i'll redraft the patch with the ps fall back | 18:03 |
| kirkland | slangasek: it'll be a few minutes, as I'm otherwise occupied at the very moment | 18:03 |
| cjwatson | consistency > * | 18:03 |
| kirkland | slangasek: i'll pass it by your review again | 18:03 |
| ogra | it should be the initial question at MOTU application reviews :) | 18:03 |
| cjwatson | (yes yes hobgoblin of little minds etc.) | 18:03 |
| liw | hobgoblins are cute | 18:04 |
| slangasek | kirkland: it doesn't suck /generally/, just the "let's use redhat as a model for init scripts" part :) | 18:04 |
| cjwatson | liw: yes, the little 'o' character is nice and rounded, and they're easy to kill | 18:05 |
| savvas | why does debdiff always attach a /tmp/something/ path in the changelog diff? | 18:06 |
| cjwatson | probably because that's where it unpacks them to diff, and it doesn't pass the right options to trim that off | 18:12 |
| sistpoty|work | savvas: that iirc only happens for new upstream versions (or native packages), where there is no common base path | 18:13 |
| savvas | bug? :) | 18:13 |
| savvas | ah | 18:13 |
| savvas | ok | 18:13 |
| mdz | pitti: around? | 18:23 |
| pitti | mdz: for another 5 minutes or so, yes | 18:23 |
| mdz | pitti: I am trying to debug bug 246585, and the simplest way to do so seemed to be to use apport to gather a crash report (since the console and X were unusable for gdb) | 18:24 |
| ubottu | Launchpad bug 246585 in xserver-xorg-video-vesa "GTK applications crashing reproducibly when using vesa" [Undecided,Incomplete] https://launchpad.net/bugs/246585 | 18:24 |
| mdz | pitti: but apport-retrace chokes on the .crash file because it is lacking a Package: field | 18:24 |
| mdz | I don't see why it should be missing; it has a correct ExecutablePath which is clearly part of the gdm package | 18:24 |
| pitti | mdz: right, Package:, Dependencies:, etc. are only added in the UI | 18:25 |
| pitti | mdz: since they are expensive to generate (same like all the Gdb fields) | 18:25 |
| mdz | pitti: I hand-hacked it back in. do you expect the auto-retracer will accept it? | 18:25 |
| mdz | pitti: I'd like to attach it to the existing bug report | 18:25 |
| pitti | mdz: so either run apport-gtk -f /var/crash/... on it, or call apport-retrace manually with -R, --rebuild-package-info | 18:26 |
| mdz | pitti: I'd rather just give it to the server to retrace, and not download all the debug symbols, if that will work | 18:26 |
| pitti | mdz: ah, no apport retracers for intrepid yet, I'm afraid, and unfolding the blob to an existing bug isn't possible yet either (long-standing LP wishlist bug) | 18:26 |
| mdz | pitti: oh, ok. I'll retrace locally then. thanks | 18:27 |
| pitti | ATM, p-lp-bugs is yet again broken with current LP, and I need to set up intrepid chroots | 18:27 |
| pitti | it's a constant chase :/ | 18:27 |
| mdz | pitti: LP 2.0 is supposed to give us APIs to back p-lp-bugs... | 18:29 |
| pitti | yeah, I'm craving for that :) | 18:29 |
| savvas | when there are two packages listed in debian/control, do I have to add XSBC-Original-Maintainer twice? | 18:38 |
| ogra | tere are surely not two source packages listed | 18:38 |
| ogra | that field applies to the source package | 18:38 |
| savvas | Package: htcheck | 18:39 |
| savvas | Package: htcheck-php | 18:39 |
| mdz | bryce: around? | 18:40 |
| bryce | mdz, yep | 18:41 |
| emgent | hello | 18:41 |
| mdz | bryce: I've attached what you requested to 246585, though it only seems to get weirder | 18:41 |
| bryce | ok looking | 18:42 |
| mdz | bryce: I noticed along the way that X server crashes don't seem to trigger apport; is that intentional? i thought it used to | 18:42 |
| mdz | (this particular problem isn't an X server crash, but in the course of events it's crashed on me a few times in the past day) | 18:42 |
| bryce | mdz: hrm, it *should* be triggering them. Might be my own lack of apport-fu is making them not work | 18:43 |
| sladen | come to think of it; I haven't had anything trigger apport for quite a while | 18:43 |
| laga | sladen: are you on a stable release? | 18:43 |
| Tm_T | hi sladen :) | 18:43 |
| bryce | I recently in Intrepid changed how the xserver apport stuff is hooked up based on pitti's advice, but it may still not be right yet | 18:43 |
| sladen | laga: ah, _this_ machine is | 18:44 |
| laga | sladen: see /etc/default/apport | 18:44 |
| laga | i need to enable it on my laptop because kded crashes frequently | 18:44 |
| mdz | bryce: in which package does the magic live? | 18:44 |
| mdz | ah, -core | 18:45 |
| bryce | mdz, I stuck it in the xorg package, but am wondering if it needs to live in xorg-server | 18:45 |
| mdz | bryce: I think it needs to be in the same package as the binary in order to be triggered | 18:47 |
| bryce | mdz, that's what I suspected... I'll try moving it over to xorg-server then | 18:48 |
| bryce | I also need to investigate if we can get richer stacktraces when xserver crashes; currently what it puts into Xorg.0.log generally proves insufficient for troubleshooting | 18:49 |
| mdz | bryce: I don't think the package hook is the problem; apport never gets invoked at all | 18:50 |
| mdz | I assume it's because the X server is handling the signal itself | 18:51 |
| mdz | though, it does rethrow it I guess, so it should work | 18:51 |
| mdz | bryce: I've attached gnome-panel and gnome-terminal crash reports to the bug as well. you should notice a pattern... | 18:52 |
| mdz | they're all falling over in the course of inquiring about screen geometry | 18:52 |
| bryce | ok | 18:52 |
| mdz | apport should do a much better job of decoding the stack trace than the X server does | 18:54 |
| mdz | if you let it do its thing | 18:54 |
| bryce | mm, definitely an error in xrandr-ish stuff | 18:54 |
| mdz | mako: dude | 18:56 |
| bryce | if I were to guess at this point, I'd guess it to be that gdk's xrandr bindings are bugged | 18:56 |
| mdz | bryce: re: X server crashes, /var/log/apport.log has this to say: | 18:58 |
| mdz | ValueError: Invalid process ID: [Errno 2] No such file or directory: '/proc/21945' | 18:58 |
| mdz | it seems the process has already exited before apport gets its paws on it | 18:58 |
| jcristau | mdz: does gdk_screen_get_n_monitors() return 0? | 18:59 |
| bryce | mdz, also attach your .xsession-errors. Since it's looking like this might be somewhere in the gnome stack, that might have useful info | 18:59 |
| ogra | haha | 19:02 |
| mdz | jcristau: is there an easy way to get to that from PyGTK? | 19:02 |
| ogra | if you find it in there at least | 19:02 |
| mdz | bryce: there's nothing on stdout or stderr except what I already put in the bug | 19:02 |
| Amaranth | .xsession-errors wouldn't be so bad if you didn't have 10 things writing to it at once | 19:03 |
| Amaranth | everything kind of...merges | 19:03 |
| Amaranth | "ok, here is the first line of compiz-manager output, where is the second? oh, i see it, 50 lines down..." | 19:03 |
| mdz | jcristau: not sure if I'm using the API correctly, but: | 19:04 |
| mdz | >>> gtk.gdk.Screen().get_n_monitors() | 19:04 |
| mdz | __main__:1: Warning: invalid cast from `GdkScreen' to `GdkScreenX11' | 19:04 |
| mdz | 1946711135 | 19:04 |
| Amaranth | that looks...bad | 19:04 |
| mdz | it returns the same sort of random garbage when I try that on a working X server, though, so I don't think I'm asking the right question | 19:05 |
| Amaranth | mdz: try gtk.gdk.screen_get_default().get_n_monitors() | 19:05 |
| mdz | Amaranth: returns 0 | 19:06 |
| mdz | returns 1 on my healthy X server | 19:06 |
| bryce | jcristau: from the panel_multiscreen_width() routine, it looks like it only reaches the line it crashes on if gdk_screen_get_number(screen) returns 0 or higher | 19:06 |
| Amaranth | jcristau: ^ | 19:06 |
| jcristau | sounds like XineramaIsActive() or XineramaQueryScreens() bugginess | 19:07 |
| Amaranth | that's as far as I can help from a mac | 19:07 |
| jcristau | mdz: what's the output of xdpyinfo -ext XINERAMA? | 19:09 |
| bryce | from the vesa Xorg.0.log: (II) Initializing built-in extension XINERAMA | 19:10 |
| mdz | jcristau: http://paste.ubuntu.com/26264/ | 19:10 |
| bryce | jcristau: is -vesa still set up to use xinerama? | 19:11 |
| mdz | it prints output, but then the X server crashes | 19:11 |
| mdz | number of screens: 1 | 19:11 |
| jcristau | bryce: vesa doesn't do xinerama, no. so XineramaIsActive() is supposed to return false. Xinerama is inactive. | 19:12 |
| jcristau | .. in the xdpyinfo output suggests that it does | 19:12 |
| mdz | xrandr --verbose: http://paste.ubuntu.com/26265/ | 19:13 |
| jcristau | the crash looks like a wacom bug | 19:13 |
| mdz | the crash during server shutdown is presumably a separate issue | 19:13 |
| mdz | I'll report it to LP | 19:13 |
| * mdz starts using -noreset | 19:14 | |
| bryce | jcristau: why do you think it's related to wacom? | 19:15 |
| bryce | jcristau: the wacom error messages that appear in Xorg.0.log have generally proven non-fatal with gnome | 19:15 |
| jcristau | so if XineramaIsActive() returns false then i have no idea why gdk's get_n_monitors() doesn't return 1 | 19:15 |
| mdz | bryce: because it's crashing in 2: /usr/lib/xorg/modules/input//wacom_drv.so [0xb7b3c0fc] | 19:15 |
| mdz | GTK seems to set n_monitors based on either XineramaQueryScreens or XRRGetScreenResources | 19:16 |
| bryce | ah | 19:16 |
| mdz | both of which seem to be behaving | 19:16 |
| mdz | bryce: have you tried this yourself? | 19:17 |
| bryce | mdz, no I haven't | 19:17 |
| mdz | bryce: does vesa work on your hardware? have a go | 19:18 |
| bryce | ok I'll give it a shot | 19:18 |
| tjaalton | it doesn't work on mine, and I don't have anything wacom related in the conf | 19:19 |
| mdz | tjaalton: two separate issues, vesa and wacom | 19:20 |
| tjaalton | mdz: oh, ok | 19:20 |
| mdz | not too concerned about wacom right now, since the server is going down anyway at that point | 19:20 |
| tjaalton | heh | 19:20 |
| mdz | bryce: I'm using sudo -b X :1 -ac -noreset -config xorg.conf.test | 19:22 |
| mdz | for convenience, though it definitely happens when it's the only X server running as well | 19:22 |
| savvas | can someone take a look at the patches listed here: http://tinyurl.com/58dgl3 | 19:23 |
| savvas | or the huge link :) https://bugs.launchpad.net/~medigeek?field.searchtext=fixed+maintainer+debian+control+field&orderby=-datecreated | 19:24 |
| mdz | savvas: the changelog says hardy, but should probably say intrepid | 19:24 |
| savvas | darn, true | 19:24 |
| geser | savvas: and subscribe ubuntu-universe-sponsors for packages in universe and ubuntu-main-sponsors for packages in main | 19:25 |
| savvas | will do, have to run though, I'll change them to intrepid and subscribe the sponsors later :\ | 19:27 |
| bryce | rats, networking is busted on my dev box at the moment. -vesa is working on it but it's running xserver 1.4 | 19:28 |
| bryce | (so I'll set up another box) | 19:32 |
| mdz | bryce: what's wrong with the box you're on? | 19:36 |
| sbeattie | slangasek: is there a reason the kubuntu-kde4 i386 alternate image is 403? | 19:36 |
| sbeattie | slangasek: nevermind, brain not working today | 19:37 |
| bryce | mdz, ah, it's the one I use for mail services and such and is still on hardy. | 19:42 |
| === ember_ is now known as ember | ||
| mdz | bryce: so what are you using for testing your intrepid uploads? ;-) | 19:44 |
| kirkland | slangasek: hey, sorry, got drawn away for longer than I expected. Updated patch on https://bugs.edge.launchpad.net/ubuntu/+source/lsb/+bug/246735 using ps | 19:46 |
| ubottu | Launchpad bug 246735 in lsb "status_of_proc() calls pidofproc() which calls kill, requiring ownership privileges on the process" [Medium,Fix released] | 19:46 |
| kirkland | slangasek: mdz made the same suggestion ;-) | 19:47 |
| bryce | mdz, long story, but basically last weekend I started some machine shuffling, and the machine I set up for testing currently has a network support issue (getting workaround from tim). | 19:50 |
| slangasek | kirkland: my suggestion was not altogether independent of his :) | 19:51 |
| kirkland | slangasek: :-D | 19:51 |
| slangasek | kirkland: I guess I would expect that if you find the process with 'ps', you would still return 0, not 100 | 19:58 |
| slangasek | otherwise, why look with ps at all? | 19:58 |
| kirkland | slangasek: hmm, well i didn't want to disturb pidofproc()'s non-zero return code in the kill -0 fails case | 19:59 |
| slangasek | hum | 19:59 |
| slangasek | I don't think pidofproc is documented as returning non-zero in the case you don't own the process, is it? | 19:59 |
| kirkland | slangasek: i'm still treating this status gathering business as a special case, allowable as a non-owner/non-root user | 19:59 |
| slangasek | if it's not a documented feature, sucks to be whoever assumed this was an ok way to check for ownership of the process :P | 20:00 |
| kirkland | slangasek: good point.... if no pid file is found, and /bin/pidof runs, it doesn't check ownership either | 20:00 |
| slangasek | right | 20:00 |
| * kirkland programs conservatively and he gets smacked for it... programs more liberally and gets smacked for it :-) | 20:01 | |
| kirkland | :-P | 20:01 |
| slangasek | heh :) | 20:02 |
| Mithrandir | kirkland: it's called "You can't win", aka the second law of thermodynamics. | 20:04 |
| slangasek | Mithrandir: first law; the second law is "you can't break even" :) | 20:05 |
| Mithrandir | slangasek: true. | 20:05 |
| gp | hi | 20:08 |
| gp | is there a vunerbaility in ubuntu 8.04 ? | 20:09 |
| gp | all my systems in office started behaving strangely around 8 pm ist | 20:10 |
| kirkland | slangasek: okay, patch updated at https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/246735 | 20:10 |
| ubottu | Launchpad bug 246735 in lsb "status_of_proc() calls pidofproc() which calls kill, requiring ownership privileges on the process" [Medium,Fix released] | 20:10 |
| slangasek | gp: if you mean the initial release of Ubuntu 8.04, there are multiple vulnerabilities that have been fixed since the release via security updates; http://www.ubuntu.com/usn/ has a complete list | 20:10 |
| geser | gp: can you be more verbose on "strangely"? | 20:10 |
| slangasek | you should definitely be tracking the "important security updates", as they're called in the admin interface, for any Ubuntu release | 20:12 |
| gp | they were in network and was able to ping each other but any services like ssh , ftp , databse server disconnected or timed out | 20:13 |
| gp | machines were able to ping each other at very low lan latency | 20:13 |
| gp | i thought there was problem with switch intially so replaced the switch | 20:14 |
| gp | but again same problem | 20:14 |
| gp | now stuff like ssh takes too much time | 20:15 |
| gp | or time outs on all machines | 20:15 |
| slangasek | well, you're the only one that I've heard reporting such a problem, I'm afraid. If you haven't installed all of the security updates, it could very well be because of one of those. If you have installed the security updates, it's likely to be a local problem (perhaps a DNS configuration problem?) since no one else is reporting it | 20:16 |
| kirkland | slangasek: if you're satisfied with the latest version of that patch, could I trouble you for a sponsor/upload? | 20:17 |
| kees | gp: there was a significant DNS update happening for all vendors yesterday and today. it could be related, but as slangasek says, this is the first we've heard of anything like this. | 20:17 |
| slangasek | kirkland: sure, I can do that | 20:17 |
| gp | these are unpatched systems | 20:17 |
| kirkland | slangasek: cool, after that happens, i'll send it over to Debian. they accepted the last one (sans pidfile support) yesterday | 20:17 |
| kees | gp: right, but other infrastructure may be getting updated was my point. | 20:20 |
| mako | mdz: dude | 20:21 |
| gp | maybe my office is under some attack ? | 20:24 |
| savvas | attack of the Huns! :) | 20:24 |
| gp | but i also tried to disconnect from router and but any service like ssh , db was taking to much time to connect | 20:25 |
| gp | i did nmap scan | 20:26 |
| gp | only ssh and db server port show one in namp | 20:27 |
| gp | how to find if systems are hacked ? | 20:31 |
| gp | my entire office is down | 20:33 |
| gp | office which runs solely on ubuntu | 20:33 |
| gp | and which i installed :-( | 20:33 |
| gp | tomm if its now fixed I will be blamed | 20:34 |
| Lrrr | gp: is there anything showing in logs? You don't seem to have much informations about what is actually happening. | 20:34 |
| gp | syslog? | 20:34 |
| Lrrr | syslog, kernel log, whatever log... | 20:35 |
| sbeattie | ssh delays tend to be DNS related. | 20:35 |
| gp | i am using ip in lan | 20:37 |
| gp | not by host name | 20:37 |
| gp | even on local computer | 20:37 |
| gp | if i ssh localhost its quite fast | 20:38 |
| gp | but if i ssh my local computer by ip it takes lot of time | 20:39 |
| Keybuk | it's because if you ssh to your IP, it first has to go all the way to your ISP and back | 20:39 |
| Keybuk | no, I can't keep a straight face ;) | 20:40 |
| Lrrr | gp: Please gather more informations than simple network delays. | 20:40 |
| Keybuk | in reality, it's almost certainly that you don't have reverse DNS for your IP | 20:41 |
| Keybuk | or that it doesn't match the forward | 20:41 |
| Keybuk | or that your DNS resolver is slow | 20:41 |
| kirkland | slangasek: http://pastebin.ubuntu.com/26288/ | 20:41 |
| kirkland | slangasek: that's the bug report + patch I'm sending to Debian | 20:41 |
| gp | Lrrr: which info i should look for | 20:41 |
| kirkland | slangasek: includes the patch as you've seen it, plus two minor diff's between Debian/Ubuntu lsb-base that I've dealt with before on merges | 20:42 |
| kirkland | slangasek: should clean up our merge, which I'll do for intrepid again, as soon as he accepts this | 20:42 |
| Lrrr | Keybuk has a good point there. | 20:42 |
| slangasek | gp: as Keybuk says, a slow DNS resolution does perfectly explain slow ssh connections when connecting by IP, because the /server/ has to identify the client even if the client uses an IP when connecting to the server | 20:43 |
| Mithrandir | providing network traces often shows this very clearly, if things take exactly 30s to time out for instance. | 20:46 |
| gp | Mithrandir: u mean traceroute ? | 20:47 |
| Mithrandir | no, I mean tcpdump/tshark logs | 20:48 |
| gp | http://pastebin.ubuntu.com/26291/ | 20:55 |
| gp | i am sorry to disturb u guys with my problems | 20:57 |
| gp | am i no security / network guru only developer | 20:57 |
| gnomefreak | did we do away with gtksu/gtksudo? | 20:58 |
| Lrrr | there seem to be a name resolution error there | 20:58 |
| Mithrandir | gp: well, it doesn't look like any of your DNS servers are actually answering? | 20:58 |
| gp | http://pastebin.ubuntu.com/26292/ | 20:59 |
| gnomefreak | sorry typo | 20:59 |
| gp | when i dig yahoo.com it responds pretty quickly | 21:00 |
| Mithrandir | gp: can you install moreutils and then pastebin the output of dig +trace err.no | ts ? | 21:01 |
| slangasek | 2>&1 >/dev/null | 21:05 |
| slangasek | kirkland: ^^ doesn't the above redirect the fds in the wrong order? | 21:05 |
| Mithrandir | usually, yes. | 21:05 |
| gp | http://pastebin.ubuntu.com/26294/ | 21:06 |
| kirkland | slangasek: i wrote/read that as "stderr to stdout, then stdout to /dev/null" | 21:06 |
| slangasek | kirkland: so you meant for the stderr output to not be suppressed? | 21:06 |
| kirkland | slangasek: i mean to suppress EVERYTHING | 21:06 |
| Mithrandir | kirkland: then it's the wrong order. | 21:07 |
| kirkland | slangasek: and only operate on the $? | 21:07 |
| slangasek | kirkland: then that needs to be >/dev/null 2>&1 | 21:07 |
| slangasek | kirkland: because 2>&1 means "clone the current fd1 as fd2" | 21:07 |
| slangasek | and if you do that before stdout is repointed at /dev/null, it's basically a no-op :) | 21:07 |
| kirkland | wow, i've been screwing that up for years, then | 21:07 |
| slangasek | I can fix that here if you're happy with that, no need for a patch reupload | 21:08 |
| kirkland | please | 21:08 |
| kirkland | slangasek: i'll update the patch I sent to Debian | 21:08 |
| slangasek | ok | 21:08 |
| kirkland | slangasek: thanks. | 21:08 |
| gp | Mithrandir: http://pastebin.ubuntu.com/26294/ ->>> output of dig +trace err.no | ts | 21:09 |
| Mithrandir | gp: yeah, that looks nice and fast. | 21:09 |
| slangasek | kirkland: hrrrm, status_of_proc() also still doesn't actually give you a way to *pass* a pidfile argument to pidofproc :) | 21:10 |
| slangasek | pidofproc $daemon -- I need it to be able to call pidofproc -p $pidfile $daemon :) | 21:11 |
| kirkland | slangasek: pidofproc() sort of autodetects that | 21:11 |
| slangasek | hmm | 21:11 |
| kirkland | slangasek: but i guess it would be good to explicitly state that | 21:11 |
| gp | Mithrandir: why my ssh is slow in lan | 21:12 |
| slangasek | well, for completeness it should be possible to override the autodetection | 21:12 |
| gp | eralier it was instaneius | 21:12 |
| kirkland | slangasek: actually, you're right, it's a problem with cron... the daemon is /usr/sbin/cron, but the pid is /var/run/crond.pid | 21:12 |
| slangasek | kirkland: right, not guaranteed to match :) | 21:12 |
| kirkland | slangasek: k, i'll spin a new version | 21:13 |
| gp | all services super slow in lan | 21:13 |
| slangasek | kirkland: indeed, for samba the pid files are down a level, so my omgkittens use case isn't addressed by the current implementation :-) | 21:13 |
| slangasek | kirkland: sorry for not catching this in earlier reviews, I guess I had tunnel vision | 21:15 |
| kirkland | slangasek: no problem, i had thought about it, but figured i'd rely on pidofproc()'s autodetection (which in retrospect was poor) | 21:15 |
| * kirkland has a habit of underestimating problems :-) | 21:15 | |
| kirkland | too optimistic, i suppose | 21:15 |
| Mithrandir | that's a fairly common disease affecting programmers. | 21:17 |
| Mithrandir | remember to multiply by π | 21:18 |
| kirkland | slangasek: what did you think of mdz's suggestion of just removing the kill -0 statement and using ps exclusively? | 21:18 |
| kirkland | slangasek: also, is this construct correct? it's used elsewhere in that file: elif ps "${pid:-}" 2> >/dev/null; then | 21:18 |
| infinity | pitti: Sorry about the missing bug number, reuploaded with fixed changelog. | 21:19 |
| kirkland | infinity: aw, admit it.... adding the bug number screwed up your fully justified changelog :-) | 21:20 |
| infinity | kirkland: *cough* | 21:20 |
| infinity | kirkland: No, I've just always been slack about Ubuntu bug numbers in changelogs, since I left the distro team before we finally got auto-closing of bugs in soyuz/malone. | 21:20 |
| slangasek | kirkland: well, I commented to the bug that if we use ps exclusively, that sorta implies a dep on procps for the lsb-base package; that might be ok, I can't think of a specific reason right now that it wouldn't, but I think the idea should be shopped around more before committing to it | 21:22 |
| Lrrr | gp: Can we speak in private? | 21:22 |
| kirkland | slangasek: k, sounds good | 21:22 |
| kirkland | slangasek: and about ps "${pid:-}" 2> >/dev/null ? | 21:22 |
| slangasek | kirkland: 2> >/dev/null is not correct. 2> /dev/null is ok (i.e., you're allowed to have a space between the operator and the arg), but incomplete | 21:23 |
| Lrrr | Couldn't gp problem be related to mdns? | 21:23 |
| slangasek | kirkland: >/dev/null 2>&1 is the traditional method | 21:23 |
| kirkland | slangasek: okay. in that case, there are issues elsewhere in that script | 21:23 |
| slangasek | kirkland: in init-functions? they're eluding my gaze | 21:24 |
| kirkland | slangasek: blah...meh. sorry, i've gone crosseyed | 21:24 |
| slangasek | mental note, Canonical USA needs to get a health plan that includes optical ;) | 21:25 |
| kirkland | slangasek: +1! | 21:25 |
| liw | also, bigger monitors so you can use bigger fonts | 21:26 |
| Lrrr | gp: please, look at https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940 | 21:26 |
| ubottu | Launchpad bug 94940 in avahi "mdns listed in nsswitch.conf causes excessive time for dns lookups" [Undecided,Confirmed] | 21:26 |
| kirkland | slangasek: try this one... http://pastebin.ubuntu.com/26298/ | 21:28 |
| kirkland | slangasek: i made pidfile an optional, 3rd parameter to status_of_proc() | 21:28 |
| kirkland | slangasek: if it's found, i add a "-p $3" to the pidofproc() call | 21:29 |
| slangasek | kirkland: the -p syntax would be more consistent with the interface of the other functions provided, so I think it would be better to have status_of_proc() support -p $pidfile the same way pidofproc does | 21:30 |
| slangasek | kirkland: but I'd be happy to sponsor this revision, all the same | 21:30 |
| kirkland | slangasek: i can make that change easily enough | 21:30 |
| kirkland | slangasek: personally, i think "-p $pidfile" is kinda ugly | 21:30 |
| kirkland | slangasek: i don't like mixing -param and positional parameters | 21:31 |
| slangasek | 10:03 < cjwatson> consistency > * | 21:31 |
| slangasek | :-) | 21:31 |
| kirkland | slangasek: say the magic word and I'll go change it to use -p .... | 21:31 |
| * liw would vote for everyone using GNU getopt (_long) option parsing... | 21:32 | |
| slangasek | kirkland: yes, please | 21:32 |
| kirkland | slangasek: k... | 21:32 |
| slangasek | kirkland: I'm off to lunch now anyway, which I need to squeeze in before the platform meeting | 21:32 |
| kirkland | slangasek: i'll bug you shortly then.... | 21:32 |
| kirkland | slangasek: i'd like to put a nail in this coffin today, if possible | 21:32 |
| slangasek | right :) | 21:33 |
| kirkland | slangasek: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/246735/comments/11 | 22:19 |
| ubottu | Launchpad bug 246735 in lsb "status_of_proc() calls pidofproc() which calls kill, requiring ownership privileges on the process" [Medium,Fix released] | 22:19 |
| kirkland | slangasek: patch updated there, with pidfile support | 22:19 |
| kirkland | slangasek: ping me when you come back around, review, and potentially commit | 22:19 |
| kirkland | slangasek: I want to push the patch back to debian, but I'll refrain from spamming Debian's bts until we settle on something for ubuntu's lsb-base | 22:20 |
| === asac_ is now known as asac | ||
| === Keybuk is now known as Guest62599 | ||
| === Keybuk_ is now known as Keybuk | ||
| slangasek | mathiaz: "why use the dovecot implementation instead of cyrus" - because everyone hates the cyrus SASl implementation :) | 22:37 |
| slangasek | I don't know to what extent this is inherent in sasl, and to what extent it's the result of cyrus's strange configuration semantics | 22:38 |
| mathiaz | slangasek: right - OTOH dovecot sasl implementation is only supported by postfix and exim | 22:40 |
| slangasek | mathiaz: right, and postfix doesn't even depend on it, it only depends on libsasl2-2 | 22:40 |
| mathiaz | slangasek: so from a practical pov, if we want to support SASL correctly cyrus implementation is the only option for the time being | 22:40 |
| slangasek | I agree | 22:41 |
| mathiaz | slangasek: another option would be to add support for dovecot to other services :) | 22:41 |
| slangasek | I've never looked at the dovecot implementation myself, so I don't know whether that's really as great an idea as people make it out to be | 22:42 |
| ScottK | For postfix it's definitely easier to configure correctly. | 22:52 |
| lamont | I don't mind having postfix Suggest: either dovecot or cyrus... Recommends? dunno. Depends: no way | 22:53 |
| ScottK | Since dovecot is our preferred delivery agent, it makes sense to focus on it for SASL too. | 22:53 |
| ScottK | lamont: I'd say Suggests both. | 22:53 |
| lamont | do they conflict? | 22:53 |
| lamont | because suggesting two conflicting packages strikes me as kinda strange | 22:54 |
| soren | ScottK: Suggest... both? | 22:55 |
| soren | ScottK: Why would you want both dovecot and cyrus? | 22:55 |
| ScottK | Suggest them alternatively. | 22:55 |
| soren | Now, *that* makes sense. | 22:55 |
| ScottK | dovecot|cyrus | 22:55 |
| slangasek | lamont: postfix already depends: the cyrus sasl implementation, it's a shlibdep | 22:55 |
| slangasek | we're discussing the SASL libs, not the POP servers :) | 22:56 |
| lamont | ah, ok | 22:56 |
| soren | Oh. | 22:56 |
| slangasek | kirkland: latest patch looks good, should be uploaded shortly | 22:56 |
| kirkland | slangasek: outstanding! | 22:57 |
| lamont | 1 7 277680 57036 3968 942264 2 0 28688 24519 2487 14540 18 14 38 30 | 22:57 |
| lamont | scary vmstat output | 22:57 |
| kirkland | slangasek: here's the caller patch for samba: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/247087 | 22:58 |
| ubottu | Launchpad bug 247087 in samba "samba init script status action" [Low,In progress] | 22:58 |
| kirkland | slangasek: see how that guy looks to you | 22:58 |
| slangasek | kirkland: hmm, there are some comments in the thread on the Debian bug that are probably relevant; i.e., it's not safe to assume that the status of "samba" as a whole is always dependent on the status of both nmbd and smbd, there are cases where one or the other is legitimately configured not to run | 23:04 |
| kirkland | slangasek: your recommendation? | 23:05 |
| slangasek | kirkland: present in that bug log; sorry, platform meeting just started now, split attention | 23:06 |
| kirkland | slangasek: okay, i'll dig deeper | 23:06 |
| slangasek | that's Debian bug #488275, if you don't have it to hand | 23:07 |
| ubottu | Debian bug 488275 in samba "samba and winbind: initscript miss 'status' option" [Wishlist,Open] http://bugs.debian.org/488275 | 23:07 |
| kirkland | slangasek: thx | 23:09 |
| kirkland | slangasek: see https://bugs.launchpad.net/debian/+source/samba/+bug/247087/comments/3 | 23:37 |
| ubottu | Launchpad bug 247087 in samba "samba init script status action" [Low,In progress] | 23:37 |
| kirkland | slangasek: updated to test for $NMBD_DISABLED and $RUN_MODE | 23:37 |
| kirkland | slangasek: is this sufficient, or are you thinking something more complex will be required? | 23:38 |
| * kirkland recognizes that slangasek is active in #ubuntu-meeting at the moment ;-) | 23:38 | |
| slangasek | kirkland: hmm, what should the status be if 'disable netbios' is set *and* smbd is run out of inetd? :-) | 23:43 |
| slangasek | (i.e., I think we need the default status to be 'undefined') | 23:43 |
| kirkland | slangasek: which is what in sysv return codes? | 23:44 |
| slangasek | sysv, or lsb? | 23:44 |
| kirkland | slangasek: ah, good point. lsb. | 23:44 |
| * kirkland goes to the spec.... | 23:45 | |
| Riddell | pitti: fancy looking to see if ew can get policykit-kde to do anything next week? | 23:45 |
| kirkland | slangasek: according to http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html, 4="program or service status is unknown" | 23:45 |
| slangasek | kirkland: sounds good to me :) | 23:46 |
| slangasek | so yeah, lots of fun - the return code needs to be 4 if neither daemon is configured to run, 0 if at least one is configured to run and all those that are configured to run are running, otherwise whatever error status_of_proc returned | 23:47 |
| kirkland | slangasek: i was drawing it on paper, actually :-P | 23:48 |
| slangasek | :-) | 23:48 |
| stgraber | erk, encrypted lvm seems to fail on current Intrepid alternate :( | 23:50 |
| slangasek | bryce: well, everything past the 'milestone' column is lost screen real estate to me... it really would be nice to have those columns hidden, so that more rows can fit on a screen without wrapping | 23:50 |
| cjwatson | stgraber: oh? | 23:51 |
| ogra | stgraber, sure its not just slow ? | 23:52 |
| slangasek | kirkland: I think the easiest is to just check the two vars at the end, and if we don't hit either case, set status=4 | 23:52 |
| kirkland | slangasek: right | 23:52 |
| stgraber | big red screen, so not it's not just slow .) | 23:53 |
| stgraber | doing manual partitioning with encryption + lvm | 23:53 |
| stgraber | my usual advanced manual testcase :) boot + encrypted partition containing LVM with / and /home | 23:53 |
| bryce | slangasek: ok, I can probably add a 'shrink columns' option. | 23:53 |
| stgraber | standard: erase-disk + encrypted LVM worked though | 23:54 |
| cjwatson | stgraber: can I get logs? | 23:54 |
| stgraber | cjwatson: sure | 23:55 |
| cjwatson | kees: you sure about closing Debian bug #403718? the 'if (int_value > 19) int_value = 19;' bit I saw still isn't accompanied by a similar bound-from-below | 23:56 |
| ubottu | Debian bug 403718 in pam "pam: pam_limits fails to bound RLIMIT_NICE from below" [Normal,Closed] http://bugs.debian.org/403718 | 23:56 |
| cjwatson | am I missing something | 23:56 |
| cjwatson | ? | 23:56 |
| cjwatson | kees: oh, hmm, maybe I'm confused because debian/patches-applied/ in fact isn't | 23:57 |
| cjwatson | yeah, I'm just confused. never mind me | 23:59 |
| kees | cjwatson: heh, okay, no problemo. Yeah, from the testing I did during the 0.99 updates a while back, that was all taken care of. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!