[00:03] <cjwatson> jameswf-home: oh, I forgot to ask for DEBCONF_DEBUG=developer on the kernel command line, which is usually needed for detailed work here. Still, if it's working fine for you now, no need; I don't see anything obviously wrong in that log now
[00:04] <jameswf-home> cjwatson: The asterisk workd is ownde by RHEL my goal it to chip away from that so hopefully i will get it going good enough to give a base for folks...
[00:08] <RAOF> My laptop's
[00:09] <RAOF> ACPI is awesome.  During hardy development there was a time when it wouldn't boot while plugged in.  Now it doesn't boot when it isn't plugged in :)
[00:13] <cjwatson> jameswf-home: good luck :)
[00:51] <kirkland> cjwatson: slangasek: either of you around?
[00:52] <kirkland> cjwatson: slangasek: if so, i opened a new grub bug, with bzr branch/patch that fixes it, https://bugs.launchpad.net/ubuntu/+source/grub/+bug/264160
[00:52] <kirkland> cjwatson: slangasek: based on my testing of the latest iso's
[01:39] <pwnguin> man, google chrome's checkout is like 600 megs
[01:39] <superm1> pwnguin, how far back does the history go on it?
[01:40] <pwnguin> good question
[01:40] <pwnguin> they have this crazy multi tiered checkout tool
[01:40] <pwnguin> i have version 1663
[01:41] <wgrant> Does it include a whole lot of modified standard libraries?
[01:41] <wgrant> If not, it's no fun.
[01:41] <wgrant> Everybody has to include their own modified libs.
[01:41] <pwnguin> im not sure if they're modified
[01:41] <superm1> i'm mostly curious when they "claim" to have started development with it
[01:41] <pwnguin> but they also use sqllite
[01:41] <pwnguin> superm1: its svn; i dont know offhand how to query for the oldest revision
[01:42] <jcastro> it's importing into launchpad right now.
[01:42] <pwnguin> heh
[01:42] <wgrant> Could take a while.
[01:42] <jcastro> yeah
[01:42] <jcastro> it failed the first few times
[01:42] <pwnguin> i think like half of it is test and data files
[01:42] <pwnguin> dictionaries for the world
[01:43] <wgrant> Hm.
[01:43] <wgrant> Why is it owned by the mozillateam?
[01:43] <wgrant> Isn't it WebKit?
[01:43] <pwnguin> it is
[01:44] <pwnguin> and a crazy 32bit only javascript VM
[01:44] <jcastro> mozillateam is really "browser team" these days
[01:44] <pwnguin> yea. 200 megs of tests
[01:45] <pwnguin> there apperas to be a reference build in revision control
[01:46] <wgrant> Ew.
[01:48] <RAOF> Heh.  The google data .NET library svn contains not one, but 4 different builds in svn.  And a couple of zlib binaires, too.
[01:49] <pwnguin> im trying to follow their build directions, but it won't take
[01:49] <pwnguin> i have no src dir
[01:58] <ajmitch> ah, everyone else is checking out & trying to build chrome too? excellent
[02:00] <superm1> is anyone sure it will even build at this point?  I would have assumed if it did they just would have released some binaries for linux too
[02:01] <ajmitch> 'Although many Chromium submodules build under Linux and a few unit tests pass, all that runs is a command-line "all tests pass" executable.'
[02:01] <jcastro> it's not ported yet
[02:01] <jcastro> the gui, etc. is all windows only afaict
[02:01] <ajmitch> they've been using hardy as a development platform for the port though
[02:02] <ajmitch> which makes getting the right bits in place slightly easier
[02:18] <ion_> Hopefully they’ll use native Gtk.
[05:53] <pitti> Good morning
[05:53] <pitti> kees: still awake by any chance?
[06:50] <pitti> doko: any idea about the weird libffi4 uninstallability? (it depends on gcc-4.2-base (= 4.2.3-2ubuntu7) )
[06:51] <pitti> doko: is this a hardcoded binary package version in the gcc-4.2 source package?
[06:53] <pitti> cjwatson: what's necessary to re-include mobile into http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt ? ATM processing the source/binary demotions list is dangerous due to that
[06:54] <pitti> Riddell: desktop-effects-kde wants to go to universe, is that deliberate?
[06:54] <pitti> Riddell: kdebluetooth as well
[06:58] <StevenK> pitti: Since ubuntu-{mobile,mid} are in universe, most of the stuff in component-mismatches.txt shouldn't be related to it.
[06:59] <pitti> StevenK: hm, but there's a lot of stuff we moved into main in hardy, which didn't appear in c-m earlier
[07:02] <StevenK> pitti: I think we should crowbar them back together, and then I'll be happy to dig out the -m{id,obile} stuff out of it.
[07:22] <pitti> lool: the pygtk FTBFS on amd64 (and others) causes some uninstallability; the error looks weird (segfault during make), I try a giveback
[07:23] <laughtear> hello everyone, good morning from istanbul
[07:23] <Hobbsee> annoying intrepid hang, now.
[07:24] <pitti> ogra: ltsp-client now depends on sshfs, but that is in universe; thus ltsp-client is currently uninstallable
[07:24] <laughtear> i have intrepid ibex on my computer, i'm an ubuntu for some time. i have a problem in ibex about graphic drivers
[07:24] <laughtear> anybody could give me a hand?
[07:25] <RAOF> laughtear: Probably, but not in here; Intrepid support lives in #ubuntu+1
[07:25] <laughtear> (i am an ubuntu user, i mean..:))
[07:25] <pitti> Riddell: once you have a moment, can you please have a look at the kdesdk uninstallability? needs some MIRs or changed dependencies
[07:25] <laughtear> all rite, thank you RAOF
[07:26] <kees> pitti: actually, I am awake -- just got back from a movie.  what's up?
[07:27] <pitti> kees: after my holidays I noticed bug 255563
[07:27] <kees> aah, yeah.
[07:27] <pitti> kees: I haven't done any investigation about it yet, and wondered if you could give me some details what happens here? anything that could help me with a head-start?
[07:28] <kees> pitti: sure -- I apologize for not digging in but it always happens when I'm in a rush to get back up and booted.  :P
[07:28] <pitti> the usplash/fsck scripts didn't change since hardy, so either something else in intrepid changed, or we have that grave problem in hardy too
[07:28] <kees> pitti: I suspect fsck has changed
[07:28] <pitti> kees: don't worry, I'm not trying to shove it off to you
[07:28] <kees> pitti: I have about 6 ext3 partitions
[07:28] <pitti> kees: I just wondered whether you know anything about the problem, i. e. how to reproduce it
[07:29] <pitti> just having e. g. /var and /usr on a separate partition and having them all fsck'ed will do?
[07:29] <pitti> that'd be easy enough to do in a vm
[07:29] <kees> pitti: they're all mounted at boot-time, and when one of the later ones (not root) needs fscking, the fsck init line goes by very quickly (showing "fail", I think, though it might be the mountall).
[07:29] <pitti> ogra: ah, nevermind, there's an approved MIR for it
[07:30] <kees> when I come up, a fsck is still running, and I'm missing one of my partitions (since it's being fscked)
[07:30] <pitti> kees: eww, *all* mounted?
[07:30] <kees> pitti: all but the fsck'd one mounted, yeah
[07:30] <pitti> AFAIR it should be checkroot - mountroot - checkfs - mountother
[07:31] <pitti> kees: so the problem is that the usplash scripts don't wait for the fsck to finish, because it forks off some to the background?
[07:31] <kees> right, so checkfs happens quickly and exits, and then mountother runs, but one of the partitions isn't available since fsck is still running on it.
[07:31] <kees> pitti: right, something along those lines
[07:32] <kees> though I have to say, it's been kind of nice to only fsck one partition per boot.  ;)
[07:34]  * StevenK glares at pygtk
[07:34] <pitti> kees: ok, then the right solution is to properly wait
[07:35] <kees> pitti: right, I assume that's what's going on.
[07:35] <pitti> kees: do you happen to know, does that only affect the usplash part, or the text-only mode as well?
[07:36] <dholbach> good morning
[07:36] <kees> pitti: I didn't try booting without usplash.
[07:36] <pitti> kees: ok, thanks a lot for the heads-up; I'll try it in a VM then, but this gives me something to work on
[07:36]  * pitti hugs dholbach, morning
[07:36] <dholbach> hi pitti :)
[07:36]  * dholbach hugs pitti back
[07:36] <kees> pitti: cool, thanks.
[07:37] <kees> dholbach: thanks for another great mix.  I was enjoying it earlier today.  :)
[07:37] <dholbach> thanks a lot for the flowers, kees :-)
[07:38] <dholbach> kees: it's been a while since the last one and it was a good opportunity to plug one of the pictures from India ;-)
[07:38] <kees> hehe, I never know what that means.  :)
[07:38] <dholbach> kees: what what means?
[07:38] <kees> dholbach: "thanks for the flowers"
[07:38] <dholbach> oh... you don't say that in English?
[07:38] <dholbach> it's just thanking for a compliment :)
[07:39] <kees> dholbach: well, it's not a phrase I've heard before, but intent is clear.  I'm always just momentarily confused.  :)
[07:39] <dholbach> well ... thanks :-)
[07:39] <kees> regardless, I need to start saying that to people.  :)
[07:40] <dholbach> hehe
[07:40] <StevenK> So you can share your confusion?
[07:40] <kees> say, anyone else on 64bit with sane flash in firefox?
[07:40] <dholbach> and I need to write that blog post I about India I promised
[07:40] <kees> StevenK: 'zactly
[07:40] <StevenK> kees: I'm on 64bit with sane flash. Read as, no flash.
[07:40] <RAOF> kees: Does the definition of "sane" exclude "opens one decorated window per embedded flash object per page transition"?
[07:40] <kees> StevenK: heh.  I guess I should clarify.  :)
[07:41] <kees> RAOF: oh god, yes, I hope so.
[07:41] <kees> RAOF: but yeah, that's what I'm seeing.
[07:41] <RAOF> That excludes my flash experience, then :)
[07:41] <kees> RAOF: I've done exactly 0 bug hunting, but figured I'd just ask since I was just now staring at a mess of them on my task bar.
[07:42]  * RAOF doesn't actually use a task bar.
[07:42] <RAOF> They're a nspluginwrapper bug, IIRC.
[07:42] <StevenK> kees: Thinking, "Oh damn it, they're breeding" ?
[07:43] <kees> RAOF: yeah, that'd make sense.  I'll go dig
[07:44] <kees> StevenK: yeah, or "I couldn't possibly be the only person annoyed by this"
[07:44] <RAOF> It's not _substantially_ more annoying than the standard flash behaviour ;)
[07:44] <kees> at least swfdec doesn't auto-start them.  :P
[07:45] <kees> waaait... it couldn't be nspluginwrapper
[07:45] <kees> that doesn't apply for swfdec
[07:45] <RAOF> Yeah!  That's right.  I noticed that.  I blame 6am.
[07:46] <RAOF> I forget if gnash does it, too.
[07:46]  * kees eyeballs firefox
[07:49] <RAOF> For what it's worth, banshee(trunk) seems to be having problems embedding its NowPlaying window, too.
[07:49] <RAOF> That's not unlikely to be unrelated, though.
[07:50] <kees> is the publisher stuck?
[07:51] <pitti> lool: nope, failed again
[07:51] <kees> ff3 built 17 hours ago, but is not in the archive.  https://edge.launchpad.net/ubuntu/+source/firefox-3.0/3.0.2+build3+nobinonly-0ubuntu1/+build/706678 http://archive.ubuntu.com/ubuntu/pool/main/f/firefox-3.0/
[07:51] <pitti> kees: looks fine here
[07:52] <pitti> kees: ffox is in binary NEW
[07:52] <kees> pitti: Aaaaah
[07:52] <laughtear> RAOF: which channel we were?
[07:53] <laughtear> RAOF: for intrepid help?
[07:53] <kees> pitti: what caused that?  the translations?
[07:53] <pitti> kees: there are some split-out -branding packages
[07:53] <RAOF> laughtear: #ubuntu+1
[07:54] <kees> pitti: ah! I didn't open the arrow.  I see it now.  nm.
[07:57] <pitti> asac: I find the {firefox,webbrowser}-branding packages very confusing TBH; what's the idea of this?
[07:58] <pitti> asac: also, the package descriptions make it worse; webbrowser-3.0-branding is not a metapackage, talks about "The Awesome Browser", is called "-branding", and describes itself as "unbranded firefox"
[08:07]  * kees -> really to bed
[08:26] <tkamppeter> pitti, hi
[08:28] <StevenK> Hm. For want of a depgraph tool
[08:28] <Mithrandir> StevenK: apt-cache dotty ?
[08:28] <lool> pitti: Could you make sure it's building against -0ubuntu3?
[08:28] <lool> Yeah, /me wrote a build-deps dotty generator and later discovered apt-cache dotty :)
[08:28]  * StevenK fights his machine for some CPU time
[08:28] <StevenK> lool: Hah. Now fix pygtk!
[08:29]  * StevenK cracks a whip
[08:29] <lool> lpia: Successfully built.
[08:29] <StevenK> What makes you think I was talking about lpia? :-)
[08:29] <lool> I was thinking you could only be using lpia binaries!
[08:30] <lool> pitti: (I built it on amd64 on my host before uploading yesterday)
[08:30] <slangasek> ogra: did you ever submit an MIR for libaubio-dev? (denemo 0.7.7-3.1ubuntu1 changelog, from May)
[08:31] <StevenK> lool: I have a soft spot for amd64
[08:31] <lool> Weird, it's -0ubuntu3 in the buildd's log as well
[08:31] <StevenK> So I care about i386, amd64 and lpia
[08:38] <lool> pitti: Looks like a xvfb issue
[08:38] <lool> Xlib:  extension "RANDR" missing on display ":99.0".
[08:39] <lool> Gtk-WARNING **: Could not find the icon 'drive-optical'. The 'hicolor' theme
[08:39] <lool> It's not clear to me whether these are fatal
[08:39] <lool> I get the Xlib ones
[08:39] <pitti> hi tkamppeter
[08:39] <lool> I don't get the icon wqrning
[08:40] <seb128> what is broken?
[08:41] <lool> seb128: The testsuite failed; I'm trying to understand what bdep to add if any, otherwise I'll ignore its results
[08:41] <seb128> it built on i386
[08:41] <lool> Indeed
[08:41] <seb128> maybe just give it a build retry?
[08:41] <seb128> but that's weird
[08:41] <StevenK> seb128: pitti did
[08:42] <pitti> yep, didn't work
[08:42] <slangasek> it also failed on sparc and ia64 with the same error
[08:43] <pitti> slangasek: for the record, I cleaned up some uninstallabilities and component mismatches, going through the MIR queue now
[08:43] <pitti> slangasek: dailies should be there by now, I'll give them a smoke test
[08:44] <pitti> slangasek: time to disable the cd cron jobs then?
[08:44] <slangasek> pitti: great, thanks
[08:44] <seb128> slangasek: btw thanks for not moving the GNOME sru I asked about before going in holidays :-p
[08:46] <lool> Oh I wonder whether it's trying to display some filechooser object which needs the drive-optical command to work
[08:46] <lool> Because these buildds have an optical drive
[08:46] <tkamppeter> pitti, I have seen another small problem of our PDF-printing-enabled CUPS package: The CUPS test page (not the Ubuntu test pages, the original CUPS test pages) got incompatible. See bug 263049
[08:47] <pitti> tkamppeter: ah, needs to become a PDF now?
[08:47] <slangasek> pitti: well, we probably want to get a full set of images for today; whether cronned or by hand makes no difference to me
[08:47] <slangasek> seb128: mm, sorry, just keeping up with intrepid took up my time and I never got a chance to push SRUs out to -updates :/
[08:47] <pitti> slangasek: I'll leave that to you, just asking how you generally handle that
[08:47] <ogra> slangasek, no, i didnt file a request for aubio since persia and LaserJock cornered me to decide about the other missing deps ...
[08:48] <slangasek> ogra: sorry, what are the other missing deps?
[08:48] <seb128> slangasek: alright, no problem ;-)
[08:48] <tkamppeter> pitti, yes, and as PDF is no programming language, it cannot contain margins and resolution info any more.
[08:48] <ogra> slangasek, there are more changes in the recent debian version
[08:48] <slangasek> ogra: but that doesn't seem to be relevant for intrepid?
[08:48] <ogra> hmm
[08:48] <ogra> i didnt think abut it that way
[08:48] <pitti> tkamppeter: can we convert it to PDF on build time, so that we don't need to change upstream?
[08:49] <lool> seb128: I wonder whether we should recommend gnome-icon-theme in libgtk or pygtk in this light
[08:49] <lool> I'll push a package adding it only as a bdep for now
[08:49] <slangasek> ogra: well, we're past FF and well past DIF, so right now I only care about MIRs for the /current/ build-deps ;)
[08:49] <seb128> lool: I was just going to suggest that
[08:50] <ogra> slangasek, true but there is still a newer package in debian and for universe i could rather easily get a FF exception .... so i still need to decide if we stick with something old in main to have a scoreeditor in edubuntu or not
[08:50] <tkamppeter> pitti, but then the data on the test page would be completely wrong.
[08:50] <seb128> lool: btw you didn't push glib 2.18 to debian?
[08:51] <slangasek> ogra: oh, well if you're considering demoting it to universe that's fine with me (--> not my problem anymore ;)
[08:51] <pitti> tkamppeter: alternatively, can we make it use the ubuntu test page everywhere?
[08:51] <ogra> slangasek, i'll have that decided (and potential MIRs written) by the end of my workday, does that suffice ?
[08:52] <tkamppeter> pitti, I think this would be the better approach. For Debian one could perhaps also use the Ubuntu page but with a Debian logo inserted into it.
[08:52] <ogra> (i'm a bi under load with some private errands this morning)
[08:52] <ogra> *bit
[08:52] <pitti> tkamppeter: oh, hang on, right, the ubuntu test page is in s-c-p, not cups, right?
[08:52] <tkamppeter> pitti, yes, I think so.
[08:53] <lool> seb128: No I wanted to run it first; I ran it overnight and my system is still up so I'll upload it now
[08:53] <seb128> lool: ok thanks, did you try on debian or intrepid?
[08:53] <pitti> tkamppeter: nevertheless, I don't think the page would be completely wrong, it's just saying "postscript" which is not really true any more
[08:53] <lool> On intrepid
[08:53] <seb128> alright, so I can sync it directly ;-)
[08:54] <seb128> I would have built and tested it there otherwise
[08:54] <seb128> hanks
[08:54] <seb128> thanks
[08:54] <seb128> brb
[08:54] <pitti> tkamppeter: also, why doesn't it work? cups must still be able to print a postscript document and convert it to pdf on the fly?
[08:55] <slangasek> ogra: that's plenty fast, sure; I'm just going through the out-of-date list for main, I don't expect to get these all done in time for alpha-5
[08:55] <tkamppeter> pitti, the CUPS test page contains paper size, margins, resolution, interpreter name, and serial number. This shows all completely wrong if we statically convert it to PDF.
[08:55] <pitti> right, that's dynamically created, just saw it
[08:55] <pitti> tkamppeter: so, why not just keep the .ps for now?
[08:57] <tkamppeter> pitti, CUPS is capable of converting normal PS files to PDF, but the dynamically created data in the CUPS test page is only created correctly if the interpreter directly rasterizes to the printer.
[08:58] <pitti> tkamppeter: which parts are wrong?
[09:01] <tkamppeter> pitti, display the CUPS test page, /usr/share/cups/data/testprint.ps on the screen. It gives you some default page size and a resolution of between 72 and 100 dpi and GPL GS as the interpreter (see the two boxes in the middle).
[09:01] <pitti> tkamppeter: I did that, yes
[09:02] <pitti> tkamppeter: but if yuo print to a printer through the filter chain, it should still get the correct target dpi, and all that, no?
[09:02] <seb128> lool: pygobject 2.15.4 available with your fix btw (and an another change too)
[09:03] <tkamppeter> pitti, convert the test page to PDF with the ps2pdf command. Display this on the screen. You get for sure a much higher value shown as resolution, between 600 and 720 dpi.
[09:03] <pitti> tkamppeter: I get 720, yes
[09:04] <tkamppeter> pitti, the printer prints it always in the user-requested (or ptinter-native) resolution, as the PDF file is vector graphics. What is wrong is the resolution value in the info box and this iritates users.
[09:05] <pitti> tkamppeter: that still sounds weird to me; shouldn't resolution be propagated through the cups filter chain?
[09:05] <pitti> at some point the last filter needs to know it at least
[09:07] <tkamppeter> pitti, one can fake in at least the right resolution (which one can get from the PPD and/or command line): ps2pdf -r600 /usr/share/cups/data/testprint.ps
[09:07] <pitti> tkamppeter: exactly
[09:11] <tkamppeter> pitti, any idea how to fake in the margins?
[09:11] <pitti> tkamppeter: same Q as for resolution -- the papersize needs to be propagated through the filters, isn't that done?
[09:12] <pitti> if I just run ps2pdf I get letter
[09:12] <pitti> I shuold get A4 at least when I actually print something
[09:12] <pitti> but since cups has a wrapper around ps2pdf, I guess that will/should take care of paper size as well?
[09:13] <tkamppeter> pitti, the biggest problem are the interpreter name and printer serial number. You cannot make the pstopdf filter read this out of a PostScript printer. Perhaps we need to patch these fields out of the test page.
[09:13] <pitti> tkamppeter: right, that should be fine (patching out of the ps)
[09:14] <pitti> they are largely uninteresting for the purposes of a test page; the paper size and margins matter most, IMHO
[09:14] <tkamppeter> pitti, paper size is no problem, run ps2pdf with -sPAPERSIZE=a4 or better with -dDEVICEWIDTHPOINTS=XXX -dDEVICEHEIGHTPOINTS=YYY
[09:16] <tkamppeter> ion_, are you here?
[09:19] <tkamppeter> pitti, ion_, we can also make the conversion cleaner if the pstopdf filter propagates page size, margins, and resolution to the conversion process. Imaging a PS file without well-defined page size or wrong page size is sent. The conversion process could correct the situation.
[09:19] <lool> pitti: pygtk amd64: Successfully built.
[09:20] <pitti> lool: hm, I wonder what's different on your system
[09:20] <lool> pitti: I don't have an optical drive
[09:20] <pitti> lool: and the buildd has one?
[09:20] <lool> It seems so :)
[09:20] <pitti> and that breaks pygtk build? WTH?
[09:20] <lool> That icon name I mentionned earlier is probably needed to display a filechooser during the tests
[09:21] <lool> It's certainly a bug in pygtk or gtk for having a dependency on this and the package not having a corresponding dep, or for the testsuite to fail on warnings if it's only a warning
[09:21] <pitti> hm, that does sound kind of relevant for pygtk, thuogh
[09:22] <pitti> lool: fail on warnings? I saw a segfault there, which seems more serious?
[09:22] <lool> pitti: Not sure when you saw a segfault
[09:22] <lool> pitti: Perhaps a build against pygobject -0ubuntu2?
[09:22] <pitti> lool: the previous amd64 build log had one, hang on, I'm checking the current one
[09:22] <pitti> oh, hang on, it built now?
[09:23] <lool> Yes
[09:23] <pitti> didn't I just see it FTBFS? maybe someone gave it back again
[09:23] <lool> I uploaded it with a gnome-icon-theme bdep
[09:23] <lool> (for the optical drive)
[09:24] <seb128> pitti: http://launchpadlibrarian.net/17256244/buildlog_ubuntu-intrepid-amd64.pygtk_2.13.0-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:24] <seb128> pitti: that was the build error
[09:25] <lool> seb128: I think pitti also saw a segfault in the previous log
[09:25] <lool> Quite probably because pygtk built against pygobject << -0ubuntu3
[09:25] <seb128> lool: let's pretend that one was a transitionnal issue ;-)
[09:25] <lool> seb128: I'll leave the new pygobject upstream to you if you like; I don't think it adds anything for us
[09:26] <pitti> right
[09:26] <seb128> lool: right we can skip this update
[09:26] <seb128> lool: did you upload glib2.0?
[09:26] <lool> seb128: Yes, you can sync it from incoming in a couple of minutes
[09:27] <seb128> lool: I'm wondering if you had a perfect timing and uploaded just before the dinstall run or if it's just not listed in incoming yet
[09:27] <seb128> lool: ok good
[09:27] <lool> I uploaded 3 minutes ago, it will show up soon
[09:27] <seb128> excellent, thanks
[09:31] <seb128> brb
[09:43] <slangasek> pitti: how's the smoke testing?
[09:43] <pitti> slangasek: just finished rsyncing, alternate and desktop just booting
[09:43] <slangasek> ok
[10:03] <tkamppeter> pitti, ion_, bug 263049 is now updated.
[10:12] <asac> pitti: did you look at the ffox NEW packages yet?
[10:12] <pitti> asac: yes, see my questions above
[10:12] <asac> pitti: those are bugs ... no need to keep this out tbh
[10:13] <asac> pitti: i am bad at writing descriptions
[10:13] <pitti> asac: right, the bad package descriptions are bugs, but I'd still like to understand the purpose, and why the webbrowser deb has "awesome-browser-*' files
[10:14] <pitti> and IMHO the names of the packages are highly confusing; we should make them more clear, which is why I didn't accept them yet
[10:14] <asac> pitti: what is confusing about the packages
[10:14] <asac> ?
[10:14] <asac> pitti: the packagename is a generic name, because we want to provide a free branding without any trademarks
[10:15] <asac> pitti: the "awesome" branding is just a code name for the branding directory i used during development
[10:15] <asac> pitti: it will disappear from the description
[10:15] <pitti> asac: still, why should a package named -branding give you an unbranded firefox?
[10:16] <pitti> asac: as I said, I have *no* idea how the structure *shuold* be, maybe you can tell me?
[10:16] <asac> pitti: you cannot have an unbranded browser
[10:16] <asac> pitti: just a browser with a "generic" branding
[10:16] <pitti> also, I refuse to accept a package which is called "webbrowser"
[10:17] <pitti> that's namespace pollution
[10:18] <pitti> if the idea is to take out the ubuntu branding from firefox, then there should be an unbranded firefox-3.0 (representing upstream) and a firefox-3.0-ubuntu-branding which has our changes
[10:18] <pitti> just calling it -branding doesn't help, since it doesn't tell you *what* branding, so derivatives cannot use the same schema
[10:19] <asac> pitti: derivitaves can just remove the firefox-3.0-branding packages.
[10:19] <asac> or dont sync them
[10:19] <asac> firefox-3.0-branding == firefox branding
[10:20] <pitti> doesn't work, since they are built from teh same source
[10:20] <asac> pitti: dont understand. there are 2 things here: 1st. people can just sync the binary bits they want
[10:20] <pitti> asac: ah, so firefox-3.0-branding is the upstream original, while webbrowser-3.0-branding should really be firefox-3.0-ubuntu-branding ?
[10:20] <lool> seb128: glib is in incoming
[10:20] <seb128> lool: it's in intrepid too ;-)
[10:20] <asac> pitti: no ... firefox-3.0-ubuntu-branding isnt nice
[10:20] <asac> it suggests that its ubuntu
[10:21] <seb128> lool: just synced like 15 seconds ago, but thanks for the notice ;-)
[10:21] <pitti> well, what is it then?
[10:21] <asac> we dont want that word to reside there
[10:21] <lool> Ok, didn't show up in rmadison yet
[10:21] <pitti> lool: rmadison has a ~ 6 hour lag
[10:21] <asac> pitti: its a webbrowser branding which is completely generic and not trademark encumbered
[10:22] <pitti> asac: it's not a webbrowser branding, it's at most a mozilla or firefox branding
[10:22] <pitti> (firefox, according to the .deb contents)
[10:22] <lool> asac: firefox-3.0-generic-branding?
[10:23] <pitti> ./usr/lib/firefox-3.0.2/chrome/awesome-branding-en-US.jar
[10:23] <pitti> and that's not really helpful to either users, developers, or derivatives
[10:24] <slangasek> pitti: I'm turning in for a few hours of sleep before the foundations meeting; if those images pass the smoke test, can you post the candidates to the tracker?
[10:24] <pitti> slangasek: yes, I will
[10:30] <cjwatson> lool: the generic branding specifically isn't called "firefox"
[10:30] <asac> pitti: filenames / directories and such are not covered by trademarks as far as we understand
[10:31] <wgrant> Is it really as generic as webbrowser?
[10:31] <pitti> wgrant: no
[10:31] <asac> pitti: so its helpful if derivatives want to sync from us, they can just leave the firefox-3.0-branding aside
[10:31] <cjwatson> wgrant: in the user interface, it winds up just being called "Web Browser"
[10:31] <pitti> asac: right, but then the package name should explain what it is and avoid confusing/buzz names like "awesome" and "webbrowser"
[10:32] <asac> pitti: package name and filenames that might be confusing can be (and will be) fixed.
[10:32] <cjwatson> pitti: can you suggest one that doesn't include "firefox"? We discussed this for quite a while and this was the best we could come up with
[10:32] <asac> pitti: err package description
[10:32] <pitti> asac: fixing file names is fine, fixing package names is harder
[10:32] <pitti> since it requires transitional packages, conflicts, etc.
[10:32] <asac> pitti: i misread (description)
[10:32] <cjwatson> pitti: mobile> you mean consolidating component-mismatches and component-mismatches-mobile?
[10:32] <pitti> cjwatson: if I would know the purpose of this package, then yes; AFAICS, it contains a neutral branding theme for firefox
[10:33] <pitti> cjwatson: c-m> I faintly remembered that you said you temporarily removed the mobile seeds from c-m
[10:33] <asac> pitti: the idea is that we get to the point where any distribution can just drop firefox and firefox-3.0-branding package
[10:34] <asac> and then dont have any trademark issues anymore
[10:34] <cjwatson> pitti: the full list is in c-m-mobile
[10:34] <pitti> cjwatson: if the current lists are in the intended state, I'll consult c-m-mobile for demotions
[10:34] <cjwatson> (sorry, bad naming)
[10:34] <wgrant> Can the Firefox branding then be appropriately moved to restricted?
[10:34] <pitti> cjwatson: ok, thanks
[10:34] <cjwatson> wgrant: please see the Ubuntu licensing policy. non-code is handled case-by-case so the Firefox branding doesn't necessarily have to be in restricted.
[10:35] <wgrant> cjwatson: It seems odd to have something that clearly cannot be modified in main when it's easily movable to restricted.
[10:36] <cjwatson> it can be modified, just within certain parameters
[10:36] <wgrant> That sounds non-free to me.
[10:36] <asac> pitti: whatever name you choose, downstreams will have to rename it ... either they dont like "iceweasel", or they dont like "supercoolthing" ... or whatever we choose. The best solution after lots of thought that came out is just to call it webbrowser
[10:37] <cjwatson> it *could* be moved to restricted, perhaps; and it might make sense. I object to you implying that it's required by our policy when it isn't, though.
[10:37] <cjwatson> wgrant: yes.
[10:37] <pitti> asac: iceweasel is a proper noun, whereas webbrowser is a program category where dozens of alternatives exists
[10:37] <wgrant> Policy might not state it, but common sense seems to.
[10:37] <pitti> asac: I wouldn't mind if you just call it iceweasel or vanilla-webbrowser, but not just 'webbrowser'
[10:40] <cjwatson> I like vanilla-webbrowser
[10:41] <cjwatson> I wouldn't mind the firefox branding going into restricted. It's just not a bug that it's in main and I wanted to make that clear.
[10:41] <liw> does that mean that the browser with branding should be called kinky-webbrowser?
[10:41] <cjwatson> *cough*
[10:41] <liw> I would s/vanilla/plain/
[10:42] <asac> i just want to prevent endless discussions of names ... thats why webbrowser makes sense - where the discussion is mostly about "is it ok to use that" and not "is it a good name"
[10:42] <pitti> another idea:
[10:42] <pitti> could firefox-3.0 ship the generic branding, and if you install firefox-3.0-branding, that would give yuo the firefox one?
[10:42] <wgrant> cjwatson: I don't see where in the license policy unmodifiable code is permitted.
[10:43] <pitti> thereby removing the need for a new "plain" package name at all?
[10:43] <asac> pitti: that was the way it was in a previous prototype.
[10:43] <asac> pitti: the point is that you still want a "webbrowser-3.0-branding" package, that forces the firefox branding off the disc imo
[10:43] <cjwatson> wgrant: where's the unmodifiable code in the branding?
[10:44] <cjwatson> I thought the unmodifiable parts were basically images
[10:44] <wgrant> cjwatson: So it's fine if the code is GPL but I can't modify it because of the trademark restrictions?
[10:44] <pitti> asac: uninstall firefox-3.0-branding ?
[10:44] <wgrant> GPL/$(various other free licenses)
[10:44] <asac> pitti: yeah. but then you end up in upgrade issues ... people now using firefox suddenly loos their branding
[10:45] <asac> i had recommends on the -branding package ... but that didnt work well enough in upgradfe case
[10:47] <pitti> asac: firefox depends: firefox-base, firefox-branding, firefox-base recommends: firefox-branding, ubuntu-desktop depends; firefox-base
[10:47] <pitti> wouldn't that work?
[10:48] <pitti> s/;/:/
[10:48] <asac> pitti: ubuntu-desktop DEPENDS firefox-base?
[10:48] <asac> thought that its a recommend
[10:48] <pitti> asac: well, or recommends, whatever u-desktop does right now
[10:49] <asac> pitti: remember we have firefox -> firefox-3.0
[10:49] <pitti> since webbrowser-3.0-branding depends: firefox-3.0, we won't get rid of the 'firefox-3.0' package name anyway
[10:49] <pitti> asac: yes, it was just a schema, not the real package names
[10:50] <cjwatson> wgrant: while I'm not entirely happy about this, general practice has been that we only consider items enforced by copyright law when assessing freedom, since you could always change the name to avoid the trademark. While I'm not sure there's a clause specifically about this in the Ubuntu licensing policy, the parent DFSG has a comment in point #4: "The license may require derived works to carry a different name or ...
[10:50] <cjwatson> ... version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.)"
[10:54] <asac> pitti: i thought about it ... it doesnt really work for downstreams
[10:54] <asac> pitti: they dont have a similar vehicle that "firefox" is
[10:54] <asac> e.g. that tracks them over over upstream version bumps
[10:55] <pitti> asac: we mainly need 'firefox' for clean upgrades, so downstreams just have to provide that, too; or do you mean something else?
[10:55] <asac> pitti: ... they need to provide firefox and patch the depends on -branding out of it
[10:56] <asac> let me think a moment ;)
[10:58] <pitti> yay, ubuntu desktop CDs seem happy
[10:59] <cjwatson> asac: I'm reminded of linux-generic vs. linux-image-generic
[10:59] <asac> pitti: i dont think that it works.
[10:59] <pitti> asac: how does it work in your proposed schema then?
[10:59] <asac> pitti: problem is for upgrades you need "depends" ... and depends will couple the branding
[11:00] <asac> pitti: you apt-get install webbrowser ;)
[11:00] <asac> then you get webbrowser
[11:00] <asac> you apt-get install firefox
[11:00] <asac> then you get firefox
[11:00] <pitti> asac: those are two different things
[11:00] <pitti> for upgrades you need 'firefox' no matter what
[11:00] <pitti> and for apt-get, 'firefox-base' and 'firefox' would give you unbranded/branded
[11:01] <pitti> apt-get install webbrowser (as it is in NEW now), would still pull in 'firefox-3.0', so you have the firefox package name either way, too
[11:01] <asac> pitti: so you want to introduce firefox-base and firefox-3.0-base?
[11:01] <pitti> asac: maybe not -base, could be -unbranded, or something descriptive
[11:01] <asac> pitti: thats not the point here. the point here is that if you dont have "firefox" installed ... nor "webbrowser", then you wont be upgraded to 3.1
[11:02] <cjwatson> asac: would a recommends from ubuntu-desktop on the firefox branding package not be strong enough?
[11:02] <cjwatson> recommends from metapackages have been treated quite strongly for a while
[11:02] <asac> cjwatson: in apt-get ? or just update-manager?
[11:03] <cjwatson> asac: apt-get
[11:03] <cjwatson> in hardy, it had a special bit of configuration that said to treat all recommends from Section: metapackages as depends (unless you were trying to remove those packages etc.; usual rules)
[11:03] <asac> i'd thiknk that there is a good proportion of users out there that doesnt have ubuntu-desktop installed
[11:03] <cjwatson> that's probably true
[11:03] <cjwatson> although, realistically, that's because they didn't want it installed
[11:04] <cjwatson> (for some specific reason)
[11:04] <asac> cjwatson: true. but if possible i dont want to unbrand everyone that doesnt have ubuntu-desktop on their system
[11:04] <cjwatson> oh, I wasn't suggesting that
[11:04] <pitti> that's why I thought that firefox-3.0 should depend on -branding and -unbranded, -unbranded recommends -branding, and -desktop recommends -unbranded
[11:04] <cjwatson> I'm actually slightly surprised that recommends from firefox (or firefox-3.0 or whatever) isn't strong enough with intrepid's apt
[11:05] <cjwatson> asac: would it help if the firefox official branding diverted the generic branding, so that you could install both simultaneously?
[11:05] <asac> pitti: as long as the user can just apt-get remove -branding, i am sure that good proportion of users will end up without branding
[11:05] <pitti> then upgrades would keep the branding (even with apt-get), fresh installs would get it through the recommends, and derivatives or users can uninstall -branding
[11:05] <asac> pitti: why would apt-get upgrade keep the branding? it doesnt install any new package afaik
[11:05] <pitti> asac: but isn't that precisely what you want? if I purge -branding, I end up with a vanilla one
[11:05] <asac> it wont hold it back
[11:06] <pitti> asac: dist-upgrade would
[11:06] <asac> and on next dist-upgrade the recommends dont get installed
[11:06] <pitti> asac: dist-upgrade gets the branding because firefox-3.0 depends on both
[11:06] <pitti> upgrades -> depends, installs -> recommends
[11:06] <asac> pitti: and also we are again talking about -unbranded and -braded ... which is basically what we have right now
[11:06] <asac> webbrowser-3.0-branding (aka -unbranded) and firefox-3.0-branding
[11:07] <pitti> no, it's not what is in NEW
[11:07] <pitti> I object to webbrowser-3.0-branding
[11:07] <pitti> it's too generic, it's confusing, and it won't help us to completely get rid of 'firefox-3.0'
[11:07] <asac> pitti: i dont want to get rid of firefox-3.0 for now
[11:07] <asac> if thats required we can do so later
[11:07] <pitti> (neihter do I, but I thought that was the goal)
[11:08] <pitti> and we'll need it for upgrades at least until the next LTS anyway
[11:08] <asac> you proposal wants a firefox-3.0-base package ... which still is firefox
[11:08] <pitti> asac: let's call it firefox-3.0-unbranded, not -base
[11:09] <pitti> asac: if you are happy with having 'firefox' as the transitional package, then splitting out -branding is all we need, and we don't need a -base or -unbranded
[11:09] <pitti> i. e. firefox depends: firefox-3.0, firefox-3.0-branding
[11:09] <pitti> which is solely for upgrades
[11:09] <pitti> and firefox-3.0 recommends: firefox-3.0-branding
[11:09] <pitti> for installations
[11:09] <pitti> this would be the easiest structure if we can live with 'firefox' being the transitional package, not 'firefox-3.0'
[11:10] <pitti> since u-desktop just depends on firefox, not firefox-3.0, this would be suitable IMHO
[11:12] <asac> pitti: i dont want firefox as transitional package ... i just want a top level package that users and dowstream can track/seed
[11:13] <pitti> asac: right, and that would be 'firefox' in the branded case, just like we have now
[11:13] <pitti> and if you need an unbranded one, this could just be called firefox-unbranded, depending on firefox-3.0
[11:14] <asac> pitti: thats basically what we have now
[11:14] <asac> we have webbrowser (aka firefox-unbranded)
[11:14] <asac> which depends firefox-3.0, webbrowser-3.0-branding
[11:14] <pitti> asac: so can we merge webbrowser into 'firefox-3.0' and adjust the dependencies accordingly?
[11:14] <asac> he?
[11:15] <asac> no ... then we will loose the top-level package that users can track
[11:15] <pitti> ?
[11:15] <pitti> why, we'd have firefox-unbranded for that?
[11:16] <asac> pitti: so your suggestion is to s/webbrowser/firefox-unbranded/ ?
[11:16] <asac> and keep the rest as it is?
[11:17] <pitti> not really
[11:17] <pitti> firefox and firefox-unbranded should just be metapackages IMHO
[11:17] <asac> pitti: firefox and webbrowser are metapackages atm
[11:17] <pitti> the webbrowser package, as it is in NEW, has stuff in it
[11:17] <pitti> which should be in firefox-3.0
[11:17] <asac> firefox-3.0-branding has firefox branding ... webbrowser-3.0-branding has webbrowser branding bits
[11:18] <pitti> asac: if it's hard to just put the neutral branding right into firefox-3.0, for my sake we can keep it it in the firefox-unbranded not-quite-metapackage, but that seems harder to maintain in the long-term when we have a new firefox major version
[11:18] <lool> "* State: Failed to upload" hmm first time I see this
[11:19] <asac> pitti: so the only point left is webbrowser name
[11:19] <pitti> asac: not for me
[11:19] <asac> and you suggest to change that firefox-unbranded
[11:19] <cjwatson> I'm OK with names of the general form firefox-unbranded, FWIW; as asac points out we still have firefox-3.0 anyway
[11:19] <asac> which isnt really nice.
[11:19] <bigon> seb128, it could maybe intresting to rebuild all the rdeps of enchant to be sure libs doesn't export too mush symbols, what do you think about that?
[11:19] <pitti> asac: no, that's not what I am proposing
[11:19] <seb128> bigon: after the freeze this week that could be a good idea yes
[11:19] <cjwatson> lool: which package?
[11:20] <pitti> asac: give me a minute to draw it
[11:23] <pitti> asac, cjwatson: my proposal: http://people.ubuntu.com/~pitti/tmp/firefox-dependencies.txt
[11:25] <asac> pitti: if you have firefox-3.0 (without firefox) installed now and run apt-get upgrade; apt-get dist-upgrade you will end with unbranded browser i guess
[11:25] <pitti> asac: only if you additionally disable recommends
[11:25] <pitti> asac: if you disable recommends, remove firefox, and remove ubuntu-desktop, you can't expect a clean upgrade with apt-get, right
[11:25] <cjwatson> pitti: I've changed component-mismatches to include everything again, and removed component-mismatches-mobile. If you want to put it back the way it was, see the obvious comments in ~lp_archive/dak/cron.sync
[11:25] <asac> pitti: i think if you run apt-get upgrade .... this will make the reommends on next dist-upgrade void
[11:26] <pitti> cjwatson: ah, thank yuo
[11:26] <cjwatson> (and perhaps come up with better names for those files while you're at it, if you do put that back ...)
[11:27]  * ogra wonders ... i have a mobile image of which i mounted the squashfs in an aufs merged overlay ... mounted sys and proc in there, now if i run "sudo chroot /tmp/mergemount apt-get update" apt just hangs ... i cant ctrl-c or kill it 
[11:27] <pitti> asac: but that'll just hold it back, until you run dist-upgrade?
[11:27] <pitti> asac: 'it' being the firefox package
[11:27] <asac> pitti: no ... it forgets about that
[11:27] <asac> pitti: thats what i tested
[11:27] <ogra> anyone an idea ?
[11:28] <asac> pitti: also apt-get install firefox-unbranded wont unbrand firefox here?
[11:28] <asac> but thats probably just a conflicts
[11:28] <pitti> asac: right, you need to uninstall firefox-branding, not uninstall firefox-unbranded
[11:28] <cjwatson> I think it must be quite rare to have only firefox-3.0 installed
[11:28] <cjwatson> we've never used that name in our metapackages AFAIK
[11:28] <seb128> lool: ups, sorry, conflict upload on rhythmbox I overwrote your change
[11:28] <pitti> cjwatson: ... and trying to upgrade from hardy to intrepid with "apt-get upgrade"
[11:29] <pitti> instead of dist-upgrade
[11:29] <cjwatson> I do often use 'apt-get upgrade' as a first pass; it hadn't previously occurred to me that that would mark recommends as "seen"
[11:29] <asac> there are zillions of people that run apt-get upgrade
[11:29] <cjwatson> I wonder if that's a bug
[11:29] <cjwatson> most of those people will have firefox installed, though
[11:29] <pitti> asac: if you want this work, then firefox-unbranded could conflict to firefox-3.0-branding, yes; I think that makes sense
[11:29]  * ogra wonders if he hit an ap bug here 
[11:29] <ogra> *apt
[11:30] <pitti> asac: updated the text file for that
[11:30] <asac> pitti: right. but thats exactly what i had before ;)
[11:30] <asac> pitti: and there were issues with unbranding for users ... even though i uploaded it to mozillateam ppa only
[11:30] <pitti> asac: nowhere in http://people.ubuntu.com/~pitti/tmp/firefox-dependencies.txt we have a package name "webbrowser"
[11:30] <asac> pitti: thats true. but thats just "choosing" a different name ;)
[11:31] <asac> which i think is an endless story
[11:31] <pitti> asac: no, avoiding the 'webbrowser' package altogether
[11:31] <asac> but introducing firefox-unbranded instead
[11:31] <pitti> right
[11:31] <asac> pitti: which is just a rename
[11:31] <pitti> no, firefox-unbranded ought to be a metapackage
[11:32] <ogra> oh, great, even attaching strace to the hanging apt makes strace hang as well :/
[11:32] <asac> pitti: with "before" i dont mean what i uploaded, but what i uploaded to PPA like a week ago
[11:32] <pitti> webbrowser-branding isn't a metapackage, it has a them ein it
[11:32] <pitti> ah, I don't know the ppa package
[11:32] <asac> pitti: as i said. i had almost exactly that approach
[11:32] <asac> firefox-3.0 -> free branding
[11:32] <asac> firefox-3.0-branding -> diverges to firefox branding
[11:33] <asac> (which was painful btw, to do the diverges)
[11:33] <asac> but that didnt work out well for users .... they came into channel and complained about lost branding because they ran apt-get upgrade
[11:34] <pitti> asac: well, I could live with people doing their upgrades that way, since it won't matter for hardy -> final intrepid upgrades, but if you think it's a real problem, I don't mind introducing yet another package and make firefox-3.0 the (sub)metapackage
[11:34] <asac> pitti: i think its a real problem. i have no time to deal with all the folks complaining that their branding is gone
[11:35] <pitti> but frankly, if you just have firefox-3.0 installed, without firefox, and use apt-get upgrade for dist-upgrades, you know what you are doing
[11:35] <asac> pitti: and i still dont buy why webbrwoser cannot be used
[11:35] <asac> or at least ... we rename the package we have now
[11:35] <pitti> asac: for the same reason why we don't have packages "shell", "kernel", "terminal", and "mailreader"
[11:35] <asac> and dont do another depends/recommends shuffling round
[11:36] <asac> pitti: sure. i am fine with just s/webbrowser/something-else/
[11:36] <pitti> they are not package names, they are application categories, and since we have more than one alternative for each category, we need proper nouns for applications
[11:36] <asac> but i dont want to lead the discussion on what the "something-else" is
[11:36] <lool> cjwatson: package was rhythmbox
[11:36] <pitti> asac: I want to avoid something-else altogether
[11:36] <lool> seb128: So what happens then?
[11:36] <pitti> we won't get rid of firefox, as in the package name
[11:36] <lool> seb128: I'm surprized that's possible
[11:36] <seb128> lool: I'll merge your change
[11:37] <asac> pitti: people should not apt-get install firefox* metapackages to get the unbranded build
[11:37] <lool> seb128: You did a regular upload with the same version or some archive command?!
[11:37] <seb128> lool: I did a new upstream svn snapshot, my version is higher than yours and has been uploaded 5 minutes later
[11:37] <lool> Oh I see, thanks
[11:37] <asac> firefox-3.0 is a transitional situation ... but the top level metapackages should not contain firefox
[11:39] <pitti> asac: I updated the text file with the alternative for the stupid 'purged all metapackages and uses apt-get upgrade' case
[11:39] <pitti> which, IMHO, is really stupid, but *shrug*, if we care, then we can use that schema
[11:40] <asac> pitti: firefox-3.0 still recommends branding ... which means users that have -3.0 installed will get unbranded on upgrade :)
[11:40] <pitti> asac: no
[11:40] <pitti>   firefox-3.0         Depends: firefox-3.0-unbranded, firefox-3.0-branding
[11:40] <asac> oh ... further down :)
[11:41] <pitti> asac: I kept my original proposal at the top, and the alternative below, yes
[11:41] <doko> pitti: libffi4 is not built anymore. it should be removed from the archive
[11:42] <pitti> doko: hm, I wonder why it doesn't appear in NBS; thanks
[11:42] <asac> pitti: i really dislike that kind of approach. i had dpkg-diverts before and they dont feel good. keeping the unbranded bits in its own packages is much cleaner
[11:42] <asac> but i said that before :)
[11:43] <doko> pitti: and libffi4-dev as well
[11:43] <pitti> asac: right for diversions, an alternatives symlink to the default theme should certainly do
[11:43] <asac> pitti: no alternatives are even worse
[11:43] <asac> please lets not use that
[11:44] <ScottK> pitti: I agree with you about unzoo and I've asked the Debian maintainer to drop it to suggests.  There's a new clamav upload imminent and I'll change ours if he doesn't get to it.
[11:44] <pitti> ScottK: hello
[11:44] <pitti> ScottK: ok, thanks
[11:45] <asac> pitti: so what is the problem of having a "something-else-3.0-branding" and something-else metapackage?
[11:45] <pitti> ScottK: I'll review arj next
[11:45] <asac> except that its funky to make firefox-3.0 the "unbranded" package on its own
[11:45] <ScottK> ;-)
[11:45] <pitti> asac: if something-else doesn't expand to "webbrowser", but a proper noun, I'm ok with it
[11:45] <pitti> but I won't NEW a package "webbrowser" into the archive
[11:46] <ogra> ubuntu-browser  ?
[11:46] <pitti> which means, that you either convince another archive admin, or rename it to heatbadger, or vanilla-webbrowser, or something creative :)
[11:46] <asac> ogra: putting ubuntu into it is bad for downstreams
[11:46] <asac> pitti: fair enough
[11:47] <pitti> weaselchrome!
[11:47] <ogra> thebrowser :)
[11:47] <asac> pitti: awebbrowser ;)
[11:47] <pitti> its-the-browser-you-want-trust-me
[11:47] <Company> mostawesomepackage
[11:48] <asac> Company: i had awesome-browser at some point
[11:48] <asac> but that was disliked elsewhere ;)
[11:48] <Company> :(
[11:48] <pitti> asac: what about webbrowser-branding -> firefox-3.0-neutralbranding?
[11:49] <asac> pitti: the property i want to keep up is that the metapackage (and the unbranded branding package itself) dont have the firefox mark in it
[11:49] <cjwatson> neutral-browser?
[11:49] <asac> whitebox-browser
[11:49]  * cjwatson looks at chromium and considers neutronium
[11:49] <asac> all those are nice ideas ... but they still kick off a new "brand" imo
[11:49] <asac> hehe
[11:49] <pitti> I don't understand why firefox-3.0-neutralbranding is a problematic name for a package which depends on firefox-3.0 and ships a theme for firefox-3.0
[11:49] <cjwatson> neutral-, whitebox-, vanilla-, plain- aren't really brands, imo
[11:50] <ogra> pure-
[11:50] <ogra> :)
[11:50] <pitti> I guess by the time we settled for a name, we'll all use webkit...
[11:50] <asac> most likely
[11:51] <Company> so use a name that works for webkit branding, too!
[11:52] <Company> apple can be nasty with branding ;)
[11:53]  * ogra really really doesnt get that apt-get thing ... but bug #264048 shows thats happening in other setups too :/
[11:53] <ogra> when is mvo back ?
[11:54] <pitti> asac: reload please, see the bottom part
[11:54]  * ogra wonders if that could be related ot the new hardening stuff somehow 
[11:55] <pitti> asac: I think this is what your current intention is, right? (just to understand the structure)
[11:55] <pitti> asac: except that I split your webbrowser-branding into a metapackage with neutral name (unbranded-webbrowser) and a contentful package firefox-3.0-neutralbranding
[11:55] <asac> pitti: right
[11:56] <asac> pitti:  however, i think we should choose one name for "unbranded-webbrowser" ... and use that just like i did in the branding package name
[11:57] <asac> or is there any reason to keep it in a firefox-3.0 prefixed package?
[11:57] <ScottK> pitti: You may want to hold off on arj for a bit.  It may get dropped without help from us.
[11:57] <pitti> ScottK: yay
[11:58] <pitti> ScottK: an initial grep for sprintf made me weep :)
[11:58] <ScottK> Apparently the new upstream drops support for external unpackers.
[11:58] <pitti> asac: yes, because it is a package depending on firefox-3.0, shipping a firefox-3.0 theme; it won't work with lynx or epiphany, etc.
[11:59] <pitti> ScottK: it's just a recommends, right? so we could promote clamav and the rest without arj for now
[11:59] <asac> pitti: ok
[11:59] <ScottK> pitti: They are.
[11:59] <ScottK> (just recommends)
[12:00] <pitti> asac: thanks for the discussion, and sorry for my pickyness *hug*
[12:01] <asac> pitti: cjwatson: i am a bit demotivated now (not too bad ;)) and will push that back a day or two ...  (until alpha-5 is out i guess)
[12:01] <pitti> yeah, it's a post-alpha 5 thing anyway
[12:01] <pitti> we are in freeze
[12:03] <MacSlow> pitti, how to correctly call getenv() from within a gdb session?
[12:04] <MacSlow> pitti, the gdb "call"-command only works on functions defined in the symbol-table of the process being debugged, right?
[12:05] <pitti> MacSlow: (gdb) call puts(getenv("HOME"))
[12:05] <pitti> MacSlow: right, but since getenv and puts are libc6, they should always be there
[12:08] <MacSlow> pitti, ok I tried it just with getenv("HOME") on a different process and it seem to have worked ... $1 = -870404906 is the reply I got
[12:08] <pitti> MacSlow: right, but the pointer value isn't very interesting, so you should wrap a puts() around it
[12:09] <pitti> that will give a segfault for nonexisting variables, of course, but that doesn't hurt
[12:10]  * pitti lols "Kernel alive" .... "Kernel really alive"
[12:10] <pitti> linux: I'm not quite dead yet!
[12:11] <MacSlow> brb
[12:11] <pitti> Riddell: ouch, seems that kubuntu livefses have failed to build since 20080819
[12:12] <pitti>   gtk-qt-engine-kde4: Depends: gtk-qt-engine but it is not installable
[12:12] <pitti> E: Broken packages
[12:14]  * pitti fixes
[12:15] <mdz> pitti: dovecot's LDA is choking on a message in my mailbox; it triggers an assertion failure which invokes abort() but no core file or apport crash are generated
[12:15] <mdz> reading message mdz@fastmail.fm@mail.messagingengine.com:1 of 4 (2019 header octets). (922 body octets).Aborted (core dumped)
[12:15] <mdz> pitti: the handler for SIGABRT is default, which should trigger a core, which I would expect to trigger apport.  any guess what's wrong?
[12:16] <pitti> mdz: right, apport ignores aborts
[12:16] <mdz> oh
[12:16] <pitti> mdz: I did that a while ago after seb128 complained about all the useless bugs we got from that
[12:16] <mdz> pitti: why were they useless?
[12:16] <pitti> since we can't capture the assertion message automatically in a generic way
[12:16] <mdz> oh
[12:16] <pitti> (IIRC)
[12:17] <pitti> mdz: in effect they were similarly useless like gdb stack traces in mono programs
[12:17] <mdz> pitti: I guess it is the same in this case; it is printing an assertion error before it crashes
[12:18] <pitti> mdz: if you want to grab it locally, edit /usr/share/apport/apport and delete the paragraph in line 266
[12:18] <mdz> pitti: perhaps it would be useful to provide some API which would log a crash for assertion failures explicitly
[12:18] <pitti>     # ignore SIGABRT (we currently have no way of extracting abort() messages
[12:18] <pitti>     # or mono's stderr for stack traces).
[12:19] <pitti> mdz: yes, ideally we'd modify libc6's abort() method to create such a dump for us
[12:19] <pitti> and mono to call the mono debugger (there's even a spec for it)
[12:20] <mdz> pitti: or provide our own assert() macro
[12:21] <mdz> once abort() is called it's too late to know what went wrong
[12:21] <pitti> right, we'd need that, abort(3) doesn't have a message
[12:21] <mdz> neat, trying to file a bug report about this assertion failure triggers an OOPS in launchpad
[12:22] <pitti> lol
[12:25] <MacSlow> pitti, even for upstream gdm (gdm-binary to be precise) "call puts(getenv("HOME"))" caused a segfault in libc for strlen(). As you mentioned before this usually indicates that the sought for env. var. is not set.
[12:26] <MacSlow> pitti, that sounds fishy to me
[12:26] <MacSlow> restarting everything and trying XDG_SESSION_COOKIE also failed of course
[12:27] <pitti> kirkland: currently doing a test-install of ubuntu alternate; d-i asks me whether to create ~/Private, but it asks me for a separate password for it; I thouoght it would just use my account password and unlock it with login?
[12:27] <MacSlow> seb128, when did you last try upstream gdm?
[12:27] <pitti> MacSlow: right; did you check ck-lists-sessions? does it have one for you?
[12:27] <pitti> ck-list-sessions, rather
[12:28] <pitti> kirkland: ah, nevermind, it explains about the random passphrase; the dialog should explain that you don't need to know it and it's unlocked with yuor account passworrd
[12:28] <MacSlow> pitti, no that failed with the error "** (ck-list-sessions:8034): WARNING**: Failed to get list of seats: Launch helper exited with unkown return code 0"
[12:28] <pitti> a-haaa!
[12:28] <pitti> MacSlow: do you restart dbus at any time?
[12:29] <pitti> (the system dbus, in particular)
[12:29] <MacSlow> well sometimes...
[12:29] <pitti> and do you have console-kit-daemon running?
[12:29] <pitti> MacSlow: don't do that; you can't restart dbus without losing all your CK sessions
[12:30] <pitti> if you do, you have to restart consolekit as well, and restart gdm as well
[12:31] <MacSlow> pitti, in which order: console-kit, dbus, gdm?
[12:31] <pitti> kirkland: how difficult would it be to use the ecryptfs setup to encrypt yuor entire $HOME?
[12:31] <pitti> MacSlow: restart dbus, killall console-kit-daemon, restart gdm
[12:31] <pitti> MacSlow: but why do you need to restart dbus in the first place?
[12:33] <MacSlow> pitti, sometimes my script refuses to start gdm due to var/run/dbus/system_bus_socket not being accessable
[12:34] <MacSlow> pitti, I do not have to restart the console-kit-daemon manualy?!
[12:35] <pitti> MacSlow: no, it should get activated by /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service
[12:35] <pitti> just killing the current daemon should do
[12:36] <MacSlow> pitti, ehm... I should add I run all that on non-system-wide installed /opt/gdm-new on hardy still
[12:36] <pitti> MacSlow: that should be fine
[12:36] <MacSlow> I'll try that
[12:42] <asac> hmm ... any clue what i need to isntall in order to make apt-get update use https:// urls?
[12:42] <cjwatson> apt-transport-https
[12:42] <asac> thanks
[12:49]  * lamont wonders if there is something equivalent to a "graphing calculator" in the archive, or if he needs to teach his daughter how to use gnuplot
[12:50] <Treenaks> lool: gnuplot IS a graphing calculator! :P
[12:50] <Treenaks> uhr
[12:50] <Treenaks> lamont:
[12:50] <lamont> Treenaks: well, yes... OTOH, despite her years of debian-installer testing, daughter is rather a gui person
[12:50] <lamont> holy crap.  nearing a full decade since she did her first debian install.
[12:51] <pitti> how old is she then, 11? :-P
[12:51] <lamont> heh
[12:51] <soren> I was thinking 10 :)
[12:51] <lamont> just turned 16
[12:52] <MacSlow> pitti, while ck-list-sessions now did not spit out a warning like before, it just reported nothing (after I did the proper restarting of dbus, gdm and console-kit-daemon). But now I get "Failed to identify the current session: Unable to lookup session information for process 'yadda yadda'"
[12:52] <pitti> darn, I remember having a program which would automatically draw graphs nicely laid out, but I forgot which it was (years ago)
[12:53] <pitti> MacSlow: k-li
[12:53] <pitti> MacSlow: sorry, ignore that ^
[12:54] <pitti> MacSlow: hm, weird; if I call ck-list-session from a VT (which doesn't have a CK session) it still works
[12:54] <pitti> MacSlow: however, it sounds as if gdm failed to register a session for itself
[12:55] <pitti> MacSlow: you might use dbus-monitor --system to check whether gdm actually contacts consolekit with OpenSession() or OpenSessionWithParameters()
[12:55] <MacSlow> I try that
[12:57] <pitti> ScottK: clamav-base ships ./usr/share/doc/clamav-base/examples/main.cvd which is 1.5 MB (and daily.cvd which is 870 KB); maybe those should go into the -doc package?
[12:58] <seb128> wgrant: hi, around? your synaptic changes don't work correctly
[12:59] <wgrant> seb128: I be here.
[12:59] <wgrant> seb128: What about them doesn't work?
[13:00] <seb128> wgrant: after applying the g-s-d patch the options have no effect, ie when unchecking the enable option the touchpad still move the cursor
[13:00] <seb128> wgrant: and the double click on the touchpad do something where the option is not enabled
[13:00] <wgrant> seb128: You're running a recent synaptics driver?
[13:00] <seb128> dunno
[13:00] <wgrant> What does `xinput list-props "SynPS/2 Synaptics TouchPad"` say?
[13:01] <seb128> wgrant:
[13:01] <seb128> $ xinput list-props "SynPS/2 Synaptics TouchPad"
[13:01] <seb128> unable to find device SynPS/2 Synaptics TouchPad
[13:01] <wgrant> xinput list
[13:02] <wgrant> Find the Synaptics device, and list the properties on it.
[13:02] <wgrant> You must have it defined in your xorg.conf, so it will have a different name. But that's what this patch is meant to fix.
[13:02] <seb128> wgrant: http://paste.ubuntu.com/43038/
[13:02] <seb128> $ xinput list-props "Synaptics Touchpad"
[13:02] <seb128> X Error of failed request:  BadRequest (invalid request code or no such operation)
[13:02] <seb128>   Major opcode of failed request:  146 (XInputExtension)
[13:02] <seb128>   Minor opcode of failed request:  36 ()
[13:02] <seb128>   Serial number of failed request:  12
[13:02] <seb128>   Current serial number in output stream:  12
[13:02] <wgrant> Wow.
[13:03] <wgrant> Which version of -synaptics do you have?
[13:03] <seb128> wgrant:
[13:03] <seb128> ii  xserver-xorg-input-synaptics               0.14.7~git20070706-2.1ubuntu4              Synaptics TouchPad driver for X.Org server
[13:03] <seb128> let me upgrade ;-)
[13:03] <wgrant> Aha.
[13:03] <wgrant> Ancient. That would do it.
[13:04] <wgrant> If you had the recent g-c-c, you likely wouldn't see the Touchpad tab at all.
[13:04] <ScottK> pitti: IIRC clamav behaves rather unfortunately if those don't exist, so I think we'd need to then have clamav depend on the -doc package if we did that.
[13:04] <ScottK> Which would be rather counter productive.
[13:04] <pitti> ScottK: oh, if clamav needs them, they should be in /usr/share/clamav
[13:04] <ion_> tkamppeter: I’ll take a look.
[13:05] <pitti> ScottK: Debian policy mandates that you need to be able to rm -rf /usr/share/doc without ill effects
[13:05] <seb128> wgrant: right, the tab is not listed using the patched version
[13:05] <ScottK> pitti: Ah.  I missed that.
[13:05] <ScottK> pitti: I think you're right.  Let me look into it.
[13:05] <pitti> ScottK: ok, thanks a lot!
[13:05] <wgrant> seb128: Great. I suspect that it'll all work when you use a newer -synaptics.
[13:05] <ScottK> It needs A database, just not, I guess that one.
[13:05] <pitti> ScottK: I added one question to the clamav MIR bug, spamassassin and the plethora of perl modules are ok
[13:06] <pitti> ScottK: well, I guess it needs to ship a default signature db somewhere, and those files might be just that
[13:06] <ScottK> That's what I need to check.
[13:06] <jcristau> wgrant: there's still a bug though. the getprops request shouldn't be done if the server doesn't report a new enough XI version
[13:07] <ScottK> pitti: In the short term, I don't think we're space contrained on the server CD, so I hope that won't block approval.
[13:07] <ScottK> contrained/constrained
[13:07] <pitti> ScottK: no, it won't, but it still looks fishy
[13:07] <wgrant> jcristau: Is it not OK to just catch the error?
[13:07] <MacSlow> pitti, in the log produces by "dbus-monitor --system" nothing from gdm shows up when I start gdm up. Does it matter if dbus-monitor is started as non-root user?
[13:07] <wgrant> jcristau: It's xinput that's dieing, not the stuff that I wrote.
[13:07] <pitti> MacSlow: no, it works fine as normal user
[13:07] <pitti> MacSlow: that means that gdm does not attempt to get a CK session on its own
[13:08] <ScottK> pitti: Another consideration is that jdstrand has a lightly tested apparmor profile that we should decide about adding now or waiting for Intrepid +1.
[13:08] <pitti> MacSlow: you can compare the output with what you get if you do "ck-launch-session", wait a while, do ck-list-sessions within that subshell, and ctrl+d to leave the subshell (and temporary sessoin) again
[13:09] <pitti> ScottK: I see nothing wrong with shipping it; if you have doubts, ship it as an example or set it to complaint mode?
[13:09] <pitti> well, provided that it by and large works, of course
[13:10] <ScottK> I'd be tempted to ship it now and see if anyone screams.
[13:10] <ScottK> We can always drop it to complaint mode if there are problems.
[13:10] <pitti> 'zactly
[13:11] <jcristau> wgrant: yeah, probably an xinput bug then. but i'm not even sure the server reports xi 1.5 anyway, so..
[13:13] <wgrant> jcristau: I believe that our xinput is hacked to build without the very new XI, so it's not likely to be upstream's fault.
[13:13] <jcristau> wgrant: right
[13:15] <seb128> re
[13:15] <wgrant> seb128: Any better?
[13:15] <seb128> alright, installing the new synaptic broke my laptop now
[13:15] <wgrant> O_o
[13:16] <seb128> no, xorg seems to be crashing, I can't get to gdm, booting in recovery mode now
[13:16] <wgrant> Did you grab more X as well?
[13:16] <wgrant> Lovely.
[13:16] <seb128> no I didn't
[13:16] <seb128> I expect depends grabbing what is required
[13:16] <wgrant> As would I.
[13:16] <wgrant> I was thinking that the new X might be what killed it.
[13:17] <jcristau> not getting the new X is what killed it
[13:17] <seb128> I expect
[13:17]  * wgrant is glad to not have touched the driver.
[13:17] <jcristau> tjaalton: you need to bump debian/serverminver in xorg-server, as the driver abi was changed
[13:17] <wgrant> Much.
[13:17] <seb128> but it should really conflict or depends on something
[13:18] <seb128> great, switching to a VT doesn't work either
[13:19] <soren> zul: What's the deal with the xen libraries? Which to use and which to leave for dead?
[13:19] <ScottK> pitti: clamav MIR questions answered.
[13:20] <zul> soren: what about them?
[13:21] <soren> zul: We have both libxen3 and libxen3.1.
[13:21] <soren> zul: Is that intentional? If so, which am I supposed to use?
[13:21] <zul> libxen3.1 can be dropped and it should
[13:22] <soren> zul: Lovely.
[13:22] <lool> BenC: Hmm there's a foo branch in ubuntu-intrepid.git now
[13:22] <lool>  * [new branch]      foo        -> origin/foo
[13:23] <soren> zul: Could you take care of getting it removed?
[13:23] <zul> soren: yep
[13:23]  * soren hugs zul
[13:23] <zul> thanks..
[13:25] <tjaalton> jcristau: and rebuild the drivers?
[13:25] <seb128> jcristau, wgrant: this synaptic thing is nasty, xorg freezes when it loads the synaptic driver and that breaks VT switching too
[13:25] <tjaalton> seb128: you have dist-upgraded everything?
[13:26] <seb128> tjaalton: no, I just upgraded synaptic, the package depends and conflict should allow that to work
[13:27] <tjaalton> seb128: then upgrade xserver-xorg-core too
[13:27] <wgrant> They should, but they don't because we don't have enough people following strange upgrade schedules :P
[13:27] <seb128> tjaalton: trying to get some network back first so I can download it, connection to wireless from a VT is not trivial
[13:27] <seb128> anyway xorg should not just freeze
[13:28] <tjaalton> I thought every dev was running the daily intrepid :)
[13:28] <seb128> tjaalton: I'm back from holidays and dist-upgrade is going to take over an hour on this box, I just wanted to test wgrant's patch to sponsor it
[13:28] <tjaalton> seb128: ok, understood
[13:29] <tjaalton> I guess bumping the serverminver and rebuilding synaptics is enough
[13:29] <seb128> still you want to put conflicts to avoid that
[13:29] <seb128> that's a pretty bad experience
[13:29] <tjaalton> no-one complained so far
[13:29] <seb128> I do now ;-)
[13:29] <seb128> I can give you the versions I'm using if you want
[13:29] <seb128> it's basically intrepid which is 2 weeks old and current synaptic
[13:30] <tjaalton> no need, just rebuilding them should do
[13:30] <tjaalton> erm, should fix the dependencies
[13:30] <seb128> ok, dpkg -r xorg*synaptic gave me my xorg back
[13:30] <seb128> now I can log-in, connect to wireless and upgrade xorg too
[13:31] <tjaalton> cool
[13:31] <wgrant> If you have a mouse.
[13:31] <seb128> I have a mouse
[13:31] <seb128> and I've also a keyboard which I can use ;-)
[13:32] <seb128> ok, upgrading xserver-xorg-core worked, xorg is working when using the new synaptic now
[13:33] <tjaalton> great
[13:33] <wgrant> Excellent.
[13:34] <tjaalton> lunch->
[13:34] <seb128> wgrant: ok, your patch works now
[13:34] <wgrant> Has my g-s-d patch crashed yet?
[13:34] <wgrant> This is good.
[13:39] <seb128> MacSlow: hey, no I didn't try running the new gdm since the distro sprint, enough other things to do
[13:39] <MacSlow> pitti, for just trying ck-launch-session and ck-list-sessions I get this "Faield to get list of seats: Launch helper exited with unknown return code 0" again. The resulting log from dbus-monitor --system is even smaller
[13:39] <MacSlow> seb128, ok ... was just wonder if you did ... never mind then
[13:41] <jcristau> tjaalton: those using the property stuff, yes
[13:47] <seb128> wgrant: g-s-d and g-c-c uploaded
[13:47] <wgrant> seb128: Thanks!
[13:48] <seb128> wgrant: thank you for the work on those ;-)
[13:49] <kirkland> pitti: thanks for the feedback on the ecryptfs dialog...  i'll send cjwatson a patch today.  i wanted to update the verbage slightly too.
[13:51] <kirkland> pitti: as for encrypted all of $HOME, that was my original proposal at UDS, but it was shot down as being too ambitious for Intrepid; the compromise was an encrypted ~/Private, and revisit encrypted $HOME for Intrepid+1
[13:51] <kirkland> pitti: technically, there's a few things that would have to be done differently...  ~/.ecryptfs couldn't live there for boot strapping reasons
[13:52] <kirkland> pitti: an unmounted, encrypted public ssh key would make it hard to ssh in
[13:52] <kirkland> pitti: little things like that, we'd have to solve
[13:57] <wgrant> seb128: I couldn't stay away from the desktop forever.
[13:57] <seb128> wgrant: good to have desktop contributors ;-)
[14:05] <pitti> MacSlow_: ok, then something in your d-bus packages is really seriously brkoen
[14:06] <pitti> kirkland: right, good points
[14:17] <kirkland> pitti: if encrypted ~/Private is deemed as "successful" by the December UDS, I'd like to extend that work with perhaps encrypted $HOME, spending some time focusing on the bootstrapping issues
[14:20] <torkel> kirkland: is there any way to encrypt the entire directory (and its sub directories) instead of the individual files?
[14:20] <kirkland> torkel: that's basically how it works
[14:20] <kirkland> torkel: there is a mount-wide passphrase that is applied to everything below the mount point
[14:21] <kirkland> torkel: if you're asking, instead, if there's a way to obsfucate the filenames, upstream is working on it
[14:21] <kirkland> torkel: but that has tremendously bad performance implications
[14:24] <pitti> kirkland: shouldn't be worse than with complete LUKS disk encryption, should it?
[14:24] <pitti> you have to decrypt stuff with stat() and opendir() in both cases
[14:27] <torkel> kirkland: sorry for asking the wrong question, but yes obsfucating the filenames (or the entire directory) so that their real names are not revealed was what I was thinking about
[14:27] <kirkland> pitti: with ecryptfs, an "ls" operation does not involve decryption, and so that is very fast (dare I say as fast as non-encrypted?)
[14:27] <kirkland> torkel: right, so like I said, upstream is working on it
[14:28] <kirkland> torkel: pitti: the current approach the upstream kernel maintainer is taking is to use a single, symmetric key for all filename obsfucation per mount point
[14:28] <kirkland> torkel: pitti: one of the neat things about ecryptfs is that each file can be encrypted using different algorithms, keys, etc. as defined in their extended ACLs
[14:29] <kirkland> torkel: pitti: that's the decryption situation we'd want to avoid on doing a simple "ls"
[14:29] <kirkland> torkel: let me note one nice advantage of clear text filenames....
[14:29] <kirkland> torkel: it sure makes it easy to rsync backup your encrypted data to untrusted, offsite storage ;-)
[14:30] <pitti> seb128: hm, why doesn't shutdown/reboot from the logout menu doesn't quit the session any more? reboot/halt in a running session is certainly very bad, since programs cannot ask "save document" questions and the WM can't save the session?
[14:30] <pitti> kirkland: yep, granted
[14:31] <kirkland> torkel: pitti: all that said...  i think a reasonable solution with obfuscated filenames is underway and I would like to see it as an option too
[14:31] <seb128> pitti: not sure, mvo noticed that too and wrote it on http://bugzilla.gnome.org/show_bug.cgi?id=545123, seems an upstream bug to me too
[14:31] <pitti> seb128: ok, so it is a bug, not intended; good, thanks
[14:31] <pitti> (wrong bug#?)
[14:32] <pitti> slangasek: rock, thanks for PAMifying the consolekit package
[14:32] <seb128> pitti: no, read the comments
[14:32] <seb128> "That looks correct, the logout-request signal gets send, but it seems like it
[14:32] <seb128> is not acted upon. Should I file a seperate bug about this?
[14:32] <seb128> "
[14:36] <pitti> ah, I see
[14:37] <pitti> seb128: ATM I'm tempted to reinstate the upstream consolekit reboot thing, for testing and having something that works until we come up with something better
[14:37] <pitti> seb128: WDYT?
[14:37] <seb128> pitti: I've been arguing for that since before your holidays ;-)
[14:40] <seb128> pitti: and yeah, I think it's time to get those actions fixed in intrepid, whatever is the way used
[14:40] <seb128> hey tedg
[14:42] <tedg> Morning seb128
[14:48] <mdz> argh
[14:48] <mdz> drwxr-xr-x 15 hplip lp 4096 2006-07-27 02:30 /var
[14:48] <mdz> did that happen to anyone else?  I remember older bugs where hplip was changing permissions on /
[14:49] <pitti> mdz: fine here (root:root), but then again I uninstall hplip right after a fresh ubuntu install
[14:49] <mdz> pitti: both times that I've seen it, I panic and chown it before I think to check the ctime
[14:50] <mdz> the only thing remaining owned by hplip is /etc/ptal
[14:50] <mdz> which isn't owned by any package
[14:50] <mdz> and is from 2005.
[14:50]  * mdz deletes
[14:50] <pitti> brb
[14:52] <tedg> So is there a "right way" to add icons to a package?  I know that the diff can't include binaries, so I was told I need to base64 them...  dh_?
[14:52] <tedg> Anyone know a package that does this so I can steal some debian/rules code?
[14:53] <ion_> tedg: I’d use sng. It’s in universe, though.
[14:54] <tedg> ion_: Hmm, interesting -- but this package is in main.
[14:55] <ion_> Then might as well use base64, presuming nobody feels like getting sng to main. :-)
[14:57] <tedg> I'm thinking about base64 encoding an entire tar file, that way I only have to deal with that once.
[14:59] <cjwatson> tedg: uudecode is the usual approach; look for build-dependencies on sharutils
[14:59] <seb128> dholbach: can you look at bug #261017?
[14:59] <dholbach> seb128: in a bit, in a meeting right now
[14:59] <seb128> dholbach: alright
[15:00] <dholbach> seb128: opened in the browser and will check it in a bit of time - thanks
[15:00] <cjwatson> tedg: browser-history is an example I'm familiar with
[15:00] <cjwatson> nothing magic about the make rules though, lay it out however you're comfortable with; it's just a one-liner
[15:01] <cjwatson> I think it might be more conventional to have an explicit target for the generated file, but I was young and foolish when I did that
[15:01] <cjwatson> tedg: grep-dctrl -nsPackage -FBuild-Depends,Build-Depends-Indep sharutils /var/lib/apt/lists/*_Sources | sort -u
[15:01] <mterry> Keybuk: Can you talk to me about the current blockers for the usplash-until-desktop blueprint?  (https://blueprints.launchpad.net/ubuntu/+spec/usplash-until-desktop)
[15:02] <Keybuk> mterry: kernel mode setting
[15:02] <mterry> Keybuk: Sigh.  Is that available in any drivers right now?  (like, say, intel)
[15:02] <Keybuk> not in any stable fashion
[15:03] <Keybuk> basically until we have that, X must be started from a text console
[15:03] <tedg> cjwatson: Cool, thanks I'll start looking.
[15:03] <tedg> If "broken" is a mode, we have kernel mode setting 100% :)
[15:04] <mterry> Keybuk: OK.  I was looking into trying to start X on a different VT, so that we could at least avoid the "brown screen" until the login screen was available
[15:04] <mterry> Keybuk: But I ran into difficulties (the graphics driver wanted to take over the screen).  Do you know technical details about solving that?
[15:05] <tjaalton> better to ditch usplash and start using plymouth for intrepid+1
[15:06] <siretart> what's the procedure for nominating a contributer upload access for a specific package in universe? mail the technical board?
[15:09] <cjwatson> siretart: I believe so
[15:31] <slangasek> pitti: sure thing :)
[15:39] <didrocks> BenC: around?
[15:40] <BenC> didrocks: yep
[15:41] <didrocks> Hi ;) I have been working on removing the multiuser tag on some packages for calling /etc/init.d scripts
[15:41] <didrocks> one example is the nvidia-common-kernel package (#254264) which has been fixed in upstream
[15:42] <didrocks> hum, bug #254264
[15:42] <didrocks> So, after having talked to many person, everyone telling me to talk to another person (an amazing trip), tseliot told me to get in touch with you
[15:43] <didrocks> apparently, this doesn't need a FFe (from the previous discussion I had)
[15:44] <didrocks> and I would like to know how to get those (6 packages) sponsored (if everything all right for you) in intrepid
[15:46] <pitti> slangasek: good morning
[15:49] <seb128> lool: does python-dbg -c "import gobject" work for you?
[15:53] <didrocks> BenC: well, I will be away for 2 hours approximately. You can respond here when you will have time. I will backlog at my return. Thanks :)
[16:01] <siekacz> is it possible, that Wall Light theme will be implented in 8.10?
[16:01] <_MMA_> siekacz: No.
[16:02] <_MMA_> siekacz: A better place to chat about this is #ubuntu-artwork.
[16:08] <lool> seb128: Nope
[16:08] <lool> seb128: I saw this yesterday during my debug session as well but forgot about it later
[16:08] <seb128> lool: ok, it seems to want to import apt_pkg, which is weird
[16:09] <lool> seb128: It's because of the apport hook
[16:09] <seb128> lool: that breaks applications build btw
[16:09] <seb128> ah
[16:09] <seb128> hum
[16:09] <lool> The actual error is ImportError: could not import glib (could not find _PyGLib_API object)
[16:09] <seb128> alright, makes sense
[16:09] <seb128> maybe worth pinging doko about it
[16:10] <seb128> I've no real clue about python-dbg
[16:11] <lool> seb128: Looks like we're missing a _hobject_d.so
[16:11] <lool> err _gobject_d.so
[16:12] <doko> seb128: did you make progress with the python-gobject build, or should I look again?
[16:12] <seb128> doko: lool fixed it
[16:12] <doko> ahh, ok
[16:12] <lool> Fatal Python error: UNREF invalid object
[16:12] <lool> zsh: abort (core dumped)  python-dbg
[16:12] <lool> cough
[16:20] <cjwatson> kirkland: reminder about asking for more info on bug 33649, since it seems you've tested that now
[16:21] <kirkland> cjwatson: yes, so based on my testing, i opened a bug, submitted a patch for grub, which kees sponsored last night
[16:21] <cjwatson> right, I noticed that bug but it had already been merged by the time I saw it
[16:21] <kirkland> cjwatson: just an fyi, he asked for a debdiff; i have a bzr branch that you might want to merge/resolve
[16:22] <kirkland> cjwatson: i'd like to test a new cd image with that grub patch on it, to see if it solved the issue that I saw
[16:23] <kirkland> cjwatson: once i do that, and i'm satisfied with my testing of grub/33649, i was then going to mark as "Fix Released" again, and ask for more infor
[16:24] <cjwatson> kees: debdiff for something where a bzr branch existed? you could use the LP UI if you just wanted to look at it ...
[16:24] <cjwatson> ok
[16:25] <jawub> Hi, for school I have to do some work on a open source project (which is very cool :). I'm really interested in usability and interaction design so I'd like to do some usability testing for a ubuntu project. I'm currently thinking about testing the ubuntu website. Who do I have to contact?
[16:27] <kirkland> jawub: newz2000 is the webmaster
[16:27] <jawub> hmm not online on irc. Thank you
[16:41] <kees> cjwatson, kirkland: I had wanted a source.changes because I'm lazy.  ;)  Also, I already merged the branch into the grub bzr tree.
[16:52] <BenC> didrocks: kernel team doesn't maintain nvidia drivers anymore...
[16:53] <lool> ScottK: bug #229845: python-kde3-dev still uses the wrong path here
[16:54] <lool> ScottK: Hmm the fact looks reversed?
[16:54] <lool> *patch
[16:59] <jpds> seb128: Could you possibly sponser a package to Debian for me? (pidgin-facebookchat)
[16:59] <tseliot> BenC: I have never touched nvidia-kernel-common furthermore I have no upload privileges therefore I suggested didrocks to talk to you. Can either someone from the kernel team or a core-dev have a look at didrocks' patch, please?
[17:00] <seb128> jpds: no, my debian disk doesn't boot due to hdd issues so I've no current debian unstable install I can use to do builds and testing
[17:00] <ScottK> lool: I'll have a look at it.
[17:00] <seb128> jpds: and I've already way too much to do
[17:00] <pitti> kees: ugh, it almost seems that the "set -m" "logsave fsck &" "set +m" sequence in checkroot.sh doesn't work any more; the script simply terminates after the "logsafe fsck"
[17:00] <jpds> seb128: OK; I shall look for someone else.
[17:01] <kees> pitti: erf.
[17:01] <kees> pitti: I still think it should be possible to pass an env var around with the pid.
[17:02] <pitti> kees: I added set -x and echos after every line
[17:02]  * kees nods
[17:02] <kees> pitti: so you were able to reproduce it, I take it?
[17:02] <pitti> and there is no output any more after the fsck call; I do see the output from fsck itself
[17:02] <ogra> cjwatson, bug 264048 might affect the liveCD
[17:02] <pitti> kees: yes, I set up a vm with /usr, /tmp/ and /scratch on separate partition, and tune2fs -C 50'ed them
[17:02] <ogra> seems aufs has a prob with mmap
[17:02] <pitti> kees: VMware snapshots FTW :)
[17:03] <kees> pitti: heh
[17:03] <pitti> kees: checkfs.sh starts immediately afterwards, and in the end I have /usr not mounted, and logsave still running
[17:04] <kees> pitti: yup, that's certainly it.
[17:04] <cjwatson> ogra: oh, interesting. I'll try it
[17:04] <cjwatson> funnily enough, unionfs had what sounds like a nearly identical problem some time back
[17:04] <kees> pitti: I saw this post on the debian planet: http://kitenet.net/~joey/blog/entry/human_nature/ :)
[17:05] <ogra> the hang i reported with ls was caused by the hanging apt-get though
[17:05] <didrocks> BenC, tseliot: and there are some more in addition to #254264 (#254249,#254252,#254257,#254259). All related to removing multiuser. I am contacting a lot of persons and everytime everybody agrees with this change (as it has been first requested by james_w in server team), but it is still waiting for sponsoring (getting tired :)). Don't know to who the right person to speak with!
[17:05] <BenC> tseliot: you seem to have done an upload before...do you just want to have someone sponsor it?
[17:05] <cjwatson> ogra: bug 144001
[17:05] <BenC> tseliot: I'm neck deep in some other things at the moment
[17:05] <pitti> kees: heh
[17:06] <cjwatson> in that case it was a failure rather than a hang
[17:06] <pitti> kees: with bash it does the same; WTH...
[17:06] <BenC> tseliot: if you can get it prepared, I'll sponsor it
[17:07] <tseliot> BenC: ok, thanks
[17:07] <ogra> cjwatson, oh, thanks ... i had seen that before but didnt make the connection :)
[17:08] <ogra> cjwatson, hmm, but thats unionfs
[17:08] <cjwatson> 17:04 <cjwatson> funnily enough, unionfs had what sounds like a nearly identical problem some time back
[17:09] <cjwatson> I was just clarifying that
[17:09] <ogra> ah
[17:09] <ogra> sorry, missed that ... i'm jumping channels with -mobile atm
[17:09] <lool> doko: Hey
[17:10] <cjwatson> so the hang is on the rename()?
[17:10] <doko> lool: here!
[17:10] <lool> doko: When code does PyImport_ImportModule(), does it have to be patched to use _d instead to work with python-dbg?
[17:10] <ogra> cjwatson, thats where strace gets stuck, yes
[17:10] <cjwatson> lool: why do you think mmap is to blame? the thing that's being rename()d when it hangs doesn't seem to have been previously mmaped
[17:10] <cjwatson> ogra: I wonder if it's reproducible with mv
[17:11] <lool> cjwatson: Because the process is hung in a mmap
[17:11] <ogra> well, lool was referring to something from the aufs docs where it tlaked about mmap2
[17:11] <cjwatson> rename() is not very simple in a union filesystem; it has a whole C file all to itself
[17:11] <cjwatson> lool: really, is strace lying?
[17:12] <lool> Hmm refreshes his memory and looks at the strace again
[17:12] <cjwatson> ogra: did ls /var/lib/apt/lists/ reproduce the problem *before* running apt-get update?
[17:12] <cjwatson> I suspect that once you hit the problem all sorts of things will break, but that doesn't mean they would trigger it to start with
[17:12] <ogra> no, only *while* it was hanging stuck
[17:12] <lool> cjwatson: No, it's me not able to use Launchpad
[17:12] <cjwatson> i.e. the directory is now buggered
[17:12] <alex-weej> RGBA anti-aliasing has regressed in Intrepid as of a few days ago - it appears as if we've dropped the FIR patches that we picked up a couple releases ago
[17:12] <cjwatson> lool: oh, you were confused by the read more...
[17:12] <lool> cjwatson: Yes
[17:13] <ogra> next time i'll do an attachment :)
[17:13] <lool> How stupid
[17:13] <persia> It's not reproducible with mv (or wasn't for me, using the same files)
[17:13] <lool> I suspect I'm slightly lacking sleep
[17:13] <cjwatson> a very slow and tedious approach would be to write a series of C programs to basically bisect the syscall list you get from strace
[17:14] <lool> Yeah I first asked for a mmap() test case
[17:14] <cjwatson> also, is there anything in the kernel log, like an oops?
[17:14] <persia> Unfortunately not.
[17:14] <ogra> ogra@osiris:~$ cat /var/log/kern.log|wc -l
[17:14] <ogra> 19
[17:14] <ogra> ERR !
[17:15]  * ogra is confused
[17:15] <ogra> where is my kern.log ?
[17:15] <ogra> last entry from aug 31st
[17:16] <ogra> nothing in dmesg at least
[17:16] <Treenaks> ogra: your kernel didn't have anything to say?
[17:17] <ogra> Treenaks, yeah, apparently ...
[17:17] <ogra> since i updated to 2.6.27-2-generic
[17:17] <ogra> -1 seems to have done logging until sunday
[17:18] <ogra> but dmesg should have the oops which it doesnt
[17:18] <Treenaks> ogra: are your log daemons running?
[17:18] <ogra> [  105.118542] loop: module loaded
[17:18] <ogra> [  105.342986] squashfs: version 3.3 (2007/10/31) Phillip Lougher
[17:18] <ogra> [  105.424975] aufs test_add:375:mount[9920]: uid/gid/perm /tmp/squashfs 0/0/0755, 0/0/01777
[17:18] <ogra> Treenaks,
[17:19] <ogra> ogra@osiris:~$ ps ax|grep klogd
[17:19] <ogra> 17156 pts/0    S+     0:00 grep klogd
[17:19] <ogra> obviously not
[17:19] <cjwatson> it might of course not actually be an oops
[17:20] <asac> cjwatson: bug #263668 needs a punch
[17:20] <asac> ;)
[17:20] <ogra> hmm ... sudo /etc/init.d/sysklogd start doesnt actually give me a klogd process
[17:20] <ogra> thats weird
[17:21] <ogra> though i get a rinning syslogd
[17:21] <ogra> *running
[17:22] <ScottK> lool: Looks like I fixed it for python-kde3, but not python-kde3-dev.  Thanks.
[17:23] <ogra> seb128, you are the NEW master today ?
[17:24] <seb128> ogra: theorically yes, in practice I've way too much to do and will probably not clean everything which is there, anything special you need to get accepted there?
[17:24] <asac> ogra: https://wiki.ubuntu.com/ArchiveAdministration ... according to that yes.
[17:25] <seb128> oh reminds me I wanted to sync swfdec0.7
[17:25] <ScottK> That or I messed it up completely.  I'll get it fixed up after Alpha 5 is out.
[17:25] <asac> seb128: wait
[17:25] <asac> seb128: there is a sponsoring bug
[17:25] <ogra> seb128, i'd like to see the apps from bug 263493 going through soon (modulo netbook-remix-launcher) they all had REVU peer reviews already so should be an easy wave through thing
[17:25] <asac> seb128: and there are "diffs"
[17:25] <asac> seb128: the bug is ready
[17:25] <seb128> asac: I know, I asked you to look at that weeks ago
[17:25] <asac> seb128: it just needs a FFe
[17:26] <lool> seb128: Ok, I think I grasp the pygobject byg
[17:26] <seb128> asac: but since nothing is happening I was going to sync 0.7 which is in debian experimental
[17:26] <seb128> lool: cool
[17:26] <ogra> seb128, but if you dont make it i see tomorrow is "Anyone" day ... so i can wait 24h
[17:26] <asac> seb128: its ready. bug 254841
[17:26] <seb128> asac: no need, that's GNOME
[17:26] <seb128> ogra: ok, will have a look later
[17:27] <asac> seb128: didnt know that. then we can just upload those bit
[17:27] <lool> seb128: the new libpyglib calls into the python module API and needs to be built with python-dbg; the "find debian/python-gobject-dbg ! -type d ! -name '*.so' | xargs rm -f" snippet silently removes the actual shared library built for python-dbg
[17:27] <lool> Then we happily mv the .so which is just a symlink to the lib which is no more to _d.so
[17:27] <seb128> asac: well, rather it's required for swfdec-gnome which is a GNOME component so about the same, just upload ;-)
[17:27] <asac> seb128: ok. will do that now
[17:27] <seb128> lool: ah I see
[17:27] <lool> Both packages can be installed at the same time, and we load the regular lib instead of the _d one
[17:27] <seb128> asac: thanks
[17:28] <seb128> lool: so we would need another set of library for debug builds?
[17:28] <lool> seb128: I also suspect that even if we fix this we're going to be hit by stuff being linked to this lib
[17:29] <seb128> lool: hum, what do you suggest then?
[17:29] <lool> I'm not sure
[17:29] <seb128> doko: ^
[17:29] <lool> seb128: The problem is that other things are going to be linked to that
[17:30] <doko> lool, ohh sorry, did miss your message
[17:30] <lool> doko: Do you have a library package in mind which uses python API and provides a shared library and is built with python-dbgN
[17:31] <lool> doko: Basically new pygobject python extensions are linked to a new shared library (which upstream installs in /usr/lib, I moved to /usr/lib/pygobject/pythonX.Y)
[17:31] <doko> lool: no, subversion was such a case, but it doesn't server as an example
[17:31] <lool> doko: The problem is that the actual extensions have an ELF link to pyglib.so.0
[17:31] <doko> lool: did you use my pygobject package, or did you start with seb128's?
[17:32] <lool> doko: I started from scratch again and glanced at your packages
[17:32] <doko> then why not change that ELF name?
[17:33] <lool> doko: They intend to make other packages link against it too
[17:33] <doko> imo, these should live in /usr/lib, or else you will have to work with rpath, won't you?
[17:34] <lool> doko: The problem is that I needed a lib per python interpreter
[17:34] <doko> the default name still could be a symlink to the upstream name
[17:34] <doko> correct, I did rename these libs
[17:34] <lool> So I've put the libs below /usr/lib/pygobject/pythonX.Y; but I proposed upstream to either do that or use /usr/lib/libpyglib-pythonX.Y.so
[17:35] <lool> They seem to prefer the latter, but didn't implement anything yet
[17:35] <lool> I sued my first patch which was to use /usr/lib/pygobject
[17:35] <ogra> you sue your patches ?
[17:35] <ogra> evil :)
[17:35] <lool> I guess I could have a /usr/lib/pygobject/python2.5-dbg
[17:36] <lool> Right, that would work
[17:36] <lool> doko: Ok; I think I know how to defer the problem until upstream decides which they want :)
[17:37] <doko> lool: yes, the latter sounds fine. then we still have the problem of building the debug library. but that should be solvable as well
[17:38] <lool> Hmm what problem of building the debug library?
[17:38] <asac> seb128: hmm ... i reconsidered my assumptions. please sync swfdec; the changes we need need to go into swfdec-mozilla only.
[17:38] <seb128> asac: ok will do, thank you for looking at it ;-)
[17:38] <asac> seb128: ill do the swfdec-mozilla merge now
[17:39] <seb128> asac: thanks
[17:39]  * norsetto hugs asac
[17:40] <lool> doko: What problem of building the debug library?
[17:40] <kirkland> cjwatson: btw, i've been meaning to thank you for doing the user-setup hooks for ecryptfs-setup-private!
[17:40] <kirkland> cjwatson: thanks!
[17:41] <doko> lool: if it doesn't need to be a separate build, that's ok as well
[17:56] <cjwatson> kirkland: oh, no problem
[18:10] <pitti> kees: gotcha!
[18:10] <pitti> \o/
[18:12] <kees> pitti: oooh! what was it?
[18:13] <pitti> fsck -C behaves differently now
[18:13] <pitti> before it would report "pass cur max"
[18:13] <pitti> now it reports "pass cur max device"
[18:13] <pitti> thus fsck_progress_to_percent() tried a division by something like "8 /dev/sda1"
[18:14] <pitti> which was considered a division by zero and thus the set -e'ed script aborts
[18:14] <pitti> I made it more robust now by using "read pass cur max tail"
[18:14] <pitti> so that it works with older and newer fscks
[18:14] <pitti> but the set -x output seems to lag badly
[18:14] <pitti> so that you seldomly even get that far
[18:23] <pitti> there goes my last milestoned bug \o/
[18:49] <lool> seb128, doko: I pushed a pygobject with pyglib for python*-dbg; it fixes python-dbg -c import gobject for me
[18:49] <seb128> lool: thanks
[18:50] <doko> \o/
[19:02] <balachmar> tkamppeter: I have a question about bug 258421 and was forwarded here. I followed the session of fixing bugs yesterday and this is one of the "low hanging fruit", but I am unsure if this patch is wanted. Partly because you are the only one in the bugreport. :)
[19:19] <lhnn> what sets -minimal, -standard, -desktop, etc., apart? As in, which packages are included in server/desktop version? And there is no -server meta package? P.S. if there is a page with this info, just link me to it instead of spending time answering >_>
[19:34] <lhnn> <_< Well, even if I leave, please answer the question, I'll be back later or check the IRC logs. thx.
[19:34] <persia> lhnn: The contents of the seeds.  Look up SeedManagement on the wiki.
[19:35] <lhnn> 10-4
[20:31] <tseliot> superm1: it looks like my patch for nvidia-settings was ignored: http://www.nvnews.net/vbulletin/showthread.php?t=118640
[20:34] <siretart> evand: you might want to subscribe to the package 'usb-creator'. I just tried it, see bug #264464
[20:38] <evand> siretart: thanks, will do
[20:44] <kees> slangasek: agh, sorry, I uploaded debianutils just now -- I had forgotten about the freeze.
[20:57] <tkamppeter> balachmar, the motivation for bug 258421 is that PDF should get the standard format foir print jobs
[20:57] <tkamppeter> balachmar, see the related blueprint.
[21:34] <CSX_Lappy> hi, i've got a problem with gnoem-commander
[21:34] <CSX_Lappy> at start (from console) it prints this:
[21:35] <CSX_Lappy> CRITICAL **: GnomeCmdConFtp* gnome_cmd_con_ftp_new(const gchar*, const std::string&): assertion `uri != NULL' failed
[21:35] <CSX_Lappy> then it work, till i try to add an ftp connection to the list ... when i click on the OK button it crashes with  "Segmentation fault"
[21:36] <CSX_Lappy> again this was printet just bevore the segmentation fault: CRITICAL **: GnomeCmdConFtp* gnome_cmd_con_ftp_new(const gchar*, const std::string&): assertion `uri != NULL' failed
[21:36] <CSX_Lappy> some ideas how i can fix it? reinstalling with purging and deleting of the config files didn't worked