[00:03] <shtylman> ccheney: pong
[00:13] <mathiaz> slangasek: I've upload image-store-proxy (bug https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/423865) to karmic
[00:13] <mathiaz> slangasek: it's waiting in the NEW queue for AA review
[00:13] <slangasek> mathiaz: cheers
[00:13] <cjwatson> gah, axis2c has been broken so that eucalyptus no longer builds, and I wanted to upload the latter ...
[00:13] <mathiaz> slangasek: I'm writing the MIR now
[00:13]  * cjwatson sighs and embarks on yak-shaving
[00:13]  * slangasek passes the curry brush
[00:15] <cjwatson> oh, it's probably upgrade madness. bug 426752
[00:17] <cjwatson> ... no, I think it's just busted.
[00:18] <ccheney> shtylman: sorry was away for a bit
[00:19] <shtylman> ccheney: all good
[00:19] <ccheney> shtylman: ok just normal submission is fine
[00:19] <shtylman> ccheney: by normal you mean ? :)
[00:20] <shtylman> git patches to list?
[00:20] <ccheney> yea
[00:20] <shtylman> ok..no prob
[00:22] <cjwatson> ah, fixed, had to remove *everything* that owned /usr/lib/axis2
[00:24] <shtylman> is the next uds gonna be in the states?
[00:31] <cjwatson> shtylman: yes, one way or another
[00:31] <cjwatson> (so I hear anyway)
[00:32] <shtylman> cjwatson: gotcha
[00:37] <slangasek> cjwatson: even if we have to annex territory to do it? :)
[00:43] <mathiaz> slangasek: do you plan to process the NEW source package queue today (ie before alpha6 soft freeze)?
[00:44] <slangasek> mathiaz: yes
[00:44] <cjwatson> slangasek: I don't *think* we'll have to go that far, unless there have been recent secessions I haven't heard of :-)
[00:45] <slangasek> Texas's flirtation with secession seems to have petered out
[00:45] <mathiaz> slangasek: cool. Let me know if you run into issues with image-store-proxy
[00:54] <mathiaz> cr3: http://paste.ubuntu.com/271278/
[00:54] <mathiaz> cr3: ^^ testing checkbox-cli in a vm - ran into this error
[00:55] <cr3> mathiaz: thanks, will fix and resubmit
[00:55] <mathiaz> cr3: well - do what the problem is?
[00:56] <mathiaz> cr3: I'm not sure if it's in checkbox - let me try again
[00:57] <Keybuk> cjwatson: I still disagree
[00:57] <mathiaz> cr3: hm yes - it seems to be checkbox related
[00:57] <Keybuk> any library that changes its API in its header files in a non-backwards compatible way should take steps to ensure applications can be upgraded
[00:57] <Keybuk> e.g. by changing SONAMEs, bumping major versions, etc.
[00:58] <mathiaz> cr3: moreover I had only selected disk and network tests - and got this user applet test in a vm
[00:58] <Keybuk> this is a non-backwards compatible header change
[00:58] <Keybuk> it should be handled better
[00:58] <cjwatson> what I mean is that it is better to resolve the issue at the furthest upstream point and then trickle down, to ensure that we're not just constantly flip-flopping
[00:58] <mathiaz> cr3: I'm not sure if this is the expected behavior
[00:58] <mathiaz> cr3: as I have the option to skip it, it's ok.
[00:59] <cjwatson> I never disagreed that it's a bug - I just disagree with you about where it's best to start handling it
[00:59] <Keybuk> cjwatson: I don't disagree
[00:59] <cjwatson> (or seem to ...)
[00:59] <cjwatson> largely because I'm entirely certain that if we file a glibc bug, Ulrich will just close it, and then our only recourse is to make Ubuntu incompatible with the rest of the glibc 2.10 world
[01:00] <Keybuk> likewise there's no point fixing code until it's resolved upstream
[01:00] <Keybuk> cjwatson: wasn't that the reason we switched to eglibc?
[01:00] <cjwatson> no, it was one of the straw-men
[01:00] <cr3> mathiaz: it's not expected, I would like to look into this problem
[01:00] <cjwatson> it explicitly wasn't a way to get us out of maintaining compatibility
[01:00] <Keybuk> cjwatson: really? because I'm pretty sure having read everything that the entire reason for eglibc's existance is "Ulrich"
[01:01] <cjwatson> eglibc means that somebody else is handling the integration of ports for us
[01:01] <Keybuk> you realise that we're in the wrong seats again though? :)
[01:01] <cjwatson> I think that's 90% of the reason Debian moved to it
[01:01] <cjwatson> I do :-)
[01:01] <Keybuk> you're the one defending an API breakage that I'm complaining about <g>
[01:01] <Keybuk> we must stop doing this :p
[01:02] <cjwatson> of course BSD people I talked to took the pragmatic approach and said "just use a wrapper function already"
[01:02] <cjwatson> no doubt because they've seen the function with both prototypes in the wild :)
[01:02] <Keybuk> I'd just nih it instead and not use the library function ;)
[01:03] <cjwatson> changing SONAME would be wrong, BTW, it's not an ABI-significant change
[01:04] <Keybuk> the weird thing is that things only fail sometimes
[01:04] <Keybuk> I can't work that out yet
[01:04] <Keybuk> sometimes gcc/glibc are quite happy with one prototype matching the other
[01:04] <Keybuk> and other times they are not
[01:04] <cjwatson> oh, and unfortunately you have to register with austingroupbugs.net in order to do so, but I'd appreciate it if you would provide real-world examples of breakage in the POSIX defect I filed
[01:05] <Keybuk> doesn't seem much point
[01:05] <cjwatson> or send them to me and I'll pass them on
[01:05] <Keybuk> that's in the 10-year fix timescale
[01:05] <Keybuk> ;)
[01:05] <Keybuk> "we'll fix that in POSIX 2017"
[01:05] <Keybuk> it'd probably be better just to change the qsort() manpage, etc. and just move on
[01:05] <cjwatson> if it's on the list to be fixed in the next version of POSIX, I think it'd be much easier to persuade Ulrich to make it a POSIXLY_CORRECT thing
[01:05] <Keybuk> that's what I mean
[01:06] <Keybuk> the "next version of POSIX" is likely to *be* 2017 :p
[01:06] <Keybuk> ironically this is a fall-out from the version of POSIX that can be largely be described as "catch up with linux/glibc"
[01:06] <cjwatson> sure, but that doesn't necessarily mean we won't get an answer to the defect before that, which we can quote
[01:06] <cjwatson> and have the header change versioned with the usual feature test defines, etc.
[01:07] <Keybuk> I'm inclined though, still
[01:07] <Keybuk> to suggest this is a C bug
[01:07] <cjwatson> my brain dribbled out my ears trying to parse the relevant bit of the standard
[01:07] <Keybuk> int (const void *, const void *) and int (const char *, const char *) should really be compatible
[01:07] <Keybuk> if they were, it wouldn't matter
[01:07] <cjwatson> I'm still not sure I was reading it correctly
[01:07] <Keybuk> and you could pass strcmp and other useful things there too
[01:07] <cjwatson> yeah, I agree
[01:07] <Keybuk> and then you could do standard glib-style
[01:07] <Keybuk>   int (void *, other args here)
[01:07] <Keybuk> but pass a function in that takes
[01:08] <Keybuk>  int (SomeOtherStruct *, other args here)
[01:08] <Keybuk> without casting
[01:08] <Keybuk> and thus still be typesafe
[01:08] <cjwatson> yes, it would be much more convenient
[01:08] <Keybuk> otherwise you basically end up casting all function pointers
[01:08] <Keybuk> and lose all point of having them at all
[01:08] <cjwatson> if I could understand the relevant bit of the standard well enough, I'd file a defect report with the C committee as well :-)
[01:09] <cjwatson> well, the usual answer is not actually to cast, but to do int (void *first, other args here) { char *thingiactuallywanted = first; ... }
[01:09] <cjwatson> but that's tedious
[01:09] <Keybuk> that's horrendously inefficient
[01:09] <Keybuk> especially if you're using generic functions, which it's very common to pass, like free()
[01:10] <Keybuk> wrapping every single one costs you a PLT entry, a relocation, multiple stack frames, etc.
[01:11] <mathiaz> cr3: and what about the first bug I've seen?
[01:11] <mathiaz> cr3: (http://paste.ubuntu.com/271278/)
[01:11] <cjwatson> hmm, a clever enough compiler could perhaps notice that it was just a wrapper to get the types right and optimise it away; although it might have to do some analysis on what you were doing with the function pointers to do that
[01:11] <Keybuk> actually, I don't think it's *permitted* to optimise that away
[01:12] <Keybuk> you'll probably find that kind of thing isn't allowed
[01:12] <Keybuk> and, let's be fair about this
[01:12] <Keybuk> there are many terms we can use to describe gcc
[01:12] <Keybuk> I would not include "clever compiler" in them
[01:12] <cjwatson> hah
[01:12]  * Keybuk contemplates Build-Depends: llvm-clang
[01:13] <Keybuk> http://0pointer.de/public/keybuk
[01:13] <Keybuk> are those not the most *gorgeous* warning outputs
[01:14] <Keybuk> file.c:623:41: warning: incompatible pointer types passing 'int (struct dirent const **, struct dirent const **)', expected '__compar_fn_t' (aka 'int (*)(void const *, void const *)')
[01:14] <Keybuk>         qsort (paths, npaths, sizeof (char *), alphasort);
[01:14] <Keybuk>                                                ^~~~~~~~~
[01:21] <ion> keybuk: clang’s warnings are awesome when they exist. For some things, warnings have yet to be implemented. :-)
[01:22] <Keybuk> ion: well, yes
[01:23] <Keybuk> and the fact I use a few too many GCC Extensions for clang right now
[01:25] <mathiaz> cr3: I've uploaded checkbox 0.8.3 and reported bug 429764
[01:25] <mathiaz> cr3: it wasn't working in 0.8.2 too
[01:28] <mathiaz> cr3: and bug 429767
[02:24] <superm1> Keybuk, why are the start levels in /etc/rc*.d all changed now to 0-6?
[02:25] <Keybuk> superm1: -v
[02:38] <Keybuk> superm1: ?
[02:38] <superm1> Keybuk, i just made sense of it, it's because of the change to dependency based in sysvinit
[02:38] <Keybuk> but we didn't make that change
[02:39] <superm1> um. debian appears to have done so, and then you merged their package?
[02:39] <Keybuk> yes, but I explicitly disabled that
[02:40] <superm1> Hmm, then why is it taking effect for me on a mythbuntu live disk?
[02:40] <superm1> how was it disabled?
[02:40] <Keybuk> stat /etc/init.d/.legacy-bootordering
[02:40] <superm1> no such file or directory
[02:40] <Keybuk> err, ok
[02:41] <Keybuk> dpkg-query -W sysv-rc
[02:41] <superm1> sysv-rc 2.87dsf-4ubuntu1
[02:41] <Keybuk> stat /var/lib/insserv/using-insserv
[02:42] <superm1> no such file or directory
[02:42] <Keybuk> dpkg -s sysv-rc | grep Status
[02:42] <superm1> Status: install ok installed
[02:42] <Keybuk> grep "upgrade sysv-rc" /var/log/dpkg.log
[02:43] <superm1> no results.  it's a fresh install
[02:43] <Keybuk> ah
[02:43] <Keybuk> I think you just found a bug ;)
[02:43] <Keybuk> thx, will fix
[02:43] <superm1> yays
[02:44] <superm1> okay then i wont go and modify my init scripts to set dependencies right
[02:44] <Keybuk> touch /etc/init.d/.legacy-bootordering
[02:44] <Keybuk> that should revert things back to old behaviour
[02:44] <Keybuk> though it's possible that your install is broken
[02:45] <superm1> well it's a throwaway vm that i was just trying to identify some other bugs, so no big deal
[02:46] <Keybuk> fix uploaded
[02:46] <superm1> cool thanks
[03:05] <cr3> mathiaz: thanks for the bug reports!
[03:05] <cr3> mathiaz: by the way, in 429767, you mean "However there is *no* option to Skip the test", right?
[03:08] <mathiaz> cr3: oh - there *is* one
[03:09] <cr3> mathiaz: I understand what you mean though: the skip option doesn't actually skip the test, right?
[03:10] <mathiaz> cr3: right - this is the first bug actually
[03:10] <mathiaz> cr3: for the second, the fact that there is a skip option doesn't make it so important
[03:10] <mathiaz> cr3: the best user experience would be to *not* have the fingerprint test shown at all (since there isn't a fingerprint ready in the vm guest)
[03:11] <mathiaz> cr3: and moreover there isn't any GUI environment
[03:11] <mathiaz> cr3: so following the testing procedure isn't possible  in a vm -server guest
[03:11] <mathiaz> cr3: since there is a skip option it's not that bad - as one can just skip the test
[03:12] <mathiaz> cr3: (which doesn't work right now because of bug 429764)
[03:20] <cr3> mathiaz: gotcha, these will be fixed shortly. if I didn't have my hands full tonight, they'd be done already :(
[03:20] <mathiaz> cr3: that's fine - they're not a blocker for alpha6
[03:20] <mathiaz> cr3: I've already uploaded 0.8.3 to karmic
[03:21] <mathiaz> cr3: if you could mark the branch as merged, that would conclude the review cycle
[03:22] <tedg> Uhm, this error is too big for me.  "dpkg-shlibdeps: error: no dependency information found for /lib/libc.so.6 (used by debian/indicator-session/usr/lib/indicator-session/gtk-logout-helper)."  How could libc not have dependency information?
[03:23] <slangasek> tedg: is this in a build log?
[03:23] <tedg> slangasek: No, local machine.
[03:23] <slangasek> tedg: what version of libc6-dev?
[03:23] <tedg> I have 2.10.1-0ubuntu8 installed
[03:24] <tedg> Apparently there is a newer one on the archive.  ubuntu11.  Probably should grab that.
[03:26] <slangasek> ah; I was worried about a regression in a more recent version; I doubt it'll change anything, but yes, please retest with the latest
[03:27] <tedg> Hmmm... not pretty.  I think it's something with my dpkg db.  "unrecoverable fatal error, aborting: files list file for package 'libxklavier15' is missing final newline"
[03:27] <slangasek> oh yes, that'd do it :)
[03:27] <slangasek> disk full?
[03:28] <slangasek> mv /var/lib/dpkg/status{,-busted} && mv /var/lib/dpkg/status{-old,} ?
[03:28] <tedg> Nope, but "/var/lib/dpkg/info/libxklavier15.list" is trashed.
[03:28] <cr3> mathiaz: done, thanks again
[06:32] <dholbach> good morning
[07:35] <soren> cjwatson: If you have input on how to fix up the axis2c problem, I'm very open to suggestions. The problem is that older versions of axis2c shipped some directory symlinks, and when upgrading, dpkg respects those symlinks, so a lot of stuff ended up in all the wrong places.
[07:41] <soren> zul_: Go to bed.
[07:42] <zul_> soren: cant if liam keeps waking up every half hour
[07:43] <soren> zul_: Give him some nyquil. I took some last night, and passed out almost immediately and could hardly wake up this morning.
[07:43] <soren> (I'm not a doctor, though)
[07:43] <zul_> heh
[07:43] <soren> Wow. You know you've spent too much time in the US, when you feel the need add disclaimers to stuff like that.
[07:46] <soren> This occurred to me the other day as well.. I was in a restaurant and the menu said they recommended you order your steak rare or medium rare, because it tastes better/more that way. That would never happen in the US. They'd be too scared to be sued if someone got sick from eating undercooked meat. :)
[07:47] <zul> soren: I dont like drugging him up either
[08:00] <slangasek> soren: 425914> so what can go wrong here?  Eucalyptus packages failing to configure in cases where it configured before (e.g., if the admin provides no input on the new debconf questions)?  Things breaking on upgrade?
[08:07] <zul> soren: alrighty talk to you in a couple of hours
[08:13] <soren> slangasek: This only applies for fresh installs.
[08:14] <soren> slangasek: The primary risk is the default values for the network we provide, really. If they match a subnet the admin already uses, things are going to be odd.
[08:14] <soren> Not horrible, just odd :)
[08:14] <slangasek> ok
[08:25] <ttx> soren: where can I find the manifest for packages in the current EC2 images ?
[08:26] <soren> ttx: Err.. Good question.
[08:27] <ttx> soren: I suspect Scott's list of universe packages overlooks some multiverse ones.
[08:33] <soren> ttx: I suspect you're right.
[08:33] <pitti> Good morning
[08:34] <pitti> hi kirkland
[08:34] <ttx> pitti: o/
[08:34] <pitti> hey ttx
[08:34] <ttx> soren: I just wanted to get the list right. I'll fire up an instance and look.
[08:35] <ttx> soren: the question of manifests generation still holds, though, especially in contaxt of alpha6 release goals :)
[08:35] <soren> ttx: I hear you, I hear you.
[08:37] <wgrant> pitti: Hi. I'm currently gluing bits and pieces together to get Soyuz to manage ddebs itself. I've two pkg-create-dbgsyms branches which go part of the way to that goal. Can you have a look at them?
[08:38] <tkamppeter> pitti, hi
[08:38] <tkamppeter> pitti, can you have a look at bug 429880?
[08:40] <tkamppeter> First it seems that we need to add something to debian/control so that CUPS is only started after udev, should be a "Depends: udev". Am I right?
[08:41] <tkamppeter> pitti, second, it seems that the postinst scripts of the drivers are executed even with CUPS' postinst having failed. Is "Depends: cups" there not enough?
[08:42] <mvo> cjwatson: re bug #387112 - do you want me to do the matching debconf change as well (or do you have it prepared already)?
[08:49] <pitti> tkamppeter: depends cups: should be enough, it ensures that all the dependencies are configured before the package is configured
[08:50] <pitti> tkamppeter: one problem in bug 429880 is that the new apparmor doesn't work with the jaunty kernel, and thus reloading AA doesn't work
[08:50] <pitti> tkamppeter: that's why cupsd fails to start
[08:54] <MindVirus> Hello.
[08:54] <MindVirus> Does startupmanager work with grub2, and, if so, why does it depend on grub?
[08:55] <MindVirus> AFAIK startupmanager does work with grub2.
[08:55] <pitti> tkamppeter: I added the analysis to the bug report and assigned it to me
[09:01] <tkamppeter> pitti, are bug 429872 and bug 429880 duplicates then?
[09:02] <MindVirus> ...?
[09:03] <pitti> tkamppeter: sounds like
[09:04] <pitti> tkamppeter: for the AA issue, this should probably be fixed in apparmor itself rather
[09:08] <seb128> pitti, since you seems aa knowledgable, any clue about bug #429863?
[09:09] <mr_pouit> Why was gdm-2.20 finally accepted into karmic? Since we finally agreed on keeping the new one for Xubuntu, I don't really understand. Because of that, people are doing some unneeded changes like <https://lists.ubuntu.com/archives/karmic-changes/2009-September/008727.html>…
[09:15] <tkamppeter> pitti, I think about adding "-h localhost" to all calls of CUPS CLI tools in the postinst scripts of printer driver packages, to address the problem of uses having a client.conf.
[09:16] <pitti> tkamppeter: hm, I already did that in the previous upload; did I miss something still?
[09:16] <pitti> tkamppeter: I tested it here, could reproduce the hang, and the current version now works just fine
[09:16] <pitti> tkamppeter: oh, sorry, printer _driver_ packages
[09:16] <pitti> right
[09:16] <pitti> seb128: looking
[09:18] <tkamppeter> Now the problem is, if a user has only "Listen /var/run/cups/cups.sock" and no other "Listen ..." or "Port ..." lines in cupsd.conf, does calling CLI tools with "-h localhost" still work?
[09:18] <tkamppeter> pitti: ^^
[09:18] <pitti> seb128: looks very familiar, like bug 429880
[09:18] <pitti> seb128: I'll shuffle that around a bit
[09:18] <MindVirus> Does anyone know why startupmanager depends on grub only?
[09:18] <seb128> pitti, thanks
[09:19] <pitti> tkamppeter: I didn't test that; does it work to do -h /var/run/cups/cups.sock by any chance?
[09:20] <pitti> tkamppeter: hah, seems like
[09:20] <pitti> tkamppeter: I don't have a printer on my laptop, but does "lpstat -p -h /var/run/cups/cups.sock" work for you?
[09:21] <tkamppeter> pitti, it works. Seems that everything which appears as output of "lpstat -H" can be used for the "-h" option.
[09:21] <pitti> splendid
[09:21] <tkamppeter> pitti, the "-h" must come first.
[09:21] <pitti> so this should be done in cups' scripts, too
[09:22] <tkamppeter> lpstat -h /var/run/cups/cups.sock -p
[09:22] <tkamppeter> works for me.
[09:23] <tkamppeter> pitti, Supplying non-existing host names or files with -h gives an error, so my test did not simply work due to -h being ignored.
[09:27] <pitti> tkamppeter: btw, trunk has 1.4.1 now, but the test suite fails due to some d-bus issue; I'm still investigating this
[09:28] <pitti> I'll upload it after alpha-6
[09:28]  * YokoZar wonders if the other default games are coming back to ubuntu-desktop
[09:30] <tkamppeter> pitti, have a look at Fedora's CUPS package, if they have already packaged 1.4.1, they have perhaps fixed the test suite problem. Especially you should also take a fresh Avahi patch for the dnssd backend from there. Our current patch makes dnssd not discovering device IDs.
[09:32] <tkamppeter> pitti, "lpstat -h localhost -p" does not work if there if "Listen /var/..." is the only "Listen ..."/"Port ..." line.
[09:33] <pitti> tkamppeter: fresh avahi patch> right, will do
[09:34] <pitti> tkamppeter: changing -h localhost to -h /var/run/cups/cups.sock in the scripts then
[09:36] <pitti> tkamppeter: right, http://cvs.fedoraproject.org/viewvc/devel/cups/cups-avahi.patch?view=log was updated 10 days ago
[09:40] <pitti> tkamppeter: all done in bzr now
[09:50] <tkamppeter> pitti, only possible way to break it now is that a user removes the "Listen /var/..." line (probability VERY low), but then we simply live without auto update of the PPDs.
[09:50] <pitti> tkamppeter: *nod*
[09:51] <tkamppeter> pitti, we must only check everywhere that the maintainer scripts ignore errors of CLI tools of CUPS.
[09:52] <tkamppeter> pitti, and this way we get only errors of CLI tools, not hangs due to a password prompt.
[09:57] <MindVirus> Anyone know why startupmanager depends on grub and not grub || grub-pc?
[09:59] <tkamppeter> pitti, I have seen that you have replaced signal numbers by signal names in the "trap" command line of the PPD updater in cups.postinst. One question: What is an "ILL" signal? Or is this a typo and should be "KILL".
[10:00] <pitti> tkamppeter: SIGILL is raised for "illegal instruction"
[10:01] <pitti> tkamppeter: signal numbers are a bashism, I converted them to signal names to be POSIX compliant and work with dash, etc.
[10:02] <pitti> tkamppeter: anything else which should go into the current cups upload? otherwise I'd upload it to karmic/sid now
[10:03] <tkamppeter> pitti, I have found another bug:
[10:03] <tkamppeter> if lpstat -h /var/run/cups/cups.sock -r > /dev/null 2>&1; then echo x; fi
[10:04] <tkamppeter> is not a valid test, "lpstat -r" always does "exit 0" even in an error case, like
[10:04] <tkamppeter> if lpstat -h /var/run/cups/cups.soc -r > /dev/null 2>&1; then echo x; fi
[10:04] <tkamppeter> (see the typo in the file name).
[10:04] <tkamppeter> pitti, we must grep the output here.
[10:05] <dholbach> ttx is reviewing in #ubuntu-reviews
[10:06] <tkamppeter> pitti, it must be
[10:06] <tkamppeter> if lpstat -h /var/run/cups/cups.sock -r | grep -v not > /dev/null 2>&1; then echo x; fi
[10:06] <tkamppeter> pitti, then it works.
[10:09] <tkamppeter> pitti, I am fixing it currently, wait for my "bzr push".
[10:10] <pitti> tkamppeter: please set LC_MESSAGES=C for that
[10:10] <pitti> tkamppeter: so that translations don't break it
[10:10] <pitti> tkamppeter: also, are you sure that the error goes to stdout, not to stderr?
[10:15] <tkamppeter> pitti, I have tested it, and I have set LC_ALL=C
[10:16] <pitti> tkamppeter: cool, thanks
[10:16] <tkamppeter> LC_ALL=C should be set automatically for system scripts, I hate bug reports with russion ot chinese error messages in log files.
[10:19] <apachelogger> james_w: quite possibly mercurial's convert plugin is at fault of messed up names ... it seems to translate bzr's committer field to the mercurial user field ... then again if bzr-fast-export|git-fast-import was not broken I would not have used hg to begin with ;)
[10:20] <tkamppeter> pitti, I am also fixing the PPD auto update now, as the PPDs coming with CUPS are dynamic now.
[10:22] <sivang> hi all
[10:22] <sivang> any muse users here?
[10:26] <tkamppeter> pitti, my fixes are committed now.
[10:26] <pitti> tkamppeter: thanks
[10:31] <MindVirus> Anyone know why startupmanager depends on grub and not grub || grub-pc?
[10:31] <tseliot> mdz: can you still reproduce bug 388357 ? If so, are you available to test a new patch?
[11:14] <soren> slangasek: Oh, you approved the FFe? Thanks!
[11:19] <lool> pitti: Hey I have an ugly pkgbinarymangler + pkg-create-dbgsym issue I'd like to discuss with you
[11:20] <lool> pitti: Here's my understanding of the issue: pkgstriptranslations will create the translation tarball in a single pass at dh_builddep time (when dpkg-deb --build is called) assuming that stuff has been dh_install-ed or similar before that
[11:21] <lool> pitti: But pkg-create-dbgsym breaks this assumption since it creates a temporary .deb tree with DEBIAN/control etc. and runs at dh_strip time
[11:23] <lool> pitti: I can reproduce a case here where pkgstriptranslations creates the translations tarball at dh_strip time (processes the *-dbgsym package)
[11:24] <lool> Sorry, the assumption is a bit more subtle than that
[11:24] <pitti> hi lool
[11:25] <lool> pkgstriptranslations needs DEBIAN/control files to be ready, so needs to be run after dh_gencontrol
[11:25] <pitti> lool: sorry, I fail to see the problem -- striptranslations andd dbgsym do wildly different things?
[11:25] <lool> pitti: http://launchpadlibrarian.net/31599040/buildlog_ubuntu-karmic-i386.netbook-launcher_2.1.8-0ubuntu1_FULLYBUILT.txt.gz is an example of the issue
[11:26] <lool> pitti: They do wildly different things except that dbgsym calls dpkg-deb --build
[11:26] <lool> pitti: Which triggers striptranslations too early in the build
[11:26] <pitti> aah, I see what you mean
[11:26] <lool> and I end up without some translations in the translations tarball
[11:27] <pitti> lool: uh, really? the po files should really be complete
[11:27] <pitti> but it could end up with some unstripped .mo files in the .deb
[11:27] <lool> pitti: the .pos are picked up but not the .mos
[11:27] <pitti> lool: right; we don't use the .mo files from _translations.tar.gz anyway, but that's indeed a bug
[11:28] <lool> pitti: We dont?  I think we do
[11:28] <pitti> lool: I think binarymangler should just ignore -dbgsym
[11:28] <pitti> lool: well, Rosetta _should_ use them really, but AFAIK it still doesn't
[11:28] <lool> pitti: Well the reason I'm chasing that is because I have no translations in netbook-launcher
[11:28] <sebner> pitti: mighty pitty! I think fedora don't like us :(
[11:28] <lool> pitti: We did the translations in the upstream project
[11:28] <lool> pitti: disabling translations in ubuntu in the mean time
[11:28] <pitti> sebner: ?
[11:29] <lool> pitti: then updated .pos in the upstream tarball and reenabled translations in ubuntu
[11:29] <sebner> pitti: libatasmart
[11:29] <lool> pitti: https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot
[11:29] <sebner> pitti: did you read latest comment?
[11:29] <lool> pitti: https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher
[11:29] <pitti> sebner: right, Lennart asked for some additional debug output, I'll forward it to the LP bug soon; but feel free to already respond with it upstream
[11:29] <pitti> sebner: I did
[11:29] <lool> pitti: So the template is picked up, but not the mos
[11:29] <pitti> lool: hm, Rosetta only picks up .po files
[11:30] <pitti> .mo files aren't (and shouldn't ever) be imported
[11:30] <pitti> they are useful for mapping domains, but not for importing translations
[11:30] <sebner> pitti: yeah but "disable it for all" and "blacklist" doesn't sound that good to me though :\
[11:30] <lool> pitti: Ok then I guess there's also a bug in rosetta
[11:30] <pitti> sebner: well, better than causing kernel oopses; it'll just disable smart monitoring, which wouldn't be a regression from jaunty (that didn't have it at all)
[11:30] <lool> pitti: Or do you see a reason why .pos aren't used to seed Rosetta here?
[11:31] <pitti> lool: perhaps it still needs to be approved?
[11:31] <pitti> lool: new translation templates need to go through a queue first
[11:31] <lool> pitti: Well dpm told me the import queue was empty
[11:31] <sebner> pitti: oh, kk. I'll try to give some debug information later but I'll add it to LP if you don't mind
[11:31] <dpm> pitti: yeah, they've been approved
[11:31] <pitti> lool: the build log shows that it grabbed 55 files, presumably the *.po and some *.mo files
[11:31] <lool> dpm: Are the strings seeded from .mos or .pos?
[11:31] <lool> pitti: No, just the .pos
[11:32] <lool> and .pot
[11:32] <lool> pitti: I have a local build with the resulting netbook-launcher_2.1.8-0ubuntu1_amd64_translations.tar.gz
[11:32] <dpm> lool: AFAIK, the POs, as pitti says
[11:32] <lool> pitti: If I dont install pkg-create-dbgsym I get 111 or so translations
[11:32] <lool> dpm: Ok so it looks like there's a bug in Rosetta then?
[11:32] <pitti> dpm, lool: hm, ter_status=NEEDS_REVIEW&field.filter_extension=pot has a lot of "blocked"; why's that?
[11:32] <pitti> sorry
[11:33] <pitti> lool: https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher/+imports?field.filter_status=all&field.filter_extension=all
[11:33] <lool> dpm: ^
[11:33] <pitti> I think it picked the wrong *.po naming scheme
[11:33] <pitti>    po/netbook-launcher-it.po is a really broken name
[11:33] <pitti> perhaps that one should be blocked, and all others approved?
[11:33] <lool> pitti: The translation tarball seems to fix that though
[11:33] <lool> -rw-r--r-- root/root      4441 2009-09-15 12:09 ./source/po/nb.po
[11:33] <lool> -rw-r--r-- root/root      3728 2009-09-15 12:09 ./source/po/nds.po
[11:34] <lool> ...
[11:34] <pitti> lool: ok, so I'll change pkgbinarymangler to just silently ignore *-dbgsym
[11:34] <lool> pitti: I had a look at the source code
[11:34] <pitti> lool: I really don't think that it actually breaks anything ATM, but still better to have complete tarballs
[11:34] <lool> pitti: And I didn't find that very clean to do
[11:34] <pitti> lool: yeah, unfortuantely nothing in that divert-mania is clean to do :-(
[11:35] <lool> pitti: But what we could easily do is export NO_PKG_MANGLE in the dpkg-deb invocation in create-dbgsym
[11:35] <pitti> this is an utter hack
[11:35] <lool> Or actually doing the ignoring in the diverted /usr/bin/dpkg-deb would work too I guess
[11:35] <dpm> lool: pitti: the templates were blocked at some point in order to allow only upstream translation. That caused the PO files to be blocked automatically. I then approved the templates, which should auto-approve any translations, but the latest upload didn't seem to upload any translations. The blocked PO files are from 2009-08-07, whereas the latest upload was a few days ago
[11:36] <lool> dpm: Well the LP build log indicates 55 translations were picked up
[11:36] <pitti> lool: either setting NO_PKG_MANGLE in -create-dbgsym or in dpkg-deb (similar to where it's set for PPA, autotest, or partner)
[11:36] <lool> And my local builds, even with the bug we are discussing, show them too
[11:36] <lool> pitti: We could do both
[11:37] <pitti> lool: I think I'll just add it to p-c-d
[11:39] <lool> pitti: http://paste.ubuntu.com/271405/
[11:40] <pitti> lool: right, got the same patch; do you want to commit/upload, since you already have the changelog?
[11:40] <lool> pitti: Oh there's a bzr?
[11:40] <lool> pitti: I'm happy to upload as a reward for chasing that down  ;-)
[11:40] <pitti> lool: eww, no Vcs-Bzr: indeed
[11:40] <lool> pitti: Ok will commit and upload
[11:40] <pitti> lool: lp:~ubuntu-core-dev/pkg-create-dbgsym/ubuntu
[11:40] <pitti> lool: perhaps you can add Vcs-Bzr:
[11:40] <lool> of course
[11:41]  * pitti hugs lool, thanks!
[11:41] <wgrant> That conflicts with one of my branches :(
[11:42] <pitti> wgrant: pkg-create-dbgsym?
[11:42] <wgrant> pitti: Yeah.
[11:42] <wgrant> Trivial resolution, just amusing that that part was modified twice in one day.
[11:42] <pitti> what did you change?
[11:43] <dpm> lool: I can't see any PO files from the last upload on the 10th in the imports queue (https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher/+imports?field.filter_status=all&field.filter_extension=po). Do you mind coming over to #launchpad and continuing the conversation with the LP devs, in case it's a problem with rosetta?
[11:43] <pitti> lool: for full love, please install pkgbinarymangler and then run tests/run in p-c-d, just to be sure
[11:44] <lool> wgrant: Are your branches good to merge?
[11:44] <wgrant> pitti: Stuff related to Soyuz ddeb support. I thought I pinged you about it earlier.
[11:44] <lool> wgrant: They seem to relate to corresponding LP changes
[11:44] <pitti> !!!!
[11:44] <pitti> wgrant: soyuz can digest .ddebs now?
[11:44] <wgrant> lool: No. I'm just getting reviews for all the bits in the various systems first.
[11:44] <tkamppeter> pitti, I tried to build CUPS 1.4.1 on my local box but it fails the tests. I get the following extra warning:
[11:44] <wgrant> pitti: Yes.
[11:44] <tkamppeter> W [15/Sep/2009:12:43:03.898501 +0200] [CGI] Unhandled message: interface=org.freedesktop.DBus.Introspectable, path=/, member=Introspect
[11:44] <wgrant> pitti: Possibly for 3.0, but more likely for 3.1.10.
[11:45] <lool> Cool
[11:45] <lool> wgrant, pitti: I think we should upload wgrant's stuff after A6
[11:45] <wgrant> pitti: Most of the work was done a couple of cycles ago, but the whole stack needs to be glued together now.
[11:45] <lool> rather than now
[11:45] <wgrant> lool: Certainly.
[11:47] <wgrant> pitti: So, those two branches really should go into older series too (mainly for PPA ddebs). It has been suggested that they just be stuffed into the chroots, rather than going through SRU. What do you think is best?
[11:47] <pitti> tkamppeter: that's what I get locally under karmic, but it doesn't happen in my sid chroot, nor on the buildds
[11:48] <pitti> wgrant: I'd put it into -updates TBH, seems cleaner to me
[11:48] <wgrant> pitti: That's what I thought.
[11:48] <wgrant> pitti: But it doesn't look like it has been done in the past.
[11:49] <lool> pitti: There's no bzr branch for pkgbinarymangler though?
[11:49] <pitti> lool: no, there isn't
[11:49] <wgrant> pitti: Can you look over those branches? I need to make compatible changes in a few separate places, so it'd be nice to know now if something's wrong.
[11:50] <lool> pitti: tests pass
[11:51] <pitti> wgrant: meh, bazaar.lp.net times out for me
[11:51] <pitti> lool: \o/
[11:52] <lool> pitti: I'm adding a README mentionning the tests/run thingie
[11:52] <wgrant> pitti: Ew.
[11:52]  * pitti uses bzr diff --new lp:...
[11:55] <pitti> wgrant: dpkg -I $ddeb | grep -q "Source: $src"
[11:55] <pitti> wgrant: where do you get $src from?
[11:55] <pitti> wgrant: it seems to grep for "Source: " only, which will probably work, but not assert a correct value?
[11:55] <wgrant> pitti: Oops. I mean $s.
[11:55] <wgrant> But yes, it still works..
[11:56]  * wgrant fixes and retests.
[11:56] <tkamppeter> pitti, I have tested the new dnssd backend now (manually installed) and PPDs get correctly auto-assigned. Now it needs only some fine-tuning in s-c-p, so that the different entries for the same printer are put together and URLs pointing to a CUPS queue get set up as raw queue by default.
[11:57] <pitti> wgrant: otherwise, add-missing-source-field looks good
[11:57] <wgrant> pitti: So, Soyuz will get a 'Build-Debug-Symbols: yes' into /CurrentlyBuilding, if the archive allows ddeb creation.
[11:57] <wgrant> pitti: Unfortunately the logic gets a bit messy, as we also have to handle the old case where Soyuz doesn't know to do that yet.
[11:59] <pitti> wgrant: respect-sbuild-dbgsym-config -> that needs a check whether /CurrentlyBuilding exists in the first place
[11:59] <pitti> wgrant: the old code does "if grep -qs", which is False if the file doesn't exist, and thus behaves correctly
[11:59] <lool> pitti: (Fixes the netbook-launcher .mo issue, uploaded)
[11:59] <pitti> wgrant: fir you do "if ! grep -qs /CurrentlyBuilding"?
[12:00] <pitti> ("fir"? "but")
[12:00] <pitti> wgrant: hm, should be fine, though; nevermind
[12:01] <pitti> wgrant: that branch looks good
[12:01] <wgrant> pitti: Great, thanks.
[12:01] <pitti> thanks to you
[12:02] <wgrant> pitti: The code to copy dbgsyms to public_html will remain for now, but it would be nice to kill it eventually.
[12:02] <wgrant> (the translations stuff is still there from 2006!)
[12:03] <pitti> wgrant: I'd love to kill it
[12:05] <lool> pitti: I just realized something relatively unfortunate: the only way to distinguish -dbgsym from other packages is their name and pkg-create-dbgsym ends with the same suffix
[12:06] <pitti> lool: what do you need this for?
[12:07] <lool> pitti: Well in cases like this for instance, when trying to identify -dbgsym packages in pkgbinarymangler
[12:07] <lool> pitti: Perhaps they should use a special section?
[12:07]  * lool goes to lunch &
[12:08] <pitti> lool: but why do you need to now?
[12:08] <pitti> lool: section> they could be in "debug", I guess
[12:13] <cjwatson> mvo: I already committed the matching debconf change upstream; I'll make sure it gets into karmic
[12:24] <wgrant> pitti: http://pastebin.ubuntu.com/271413/ (r126 and r127)
[12:24] <wgrant> A few of the test sources needed their names fixed.
[12:24] <wgrant> Though most were OK.
[12:25] <pitti> wgrant: $s$ -> $s\$
[12:25] <pitti> wgrant: otherwise looks fine, thanks
[12:26] <wgrant> pitti: Hm. It worked as expected without the backslash.
[12:27] <wgrant> Oh.
[12:27] <wgrant> I see.
[12:27] <wgrant> Duh.
[12:32] <LaserJock> cjwatson: I need some help with the Edubuntu DVD .iso regarding seeds, is there a separate channel for that sort of discussion?
[12:34]  * ogra hopes there isnt ... the amount of channel fragmentation we have nowadays is insane
[12:37] <LaserJock> ogra: agreed
[12:38] <davmor2> ogra: what do you mean.  There are only 30+ ubuntu channels, anyone would think it was hard to follow :)
[12:39] <dpm> lool: ok, the netbook-launcher translations seem to have now correctly been imported -> https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher/+pots/netbook-launcher/ I'll get on to the rest of the UNR translatable packages during the day
[12:40] <ogra> davmor2, yeah, i'm coming from a time where only #ubuntu-devel and #ubuntu-motu existed
[12:40] <davmor2> ogra: :)
[12:41] <wubbbi> I got a question. In ubuntu 9.10 netbook-remix. Are there any 3D effects enabled by default? oO my Compiz is off but there are till effects!
[12:41] <wubbbi> still
[12:48] <ogra> Keybuk, you like freezes for uploads eh ?
[12:48] <Keybuk> ogra: technically I had them queued for upload last night before Steve sent the mail
[12:49] <Keybuk> but my line went down for work half way through
[12:49] <ogra> yeah yeah :)
[12:49] <Keybuk> so there were things stuck in dep-wait
[12:49] <Keybuk> and it came back up, and the uploads continued by themselves :)
[12:49] <cjwatson> LaserJock: what's up?
[12:49] <lool> pitti: Well I just thought at a high level it was useful to have the info available when needed
[12:50] <ogra> Keybuk, whats that initramfs-tools thing ?
[12:50] <ogra> "Make usplash-related components optional, you need to set USPLASH=y"
[12:50] <lool> pitti: But I dont need it anymore; I just wondered how to do a clean -dbgsym check in pkgbinarymangler
[12:50] <ogra> Keybuk, does that affect the "splash" cmdline option in any way ?
[12:51] <LaserJock> cjwatson: well, it just doesn't look like my changes are making any effect
[12:51] <Keybuk> ogra: in the sense that usplash is not normally started, sure
[12:51] <LaserJock> cjwatson: I copied over ubuntu.karmic's dvd and dvd-live seed, I had to change STRUCTURE a little to reflect that we don't have a Desktop CD
[12:52] <ogra> Keybuk, "not normally started" ? you mean even if splash is set it wont start ?
[12:52] <LaserJock> cjwatson: I then added * edubuntu-desktop to dvd-live and waited for a rebuild. Looking at the latest one that really should have it, I don't see any real difference, no edubuntu stuff at all in the .manifest
[12:53] <Keybuk> ogra: right
[12:53] <ogra> Keybuk, grmbl
[12:53] <ogra> Keybuk, how does that act on live images ? do we leave the user without a splash ?
[12:54] <ogra> Keybuk, and how do i enable it on my arm setups where i have 1.5min bootime ?
[12:55] <Keybuk> for now, yes
[12:55]  * ogra feels like he wasted a lot of time this cycle by making usplash work on arm :/
[12:56] <Keybuk> we still want to start usplash if it takes more time than expected to start X
[12:56] <Keybuk> that bit is still to do though
[12:58] <ogra> Keybuk, well, i'D like to enforce it on arches where i know i'll never match the quick boot criteria
[12:58] <ogra> beyond that casper will always need it
[13:00] <Keybuk> ogra: you don't need to enforce it
[13:00] <Keybuk> it'll appear by itself
[13:00] <Keybuk> (it will appear, I should say)
[13:00] <ogra> ok
[13:00] <Keybuk> it's a good point though that casper probably should set it
[13:00] <ogra> unless we clean up casper :)
[13:00] <ogra> which i would prefer
[13:01] <ogra> it really has a lot of old cruft
[13:01] <Keybuk> well, that would be nice too
[13:01] <Keybuk> I'm really going to push for karmic+1 to use dracut
[13:01] <ogra> thigs were added over the years and nobody ever cared for them
[13:01] <Keybuk> complete with having a test ready for UDS to demo
[13:01] <Keybuk> that should massively help with the cleanup
[13:01] <ogra> as casper replacement ?
[13:01] <ogra> or just for initramfs-tools
[13:02] <Keybuk> initramfs-tools
[13:02] <ogra> yeah
[13:02] <Keybuk> so obviously inherently casper things too
[13:02] <soren> Keybuk: dracut? What's that?
[13:02] <soren> Keybuk: Google claims it's a place in Massachussets. :/
[13:03] <ogra> soren, a new and shiny way of building initramfs
[13:03] <Keybuk> it's a project to write an initramfs-tools/yaird/etc. variant "upstream"
[13:03] <Keybuk> it's very modular, and very configurable
[13:03] <Keybuk> e.g. just about everything can be overridden on the kernel command-line
[13:04] <soren> I see.
[13:08] <LaserJock> cjwatson: any thoughts?
[13:10] <cjwatson> LaserJock: looking
[13:11] <LaserJock> cjwatson: thanks
[13:14] <cjwatson> LaserJock: I think http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/285 should fix it
[13:16] <LaserJock> cjwatson: ahhh, I see
[13:17] <LaserJock> cjwatson: thanks for that, I thought I was doing something horribly wrong
[13:17] <LaserJock> which I suppose I still might, but at least it wouldn't be *just* me :-)
[13:24] <pitti> Keybuk: I committed your upstart changes to hal, apport, gdm bzr FYI
[13:25] <pitti> Keybuk: didn't you have a change for cups as well?
[13:27] <Keybuk> err, I have the committed
[13:27] <Keybuk> I just need to push
[13:28] <Keybuk> did you already push?
[13:28] <Keybuk> if there's nothing else in there, do you mind if I --overwrite yours
[13:28] <Keybuk> as otherwise it'll make things tricky for me in following up with other changes
[13:28] <LaserJock> cjwatson: what's the difference between LIST and LIVELIST in livecd.sh?
[13:29] <jdstrand> jjohansen1: hi! when you come online can we talk about bug #429872?
[13:29] <Keybuk> pitti: cups: yes, but you sneaked in a big update so my changes were rejected ;)
[13:29] <cjwatson> LaserJock: LIST remains installed on the target system if you use ubiquity; LIVELIST doesn't
[13:33] <Keybuk> pitti: err
[13:33] <Keybuk> pitti: apport - why did you drop the dh_installinit call?
[13:33] <LaserJock> cjwatson: so anything in the edubuntu-live seed is removed from the target system after the image is copied over?
[13:34] <cjwatson> LaserJock: that's the intent, ys
[13:34] <cjwatson> yes
[13:34] <lool> wgrant: Just a note that I pushed some packaging changes to pkg-create-dbgsym; shouldn't cause more conflicts with your branches except for changelog since I guess you touch mostly the actual code, but wanted to mention it just in case
[13:35] <Keybuk> pitti: oh, sorry, I see - cdbs will call it anyway
[13:37] <lool> ArneGoetje: Around?
[13:37] <lool> ArneGoetje: kasumi breaks the dvd build
[13:37] <lool> ArneGoetje: The following packages have unmet dependencies:                                  language-support-input-ja: Depends: kasumi but it is not installable
[13:37] <lool> ArneGoetje: Would you mind commenting on the MIR?
[13:38] <lool> ArneGoetje: If the plan is to include kasumi in karmic main for sure, then we could prepromote it and finish the MIR stuff before release
[13:38] <lool> ArneGoetje: But if you think we can do without I'd like to relax the dep so allow the dvd livefs to build
[13:38] <ogra> cjwatson, did NCommander contact you for the dove stuff he wants in ubiquity ?
[13:39] <ogra> (two changed lines)
[13:41] <oreon> sera
[13:42] <cjwatson> ogra: I'm aware of the bug, but I have not seen the flash-kernel patch yet
[13:43] <Keybuk> pitti: I'm going to defer cups
[13:43] <Keybuk> I want to sort that udev-configure-printer mess out as well
[13:43] <Keybuk> since afaict, they should not be udev rules but upstart jobs anyway
[13:44] <cjwatson> ogra: I'm looking at the ubiquity branch now
[13:44] <cjwatson> ... which is of course fine
[13:44] <ogra> cjwatson, 3437 and 3439 are needed anyway
[13:45] <ogra> thanks :)
[13:45] <ogra> CIA-33 is fun :)
[13:46] <ogra> lool, ^^^ we should steal that bot for mobile and arm branches :)
[13:46] <lool> You can set it up on cia.vc
[13:46] <cjwatson> see http://wiki.ubuntu.com/Installer/Development for the client-side setup (adjust to taste)
[13:47]  * ogra will take a look, its really helpful
[13:47] <cjwatson> ogra: what's happening with the targeted flash-kernel task on that bug?
[13:47] <cjwatson> if flash-kernel is going to change, I don't want to upload ubiquity until that's in place
[13:48] <lool> cjwatson: Last I heard NCommander had fixed the remaining issues but wanted to do a full install test
[13:48] <lool> cjwatson: Is it ok to upload flash-kernel + ubiquity tomorrow?
[13:48] <lool> or later today?
[13:48] <lool> cjwatson: Let me ask differently, until what time is it reasonnable to push them for A6?
[13:49] <cjwatson> the earlier the better, I don't want to delay CD builds
[13:49] <cjwatson> the later it lands, the more stressed davmor2 will be
[13:50] <ogra> lool, ubiquity is needed anyway
[13:50] <lool> cjwatson: I understand; I dont have the changes yet and have been harassing to get them; we will check with you when they appear
[13:50] <ogra> with or without flash-kernel
[13:50] <ogra> we should imho upload ubiquity ASAP ...
[13:50] <ogra> flash-kernel will only affect armel
[13:51] <lool> ogra: flash-kernel is copied in ubiquity
[13:52] <cjwatson> indeed
[13:52] <cjwatson> if I upload ubiquity now, I'm just going to have to upload it again when flash-kernel lands
[13:52] <ogra> oh, damned, yes, i forgot about that
[13:53] <ogra> well, NCommander has to run the meeting in 7 min so he should show up soon :)
[13:57] <MacSlow> pitti, what could I try to do (with jockey) to force it to detect the proprietary nvidia-driver being installed on the system?
[13:57] <cjwatson> soren: has anyone had a chance to look over my branch in bug 425922? it'd be awfully nice to get that into alpha 6 if possible
[13:57] <soren> cjwatson: I thought I saw you push that to the main branch?
[13:57] <cjwatson> no
[13:57] <cjwatson> I pushed the bridge device change
[13:58] <soren> Oh.
[13:58] <soren> Well, I'm perfectly happy with the change.
[13:58] <MacSlow> pitti, right now it does not show up in the windowed opened up "jockey-gtk" and I'm running on "nv" instead of "nvidia"
[13:59] <cjwatson> soren: I haven't been able to test it, that's all ...
[13:59] <soren> cjwatson: Oh.
[13:59] <cjwatson> that's why I'm asking for extra eyeballs :)
[13:59] <soren> cjwatson: I thought you had a cdimage building rig locally :)
[13:59] <cjwatson> I have some disk space problems
[13:59] <soren> Oh, that.
[13:59] <soren> right.
[13:59] <cjwatson> I try to avoid building locally unless I have to
[14:00] <cjwatson> I can give it another try and see if I can squeeze it in somewhere ...
[14:00] <davmor2> cjwatson: ubuntu has issues with oem ubi-timezone so there maybe a respin to fix that yet :(
[14:00] <soren> Well, it /looks/ good to me. :) I haven't tested it either.
[14:00] <cjwatson> davmor2: yes, I followed up to your bug
[14:02] <pitti> Keybuk: apport dh_installinit> me? you dropped it, you commented it out; I just removed it completely
[14:02] <pitti> Keybuk: cups> okay
[14:03] <pitti> MacSlow: hm, but you have it installed? from where?
[14:03] <MacSlow> pitti, via synaptic "nvidia-glx-185"
[14:04] <davmor2> cjwatson: I think there is something wrong, could be that it is halfway through being configured.  But apport-collect say Error connecting to Launchpad yadda yadda yadda
[14:04] <MacSlow> pitti, trying to force its use via xorg.conf causes a crash of Xorg (without a recoverable stacktrace)
[14:05] <soren> cjwatson: Do you have an opinion on https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/429087 ? Dan's suggestion seems reasonable enough to me.
[14:05] <pitti> MacSlow: hm, perhaps 185 is just not supported on your card?
[14:05] <MacSlow> pitti, my guess is, that the crash is caused by loading the glx-module
[14:05] <soren> cjwatson: (without it, your stuff will likely fail)
[14:05] <cjwatson> davmor2: please have a look around for other logs, then - syslog doesn't have the stuff I need
[14:05] <MacSlow> pitti, I'm pretty sure the GeForce 8800 GT is supported by nvidia-glx-185
[14:05] <cjwatson> davmor2: /var/log/installer/debug or /var/log/oem-config.log perhaps
[14:06] <pitti> MacSlow: can you please send me /var/log/jockey.log? (pastebin or mail)
[14:06] <davmor2> cjwatson: the popup says further info may be found in /var/log/syslog
[14:07] <davmor2> I've add oem-config.log
[14:07] <cjwatson> soren: oh, yeah, that should be straightforward to fix, I'll do that
[14:08] <soren> cjwatson: Lovely, thanks.
[14:08] <cjwatson> davmor2: ok, will look after food
[14:08] <soren> cjwatson: If you want to roll a new revision and upload, I'm cool with that.
[14:09] <MacSlow> pitti, http://paste.ubuntu.com/271444
[14:13] <Keybuk> pitti: yeah just misinterpreted the comment
[14:13] <Keybuk> thought for a second you'd gone "oh, no more init script" and deleted the dh_installinit not realising that dh_installinit is what installs debian/*.upstart ;)
[14:13] <pitti> MacSlow: a-ha: ImportError: No module named NvidiaDetector.nvidiadetector
[14:14] <pitti> MacSlow: do you have the "nvidia-common" package installed?
[14:15] <blackxored> hello
[14:15] <MacSlow> pitti, checking...
[14:18] <MacSlow> pitti, ah ok... installed "nvidia-common" and depedencies and did "jockey-gtk -c -u", next call to "jockey-gtk" now does list the proprietary nvidia-driver
[14:19] <MacSlow> pitti, I wonder why this (nvidia-common) did not survive the dist-upgrade (from jaunty to karmic)
[14:19] <pitti> MacSlow: sometimes packages get slightly out of sync, and people accidentally uninstall them instead of holding them back
[14:19] <pitti> but I don't know for sure, of course, what happened to your's
[14:22] <Keybuk> pitti: interesting FTBFS on apport
[14:22] <Keybuk> not sure whether it's just archive churn
[14:23] <MacSlow> pitti, could a "apt-get autoremove" have been the reason for unintalling "nvidia-common"?
[14:24] <MacSlow> pitti, that's the only "out of the ordinary" thing I did in between
[14:26] <pitti> Keybuk: lol
[14:26] <pitti> Keybuk: 2.10 < 2.2 ...
[14:26] <pitti> Keybuk: will fix
[14:26] <Keybuk> ok, thanks
[14:31] <pitti> hm, ssh to the DC just fell of the planet
[14:32] <pitti> oh, it's just ronne
[14:32] <soren> works for me.
[14:32] <pitti> damn, I just wanted to fix the retracers
[14:33] <soren> pitti: Looks like it crashed. :(
[14:34]  * pitti sobs in the IS channel
[14:39] <cjwatson> urk, buildds are busted
[14:39] <cjwatson> http://launchpadlibrarian.net/31841882/buildlog_ubuntu-karmic-i386.os-prober_1.33_CHROOTWAIT.txt.gz
[14:39] <cjwatson> Keybuk: ^-
[14:40] <cjwatson> hmm, I wonder why 2.86.ds1-61ubuntu16 is still being used
[14:40] <cjwatson> lamont: can the above ^- be fixed by a chroot refresh? karmic has sysvinit 2.87dsf-4ubuntu3
[14:47] <smoser> slangasek, ping
[14:52] <robbiew> slangesek: did you get access to nectarine yet?
[14:53] <Keybuk> cjwatson: yeah I had that with the PPA system last night
[14:53] <Keybuk> I have *no* idea what they're up to
[14:54] <kirkland> pitti: howdy
[14:55] <pitti> hey kirkland
[14:55] <kirkland> pitti: hey man
[14:56] <Keybuk> the strange thing is that version of initscripts has been superseded at least 3 times now
[14:56] <Keybuk> and isn't even in the pool anymore
[14:57] <cjwatson> yeah, I wonder if it's in the chroot and is being held back
[14:57] <elops> a mount keeps being added to my mtab file
[14:57] <Keybuk> that was my guess
[14:57] <cjwatson> would /var/lib/dpkg from the chroot help?
[14:57] <elops> any idea why this might be? i may have added something somewhere a while back that did this, but i cant remember where... it is not in fstab
[14:57] <Keybuk> what's odd is that it started last night
[14:57] <Keybuk> cjwatson: it might
[14:57] <cjwatson> I think I can manage to extract it
[14:57] <Keybuk> elops: ?  that's what your mtab file is for
[14:57] <elops> the mount i do not want is identified in there.
[14:58] <elops> what to do?
[14:58] <Keybuk> elops: is the mount you do not want in your /etc/fstab ?
[14:58] <elops> no, i removed it (actually, changed its location)
[14:59] <elops> but the location that i do not want remains in the mtab and the /proc/mounts
[14:59] <Keybuk> did you reboot since?
[14:59] <kirkland> pitti: were you looking for me?
[14:59] <elops> yes, several times
[14:59] <pitti> kirkland: not particularly, I just answered some scrollback from overnight
[14:59] <kirkland> pitti: ah
[14:59] <Keybuk> elops: curious, can you pastebin your /etc/fstab and /etc/mtab files
[15:00] <Keybuk> and /proc/self/mountinfo too
[15:00] <kirkland> pitti: so the .face thing i've solved
[15:00] <kirkland> pitti: .dmrc is subtlely more difficult
[15:00] <cjwatson> Keybuk: cocoplum:/tmp/cjwatson/karmic-i386.tar.gz
[15:00] <elops> Keybuk: Sure.
[15:00] <pitti> kirkland: oh, not just an alternative path?
[15:00] <Keybuk> cjwatson: ITYM bz2
[15:00] <kirkland> pitti: because in the place where the path is build, there isn't already immediate access to the username
[15:00] <kirkland> pitti: needs a pwd call
[15:00] <kirkland> pitti: i just haven't gotten around to it
[15:01] <pitti> kirkland: oh, is the user name path of the .ecryptfs/.../.../.dmrc trail?
[15:01] <slangasek> smoser: ribbit
[15:01] <kirkland> pitti: /home/.ecryptfs/$USER/
[15:01] <pitti> ah, I see
[15:02] <kirkland> pitti: it's okay... i have a user object in the places where .face is called
[15:02] <Keybuk> cjwatson: did I tell you that I had a *total* epiphany about the hwclock stuff last night?
[15:02] <cjwatson> no?
[15:02] <Keybuk> you know that we do the system clock stepping in a udev rule when we see the first rtc device
[15:02] <evand> pitti: If I wanted to say "authorization is contingent on the request coming from the same physical console a specific USB disk is used on", do you know how I'd express that in policykit?  I'm not sure what the correct approach is, reading the current documentation.
[15:02] <Keybuk> I realised that was pointless
[15:02] <Keybuk> we deliberately designed that to *not* need the hardware ;)
[15:02] <Keybuk> so it can be done as an ordinary upstart job before mounting the root filesystem
[15:02] <pitti> evand: I don't think you can build relationships like that
[15:03] <pitti> evand: just "anyone", "local console", "active console"
[15:03] <elops> Keybuk: http://pastebin.com/d27473af
[15:03] <Keybuk> there's also a bug when UTC=yes at the moment
[15:03] <cjwatson> well, it needs the hardware, but the kernel has already read it on initialisation?
[15:03] <Keybuk> cjwatson: right, exactly
[15:03] <Keybuk> we don't set the system timezone if UTC=yes
[15:03] <evand> argh, okay
[15:03] <evand> pitti: thanks
[15:03] <Keybuk> so FAT timestamps are written in UTC instead of localtime
[15:03] <cjwatson> yum
[15:03] <elops> Keybuk: i dont have a mountinfo
[15:04] <cjwatson> bet that breaks subtlely
[15:04] <Keybuk> elops: /proc/self/mountinfo
[15:04] <cjwatson> subtly?
[15:04] <ogra> with subtitles ?
[15:04] <Keybuk> cjwatson: it doesn't break, it just annoys people because the times/dates on their cameras aren't right when they look in nautilus
[15:04] <elops> Keybuk: http://pastebin.com/d27473af
[15:04] <Keybuk> well, it annoyed one person so far
[15:05] <elops> Keybuk; there is only mounts and mountstats
[15:05] <Keybuk> elops: what kernel version?
[15:05] <Keybuk> elops: I'd say that whatever is mounting that icebox thing isn't reading fstab
[15:05] <elops> 2.6.22-14-server
[15:06] <Keybuk> your mtab is "correct"
[15:06] <Keybuk> in that it matches the kernel mount table
[15:06] <elops> i wonder where the hell i put the damn mount command at :(
[15:06] <elops> How can I fix this sir?
[15:06] <Keybuk> rc.local?
[15:06] <elops> what do you suggest I do?
[15:07] <elops> Keybuk: nope, not there
[15:07] <cjwatson> soren: I noticed that eucalyptus-{walrus,sc} weren't in main, which doesn't seem good - I promoted them and stuck them in the eucalyptus-simple-cluster seed
[15:08] <elops> Keybuk, i think i googled solutions to automounting a network drive when i tried this originally
[15:08] <cjwatson> elops: I'd 'grep -rs icebox /etc' if I were you
[15:08] <elops> its not a cronjob either
[15:08] <Keybuk> cjwatson: so there's nothing strange in status
[15:08] <elops> and i must've buried it in something on someone's advice, and now i have no idea where it is
[15:09] <elops> smb.conf of course
[15:09] <elops> lol
[15:09] <Keybuk> cjwatson: this is from the chroot itself?
[15:09] <Keybuk> rather than at the failure point, right?
[15:09] <cjwatson> Keybuk: that's the image stored in LP
[15:09] <Keybuk> *nods* just checking
[15:09] <elops> Keybuk: smb.conf of course
[15:09] <Keybuk> wondered if you knew some magic way of extracting failed build images
[15:09] <elops> hmm. i dunno if that's doing it.
[15:10] <cjwatson> Keybuk: I don't think they're stored
[15:10] <elops> can that be affecting it?
[15:10] <elops> please suggest anything.. im alsmot about to cry
[15:10] <cjwatson> Keybuk: I was wondering if it might be possible to do a trial apt-get dist-upgrade using something like chdist
[15:10] <evand> pitti: in your opinion, would it then be okay to set allow_active to yes in polkit for a method that modifies non-system internal devices, following the lead of devicekit-disks?
[15:11] <Keybuk> cjwatson: that's what I'm trying
[15:11] <elops> Keybuk: that can't cause it to mount, could it? i think that just sets up shares.
[15:11] <Keybuk> ogra: you didn't commit your usplash changes to bzr
[15:11] <Keybuk> elops: no idea, sorry
[15:12] <elops> the smb.conf I mean
[15:12] <evand> (org.freedesktop.devicekit.disks.change being what I'm referring to in devicekit)
[15:12] <elops> samba doesn't mount things for you
[15:13] <pitti> evand: with auth_admin? sure
[15:13] <pitti> evand: erm, "yes"? DK_disks doesn't do that, does it?
[15:13] <evand> pitti: It seems to: http://pastebin.ubuntu.com/271488/
[15:14] <pitti> evand: hm, indeed, that looks weird; I'm not sure what "change" means actually
[15:15] <evand> pitti: amongst other things, write a new partition table
[15:15] <pitti> evand: oh
[15:16] <pitti> evand: that's for removable devices
[15:16] <evand> indeed
[15:16] <pitti> org.freedesktop.devicekit.disks.change-system-internal is for fixed disks
[15:16] <pitti> and auth_admin
[15:16] <evand> correct
[15:16] <pitti> *phew*
[15:16] <evand> haha, sorry to scare you
[15:16] <pitti> evand: perhaps I misunderstood you
[15:16] <pitti> did you want to say non-(system internal)
[15:16] <pitti> or (non-system) internal
[15:16] <pitti> ?
[15:16] <evand> the former
[15:16] <evand> usb disks
[15:16] <pitti> aah
[15:17] <pitti> that's fine
[15:17] <evand> this is for usb-creator
[15:17] <evand> great
[15:17] <pitti> evand: right, that's fine
[15:17] <evand> thanks for the help!  Greatly appreciated
[15:17] <pitti> heh, I did't do anything :)
[15:17] <pitti> except for jumping and getting pale :)
[15:18] <evand> hahaha
[15:19] <Keybuk>   sysv-rc: Breaks: initscripts (< 2.86.ds1-63) but 2.86.ds1-61ubuntu16 is to be installed
[15:19] <Keybuk> cjwatson: yes, I see this
[15:19] <Keybuk> The following packages have been kept back:
[15:19] <Keybuk>   initscripts libc6 libc6-dev sysv-rc
[15:20] <seb128> hum, Keybuk broken the buildds!
[15:20] <seb128> broke
[15:20] <Keybuk> this is weird
[15:21] <Keybuk> ah
[15:21] <Keybuk>   initscripts: Breaks: upstart (< 0.6.3-2~boot4) but 0.6.3-1 is to be installed
[15:21] <Keybuk> and why hasn't upstart 0.6.3-2 been built?
[15:21] <Keybuk> dep-wait on debhelper
[15:22] <Keybuk> hmm, no, it has been built
[15:22] <Keybuk> just an hour ago
[15:22] <seb128> it's probably not published yet
[15:23] <Keybuk> right
[15:23] <seb128> wait another 25 minutes
[15:23] <Keybuk> cjwatson: this problem will likely cure itself :)
[15:23] <Keybuk> as soon as initscripts and upstart don't break each other
[15:23] <cjwatson> Keybuk: aha, ok, cool
[15:24] <Keybuk> lpia is going to need manual fixing though
[15:24] <cjwatson> thanks for investigating
[15:24] <Keybuk> since upstart can't build on that because the breaking initscripts is installed
[15:24] <cjwatson> upstart build arrived too late?
[15:24] <Keybuk> no, debhelper arrived too late
[15:24] <Keybuk> my internet line went down for maintenance last night *mid* uploads
[15:24] <Keybuk> and didn't come back up until noon today
[15:24] <cjwatson> looks like only amd64 armel i386 sparc have built
[15:25] <Keybuk> I've bumped the score of powerpc to rush upstart through before sysvinit
[15:25] <cjwatson> Keybuk: BTW, bug 320822 should buy another second or so on some boot workloads, although not the default
[15:25] <Keybuk> iirc, upstart and dbus don't build on ia64 anyway
[15:29] <cjwatson> Keybuk: I'll take care of a mass give-back of stuff that broke in the meantime
[15:29] <cjwatson> probably not huge amounts but it'll be easier to do by script than by hand
[15:29] <Keybuk> fair enough
[15:35] <EtienneG> Can someone look at bug #430075?  It is probably a dupe, I would just like to know if there is a temporary workaround so that I can continue testing eucalyptus (it is kind of urgent)
[15:40] <cjwatson> NCommander: what's happening with this flash-kernel change?
[15:40] <cjwatson> Keybuk: ^- 430075 looks like yours
[15:40] <cjwatson> EtienneG: might be something to do with:
[15:40] <cjwatson> sysvinit (2.87dsf-4ubuntu2) karmic; urgency=low
[15:40] <cjwatson>   * Use legacy boot ordering on fresh installs too.  Ooops.
[15:40] <cjwatson>  -- Scott James Remnant <scott@ubuntu.com>  Tue, 15 Sep 2009 02:44:35 +0100
[15:40] <cjwatson> (at a guess)
[15:40] <cjwatson> EtienneG: how recent was your installation?
[15:41] <EtienneG> cjwatson, yesterday's daily
[15:42] <EtienneG> cjwatson, that being said, it is indeed a prob with eucalyptus
[15:42] <EtienneG> cjwatson, I think the verbiage about insserv may just be cosmetic (or unrelated ot my problem)
[15:42] <cjwatson> yes, "EUCALYPTUS not configured!" is the direct breakage
[15:42] <EtienneG> cjwatson, a new version of euca conf file was shipped in the latest package, and it was not installed (might be because of the insserv package)
[15:43] <EtienneG> if eucalyptus do not have the new config, it will fail with "EUCALYPTUS not configured!"
[15:43] <EtienneG> I am adding info to the bug
[15:43] <cjwatson> I wouldn't expect that to have anything to do with insserv
[15:43] <Keybuk> I think the insserv stuff is just a different way of complaining about something that would fail anyway
[15:43] <Keybuk> the fact that insserv is there at all is a fixed bug
[15:43] <cjwatson> and I don't think that the new configuration file is relevant
[15:44] <EtienneG> Keybuk, thanks, that confirms what I think
[15:44] <cjwatson> that error is emitted when EUCALYPTUS is set to "not_configured" in /etc/eucalyptus/eucalyptus.conf
[15:44] <Keybuk> the Debian entente is that we have insserv installed, and anyone can chose to activate it if they can make it work, but not enabled by default
[15:44] <cjwatson> which probably actually happened because you accepted the entire new configuration file from the package rather than merging it
[15:44] <cjwatson> it's a slightly unfortunate state of affairs that it's so easy for this to happen
[15:46] <cjwatson> soren: any particular reason why EUCALYPTUS doesn't have a better default in our package? the current value seems ... unfriendly
[15:46] <cjwatson> Keybuk: sorry, I should have read that bug in a bit more detail before tossing it in your direction, I missed the crucial line
[15:47] <Keybuk> cjwatson: np
[15:50] <Keybuk>   * debian/control: Add udev dependency, since the init script calls udevadm.
[15:50] <Keybuk>     (LP: #429880)
[15:50] <Keybuk> pitti: (re cups) &
[15:50] <Keybuk> ARGH
[15:50] <Keybuk> WHY DOES THE INIT SCRIPT CALL UDEVADM!?!?!?!?!
[15:50]  * pitti looks
[15:50] <pitti> coldplug_usb_printers() {
[15:50] <pitti>     udevadm trigger --subsystem-match=usb \
[15:50] <Keybuk> I consider that a critical bug
[15:50] <pitti>                     --attr-match=bInterfaceClass=07 \
[15:50] <pitti>                     --attr-match=bInterfaceSubClass=01
[15:50] <Keybuk> please remove that at once
[15:50] <pitti> }
[15:51] <pitti> tkamppeter: ^ why was that necessary again?
[15:51] <pitti> ah, I guess to detect USB printers which were plugged in at boot, but not configured yet
[15:51] <slangasek> Keybuk: the init scripts sysvinit has dropped moved where?  Shouldn't sysvinit declare a pre-depends on the packages they've moved to?
[15:51] <pitti> Keybuk: out of interst, what does it break?
[15:51] <Keybuk> slangasek: it does, via upstart
[15:52] <Keybuk> pitti: boot performance
[15:52] <Keybuk> pitti: nothing should *ever* call udevadm trigger
[15:52] <Keybuk> I don't care whether or not it works in Mandriva
[15:52] <pitti> Keybuk: what's the correct way to do that then?
[15:52] <Keybuk> *do* *not* *do* *it*
[15:52] <Keybuk> pitti: libudev provides a udev_enumerate function set for enumerating the existing devices
[15:53] <slangasek> Keybuk: initscripts doesn't appear to have any dependencies on upstart
[15:54] <pitti> Keybuk: well, we can certainly rewrite it in some way with iteration, I just would expect this to be much slower than a precise trigger
[15:54] <Keybuk> slangasek: it does via sysv-rc no?
[15:54] <Keybuk> pitti: no, quite the opposite
[15:54] <Keybuk> and trigger can have entirely unexpected side-effects
[15:54] <Keybuk> trigger is *ONLY* used for catching up *udev*
[15:54] <Keybuk> not any other application
[15:55] <slangasek> Keybuk: sysv-rc also doesn't depend on upstart AFAICS
[15:55] <Keybuk> slangasek: this is one of those situations where dependencies won't make any difference no?
[15:55] <soren> cjwatson: What is it now? I forget.
[15:55] <soren> cjwatson: /?
[15:55] <Keybuk> everything depends on each other, and dpkg won't do anything useful anyway
[15:56] <slangasek> Keybuk: I'm trying to ascertain that things really do depend on each other in a useful manner, such that users don't have all their critical init scripts removed for a period during upgrade :-)
[15:56] <Keybuk> slangasek: doesn't the Breaks ensure that?
[15:56] <pitti> Keybuk: is it ok to call it with --dry-run, to get the affected devices?
[15:56] <slangasek> Keybuk: which breaks where?
[15:56] <Keybuk> pitti: yes
[15:57] <cjwatson> soren: yeah
[15:57] <pitti> Keybuk: good, thanks
[15:57] <Keybuk> slangasek: initscripts breaks the version of upstart that doesn't have the right support
[15:57] <soren> cjwatson: What would you suggest instead? ""?
[15:57] <Keybuk> which should force the upgrade
[15:57] <cjwatson> soren: um
[15:57] <slangasek> Keybuk: ah, ok; that might do it, let me meditate on that a bit
[15:57] <Keybuk> remember that upstart pre-depends initscripts
[15:57] <cjwatson> soren: no, what I mean is that *in the package* it's currently EUCALYPTUS="not_configured"
[15:57] <Keybuk> so it all gets very messy ;)
[15:57] <slangasek> right... :)
[15:58] <Keybuk> upstart -pre-depends-> initscripts -depends-> upstart
[15:58] <Keybuk> won't work
[15:58] <Keybuk> but I think (and tested) that
[15:58] <soren> cjwatson: It gets set by eucalypus-common in the postinst.
[15:58] <Keybuk> upstart -pre-depends-> initscripts -breaks-> upstart
[15:58] <Keybuk> does the right thing
[15:58] <soren> cjwatson: ...which is another thing I need to take care of.
[15:58] <soren> cjwatson: I.e. the whole conffile thing.
[15:58] <Keybuk> since it's upstart that depends on initscripts, which would not otherwise be installed, I think this is right
[15:58] <cjwatson> soren: yes. but this means that upgraders get it set back to EUCALYPTUS="not_configured" if they incautiously accept the change, and the postinst never undoes that.
[15:59] <cjwatson> soren: pending the whole conffile fix, why not just make it EUCALYPTUS="/" in the package?
[15:59] <soren> cjwatson: No particular reason anymore.
[16:00] <soren> cjwatson: And hypervisor could be set to KVM.
[16:02] <ArneGoetje> lool: I've taken kasumi out of the language-support-input-ja Depends: for now until the MIR is done...
[16:02] <jjohansen1> jdstrand: ping
[16:05] <cjwatson> soren: ok, this is odd. java -version is failing for me, saying it can't find libjli.so. do you see the same thing?
[16:05] <jdstrand> jjohansen1: so regarding bug #429872, it is causing some upgrade issues. Upgrades don't fail because of how we call apparmor_parser, but they are noisy and confusing due to the 'Profile doesn't conform to protocol' messages
[16:05] <tkamppeter> pitti, the udevadm call in the CUPS init script is to send a "plugged-in" signal for all USB printers. It takes care of re-enabling or setting up USB printers which where already plugged before the start of udev and cups.
[16:06] <pitti> tkamppeter: right, seems we need to rewrite that
[16:06] <pitti> tkamppeter: can I commit a rewrite to bzr, and you can test it?
[16:06] <jdstrand> jjohansen1: we talked about this a bit the other day with kees and mdeslaur, but I don't recall what the resolution was
[16:06] <tkamppeter> pitti, OK.
[16:06] <soren> cjwatson: Nope, works for me.
[16:06] <jdstrand> jjohansen1: well, we tangentially talked about it
[16:06] <tkamppeter> pitti, why can one not use these udevadm calls in the init script?
[16:06] <pitti> tkamppeter: Keybuk says it kills kittens and slows down boot
[16:07] <jjohansen1> jdstrand: it is a related issue,  yes
[16:07] <tkamppeter> It kills kittens?
[16:07] <Keybuk> tkamppeter: udevadm is for udev, not for cups
[16:07] <tkamppeter> pitti: Let us obsolete kittens and use another method.
[16:07] <jjohansen1> jdstrand: it happens because you are loading profiles under a newer kernel with an older parser
[16:07] <Keybuk> tkamppeter: is this to re-trigger udev-configure-printer ?
[16:07] <Keybuk> or does the cups daemon itself need it?
[16:07] <jjohansen1> jdstrand: but it shouldn't be happening from a jaunty userspace
[16:08] <pitti> tkamppeter: by discarding kittens so easily you aren't playing by the rules :)
[16:08] <jdstrand> jjohansen1: well, this is for people upgrading from jaunty to karmic
[16:08] <pitti> Keybuk: the former
[16:08] <Keybuk> pitti: right
[16:08] <Keybuk> as I've been saying for the past few weeks
[16:08] <pitti> Keybuk: I thought about using --dry-run and just calling udev-configure-printer in a loop
[16:08] <Keybuk> those should be called from Upstart, not from udev
[16:08] <jdstrand> jjohansen1: apparmor userspace will get upgraded and restarted first
[16:08] <tkamppeter> Keybuk: It is to retrigger udev-configure-printer, for printers which got already plugged before udev and cups got started.
[16:08] <Keybuk> then that solves your problem
[16:09] <jdstrand> jjohansen1: and then the packages with profiles come along and their postinst runs
[16:09] <jjohansen1> ah, okay - other way then
[16:09] <jdstrand> jjohansen1: so apparmor userspace is new on a jaunty kernel
[16:09] <jdstrand> jjohansen1: as soon as they reboot, it is all fine of cours
[16:09] <jjohansen1> jdstrand: right
[16:09] <kees> jjohansen1, jdstrand: what do you think about making the parser kernel-version aware?
[16:09] <jjohansen1> kees: that is the plan
[16:10] <kees> jjohansen1: well, that plan is *really* aware, I mean just "oh, wrong version *fail*"
[16:10] <jdstrand> kees: I'd actually rather like that. it seems a little odd that the parser is so closely tied to a particular kernel version-- and we aren't expressing that dependency anywhere
[16:10] <kees> jdstrand: *nod*
[16:10] <jjohansen1> yep
[16:10] <cjwatson> soren: ah. weirdness. /proc needs to be mounted or java gets its search path wrong ...
[16:11] <mdeslaur> kees: parser or just modify the init script for now?
[16:11] <soren> cjwatson: Ah, yes, I've seen this before.
[16:11] <kees> mdeslaur: parser
[16:11] <Keybuk> pitti, tkamppeter: if we start udev-configure-printer from an Upstart job, we can do things like
[16:11] <jdstrand> modifying the initscript would be valid as a last resort though
[16:11] <pitti> Keybuk: is that better? http://paste.ubuntu.com/271508/
[16:11] <Keybuk>   start on started cups and lp-device-added
[16:11] <Keybuk> ie. udev-configure-printer is *delayed* until cups is started
[16:12] <Keybuk> pitti: that will do for now.  I'll rip all this out post-alpha-6
[16:12] <slangasek> pitti: seen thta language-support-input-ja Depends: kasumi, which is in universe?  can we pre-promote that (MIR is open), or revert this in language-support-input-ja, so we can have DVDs build for A6?
[16:12] <jjohansen1> jdstrand: modifying the parser is easy
[16:12] <jjohansen1> jdstrand: there is already code doing some "version" checking, we just need to augment it
[16:12] <jdstrand> jjohansen1: I assigned the bug to you for now, based on my recollection of the conversation the other day. if someone else will be doing the modification, please reassign
[16:12] <pitti> Keybuk: right, it's just a quick fix; separate upstart job sounds good (but introduces a delta to Debian)
[16:12] <Keybuk> pitti: delta to Debian are not bad
[16:13] <pitti> tkamppeter: could you please verify that this http://paste.ubuntu.com/271508/ still works?
[16:13] <Keybuk> they're inevitable when shipping anything involving init or udev for the time being
[16:13] <Keybuk> though Debian is catching up :)
[16:13] <jjohansen1> jdstrand, kees: what kind of failure message are you looking for
[16:13] <slangasek> is the sysvinit upstart-job coming together?
[16:13] <Keybuk> slangasek: ?
[16:13] <pitti> Keybuk: well, in the case of cups I care, since I maintain it in Debian as well :) but we can certainly figure something out with lsb_release checking (as I already do on some other places)
[16:13] <slangasek> Keybuk: the compat wrapper that's the blocker for starting to ship upstart jobs in Debian packages?
[16:14] <Keybuk> pitti: right, that's what I was thinking
[16:14] <Keybuk> slangasek: nothing to do with me
[16:14] <jdstrand> jjohansen1: I don't suppose it is possible to run in a degraded mode, is it? (we talked a bit about that too I thought)
[16:14] <slangasek> well, you said Debian is catching up, so I thought you might know :P
[16:14] <slangasek> apparently it was just an empty platitude though :-P
[16:14] <Keybuk> slangasek: according to linux news sources, Debian have announced that they'll switch to Upstart
[16:14] <Keybuk> this is "catching up"
[16:15] <Keybuk> ie. we won't have a significant delta in the choice of our init system ;)
[16:15] <slangasek> yes, they'll switch once upstart-job is done. :)
[16:15] <jjohansen1> jdstrand: for karmic to jaunty, almost
[16:15] <Keybuk> slangasek: which is something someone in Debian is doing
[16:15] <Keybuk> I'm not a Debian Developer
[16:15] <jjohansen1> jdstrand: there are just a couple little things that can cause problems
[16:15] <Keybuk> nor do I follow Debian development
[16:15] <Keybuk> I have far too much Ubuntu development to follow ;)
[16:16] <jjohansen1> jdstrand: it is possible to do a simple degraded mode
[16:16] <jdstrand> jjohansen1: I ask because, while it is cryptic, we already have an error message. I wouldn't want the new message to be equally confusing
[16:17] <jjohansen1> jdstrand: yeah
[16:17] <jdstrand> we could probably come up with something though...
[16:17] <jdstrand> kees, mdeslaur: what do you think? ^
[16:17] <jjohansen1> jdstrand: I think the only thing that would have to fail would be the regexp based profile names, and that could be silent or a warning
[16:17] <kees> jjohansen1: "Current kernel version does not support Xyz, ignoring." or something?
[16:18] <jjohansen1> kees: no
[16:18] <jdstrand> kees: well, it fails for *all* profiles afaict
[16:18] <jdstrand> if we fail, it should be for profiles using unsupported features
[16:18] <jjohansen1> jdstrand: that is because the parser is putting caps64 in each profile
[16:19] <jjohansen1> jdstrand: it doesn't have to do that
[16:19] <pitti> slangasek: pre-promoting kasumi sounds fine (done), I'll update the MIR bug
[16:19] <jdstrand> the others should theoretically be made to work
[16:19] <slangasek> pitti: thanks
[16:19] <EtienneG> cjwatson, re: default config in eucalyptus; I think the previous situation was a bug (and a regression from jaunty).  Config *used* to have sensible default, but that was set in the postinst postinst
[16:19] <jjohansen1> jdstrand: yep without caps64 they do
[16:19] <jdstrand> jjohansen1: ah! so we can do a kernel check and add caps64 if it is supported?
[16:19] <tkamppeter> pitti,
[16:19] <tkamppeter> udevadm trigger --dry-run --subsystem-match=usb --attr-match=bInterfaceClass=07 --attr-match=bInterfaceSubClass=01
[16:19] <cjwatson> EtienneG: I can't figure out whether you're agreeing with what I said or not :-)
[16:19] <jjohansen1> jdstrand: yes
[16:20] <tkamppeter> has no output for me.
[16:20] <jdstrand> jjohansen1: could we then fail (with an appropriate message) for profiles that use an unsupported feature?
[16:20] <jjohansen1> jdstrand: yes
[16:20] <pitti> tkamppeter: ooh, of course; can you please add --verbose ?
[16:20] <mdeslaur> jjohansen1: are there any unsupported features besides caps64 in the current profiles?
[16:21] <mdeslaur> jdstrand: ^
[16:21] <jdstrand> jjohansen1: would it be possible to also list in the error message the feature that isn't supported?
[16:21] <jjohansen1> mdeslaur: yeah, pux, regexp profile names
[16:21] <jdstrand> mdeslaur: yes, pux and binary globbing/regex
[16:21] <jdstrand> basically, evince and firefox
[16:22] <mdeslaur> jdstrand: oh, ok. so why don't we just bomb out with the clear error message kees gave. I'll only log it once.
[16:23] <jdstrand> jjohansen1: I'm actually quite ok with failing gracefully in this way. if people are running an unsupported kernel, the error should let them know to adjust the profile if they are using an unsupported kernel
[16:23] <jjohansen1> jdstrand: yeah it should be able to list what isn't supported.
[16:23] <jdstrand> jjohansen1: the message just needs to be clear enough so that it isn't confusing on upgrade
[16:23] <jdstrand> jjohansen1: I think kees' suggestion does that well
[16:24] <mdeslaur> jdstrand: only logging once instead of logging for each profile would be nice
[16:24] <jjohansen1> mdeslaur: that is harder
[16:24] <jjohansen1> mdeslaur: we could modify the init scipt to quite after the first failure
[16:25] <jdstrand> I actually think it needs to be for each profile
[16:25] <jdstrand> that way, someone running an older kernel will know what is going on
[16:25] <mdeslaur> jjohansen1: oh, I though it was the parser that now went through the directory. my bad.
[16:25] <lool> ArneGoetje: ok thanks
[16:25] <ogra> Keybuk, ??
[16:26] <ogra> Keybuk, i committed before i even rolled the package
[16:26] <jjohansen1> jdstrand: yeah, I think it is cleaner and you get exactly what failed, as opposed to a single failure killing all profiles
[16:27] <jdstrand> also keep in mind, it should only be two profiles for jaunty -> karmic, and only one of those will be enabled
[16:27] <jdstrand> (be default)
[16:27] <jdstrand> s/be/by/
[16:27] <slangasek> pitti, tkamppeter: any time we can stop getting conffile changes on /etc/cups/cupsd.conf would be lovely
[16:27] <jjohansen1> jdstrand: uh isn't this case trying to load karmic profiles onto jaunty kernel
[16:27] <jdstrand> jjohansen1: yes
[16:28] <jjohansen1> so aren't we in the case of trying to load the full karmic profile set not just the 2 jaunty profiles
[16:28] <jdstrand> jjohansen1: jaunty upgrade to karmic. apparmor userspace is upgraded, profiles load for everything else after. only evince will have an unsupported feature by default
[16:29] <jdstrand> jjohansen1: all the other profiles aren't affected (once caps64 is fixed)
[16:29] <jjohansen1> jdstrand: right, cause firefox is not enabled by default
[16:29] <jdstrand> jjohansen1: exactly
[16:29] <jdstrand> jjohansen1: I was assuming fixing caps64 was a given. sorry for the confusion
[16:29] <ogra> Keybuk, hmm, i definately have the push in my bash history as well, but you are right, it doesnt show up on LP
[16:29] <jjohansen1> jdstrand: yeah its a given
[16:30] <mdeslaur> so, 1- kernel detection to fix caps64, and 2- more clear error message is profile is unsupported
[16:30] <mdeslaur> s/is/if/
[16:30] <jdstrand> that sounds perfect to me
[16:30] <jdstrand> (sans typo :P)
[16:30] <jjohansen1> mdeslaur: 1 - kernel detection, 2 caps64, pux, regexp profile name
[16:32] <jjohansen1> mdeslaur, jdstrand: caps64 will have failure message if a profile uses cap mac_override
[16:32] <jdstrand> jjohansen1: ok. we don't use it currently
[16:32] <pitti> slangasek: perhaps we shouldn't make it a conffile any more at all; we can't really stop cupsd from writing it, we just try to not change it over time
[16:33] <slangasek> pitti: I'm not concerned about cupsd writing it, I'm concerned about the fact that this is where I declare all my ACLs
[16:33] <slangasek> so I get a conffile prompt every time
[16:33] <slangasek> if there's another place that I can declare my ACLs that's not a conffile, I'll be happy to move them
[16:36] <pitti> tkamppeter: does it work with --verbose?
[16:36] <cjwatson> soren: eucalyptus-{sc,walrus} init scripts seem kind of busted. they just start/stop the cloud, as far as I can see!
[16:37] <cjwatson> what are they supposed to do?
[16:37] <soren> cjwatson: You might be fooled by the fact that eucalyptus-cloud is the bootstrapping thingamabob for all the java things?
[16:37]  * soren takes a look, though.
[16:37] <cjwatson> why are there three init scripts then?
[16:38] <cjwatson> it's not called with substantially different arguments or anything
[16:38] <cjwatson> it even uses the same pidfile in all three init scripts
[16:39] <soren> The -sc script sets JAR_NAME=/usr/share/eucalyptus/eucalyptus-storagecontroller-1.6-devel.jar
[16:39] <soren> Walrus sets it to something walrusy, I imagine.
[16:39]  * soren checks that.
[16:39] <cjwatson> yes, but it doesn't actually do anything with that other than checking that it's present
[16:41] <soren> Oh.
[16:41] <soren> Oh, dear.
[16:42]  * soren facepalms hesitantly.
[16:42] <soren> cjwatson: From the looks of it... "eucalyptus-walrus start" will copy the walrus jars to somewhere magical, and restart "the container".
[16:43] <soren> cjwatson: Similarly for the other java based things.
[16:43] <cjwatson> I don't see it copying anything
[16:43] <cjwatson> oh, enable_disable_service
[16:43] <cjwatson> wow, that's special
[16:44] <soren> Yes.
[16:44] <soren> Yes, it is.
[16:44] <cjwatson> do_stop is really quite wrong though, it stops the whole cloud
[16:45] <cjwatson> I'd argue that if there's a local cloud controller then do_stop should probably do nothing for the other Java components
[16:45] <cjwatson> unless there's some other way to stop the components independently
[16:45] <nixternal> any idea on how long the sysv, upstart, initscripts, and mountall will be fixed?
[16:45] <cjwatson> nixternal: I think they should already be fixed ...?
[16:45] <cjwatson> nixternal: -v
[16:46] <nixternal> just waiting for them to build then...groovy
[16:46] <cjwatson> they should already be built
[16:46] <cjwatson> what is your problem?
[16:46] <nixternal> amd64
[16:46] <nixternal> mountall isn't building according to LP
[16:46] <cjwatson> always pays to be specific :)
[16:47] <soren> cjwatson: Yes, do_stop is definitely wrong.
[16:47] <cjwatson> nixternal: I'm about to do a mass give-back of all the packages affected by this breakage
[16:47] <tkamppeter> pitti, now I have added --verbose, and udev-config-printer gets started for each USB printer, but with the following error:
[16:47] <tkamppeter> Sep 15 17:43:31 till-laptop udev-configure-printer: add /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.2/3-1.4.2:1.0
[16:47] <tkamppeter> Sep 15 17:43:31 till-laptop udev-configure-printer: unable to access /sys/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.2/3-1.4.2:1.0
[16:47] <nixternal> cjwatson: sounds like a ton of fun :)
[16:48] <cjwatson> nixternal: automatic
[16:48] <nixternal> well then, that is no fun
[16:48] <cjwatson> or at least it will be if I can find the relevant script
[16:49] <nixternal> hehe
[16:54] <pitti> re; sorry, dist-upgrade killed my session and then I had to repair apt and packages
[16:55] <cjwatson> Keybuk: is there a MIR for mountall? we'll need to get that reviewed quickly
[16:55] <pitti> tkamppeter: oh, it seems it doesn't like getting the full path
[16:56] <pitti> tkamppeter: if you replace "$printer" with ${printer#/sys} does it work then?
[16:56] <Keybuk> cjwatson: does it need one?
[16:56] <Keybuk> "I wrotez it, itz gud ya?"
[16:56] <ion> keybuk: I installed a local build of mountall and upgraded. It seems the rcS.d fsck/mount scripts are active now and clash badly with mountall.
[16:56] <Keybuk> ion: update initscripts too then, duh :p
[16:56] <cjwatson> Keybuk: I'm not actually overly bothered myself ...
[16:56] <cjwatson> pitti: do you care about a MIR for mountall?
[16:56] <pitti> cjwatson: not really
[16:57] <cjwatson> alright then
[16:57] <pitti> I noticed that it was missing and holds back upstart, but I didn't see it in the archive, nor in NEW
[16:57] <cjwatson> it's awaiting builds
[16:57] <pitti> ah
[16:57] <ion> keybuk: I should have the most recent versions of everything. initscripts 2.87dsf-4ubuntu2
[16:57] <cjwatson> which is awaiting me beating ubuntu-dev-tools over the head suitably
[16:57] <Keybuk> ion: 4ubuntu3 is the latest
[16:58] <ion> Ah, mirror lag probably.
[16:58] <Keybuk> ion: no, we're still picking pieces of the archive off the floor
[16:58] <Keybuk> the buildds did their thing in a, err, sub-optimal order
[16:58] <ion> Heh
[16:59] <ion> Ok, apt-get update, and the new initscripts package is available now.
[17:00] <cjwatson> Keybuk: what architectures is it safe to retry on?
[17:00] <cjwatson> amd64 i386 sparc at least
[17:01] <cjwatson> armel and powerpc look ok too
[17:01] <Keybuk> i386 looks ok
[17:01] <cjwatson> I'm guessing not lpia
[17:01] <Keybuk> amd64 should be ok too
[17:01] <Keybuk> lpia looks fucked yeah
[17:01] <Keybuk> ia64 probably won't build upstart anyway still
[17:02] <cjwatson> no, it's still stuck on 0.3.10 by the looks of things
[17:02] <Keybuk> all the others look good to me
[17:02] <Keybuk> cjwatson: yeah ;)  I had a strange feeling earlier, I thought I was caring about ia64, but then I realised I was just hungry
[17:02] <NCommander> Keybuk, O_O;
[17:03] <NCommander> Keybuk, aw, you should care about ia64, I like my desktop :-/
[17:03] <pitti> Keybuk: odd, when I'm hungry I stop caring about i386 as well..
[17:03] <tkamppeter> pitti, still does not work, I get now
[17:03] <tkamppeter> Sep 15 18:02:36 till-laptop udev-configure-printer: add /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.3/3-1.4.3.3:1.0
[17:03] <tkamppeter> Sep 15 18:02:36 till-laptop udev-configure-printer: parent devpath is /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.3
[17:04] <pitti> tkamppeter: and that's wrong?
[17:04] <tkamppeter> for each printer. A printer, manually disabled with the reason "Unplugged or turned off" does not get re-enabled by starting CUPS.
[17:04] <NCommander> cjwatson, ubiquity question, ubiquity normally copies the vmlinuz files from the /casper directory, but on Dove, we currently don't have a vmlinuz file available for it to copy (we have a uImage which we can strip down to a vmlinuz). How the best way to deal with this; I'm kinda tempted to just have livecd-rootfs leave the vmlinuz files in place on dove as we did with older ubiquities, but there may be a better way to deal with it
[17:04] <Keybuk> pitti: strangely, I still tend to use i386 rather than amd64
[17:05] <pitti> Keybuk: new apport uploaded, should build now
[17:06] <cjwatson> NCommander: can we just copy the uImage instead?
[17:06] <NCommander> cjwatson, I'll have to extend install.py to strip the first 64 bites off the file to remove the header
[17:06] <cjwatson> NCommander: ia64> port upstart, then ;-)
[17:06] <pitti> Keybuk: at least, it won't FTBFS due to the broken version check
[17:06] <cjwatson> NCommander: ick
[17:06] <cjwatson> NCommander: you know, all of this is just a space optimisation
[17:06] <Keybuk> pitti: :D
[17:06] <cjwatson> NCommander: if it's simpler to have livecd-rootfs leave the vmlinuz in place, then I'd recommend doing that
[17:06] <NCommander> cjwatson, thats probably ideally what we want to do, but this is "OMG, NEED IMAGE." mode right now
[17:07] <NCommander> (that is, with stripping the header)
[17:07] <Keybuk> cjwatson: actually it's deep pthready/libc issue
[17:07] <Keybuk> ../dbus/.libs/libdbus-convenience.a(dbus-sysdeps-pthread.o): In function `_dbus_pthread_condvar_wait_timeout':
[17:07] <Keybuk> ../dbus/.libs/libdbus-convenience.a(dbus-sysdeps-pthread.o): In function `check_monotonic_clock':
[17:07] <Keybuk> /build/buildd/dbus-1.2.16/dbus/dbus-sysdeps-pthread.c:353: undefined reference to `clock_getres'
[17:07] <Keybuk> /build/buildd/dbus-1.2.16/dbus/dbus-sysdeps-pthread.c:273: undefined reference to `clock_gettime'
[17:07] <cjwatson> NCommander: then just hack it in livecd-rootfs
[17:08] <Keybuk> (this is with -lrt)
[17:08] <pitti> tkamppeter: hm, did that really work with the previous rule (without --dry-run)? It's doing exactly the same call to the script as the udev rule..
[17:08] <NCommander> cjwatson, cool, just wanted to make sure ubiquity would still be happy in this configuration (I had checked the code, but wanted to make sure I didn't overlook something)
[17:09] <tkamppeter> pitti, I do not really know whether the old rule worked. What should happen is http://paste.ubuntu.com/271539/
[17:10] <EtienneG> cjwatson, total agreement, no worry there!
[17:10] <EtienneG> anyway, gotta go!
[17:11] <cjwatson> NCommander: yeah, it ought to be fine
[17:13] <pitti> tkamppeter: if you revert to the old init script, stop your printers, and restart cups, it works?
[17:13] <cjwatson> soren: also, uh, shouldn't do_stop actually kill $pid before it goes into the timeout loop?
[17:13] <cjwatson> (in tools/eucalyptus-java-ws.in)
[17:13] <tkamppeter> pitti, it seems that the "manual" call of "/lib/udev/udev-configure-printer add /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.2/3-1.2:1.0" does nothing (manually on command line, with sudo, or from the CUPS init script), but the call done by udev has the desired effect of re-enabvling the printer.
[17:14] <pitti> tkamppeter: does udev-configure-printer check any environment variables which might be set by udev? (it really shouldn't, though)
[17:15] <soren> cjwatson: It really should do a lot of things differently, if you ask me..
[17:18] <tseliot> slangasek: would it be possible to include a fix for bug 429241 in mesa despite the freeze?
[17:18] <tseliot> I wouldn't ask if it wasn't such a nasty bug
[17:23] <cjwatson> soren: I'll fix that particular bug, but it sort of needs torn up and rewritten :-(
[17:25] <soren> cjwatson: I agree.
[17:25] <soren> cjwatson: Will you file a bug on the subject?
[17:26] <slangasek> tseliot: if the upload is ready to go right now, yes please
[17:26] <cjwatson> soren: ok
[17:27] <tseliot> slangasek: yes, it is. I was waiting for your reply. Thanks
[17:30] <soren> cjwatson: Thanks very much.
[17:30] <tkamppeter> pitti, I have found the problem: There is the file /var/run/udev-configure-printer/usb-uris holding all device files and URIs of printers which are turned on, so doing a faked turn-off with cupsdisable does not work.
[17:32] <pitti> tkamppeter: ah, so it was just a testing error?
[17:33] <tkamppeter> Yes, pitti, now after also manually editing /var/run/udev-configure-printer/usb-uris to correctly fake the turn-off of the printer the start of CUPS enables it correctly.
[17:34] <pitti> tkamppeter: rock, then I'll commit that; thanks a lot for testing!
[17:34] <tkamppeter> pitti, so the correct coldplug function is http://paste.ubuntu.com/271554/
[17:35] <pitti> tkamppeter: right, that's what I have now
[17:36] <pitti> tkamppeter: pushed (thanks for your help, Keybuk)
[17:36] <tkamppeter> pitti, slangasek told that there is always a conffile change in /etc/cups/cupsd.conf.
[17:36] <pitti> tkamppeter: we should probably just stop treating this as a conffile
[17:37] <tkamppeter> It seems that it is not such a good idea to use cupsctl in the initscript. Usually this should change the conffile only once, as the user does not change the ammount of memory in the computer all the time.
[17:38] <pitti> tkamppeter: cupsd itself also changes it all the time, though
[17:38] <tkamppeter> pitti, then this one cupsctl call should not be a problem.
[17:39] <tkamppeter> How does CUPS itself change cupsd.conf (except of using cupsctl and similar user-initiated config tools).
[17:39] <pitti> tkamppeter: the web UI, s-c-p configuration, etc.
[17:40] <tkamppeter> pitti, but these are all configuration actions. The user changes the configuration, only he uses a GUI frontend.
[17:40] <pitti> tkamppeter: right, I'm just saying that I doubt that there are many users out there who have an unchanged cupsd.conf
[17:42] <tkamppeter> So then we must keep it being considered a conffile, as otherwise every CUPS update would reset it.
[17:43] <pitti> tkamppeter: no, to the contrary
[17:44] <pitti> tkamppeter: cups updates wouldn't update it any more, even if we change defaults (unless we explicitly use seddery)
[17:47] <tkamppeter> pitti, how does this work? Does cups not contain cupsd.conf as a file?
[17:47] <pitti> tkamppeter: we'd need to install it in /usr/share/cups/cupsd.conf.default, and only copy it to /etc on first installation
[17:51] <tkamppeter> pitti, will this not cause any problem on a major version change (ex: 1.3.x -> 1.4.x) of CUPS?
[17:51] <pitti> tkamppeter: well, it will cause problems either way, if the user keeps the old version and it becomes incompatible, he loses
[17:53]  * apw wonders where the OSD people hang out
[17:54] <int0x0c> I'm almost positive that last night's udev upgrade in karmic broke udev (effectively no modules are being loaded; e.g. intel_agp and psmouse are two notable cases)
[17:55] <cjwatson> soren: bug 430163
[17:55] <int0x0c> that is udev-147~-1
[17:55] <zyga> mvo: hey
[17:56] <zyga> mvo: yesterday I managed to finish the stuff at API level, implementation is still lacking in the new areas we talked about yesterday but should be fully done by today
[17:57] <zyga> mvo: I noticed that main got frozen today, that probably means that all the code done since then is not going to hit the master right? I'm fine with that because I hobby and deadlines dont mix very well, I'd like to track you with development and help however I can
[18:01] <ion> keybuk: http://heh.fi/patches/mountall/ rebased onto the current mountall. There’s also a new patch that fixes a bug: if a udev event triggers a check for a device that has already been checked but that is waiting for the parent partition to be mounted, it’s possible for another check to be started.
[18:03] <elops> Anyone know why file timestamps would be showing up as 'à¸.à¸' on an ext3 partition?
[18:04] <ion> Your locales contain such characters and your terminal prints UTF-8 incorrectly.
[18:05] <cjwatson> soren: is bug 426514 fixed now?
[18:06] <cjwatson> soren: it seems unlikely that that sort of thing would have survived an upstream update, but I'm not sure ...
[18:07] <cjwatson> soren: huh - actually, I don't see a definition of adb_ccInstanceType_set_networkIndex here?
[18:07] <elops> I thought it just showed question marks when the x attribute isn't set
[18:07] <cjwatson> does debian/patches/01-wsdl-stubs.patch need to be updated?
[18:08] <int0x0c> Can the udev scott james remnant ever be found around here?
[18:08] <int0x0c> s/the udev//
[18:08] <cjwatson> Keybuk: ^-
[18:09] <cjwatson> (your friendly answering machine)
[18:09] <ogra> you didnt beep :)
[18:09] <cjwatson> BEEP
[18:09] <ogra> heh
[18:10] <cjwatson> int0x0c: (do be patient, BTW, IRC is not as real-time as it looks and it's fairly normal to have conversations with long time lags)
[18:12] <madmike77_eee> I'm with a friend with a karmic alpha installation. We got a '/var/run/dbus/...' not found. Upon starting gdm manually we get a xorg-server but mouse and keyboard don't respond
[18:13] <int0x0c> Is there any way to force dpkg to mark a package as configured?
[18:14] <madmike77_eee> Also we have some packages on 'apt-get upgrade' (among those is upstart) that won't install because of missing dependancies
[18:14] <cjwatson> int0x0c: in theory yes, but please don't - better to give Keybuk a chance to find out what's wrong with your system, when he's around
[18:14] <cjwatson> madmike77_eee: upstart> that's known, we're in the process of fixing it
[18:15] <madmike77_eee> cjwatson: okay
[18:15] <Keybuk> int0x0c: what package is not configured?
[18:15] <cjwatson> (I don't know about dbus)
[18:15] <int0x0c> cjwatson: well, I'm fairly certain it's a completely recoverable failure
[18:15] <madmike77_eee> cjwatson: do you think the problem with dbus is related to upstart?
[18:15] <int0x0c> Keybuk: udev. It wants to `service restart udev`
[18:15] <cjwatson> madmike77_eee: I don't know
[18:15] <int0x0c> which is failing (which is clearly an issue)
[18:15] <Keybuk> int0x0c: what wants to do that?
[18:16] <int0x0c> Keybuk: udev's configure stage
[18:16] <int0x0c> really throws a wrench into things
[18:16] <Keybuk> int0x0c: yes, but if that does not succeed, it will not fail to configure
[18:16] <Keybuk> int0x0c: grep restart /var/lib/dpkg/info/udev.postinst
[18:17] <int0x0c> unfortunately, that doesn't seem to be true
[18:18] <madmike77_eee> cjwatson: is it not fixed yet or just released yet? I guess my friend here would be willing to install a pre-release
[18:19] <cjwatson> madmike77_eee: your friend will get it in karmic at the same time as everyone else :)
[18:19] <cjwatson> madmike77_eee: the build process went a bit awry, and we're having to unstick the build servers by hand
[18:19] <madmike77_eee> cjwatson: good news then :)
[18:20] <int0x0c> Keybuk: msg'd
[18:20] <int0x0c> Keybuk: sorry for the delay, not used to using irssi
[18:21] <Keybuk> int0x0c: you have an old version of the udev package
[18:21] <Keybuk> I'm not sure why it fails for you
[18:21] <int0x0c> Keybuk: Yes, I tried downgrading after 147 failed
[18:22] <int0x0c> Keybuk: I'll revert to 147
[18:22] <MindVirus> You guys know that the latest update in karmic removes ubuntu-minimal, yes?
[18:22] <Keybuk> yeah I think you fluffed the downgrade as well
[18:22] <cjwatson> MindVirus: yep, it's being sorted
[18:22] <Keybuk> argh
[18:22] <cjwatson> MindVirus: I hope it goes without saying that you should always carefully review the list of packages to be removed on any upgrade within a development release
[18:23] <MindVirus> cjwatson: OK. What is approximate TTL?
[18:23] <cjwatson> MindVirus: a few hours
[18:23] <MindVirus> cjwatson: I am very aware. :)
[18:23] <int0x0c> Keybuk: alright, yeah. My bad. I've reverted to 147
[18:23] <cjwatson> well, depending on when my wife gets back and drags me off for dinner :)
[18:23] <Keybuk> ah thanks
[18:23] <int0x0c> Keybuk: configured succesfully
[18:23] <MindVirus> cjwatson: great news.
[18:23] <ion> keybuk: Did you notice my message? :-)
[18:23]  * ogra grins
[18:23] <MindVirus> cjwatson: thanks for your help. :)
[18:24] <int0x0c> Keybuk: allow me to reboot and i'll see if this install went any better
[18:24] <Keybuk> int0x0c: WAIT!
[18:24] <Keybuk> oh, he left
[18:24] <ogra> heh
[18:24] <Keybuk> still, he won't be back
[18:24] <ion> Hehe
[18:24] <ogra> probably from the livecd he installed from
[18:25] <directhex> i'm glad i didn't use last weekend to update to karmic!
[18:26] <mvo> zyga: hey! yeah, main is frozen, I will do a upload today, but it will not include your work yet. I can only merge when I get the contribuor agreement
[18:26] <zyga> mvo: I fully understand, arghh
[18:26] <zyga> (corporate world issues)
[18:26] <int0x0c> Keybuk: alright, we it seems that udev-147 is just generally broken when it comes to module probing
[18:26] <int0x0c> Keybuk: Unfortunately, I can't directly confirm that as the downgrade path is broken
[18:27] <Keybuk> int0x0c: no, just karmic is incomplete right now
[18:27] <int0x0c> Keybuk: But it's the only package that has been touched recently that would cause this sort of failure, as far as I can see
[18:27] <zyga> mvo: are you going to keep on hacking software-store even though we're past freeze?
[18:27] <int0x0c> Keybuk: How so?
[18:27] <zyga> (targeting +1)
[18:28] <mvo> zyga: yes, a little bit at least, bugfixing is sitll permited :)
[18:28] <Keybuk> int0x0c: don't worry about the why, it's just broken right now
[18:28] <int0x0c> Keybuk: I don't mean to be difficult, but I am almost certain this is a udev issue
[18:28] <Keybuk> it isn't
[18:28] <int0x0c> Keybuk: Things are generally fine after I modprobe the missing modules
[18:29] <int0x0c> Keybuk: Then what is the issue?
[18:29] <ogra> flux :)
[18:30] <int0x0c> Keybuk: I don't mind sitting down and debugging, but I need a little more to work with that "it's broken"
[18:30] <zyga> mvo: and feature development/major stuff as outlined by the wiki/roadmap?
[18:30] <Keybuk> we don't need you to debug
[18:30] <madmike77_eee> do i have a chance to get the dbus up by hand?
[18:30] <mvo> zyga: no, that will not be possible anymore
[18:30] <ogra> int0x0c, there is a transition going on, its simply not complate yet
[18:30] <ogra> *complete
[18:31] <int0x0c> a transition from/to?
[18:31] <ion> keybuk: In fact, you might want to apply the bug fix to mountall before α6, if that’s possible. It’s just af small additional check. Without it, it was possible for a second fsck to be launched in parallel with mount for a device, causing nasty errors.
[18:32] <zyga> mvo: I'm not talking about stuff that goes for the release
[18:32] <int0x0c> Is there a timeframe for completion?
[18:32] <zyga> mvo: I'm strictly interested in stuff for +1, even +2
[18:32] <cjwatson> int0x0c: we should get a lot more of it sorted out today
[18:32] <int0x0c> the issue is, I'm trying to finish up an intel graphics patchset which will hopefully make it in before the merge window closes
[18:33] <int0x0c> so time is a little tight
[18:33] <mvo> zyga: oh, sorry. I don't have the capacity to work in parallel on two branches, but we can branch off a +1 and see how it goes :)
[18:33] <int0x0c> cjwatson: alright
[18:33] <cjwatson> once we get mountall built, things should trickle into place fairly quickly
[18:33] <Keybuk> ion: what's the patch?
[18:33] <int0x0c> cjwatson: ahh, alright
[18:33] <ion> ti200151 < ion> keybuk: http://heh.fi/patches/mountall/ rebased onto the current mountall. There’s also a new patch that fixes a bug: if a udev event triggers a check for a  device that has already been checked but that is waiting for the parent partition to be mounted, it’s possible for another check to be started.
[18:34] <ion> 0003
[18:34] <zyga> mvo: I see, I think I'm happy with that answer, I was just interested in knowing if you are going to stop working on this because it's past freeze time and +1 opens in so-many-months from now that you don't care yet
[18:34] <Keybuk> int0x0c: sorry, I don't mean to be rude, but we're very busy trying to sort out the problem
[18:34] <int0x0c> I completely understand
[18:34] <Keybuk> stopping to explain it, in detail, to everyone on IRC means we won't sort it out
[18:34] <int0x0c> I'm satisfied
[18:34] <int0x0c> sure
[18:34] <Keybuk> it's karmic
[18:34] <Keybuk> you're lucky it even boots
[18:34] <int0x0c> yep, certainly
[18:34] <Keybuk> in fact, you're lucky it doesn't run off with your daughter to the middle east
[18:34] <mvo> zyga: its really a problem of time, if there are some people interessted in working on +1 while the current one is in fixing mode, that is absolutely fine
[18:35] <int0x0c> thankfully, I don't have a daughter to run off with (that I know of)
[18:35] <madmike77_eee> well since today it worked fine!
[18:35] <Keybuk> ion: I don't see how you can get into that condition
[18:35] <Keybuk> ion: it can double-check a partition, but I don't see that it can mount it?
[18:37] <nixternal> 12:34:46 [    Keybuk] in fact, you're lucky it doesn't run off with your daughter to the middle east
[18:37] <nixternal> ahh, so that's where she went
[18:40] <ion> keybuk: run_mount doesn’t seem to check whether a fsck is running. The first check calls device_ready(), later a udev event triggers the second check. Then the *parent* partition happens to get mounted and mountpoint_ready() is called. Now run_mount happily mounts the partition in question, with the second check running in background. That actually happened consistently and repatedly in my virtual machine.
[18:41] <Keybuk> ah
[18:41] <Keybuk> I see
[18:41] <Keybuk> sure, will apply and upload once it's built and the mess has settled down
[18:41] <Keybuk> thanks ;)
[18:43] <madmike77_eee> is the build server back alive?
[18:43] <tormod> keybuk, (boot ppa) there is no visual feedback when fsck is running
[18:43] <ion> tormod: That’s a TODO item.
[18:44] <cjwatson> oh, come ON launchpad
[18:44] <cjwatson> madmike77_eee: working on it
[18:45] <madmike77_eee> (dang it firend is chatting for me...)
[18:46] <Keybuk> tormod: there should be in karmic proper, as a temporary measure I turned on output
[18:59] <cjwatson> mountall publishing. dinnertime
[19:07] <tormod> keybuk, stop cups is hanging here during package upgrade, want debugging?
[19:17] <cr3> does dpkg -i file.deb, where an earlier version of file.deb was installed, do the same as apt-get upgrade or does it remove/install the package?
[19:17] <slangasek> tormod: hmm, /stopping/ is hanging?
[19:18] <maxb> cr3: it's pretty much the same
[19:19] <cr3> maxb: ah, I was trying to reproduce an upgrade problem and it seems to only occur when a configuration file was changed from the maintainer version, so I wasn't actually testing the right problem. dpkg should indeed enable me to reproduce the problem if I modify the configuration file too :)
[19:22] <tormod> slangasek: yes there was no cups process, but "stop cups" was hanging
[19:22] <slangasek> tormod: after the init script has been replaced with a symlink, or before?
[19:22] <tormod> later in the upgrade process X died (gdm restart?) so here I am in Jaunty :)
[19:23] <tormod> slangasek: I lost patience and killed the "stop cups" so I can not tell
[19:23] <slangasek> gdm restart> fagh, the maintainer script is supposed to do a reload
[19:24] <slangasek> tormod: difficult to debug, then.  I'll check whether it's reproducible here
[19:24] <slangasek> well, no
[19:24] <tormod> last thing in dpkg.log is "status unpacked cups 1.4.1-1"
[19:24] <slangasek> the version of cups in the archive is still 1.4.1-1
[19:24] <slangasek> which doesn't include the upstart job
[19:24] <slangasek> so look to pitti/tkamppeter for answers, not Keybuk :)
[19:24] <madmike77_eee> is there a dbus update avaliable?
[19:25] <tormod> ok I thought I had cups from the boot ppa...
[19:25] <slangasek> tormod: oh
[19:25] <slangasek> in that case, no debugging needed
[19:26] <slangasek> because cups in karmic is supposed to be replaced shortly with one that switches it back to the upstart job, and upgrading from the boot-ppa to a non-upstart cups package isn't really supported
[19:26] <tormod> yes that seems like what happened
[19:27] <tormod> same goes for gdm...
[19:31] <tormod> it is not so easy to upgrade stuff in a chroot any longer... "start: Unable to connect to Upstart:"
[19:32] <slangasek> tormod: oh, ick
[19:33] <slangasek> tormod: workaround: install a /usr/sbin/policy-rc.d in the chroot which consists of "#!/bin/sh\n\nexit 101"
[19:33] <slangasek> (and executable)
[19:34] <tormod> thanks!
[19:34] <slangasek> tormod: but please file a bug against upstart about this blowing up in chroot
[19:34] <slangasek> upstart-job will need to handle that case gracefully
[19:36] <pitti> tormod: that's what might have happened to me, too
[19:36] <pitti> got the boot PPA, then installed a local non-upstartified cups again for testing, then got re-upstartified
[19:38] <tormod> is the policy-rc.d used only when upgrading or should I remove it again before trying to boot?
[19:39] <lool> pitti: Just a heads up on my latest comment on kasumi in 424238
[19:40] <slangasek> tormod: the policy-rc.d is only used by invoke-rc.d, which is specific to maintainer scripts, yes
[19:40] <slangasek> tormod: you /should/ remove it so that future upgrades work correctly, but it won't prevent you from booting
[19:44] <tormod> slangasek: filed bug #430224
[19:44] <Keybuk> in chroots, divert initctl to /bin/true much as you'd direct invoke-rc.d
[19:44] <Keybuk> I thought lamont had already done the update to make that happen
[19:45] <Keybuk> it's certainly been applied to buildds
[19:46] <mathiaz> pitti: thanks! :)
[19:46] <slangasek> Keybuk: "the update"?
[19:46] <Keybuk> slangasek: whatever one needs to change to make that true
[19:46] <slangasek> Keybuk: upstart needs to work in arbitrary end-user chroots, not just on the buildds
[19:47] <lamont> yep...  applied to the builds
[19:47] <slangasek> (including, in this case, when one is chrooted to the root system for rescue)
[19:47] <Keybuk> slangasek: like I said, divert initctl to /bin/true
[19:47] <Keybuk> that disables starting or stopping like policy-rc.d does
[19:47] <slangasek> Keybuk: ... no
[19:47] <madmike77_eee> the new upstart packages and mount all gives karmic  the rest...
[19:47] <lamont>         dpkg-divert --local --rename --divert /sbin/initctl.real /sbin/initctl
[19:47] <lamont>         ln -s /bin/true /sbin/initctl
[19:48] <Keybuk> slangasek: I'm not sure what you mean by "no", it works
[19:48] <madmike77_eee> uhm
[19:48] <lamont> slangasek: and then policyrcd-script-zg2 ++ for the rest of the love
[19:48] <madmike77_eee> we got a black screen without a working terminal after the latest upstart mountall upgrade
[19:48]  * madmike77_eee is open for ideas
[19:49] <Keybuk> madmike77_eee: see topic.
[19:49] <slangasek> Keybuk: I mean I don't think it's acceptable for upgrades in chroots to /fail/ without using policy-rc.d or diverting initctl
[19:49] <Keybuk> slangasek: err, I still don't follow, sorry
[19:50] <slangasek> Keybuk: AFAICS you're saying the solution to upgrades in chroots breaking is "do this manual thing in the chroot"
[19:50] <slangasek> I'm saying it's a bug in upstart that this is necessary
[19:50] <Keybuk> slangasek: you have to do the same for sysvinit ?
[19:50] <slangasek> nope
[19:50] <Keybuk> you do, otherwise policy-rc.d doesn't exist
[19:50] <slangasek> you only have to do that for sysvinit if you want services to not be started in the chroot
[19:51] <Keybuk> oh, you mean that Upstart in general can't run services inside a chroot?
[19:51] <Keybuk> that's a known flaw - and on the todo to fix
[19:51] <slangasek> right, that :)
[19:51] <Keybuk> it's no different than sysvinit really
[19:52] <Keybuk> sysvinit can't start getty in a chroot
[19:52] <slangasek> or, barring that, divining that it's in a chroot and failing gracefully when called by upstart-job
[19:53] <slangasek> Keybuk: I don't start getties from maintainer scripts on upgrade either, though :)
[19:54] <Keybuk> the problem is that Upstart itself doesn't support services in chroots
[19:54] <Keybuk> it can't see the conf files, for a start
[19:54] <Keybuk> and wouldn't know to "chroot" them
[19:54] <Keybuk> likewise, it has the same problem with services in different pid namespaces
[19:55] <madmike77_eee> Keybuk: any chance to revive this currently bricked netbook? Any magic Keyboard-foo?
[19:55] <Keybuk> madmike77_eee: I'm busy.
[19:56] <tag> What version of evolution and libmapi are in the latest ubuntu?
[19:56] <tag> karamic koala, as it is
[19:57] <bgamari> tag: http://packages.ubuntu.com/
[19:57] <bgamari> use it
[20:05] <Keybuk> slangasek: I've given everything back now
[20:06] <Keybuk> hopefully this lot will build ;)
[20:07] <Keybuk> I shall go and eat some dinner
[20:07] <Keybuk> and then I'll come back, and put out any more fires that I find ;)
[20:10] <bgamari> Keybuk: Thanks for your work
[20:10] <bgamari> It's appreciated
[20:11] <Keybuk> madmike77_eee: without knowing why it's hung, it's hard to debug - best thing is to plug a wired network cable in
[20:11] <Keybuk> madmike77_eee: boot with "init=/bin/bash" instead of "quiet splash"
[20:12] <soren> cjwatson: bug 426514 should be fixed, yes.
[20:12] <Keybuk> madmike77_eee: mount -o ro,remount / ... modprobe <your network card> ... dhclient eth0 ... apt-get update ... apt-get dist-upgrade
[20:12] <madmike77_eee> Keybuk: Right now we can't enter into the grub2 menu
[20:12] <Keybuk> madmike77_eee: (in a few hours when the archive settles)
[20:12] <Keybuk> madmike77_eee: hold down SHIFT
[20:12] <bgamari> Keybuk: These built packages won't be directly incorporated into the archive, right?
[20:13] <Keybuk> bgamari: yes
[20:13] <soren> cjwatson: Thing is, we regenerate the C stubs for their wsdl's until they release an actual tarball, and sometimes they update the wsdl without notifying me, so I didn't regenereate the C stubs.
[20:13] <Keybuk> they will
[20:13] <bgamari> ahh, alright. Thanks.
[20:13] <Keybuk> from german import doch
[20:14] <Keybuk> ;)
[20:14] <cjwatson> soren: we can't do it at build time?
[20:14] <soren> cjwatson: No. That would pull a ton of stuff into main that we don't want.
[20:15] <soren> cjwatson: As I said: This is only until they release an actual tarball.
[20:15] <soren> cjwatson: It's a mess, I know.
[20:15] <J_P> hi all
[20:15] <J_P> people, I want change time 60s when  power button is pressed. Or just power down without wait anytime. I try System > Preferences > Power Management (or Screensaver > Power management) > General > Select what to do "when power button is pressed" I select (shutdown). but not works. I press power button and show message 60s to shutodown.
[20:15] <J_P> any idea?
[20:15] <J_P> Or just, where i configure that 60s ?
[20:16] <mneptok> J_P: this channel is ot for Ubuntu support.
[20:16] <mneptok> *not
[20:16] <mneptok> J_P: please read the /topic, as Pici asked.
[20:17] <J_P> mneptok: Pici tell to go here.. So, what is correct channel to this question?
[20:17] <mneptok> J_P: this one.
[20:18] <J_P> mneptok: I think any developer know where that 60s is configurable.
[20:19] <mneptok> J_P: it's not the job of developers to answer support questions from end users
[20:19] <J_P> mneptok: ok, sorry
[20:19] <cjwatson> personally I have no idea where that is configurable :-) I'd have to spend a fair amount of time looking it up
[20:20] <cjwatson> no doubt *somebody* knows offhand
[20:20] <soren> J_P: I'm a developer and I have no clue where to configure that.
[20:20]  * Keybuk doesn't even know whether it *is* configurable
[20:20] <cjwatson> we don't necessarily all know the ins and outs of every single package in the archive, although given time we can usually find out
[20:20] <cjwatson> but really support channels are better for that
[20:20] <J_P> ok, thanks all :-)
[20:20] <kirkland> NetworkMangler appears foobar'd
[20:20] <J_P> good works for all :-)
[20:21] <Keybuk> kirkland: see /topic
[20:21] <kirkland> Keybuk: gotcha, thanks.
[20:21] <Daviey> you could update the po to remove the timer :)
[20:21] <cjwatson> Keybuk: initscripts is still kept back here
[20:22] <cjwatson> though mountall is now installable
[20:22] <sebner> cjwatson: you can force install and remove half of the system though :P
[20:22] <cjwatson> sebner: thanks, can I talk with the relevant developer to actually fix the problem now?
[20:22]  * cjwatson doesn't really need clever remarks
[20:22] <sebner> sure
[20:22]  * sebner hides
[20:22] <cjwatson> we know the archive is busted
[20:23] <cjwatson> sorry, it's just getting into my evening and I don't want to finish until the archive is working again
[20:23]  * Keybuk looks forlornly at his uncooked dinner
[20:23] <cjwatson> ah, probably need to get udev built
[20:24] <Keybuk> possibly
[20:24] <Keybuk> I gave everything back about 20 minutes ago
[20:24] <cjwatson> yeah, but the chroots need to be fixed first
[20:24] <Keybuk> yes
[20:24] <cjwatson> lamont's doing that
[20:24] <Keybuk> initscripts Breaks udev
[20:24] <Keybuk> the chroots seem fine now
[20:24] <cjwatson> will udev be able to build without manual intervention?
[20:25] <cjwatson> by "fixed", I mean "put back to non-frobbed state"
[20:25] <Keybuk> let's see
[20:25]  * Keybuk bumps the score
[20:25] <Keybuk> util-linux certainly built ok
[20:26] <Keybuk> Please try again
[20:26] <Keybuk> Sorry, there was a problem connecting to the Launchpad server.
[20:26] <cjwatson> when we have to build stuff manually, we (1) put buildds on manual (2) upload frobbed chroots that behave however we want (3) build ONLY the things that we need to build (4) put the chroots back (5) test run something (6) put buildds back on auto
[20:26] <Keybuk> GODS DAMNIT LAUNCHPAD
[20:26] <cjwatson> we're at (4)
[20:26] <cjwatson> so please don't push packages through until that's done
[20:26] <Keybuk> oh, too late ;)
[20:26] <cjwatson> are you putting buildds back on auto?
[20:26] <Keybuk> no, not touching them
[20:26] <cjwatson> ok, don't :-)
[20:27] <Keybuk> I just queued things for when they were
[20:27] <cjwatson> right, that's fine
[20:27] <Keybuk> that's what I thought
[20:27] <cjwatson> as long as they stay on manual until the chroots are restored to normal
[20:27] <Keybuk> phew ;)  you had me worried there
[20:27] <lamont> cjwatson: the normal chroots are all active now
[20:27] <cjwatson> excellent
[20:27] <cjwatson> Keybuk: what did you score up, and to what?
[20:28]  * cjwatson wants to make sure he has the ordering right
[20:28] <Keybuk> there shouldn't be an ordering now
[20:28] <Keybuk> once upstart, sysvinit and debhelper are built, everything else will work ok
[20:28] <cjwatson> ok, why don't we do udev first since it's actually breaking stuff
[20:28] <Keybuk> err I mean mountall
[20:28] <Keybuk> it was just the unexpected problem with sysvinit being upgraded while trying to build upstart ;)
[20:29] <Keybuk> "21000" ?! :)
[20:29] <Keybuk> is that Colin priority
[20:29]  * lamont uses 5555555
[20:30] <cjwatson> 20000 is my usual "build FIRST, damnit"
[20:30] <Keybuk> I tend to use 10000, and it doesn't give me a value less than a minute, 100000 ;)
[20:30] <cjwatson> but I'd already used that
[20:30] <cjwatson> oh, the times are sometimes a bit made up
[20:30] <pitti> "sometimes" is a neat euphemism
[20:30] <Keybuk> yeah but they're a good indication
[20:30] <cjwatson> gah, os-prober is building anyway
[20:30] <cjwatson> oh well
[20:30] <Keybuk> armel failed - chroot problem
[20:31] <Keybuk> lpia failed - chroot problem
[20:31] <Keybuk> sparc failed - chroot problem
[20:31] <lamont> udev?
[20:31] <Keybuk> lamont: yes
[20:31] <Keybuk> powerpc looks like it's building
[20:31]  * Keybuk sees apt output
[20:32] <cjwatson> right, so the arches that fail will need manual bootstrapping again
[20:32] <cjwatson> sysv-rc back on hold ...
[20:32] <Keybuk> WTF powerpc failed
[20:32] <Keybuk> dpkg-source: error: Files field contains invalid filename `udev_147~-1.tar.gz'
[20:32] <cjwatson> lamont: would you do the honours?
[20:33] <lamont> cjwatson: I'm lazy.  all of them have it on hold, as of about 60 sec from now
[20:33] <lamont> the script kinda prefers to do all 7
[20:33]  * Keybuk declares this to be dinner time
[20:34] <cjwatson> Keybuk: double wtf, I can't see that message in dpkg
[20:34] <Keybuk> no, quite
[20:35]  * cjwatson tries on i386
[20:35] <Keybuk> amd64 seemed to build it ok ;)
[20:35] <lamont> all held
[20:36] <lamont> well, now that I look, I see they are, anyway... prolly for a few
[20:38] <cjwatson> Keybuk: oh, that's the dpkg-source in the base
[20:38] <cjwatson> lamont: don't suppose we can do anything about powerpc's old base system? its dpkg-source doesn't like udev's version number
[20:39] <cjwatson> Keybuk: powerpc may be a tad buggered for a while but this is a powerpc-specific problem
[20:39] <lamont> cjwatson: not easily, no.
[20:39] <lamont> unless you wanna claim support for hardy/ppc... :-)
[20:40] <ikonia> poison challace
[20:40] <lamont> or bless a dapper backport of apt and enough else...
[20:40] <lamont> OTOH, I thought apt was just running inside the chroot at this point
[20:41] <cjwatson> it appears not to be when unpacking the source package
[20:41] <cjwatson> maybe it is when installing build-dependencies?
[20:41] <lamont> quite possible, that
[20:42] <cjwatson> dear huito, get on with it
[20:43] <lamont> it has to _THINK_ about thinking
[20:44] <cjwatson> does it require integral calculus or something?
[20:44] <cjwatson> udev/i386 built anyway
[20:45] <lamont> well, it is armel.  with swap-over-USB
[20:47] <cjwatson> lamont: do I need to try a different buildd? it's been five minutes ...
[20:47]  * lamont looks in on hito
[20:47] <cjwatson> and now it starts building util-linux!
[20:47] <cjwatson> silly thing
[20:47] <lamont> well... it's that download of all the packages that are out-of-date
[20:47] <cjwatson> we'll need rsyslog as well, I'll score it up
[20:48] <lamont>  41 upgraded, 4 newly installed, 0 to remove and 3 not upgraded.
[20:49] <lamont> cjwatson: hence once we get this all sorted, I'd like to dist-upgrade the chroots while it's fresh-n-unbroken-and-known-goodish
[20:49] <lamont> it doesn't make much of a diff on amd64, but it definitely makes armel slower
[20:49] <cjwatson> err, jambul is building udev
[20:49] <cjwatson> I didn't touch it. why's it on auto?
[20:50] <lamont> gar.  that's my bad
[20:50]  * cjwatson manuals it
[20:50] <lamont> me too.
[20:50] <smoser> has anyone done a fresh install today ?
[20:51] <lamont> it was down/deactivated due to being cranky.  that got fixed a bit ago and I activated it, _thought_ it was already manual
[20:51] <lamont> smoser: I wouldn't recommend it
[20:51] <davmor2> smoser: yes thanks
[20:51] <smoser> i'm trying to do a vmbuilder build, and its failing
[20:51] <smoser> 2009-09-15 20:41:11,392 DEBUG   : I: Configuring libc-bin...
[20:51] <smoser> 2009-09-15 20:41:11,574 DEBUG   : W: Failure while configuring base packages.  This will be attempted 5 times.
[20:51] <lamont> smoser: see /topic
[20:51] <cjwatson> smoser: the world is broken, too many things known broken to make it worth debugging :)
[20:51] <cjwatson> we'll fix the things we know about and then see what's left
[20:51] <smoser> but i need to do something :)
[20:52] <davmor2> :)
[20:52] <smoser> thanks everyone
[20:52] <lamont> cjwatson: /usr/bin/xsltproc -o udev/udevadm.8 -nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl ../udev/udevadm.xml <-- there's a certain amount of eye stabbing there.
[20:53] <cjwatson> lamont: is that breaking something?
[20:54] <lamont> no
[20:54] <lamont> I just generally find eye-stabbing in builds referencing URLs outside the world
[20:55] <cjwatson> it's -nonet though
[20:55] <lamont> OTOH, sourceforge.net is NXDOMAIN for the buildds...  so I WIN in any case
[20:56] <lamont> and through it all, openjdk slogs along
[20:56] <lamont> Keybuk: what's the util-linux change?
[20:58] <madmike77_eee> Keybuk: Just for the record: we installed the packages from the ubuntu-boot ppa and everything is up and running now. Thanks for the help ;)
[20:59] <Keybuk> lamont: will tell you later, or read ubuntu-devel scrollback
[21:01] <fta> could someone please help with bug 399938? it doesn't seem to be bzr-builddeb at all, not even python. all pipes seem broken in some situations
[21:04] <cjwatson> udev/rsyslog publishing now on as many architectures as I could manage
[21:12] <lamont> cjwatson: actually, I'm going to need to run and fetch my daughter in about 20 min - will the publisher be done by then?
[21:12] <slangasek> unlikely
[21:15] <lamont> hrmpf.  well, I'll be back online at around 2240 london for about 20 min, then hard EOD
[21:15]  * slangasek nods
[21:16] <cjwatson> lamont: anything we can do without you?
[21:16] <cjwatson> e.g. with a different GSA?
[21:17] <cjwatson> lamont: actually, maybe you could put the chroots back now
[21:18] <cjwatson> I'm expecting to at least try some normal builds after this publisher run finishes
[21:19] <lamont> cjwatson: yeah - I spewed the command sequence in the other channel
[21:19] <lamont> with new== held, old == normal
[21:19] <lamont> so... normal chroots uploading
[21:19] <cjwatson> ok, so we can flip back and forward
[21:19] <cjwatson> cool
[21:22] <lamont> cjwatson: yeah... I'm to familiar with this to not have both sitting around
[21:22] <bgamari> seems like initscripts is still being held hack here; is this expected?
[21:23] <cjwatson> bgamari: yes
[21:23] <cjwatson> lamont: hmm, amd64 armel lpia sparc still need hostname fixed. any chance at all of using the held chroots on just those architectures?
[21:23] <bgamari> alright, fair enough
[21:24] <cjwatson> I'd like to get i386 moving if possible, you see ...
[21:26] <lamont> hostname the package?
[21:26] <lamont> cjwatson: I find that letting arch-all get ahead is sometimes hurtufl
[21:26] <lamont> but yeah, we could do htat
[21:27] <cjwatson> hmm
[21:27] <cjwatson> I guess I don't mind another <hour
[21:27] <cjwatson> ok, just slam all arches back to held please :-/
[21:28] <cjwatson> lamont: can you brief the other GSAs that I'm likely to need some stuff done on cesium as well, please?
[21:28] <lamont> yeah - been chatting some
[21:31] <Mabo> hi
[21:33] <cjwatson> lamont: can you confirm that all architectures are now using the held chroots?
[21:33] <cjwatson> just before you go ...
[21:33] <lamont> everything is using the unheld
[21:33] <lamont> did you need it back to held?
[21:33] <cjwatson> yes please
[21:34] <lamont> cjwatson: I didn't prep them with the smarts around only hold/unholding a subset of architectures, though looking at the script should make it obvious... :-)
[21:34] <lamont> cjwatson: and any GSA or LOSA
[21:35] <lamont> all are held version now
[21:35] <cjwatson> nah, we'll just do all arches concurrently
[21:35] <cjwatson> thanks
[21:36] <lamont> yeah - I figured as much, so didn't worry
[21:36] <lamont> SUITE=${SUITE:-karmic}
[21:36] <lamont> ARCH=${ARCH:-"amd64 armel i386 ia64 lpia powerpc sparc"}
[21:36] <lamont> total hack
[21:38] <lamont> cjwatson: and on that note, off to stay out of trouble with my wife and kids
[21:39] <cjwatson> do :)
[21:39] <cjwatson> thanks for your help
[21:53] <Keybuk> lamont: still having trouble with the builds? :)
[21:54] <slangasek> he is not, he's left the trouble to others. :)
[21:55] <cjwatson> I'm still hand-holding
[21:55] <cjwatson> but we're getting there
[21:55] <Keybuk> oh, sorry, I'd read that *you* were playing with your wife and kids ;)
[21:56] <Keybuk> I'm honestly surprised they've dug themselves this deep into the ground
[21:56] <cjwatson> I'm watching Angel, as it happens, but that doesn't prevent a laptop beside me :)
[21:56] <cjwatson> it's just that most of initscripts' Breaks weren't satisfied
[21:56] <cjwatson> the last of them (I hope ...) is publishing now
[21:59] <Keybuk> I guess a more interesting question is how to avoid doing this next time ;)
[22:00] <slangasek> there's going to be a next time?
[22:00] <slangasek> :P
[22:00] <robbiew> heh
[22:01]  * robbiew gets up off the floor
[22:01] <Keybuk> slangasek: well, yes.  there's more of sysvinit to be replaced between now and karmic+1
[22:01] <robbiew> oh...whew
[22:01] <Keybuk> at the moment it looks like that both upstart and sysvinit have to go in the same publishing run?
[22:02] <Caesar> slangasek: has a decision been made on if 10.04 will be LTS yet?
[22:02] <slangasek> Caesar: yes, 10.04 is the LTS
[22:02] <Caesar> Great, thanks
[22:07] <samba> hi all - i'm new around these parts - anyone here knowledgable about the inner workings of Casper, for Live media installations? (Or should I go looking elsewhere?)
[22:08] <robbiew> samba: #ubuntu-installer
[22:08] <samba> robbiew, thanks
[22:08] <robbiew> np
[22:08] <samba> (what i'm looking for isn't specifically installation, but they'll likely know a bit anyway...)
[22:13] <pimbuntu> hi... i read in the topic there are issues with karmic
[22:14] <pimbuntu> however i already rendered my system unuseable with safe-upgrade
[22:14] <pimbuntu> is there a way to revert back to a specific release-point to get a useable system?
[22:14] <pimbuntu> i have a live-cd booted right now and some hint on using aptitude would be enough
[22:16] <slangasek> pimbuntu: best way out is forward, but that will require a bit of patience as the packages needed to fix it aren't all published yet
[22:17] <pimbuntu> slangasek, can you estimate the time it'll take? More in the range of minutes, hours or days?
[22:17] <slangasek> pimbuntu: hours
[22:17] <pimbuntu> as i need the box quite urgently
[22:17] <pimbuntu> ok
[22:17] <pimbuntu> can i help? :)
[22:19] <Keybuk> pimbuntu: there's not much anyone can do to help
[22:19] <Keybuk> the problem is that a set of packages needed to be updated as a group
[22:20] <Keybuk> and our build daemons can only update them one at a time
[22:20] <Keybuk> so after the first package, they broke in such a way that they couldn't build the rest of the group
[22:20] <pimbuntu> ok...
[22:20] <pimbuntu> is there a way/trick to tell aptitude/apt-get to install whatever version it finds on the cd of those packages installed?
[22:21] <Keybuk> pimbuntu: yes you can use pinning
[22:21] <Keybuk> pimbuntu: another trick people are using is to install from the ubuntu-boot PPA
[22:21] <Keybuk> that has the packages that went into the archive
[22:21] <Keybuk> but already built
[22:22] <ion> pimbuntu: For a box that might be needed urgently, a development version of a distro might not be the best choice.
[22:23] <pimbuntu> yes, i know
[22:23] <sebner> Keybuk: udev, initscripts, rsyslog just came over update fYI
[22:24] <pimbuntu> ion: it's a long story, but in the end, the latest version of the fglrx-driver crashed and somehow rendered my encrypted pv unusable. Therefor i gave karmic a try and it looked quite stable until now.
[22:24] <ScottK> ion: Thanks.  I was resisting making such a comment.
[22:24] <Keybuk> huh
[22:24] <Keybuk> I'm so used to Ubuntu, I just plugged an ethernet cable into a Windows laptop and *expected* it to do the right thing
[22:25] <sebner> lol
[22:25] <sebner> Keybuk: is there anything else to come over update or can I safely shut down my laptop? ;)
[22:26] <Keybuk> sebner: quite a bit yet
[22:26] <sebner> so it'll break?
[22:26] <Keybuk> no idea
[22:27] <sebner> heh
[22:27] <sebner> does hibernating avoids that?
[22:27] <cjwatson> I *think* we may be able to start autobuilding again now, but I want to verify that
[22:27] <ion> If it breaks, you should be able to fix it the usual way. :-)
[22:28] <pimbuntu> Keybuk, i added the ubuntu-boot ppa and now it's installing so i hope for the best. :)
[22:31]  * Keybuk debates trying to install Slow Leopard onto an XPS m1330
[22:32] <apw> Keybuk, heh a few problems remain then huh
[22:32]  * cjwatson test-builds springlobby
[22:33] <cjwatson> powerpc is still going to be broken for some time, unless we can get a udev release without ~ in its version :)
[22:33] <squirrelpimp> <- pimbuntu : It did not work
[22:33] <squirrelpimp> :(
[22:33] <Keybuk> cjwatson: we'll have one of those next week
[22:33] <cjwatson> (or somebody arranges for launchpad-buildd to extract the source in the chroot rather than in the dapper base system ...)
[22:33] <Keybuk> the plan is that we're testing udev 147, kay and I will fix the issues next week then release
[22:43] <cjwatson> a respectable selection of buildds are now back on auto, and I've asked IS to flip the switch en masse
[22:43] <cjwatson> since there are some that seem to break when I try to do it in the UI
[22:43] <cjwatson> publisher is back on auto
[22:48]  * Keybuk adjusts some priorities
[22:53] <squirrelpimp> what else can i try, if dist-upgrade from ppa didn't work?
[22:54] <Keybuk> squirrelpimp: patience
[22:54] <squirrelpimp> ah, i saw that one coming
[22:54] <squirrelpimp> :)
[22:55] <Keybuk> cor
[22:55] <Keybuk> I think that was everything i386 built then
[22:56] <davmor2> Keybuk: I refuse to believe you until I see iso's
[22:57] <Keybuk> davmor2: that's Thursday
[22:57] <davmor2> NNNNNNNOOOOOOOO!!!!!!!!!!
[22:58] <slangasek> ISOs better be here before Thursday :-P
[22:59] <maxb> so how long for amd64 then?
[23:00] <maxb> Any chance of getting the second builder off manual sooner rather than later? :-)
[23:00] <davmor2> maxb: well 64 is twice 32 so twice as long ;)
[23:01] <cjwatson> maxb: IS is on it
[23:02] <cjwatson> maxb: I couldn't make it work via the UI
[23:03] <jdub> where's the "zomg, new init, eek!" conversation happening? :-)
[23:03] <cjwatson> jdub: everywhere
[23:03] <jdub> :-)
[23:04] <jdub> oh, buildds not happy either? perfect storm!
[23:04] <Keybuk> cjwatson: it would be SO NICE if we could just copy packages from PPA to archive like we can between PPAs
[23:04] <Keybuk> jdub: the buildds not being happy is the basic source of the problems
[23:04] <cjwatson> actually, the buildds are moderately sorted now
[23:04] <cjwatson> Keybuk: yeah, the problem is that PPAs can build with all kinds of sources
[23:05] <Daviey> PPA's can also use itself as a build deps.
[23:06] <jdub> Keybuk: is this a useful spot to report problems along the way?
[23:06] <Keybuk> jdub: no, not really ;)
[23:07] <cjwatson> maxb: they should all be back on auto now
[23:07] <cjwatson> http://paste.ubuntu.com/271737/ fixes the dpkg problem on powerpc, fed to lamont
[23:07] <jdub> Keybuk: just noise in general at this point, or is there a better spot?
[23:08] <Keybuk> jdub: noise in general
[23:08] <jdub> ok
[23:08] <Keybuk> if you rebooted without all the bits, I can believe that things didn't work out for you
[23:08] <maxb> :-)
[23:08] <jdub> pretty sure i have all the bits (no depends issues), but mountall is failing
[23:09] <Keybuk> how is mountall failing?
[23:09] <jdub> (which was described as general failure, returned 1)
[23:09] <Keybuk> what is on screen above that?
[23:09] <jdub> sec, just switching to irssi on tv
[23:10] <jdub> moutnall start/running, process 1628
[23:10] <jdub> init: moutnall main process (1628) terminated with status 1
[23:10] <Keybuk> no output from mountall itself?
[23:10] <jdub> not after ctrl-d at least... i'll reboot again
[23:11] <Keybuk> also dpkg-query -W mountall
[23:11] <jdub> (fading usplash is spiffy, btw)
[23:12] <jdub> nothing above that
[23:12] <jdub> mountall 0.1.3
[23:12] <Keybuk> odd
[23:12] <Keybuk> run mountall --verbose from your own shell
[23:13] <Keybuk> anything?
[23:13] <jdub> virtual fs finished
[23:13] <jdub> remote finished
[23:13] <jdub> (btw, i'm dumped to a ro root which is marked as rw, but otherwise correct)
[23:14] <Keybuk> does that exit?
[23:14] <jdub> yes
[23:14] <Keybuk> what's the message before it exists?
[23:14] <jdub> 1 as status
[23:14] <Keybuk> exits I mean
[23:14] <jdub> nothing, that was all the output
[23:14] <ion> --debug?
[23:14] <Keybuk> try --debug ?
[23:14] <jdub> aha :-)
[23:14] <cjwatson> oh, hmm, I'd better put powerpc back on manual I guess
[23:15] <Keybuk> cjwatson: could we not put powerpc under six feet of dirt with daisies growing on top?
[23:15] <jdub> well, that's very verbose
[23:15] <cjwatson> *blink* it seems to be building, actually
[23:15] <cjwatson> I guess I'll let it
[23:16] <Keybuk> cjwatson: what could *possibly* go wrong? :)
[23:16] <cjwatson> well, if it builds at all, it's probably ok
[23:16] <cjwatson> if anything's wrong it'll just fail to upgrade right at the start
[23:17] <jdub> Keybuk: what can i provide from the --debug output?
[23:17] <Keybuk> jdub: can you take a picture?
[23:17] <jdub> oh, i can bring up network and put it somewhere
[23:20] <jdub> http://www.gnome.org/~jdub/2009/mountall-debug.txt
[23:21] <Keybuk> interesting point to fail
[23:22] <Keybuk> jdub: stupid question, did you boot with an initramfs
[23:22] <Keybuk> ?
[23:23] <jdub> yeah
[23:23] <Keybuk> ls /dev/.initramfs/varrun
[23:23] <Keybuk> do you have that directory?
[23:23] <jdub> nup
[23:23] <Keybuk> ah
[23:23] <Keybuk> make it
[23:23] <jdub> only usplash_*
[23:23] <jdub> then ctrl-d?
[23:23] <Keybuk> yes
[23:24] <jdub> mountall start/running
[23:24] <jdub> but it's just sitting there
[23:24] <Keybuk> ok, good
[23:24] <Keybuk> I forgot to mention something
[23:24] <Keybuk> ;)
[23:24] <jdub> could be best to reboot and try same without udev up?
[23:24] <Keybuk> yup
[23:24] <Keybuk> stop udev first ;)
[23:24] <jdub> ;-)
[23:25] <Keybuk> (using "stop udev", kill won't work :p)
[23:25] <jdub> ok, that looks good
[23:25] <Keybuk> thanks!
[23:26] <Keybuk> could you also tell me what I'm talking about next week ;)
[23:26] <jdub> goodness, gdm starts quickly
[23:26] <jono> hey jdong
[23:26] <jono> oops
[23:26] <jono> jdub,
[23:26] <jono> long time!
[23:26] <jdub> (sadly this is a T42 with radeon, so it *starts* quickly but doesn't actually do anything quickly)
[23:26] <jdub> hey jono
[23:26] <nixternal> Keybuk: do I need to anything similar there? I had to run to a *cough*vista*cough* machine to find out what is going on...i have a useless karmic box right now
[23:26] <jdong> jono: well, it's good to see you too ;-)
[23:26] <Keybuk> jdub: but at least you get to see xsplashy goodness
[23:26] <nixternal> need to do*
[23:26] <jdub> Keybuk: well, the abstract sounded lovely
[23:26] <jono> jdong, :)
[23:27] <squirrelpimp> nixternal: be patient
[23:27] <Keybuk> jdub: that's what I meant - what *was* the abstract ?
[23:27]  * jono is logged in with a live CD as his system won't start X :(
[23:27] <jdub> Keybuk: heh
[23:27] <nixternal> squirrelpimp: patient would be great if there wasn't work that had to be done
[23:27] <jdub> Keybuk: mmm, though xsplash takes a long time to start
[23:27] <ion> Here, too.
[23:27] <Keybuk> nixternal: if there was work to be done, you wouldn't have karmic on your box
[23:27] <squirrelpimp> nixternal: hehe... same here, but it looks like it's broken and waiting will fix it
[23:28] <nixternal> sure i would, especially this late in the game
[23:28] <pwnguin> Keybuk: alternatively, everyone would have karmic on their box
[23:28] <nixternal> squirrelpimp: waiting isn't going to fix it, cuz that would mean I would have to log in somewhere somehow to do an upgrade :)
[23:28] <jdub> everyone should have karmic -> it's what's for breakfast!
[23:28] <squirrelpimp> nixternal: yeah, of course
[23:28] <Keybuk> nixternal: "this late"?  six weeks before we release yet, that's quarter of the development cycle!
[23:28] <nixternal> jdub: +1 :)
[23:28] <nixternal> hahaha Keybuk, no more excuses! :D
[23:29] <[reed]> jdub: Koala Flakes?
[23:29] <ion> nixternal: The usual, boot with init=/bin/bash, get network up if needed, upgrade.
[23:29] <jdub> karmic has been very exciting compared to other recent releases
[23:29] <nixternal> ion: that works with my one machine with ol' skewl grub...the other machine is new grub, and damnit I can't hit escape fast enough it seems :)
[23:30] <ion> nixternal: Hold shift
[23:30] <nixternal> i shall give that a whirl
[23:30] <jdub> heh: init, upstart-udev-bridge, dbus-daemon, hald, gdm-binary -> win.
[23:31] <Keybuk> jdub: it'd be more win if X didn't need HAL :p
[23:31] <jdub> maybe next cycle.
[23:31] <jdub> *swoon*
[23:31] <Keybuk> yeah
[23:31] <Keybuk> then it'll be
[23:31] <Keybuk> init, mountall, gdm-binary
[23:31] <Keybuk>     , udev
[23:31] <TheMuso> So what exactly is the issue that caused Karmic to be in this unhappy place?
[23:31] <cjwatson> nixternal: certainly no point trying to hit Escape, as it's not checked if GRUB_HIDDEN_TIMEOUT=0
[23:32] <jdub> oh yes, i missed udevd between dbus and hald too
[23:32] <Keybuk> TheMuso: the buildds built sysvinit, and then couldn't update it for any further builds, because it hadn't built upstart yet
[23:32] <davmor2> TheMuso: the koala feel out of the tree
[23:32] <Keybuk> TheMuso: but if it'd built upstart, it wouldn't be able to update it because it hadn't built sysvinit yet
[23:32] <TheMuso> Keybuk: ah ok.
[23:33] <Keybuk> it's ok, I'll make sure I break leopard even harder
[23:33] <nixternal> haha
[23:34]  * squirrelpimp dances from one foot to the other in impatience
[23:34] <squirrelpimp> :)
[23:34] <jdub> mmm, karmic is a bit of a dropbear today
[23:35] <davmor2> Keybuk: Oh that easy just change it's spots
[23:35] <cjwatson> rickspencer3-afk: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=eucalyptus should be a bit less scary now ...
[23:36] <Keybuk> right
[23:36] <Keybuk> publisher finished
[23:39] <jdub> squirrelpimp: you can go to the toilet. the buildds will take a while. ;-)
[23:40] <squirrelpimp> well, i already added the ubuntu-boot ppa without any luck. Will the newly built packages fix that too, or did i already break more of it?
[23:40] <squirrelpimp> the system hangs right after mounting / on startup.
[23:40] <squirrelpimp> but i can access it using a live-cd and lvm2...
[23:40] <Keybuk> squirrelpimp: that I can't answer yet
[23:41] <Keybuk> how do you know it's mounting / ?
[23:41] <Keybuk> jdub: ah, memories
[23:41] <ion> keybuk: /etc/init/apport.conf: 0) Is ‘return 1’ intended at all? 1) Even though dash accepts it as exit, one probably should use exit instead of return from top-level sh code.
[23:42] <Keybuk> ion: you're right
[23:42] <squirrelpimp> i can see the output produced by mount (nr of files etc) due to nosplash and noquiet
[23:42] <Keybuk> let's fix that after α6 though since it's minor
[23:42] <squirrelpimp> i also see udev failing for hdparm and ppc files with some syntax-errors
[23:43] <Keybuk> squirrelpimp: does mountall fail, or just sit there?
[23:43] <Keybuk> (the last i386 packages missed that publisher run :-()
[23:43] <maxb> This round of updates have stopped switching my console to KMS niceness ASAP :-/
[23:44] <Keybuk> maxb: correct
[23:44] <maxb> that is a shame
[23:44] <Keybuk> cjwatson: on the bright side, amd64 has now built
[23:44] <cjwatson> Keybuk: built which?
[23:44] <Keybuk> so after the next publish, we should have a complete i386 and amd64 set
[23:44] <Keybuk> cjwatson: all of my uploads ;)
[23:44] <cjwatson> ah :)
[23:45] <squirrelpimp> i can't see anything related to mountall
[23:45]  * cjwatson will be in bed by then
[23:45] <squirrelpimp> udev complains a lot
[23:45] <Keybuk> squirrelpimp: this implies that you do not have a working installed set
[23:45] <squirrelpimp> installed set?
[23:45] <Keybuk> update in roughly an hour's time
[23:46] <cjwatson> squirrelpimp: are you on powerpc?
[23:46] <squirrelpimp> amd64
[23:46] <cjwatson> ah
[23:46]  * davmor2 is going to bed now, but if there aren't cd's tomorrow will go and pay Keybuk a visit till there are :)
[23:46] <cjwatson> (you said "ppc files" so I wondered)
[23:46] <squirrelpimp> yeah, i did too
[23:46] <Keybuk> davmor2: you're always welcome to hack here ;)
[23:46] <davmor2> Keybuk: with an axe ;)
[23:46] <squirrelpimp> i applied some pinning hackery to make it install udev from ubuntu-boot ppa, but apparently that didn't do the trick
[23:47] <jdub> /lib/udev/rules.d/40-ppc.rules <- this one
[23:48] <squirrelpimp> first one to fail with "unknown key 'SYMLINK{unique}'" is 50-udev-default.rules
[23:48] <Keybuk> that's not a fail
[23:48] <Keybuk> that's just a message
[23:48] <squirrelpimp> ah, ok
[23:48] <squirrelpimp> sounds serious though
[23:48] <Keybuk> no
[23:49] <Keybuk> udev: OMG! THE COMPUTER IS ON FIRE! QUICK! EVACUATE THE BUILDING!
[23:49] <ion> You shouldn’t need any pinning hackery. Just upgrade to the latest everything. If that fails or the system still doesn’t work, wait and redo. :-)
[23:49] <Keybuk> would sound serious
[23:49] <squirrelpimp> next one is "NAME="%k" is superflous" from 40-ppc.rules
[23:49] <jdub> udev: failed to load lp
[23:49] <squirrelpimp> yeah, but waiting always implies doing nothing
[23:49] <ion> keybuk: I’d suggest replacing the ‘unknown key’ message string with that one. :-)
[23:49] <cjwatson> launchpad-udev
[23:50] <squirrelpimp> so instead, i could try to somehow make it work.
[23:50] <Keybuk> udevadm giveback --distro-match=ubuntu
[23:50] <jdub> cjwatson: that's a scarier thought than was intended by my joke. yikes.
[23:50] <squirrelpimp> however this time i think it's beyond my knowledge of the ubuntu startup process
[23:50] <slangasek> 'giveback' is an alias for 'trigger', right?
[23:50] <Keybuk> squirrelpimp: only one person in the world knows how the udev startup process works right now
[23:50] <Keybuk> and he's desperate for the loo, and is being harassed by his two border collies who are similarly desperate
[23:50] <Keybuk> so, err
[23:50] <Keybuk> brb
[23:51] <jdub> which is why Novell is investing in a fleet of buses
[23:51] <squirrelpimp> yeah... udev is the new cups
[23:51] <squirrelpimp> :)
[23:51] <ion> No-one can be told how the udev startup process works. You have to see it for yourself.
[23:52] <squirrelpimp> i wonder why there aren't more udev-related chuck norris jokes
[23:55] <pwnguin> udev-related chuck norris jokes cure cancer. Too bad nobody makes them.
[23:56] <rickspencer3> cjwatson, I <3 the euc bug list
[23:56] <lool> cjwatson: Anything I can help with for the current buildd situation?
[23:58]  * lool realizes he offers help after the battle but was busy
[23:59] <cjwatson> lool: not any more, really :)
[23:59] <cjwatson> it should just churn through now
[23:59] <Keybuk> yeah
[23:59] <lool> Cool
[23:59] <Keybuk> this publish run should solve amd64 and i386
[23:59] <jono> Keybuk, so this will get us up and booting again?