[03:11] <slangasek> calc: yes, we ought to fix up that GPL violation; have you opened a bug on raptor in Ubuntu?
[03:12] <slangasek> mdke: split into per-language binary packages, yes - currently, gnome-user-guide is one of the 5 largest packages on the CD, and we could save a lot of that by splitting off the translations for languages that we don't ship on the CD (e.g., the large Swedish translation)
[03:23] <calc> slangasek: not yet, i will go ahead and do so
[03:24] <calc> slangasek: i noticed we don't change raptor, should i file the bug as a sync request?
[03:26] <UsamaAkkad> hello, if some one want to do minimal install cd for Mint or similar Ubuntu based distribution. what file should he change ?
[03:28] <calc> slangasek: i filed it as bug 351331 and linked to the debian issue
[03:28]  * calc wishes we could just get rid of openssl from the archive
[03:37] <TheMuso> hrm I just got a weird failure to upload with amd64 pulseaudio, twice, first after initial upload, and second after I retried the build, thinking it was possiby transient. All other arches built and uploaded successfully.
[03:40] <Hobbsee> TheMuso: looks like a launchpad error.  see #launchpad with https://launchpad.net/ubuntu/+source/pulseaudio/0.9.14-0ubuntu15/+build/923086
[03:40] <TheMuso> Hobbsee: ah ok
[06:14] <dholbach> good morning
[06:19] <robert_ancell_> dholbach: hi
[06:19] <dholbach> hey robert_ancell_!
[06:19] <dholbach> how are you doing?
[06:19] <dholbach> back at home?
[06:20] <robert_ancell_> dholbach: sure am
[06:20] <dholbach> ah great - how's life in .au? :)
[06:20] <robert_ancell_> dholbach: I miss the comfy chairs in the London office though :)
[06:20] <dholbach> hehe :-)
[06:21] <dholbach> must have been quite a trip - how long did it get you to get back?
[06:21] <robert_ancell_> dholbach: I left the hotel at 5:30am Saturday and got home at 9pm Sunday.  I think it's about 24 hours all up...
[06:24] <dholbach> robert_ancell_: ugh - it's a shame we don't have the technology for "beaming people over" yet
[06:24] <robert_ancell_> dholbach: I think there's a Canonical team working on that :)
[06:26] <dholbach> robert_ancell_: sounds like an idea only somebody who was in space already could have ;-)
[06:27] <robert_ancell_> dholbach: maybe that's the solution - you can travel faster when outside an atmosphere!
[06:28] <dholbach> robert_ancell_: so if the whole free software thing doesn't work out we all work as receptionists at the ticket counters or what?
[06:29] <robert_ancell_> dholbach: hehe
[06:52] <DaSkreech> calc: ping :)
[07:03] <dholbach> can somebody take a look at bug 350344 from the sponsoring queue?
[07:08] <DaSkreech> How many packages are in main ?
[07:10] <dholbach> DaSkreech: http://paste.ubuntu.com/140542/
[07:11] <dholbach> errr
[07:11] <dholbach> http://paste.ubuntu.com/140543/
[07:11] <DaSkreech> wow
[07:11] <dholbach> excusez-moi
[07:12] <DaSkreech> ok thanks :)
[07:12] <dholbach> the first one counted both sources and binaries
[07:13] <DaSkreech> Where did the 8 go to?
[07:15] <mdke> slangasek: that sort of thing is well beyond my packaging ability, but if it's not too late in the cycle, maybe someone else could do it
[07:16] <mdke> slangasek: the other potential solution would be to do what we do in ubuntu-docs and only ship translations which are over X% complete, and see if that reduces the size of the package
[07:16] <dholbach> DaSkreech: hm?
[07:17] <DaSkreech> dholbach: main kinda implies open source packages but adding the sources gets you less than double the number of packages
[07:17] <DaSkreech> you should have 8 more
[07:18] <dholbach> DaSkreech: no, main is what is supported by Canonical - it's not directly comparable to Debian's "main"
[07:18] <dholbach> http://www.ubuntu.com/community/ubuntustory/components
[07:19] <pwnguin> DaSkreech: you can have a source package generate more than one binary package...
[07:19] <DaSkreech> so it should be fun to track down what is in main which is not providing source
[07:19] <DaSkreech> pwnguin: like app and app-data ?
[07:19] <dholbach> DaSkreech: hu? everything in main does
[07:19] <dholbach> DaSkreech: yes
[07:20] <DaSkreech> not according to the numbers :-)
[07:20] <Mithrandir> DaSkreech: why do you think so?
[07:20] <Mithrandir> DaSkreech: can you find a single example of a package in main without corresponding source?
[07:20] <pwnguin> but you do have a point, if you have 6234 source packages, wouldn't you expect at least 6234 binaries?
[07:21] <DaSkreech> well if you have a number of binary packages each which has at least one source package
[07:21] <DaSkreech> then you should have twice the packages when you have binary and source
[07:21] <pwnguin> you know
[07:21] <DaSkreech> there is less than that
[07:21] <pwnguin> if you have a source package that builds universe and main binaries
[07:22] <pwnguin> does it go in universe or main?
[07:22] <Mithrandir> DaSkreech: no.  Each source package has at least one binary package (but often more).  Never the other way around, a binary package never has two sources.
[07:22] <Mithrandir> pwnguin: main.
[07:22] <pwnguin> Mithrandir: then obviously dholbach's cache is broke ;)
[07:22] <DaSkreech> Mithrandir: it still doesn't detract from my argument
[07:23] <dholbach> pwnguin: I'm happy with my cache right now :)
[07:25] <Mithrandir> > wget -q -O - http://archive.ubuntu.com/ubuntu/dists/jaunty/main/source/Sources.bz2 | bzip2 -d | grep -c ^Package
[07:25] <Mithrandir> 3024
[07:26] <Mithrandir> > wget -q -O - http://archive.ubuntu.com/ubuntu/dists/jaunty/main/binary-i386/Packages.bz2 | bzip2 -d | grep -c ^Package
[07:26] <Mithrandir> 6151
[07:26] <Mithrandir> so you have around 3k sources generating about 6k binary packages.
[07:27] <Mithrandir> pwnguin: dholbach only counted binary packages, nowhere did he count sources?
[07:28] <pwnguin> (well he claimed he did, and i was foolish enough to trust him ;)
[07:29] <Mithrandir> DaSkreech: your argument is the wrong way around, since you start by counting binary packages, not source packages.  You'll have at least the same number of binary packages as source packages, not at least the same number of source packages as binary packages.
[07:30] <dholbach> pwnguin: in the first paste.u.c link I did
[07:30] <pwnguin> dholbach: well your numbers dont add up :P
[07:31] <DaSkreech> ah right
[07:31] <pwnguin> or i misread
[07:31] <DaSkreech> well I was only interested in binaries anyway :)
[07:32] <pwnguin> "packages" is too generic =(
[07:32] <pwnguin> Packages, i mean
[07:33] <DaSkreech> Looks so
[07:33] <pwnguin> you know what, it's like 1am. i should just sleep or something.
[07:35] <mdke> hi dholbach
[07:35] <dholbach> hiya mdke
[07:36] <mdke> dholbach: could you do me a favour and take a look at this bug in ubuntu-docs - https://bugs.launchpad.net/bugs/303578
[07:36] <mdke> dholbach: the cause of the bug is clear (comment 12) but I don't know how to fix it, any ideas?
[07:38] <dholbach> mdke: I don't know - could it be a CDBS thing? creating those symlinks?
[07:39] <mdke> dholbach: the problem is that in previous releases we shipped some symlinks in a particular location, and now we ship a directory - but dpkg doesn't remove the symlinks so people upgrading and missing that directory
[07:39] <mdke> dholbach: so we need to include something in the upgrade process that removes those symlinks
[07:40] <mdke> dholbach: the last comment has the commands required, I don't know how to put that in the package though
[07:40] <dholbach> mdke: sounds like something you'd do in the maintainer scripts - I'd ask for advice on ubuntu-devel@ - my experience with maintainer scripts is luckily somewhat limited
[07:40] <mdke> dholbach: ok, I'll do that, thanks
[07:41] <dholbach> mdke: good luck :)
[07:42] <pitti> Good morning
[07:42] <StevenK> Morning pitti
[07:42] <pitti> slangasek: kick bug-buddy> agreed, we don't use it by default anyway
[07:43] <pitti> kirkland: no, I used --remove-home, not --remove-all-files
[07:43] <pitti> kirkland: and semantically, /var/lib/ecryptfs/$user is really a part of your /home/$user, IMHO
[07:44] <pitti> hey StevenK, had a good weekend?
[07:45] <StevenK> pitti: Yup! You?
[07:46] <pitti> StevenK: pretty good too; just an hour shorter :) (DST change)
[07:48] <StevenK> pitti: Heh, the phone company's network time did that over the weekend
[08:12] <slangasek> mdke: my biggest concern would be splitting out the languages that *are* mostly complete :)
[08:13] <slangasek> pitti: ok; I guess seb128 is already poking at the gnome-desktop-python-desktop-2-gnome stuff, so I'll coordinate with him when he awakes
[08:13] <pitti> slangasek: right, he's working on it; thanks
[08:13] <slangasek> seb128: o hai
[08:13] <slangasek> damn :)
[08:14] <mdke> slangasek: yes, but as I understand your proposal, it would be to make gnome-user-docs consistent with the rest of the desktop, which is acceptable
[08:15] <mdke> slangasek: there's not much point in a particular language being included in gnome-user-docs if the rest of the desktop is untranslated by default for that language
[08:15]  * slangasek nods
[08:15] <mdke> slangasek: ditto ubuntu-docs, and yelp itself
[08:16] <mdke> (I don't know if yelp ships translations or has them in language packs)
[08:16] <mdke> ah, it ships them in the package
[08:16] <slangasek> pitti: ^^ what do you think, splitting gnome-user-docs by language?
[08:18] <pitti> makes sense, of course, I just wished it wouldn't require manual packaging
[08:18] <pitti> but the automatic one depends on a small soyuz feature which isn't there yet :(
[08:20] <mdke> do you think we should do the same for ubuntu-docs?
[08:21] <slangasek> mdke: that's less of low-hanging fruit
[08:21] <seb128> that would win us lot of CD space for extra locales for sure
[08:21] <slangasek> so I wouldn't have us spend the effort yet
[08:23] <mdke> slangasek: ok, I was just thinking for consistency. Maybe for the next release cycle
[08:23] <slangasek> for the next release cycle, maybe the automation pitti mentions will be available :)
[08:24] <mdke> ok, I'll keep an eye out
[08:24] <mdke> gtg
[08:26]  * slangasek sees that gnome-user-docs bzr uses a separate branch for each distroseries, wah
[08:26] <slangasek> that would be fine, if debian/control didn't currently point to the hardy branch :)
[08:26] <pitti> seb128: can you ssh to ronne? hangs for me
[08:27] <pitti> I'd like to fix the retracers
[08:29] <seb128> pitti: hangs too
[08:29] <pitti> seb128: ok, thanks; I'll talk to IS
[08:36] <slangasek> pitti: bug #277589 reopened, looks like there's a bug in my attempted refactoring of the user-submitted patch :(
[08:39] <slangasek> mdke: should ubuntu-core-dev be a member of ubuntu-core-doc?
[08:45] <superm1> slangasek, that reminds me, i wanted to ask what happened to the rest of getting rid of hotkey-setup? looks like a few thinkpad related bits in there still and that flip on the xorg stuff are left
[08:49] <slangasek> superm1: the remaining thinkpad bits need to wind up as a udev rule, I guess, with the init script disabled by default if we've made it to that point; I meant to talk to thinkpad_acpi upstream (a DD), because he claimed recently that there were no thinkpads left that needed thinkpad_keys
[08:52] <superm1> slangasek, ah. so likely better to get that taken care of during early karmic then
[08:52] <superm1> and the DOS switching needs to be checked why those defaults aren't set in the kernel module yet too then
[08:53]  * slangasek nods
[09:00] <pitti> lamont: the patch in bug 348990 makes sense to me; do you want to apply it to Debian and sync, or should we apply it locally to Ubuntu?
[09:08] <slangasek> mdke: also, are there specific known reasons why you're still using pack-0.92 format for gnome-user-docs instead of something newer (and speedier)?
[09:09] <pitti> it would perhaps help if "bzr upgrade" wouldn't consider pack-0.92 as "current"
[09:17] <tkamppeter> mvo, doko, you are the Python maintainers? Can you have a look at bug 349781?
[09:19] <tkamppeter> mvo, it seems that only the i386 build server produces broken builds of Python libraries written in C.
[09:21] <dholbach> tkamppeter: that bug should be fixed since python2.6 2.6.1-1ubuntu5.1
[09:21] <dholbach> tkamppeter: bug 349467
[09:21] <dholbach> tkamppeter: it looks like a dup AFAICT
[09:22] <slangasek> yes
[09:24] <dholbach> "Running sudo perl -p -i -e 's/PyUnicodeUCS2/PyUnicodeUCS4/g' /usr/lib/python2.6/dist-packages/cupsext.so does indeed fix the problem."
[09:25] <slangasek> if editing is required, then that means we need to get that package rebuilt in the archive
[09:31] <dholbach> slangasek: I think infinity said there was just python-hildon on lpia rebuilt with that pytho
[09:38] <Keybuk> mvo: I had a fantastic bug with the dist-upgrader today
[09:39] <Keybuk> the only thing it did to upgrade me to 9.04 was uninstall nvidia-glx
[09:40] <mvo> Keybuk: with the partial upgrade?
[09:41] <Keybuk> mvo: no
[09:41] <Keybuk> turns out I had jaunty in my sources list pinned to "not upgrade"
[09:43] <seb128> cjwatson: hi
[09:43] <mvo> Keybuk: could you pastebin me your /etc/apt/preferences file please?
[09:43] <Keybuk> Package: *
[09:43] <Keybuk> Pin: release a=jaunty
[09:43] <Keybuk> Pin-Priority: -50
[09:43] <Keybuk> --
[09:43] <seb128> cjwatson: we are getting several comments on bug #343668 now, the bbc server for the totem plugin is not working for some weeks
[09:44] <seb128> cjwatson: do you think you could try to ping the bbc guys about that?
[09:46] <mvo> Keybuk: ok, thanks
[09:48] <slangasek> dholbach: then infinity's analysis is incorrect; http://launchpadlibrarian.net/24396323/buildlog_ubuntu-jaunty-i386.hplip_3.9.2-3ubuntu2_FULLYBUILT.txt.gz clearly shows python2.6-minimal 2.6.1-1ubuntu5, the broken version.
[09:49] <slangasek> tkamppeter: a simple reupload of hplip is enough to fix this bug
[09:49] <YokoZar> Man, it's very frustrating upstreaming bugs in launchpad now.  I can't figure out how to do it by just copy/pasting the upstream bug link
[09:52] <pitti> YokoZar: "now"? the workflow didn't change recently AFAICS?
[09:53] <YokoZar> pitti: the links on the page seem broken to me
[09:53] <YokoZar> On non-beta launchpad I can click "also affects project" and just paste the link there when I click "I have the URL for the upstream bug"
[09:54] <YokoZar> on new launchpad it's "simplified" by forcing me to type in the name of the project first
[09:54] <YokoZar> Half the time I think I clicked the wrong thing, so I go to "Also affects distribution" which does have a URL for upstream bug reports I can copy paste, but when I do it there I get errors
[09:54] <pitti> YokoZar: that should only happen for packages which don't already have an associated project, hmm
[09:56] <YokoZar> I'm getting it on this bug (which already has an upstream bug task) https://bugs.launchpad.net/ubuntu/+source/wine/+bug/243390
[09:56] <YokoZar> affects Wine both Wine (Ubuntu)
[09:57] <directhex> binfmt, and associate directly with the application .exe!
[09:57] <YokoZar> directhex: the issue is mime types for data files, not the .exe
[09:58] <YokoZar> directhex: eg I install Photoshop and it says it can open .jpgs, but it's very hard to make it so double clicking a .jpg will open it in photoshop
[09:59] <directhex> YokoZar, i find file type association is a black art in general
[09:59] <YokoZar> Windows has it's own separate list for these sorts of file handlers, and Wine needs to glue that into our own file type thing.  Then the desktop environment needs to be taught how to understand it as well
[09:59] <directhex> tbh i think vista allows changing default filetype handlers really well
[09:59] <slangasek> YokoZar: you can only have one task per upstream project on a bug, so of course saying 'also affects' wants you to pick a different project?
[10:00] <YokoZar> slangasek: right, which is why I ran into this launchpad upstreaming issue because I wanted to link it to another upstream project (http://bugzilla.gnome.org/show_bug.cgi?id=379658)
[10:00] <YokoZar> launchpad doesn't want to figure out that's nautilus from just looking at the bug link
[10:00] <slangasek> it never has
[10:01] <slangasek> the cases where you don't have to fill out the upstream project are when it's already pre-populated the value for you
[10:02] <YokoZar> hmmm I think you might be right
[10:02] <YokoZar> I do still get confused by the upstream bug link on the "also affects distribution" page
[10:03] <YokoZar> because I keep mixing up which of these two I'm supposed to be clicking on (my normal metric was to guess and look for the place to paste a URL, which got broken here since I needed to manually add nautilus first)
[10:12] <tkamppeter> Thanks, dholback and slangasek, I will reupload HPLIP.
[10:12] <slangasek> tkamppeter: cool, thanks :)
[10:23] <\sh> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[10:23] <pitti> \sh: bless you
[10:29] <\sh> ôh damn....
[10:29] <\sh> I shouldn't clean my desk and putting papers on my keyboard ,->
[10:33] <\sh> but now...desk is clean and I can go on holiday without anybody complaining: "You desk is totally chaotic" ,->
[10:38] <pitti> \sh: enjoy your holiday!
[10:39]  * directhex tries an update in a pbuilder
[10:40] <\sh> pitti: hehe....waiting for the boy to come :)
[10:44] <\sh> pitti: hopefully he will be released with jaunty ,-)
[10:44] <pitti> oooh!
[10:44] <pitti> \sh: congratulations! *hug*
[10:45] <Keybuk> \sh: but will you name him Jaunty? :)
[10:45] <\sh> pitti: thx :)
[10:45] <Keybuk> Jaunty Hermann has quite a ring to it
[10:45] <Keybuk> (and congrats, btw :p)
[10:45] <\sh> Keybuk: when I can convince my wife to have "Jaunty" as third or fourth name...or much better as an official nickname (Artistname) then yes :)
[10:46] <\sh> Keybuk: lastname won't be "Hermann" :) I'll go for the last name of my wife to be :)
[10:46] <\sh> Keybuk: lastname will be a cameroonian lastname ... so it will fit into the "Ubuntu" story ;)
[10:48] <\sh> ok...lunch time :) bbl
[10:48] <tkamppeter> slangasek, dholbach, HPLIP is reuploaded now.
[10:48] <dholbach> tkamppeter: super
[10:48] <slangasek> @yay
[10:51] <cjwatson> seb128: I already did
[10:51] <cjwatson> seb128: I can mail them again (somebody else asked me about this too)
[10:51] <seb128> cjwatson: well, people start suggesting we stop shipping the plugin now
[10:51] <seb128> I'm not sure what to try
[10:51] <seb128> try -> reply
[10:52] <cjwatson> like I say, I'll mail them again
[10:52] <seb128> thanks
[10:55] <directhex> silly bbc. i pay my license fee dangnabbit!
[10:59] <Keybuk> ==17268== Conditional jump or move depends on uninitialised value(s)
[10:59] <Keybuk> ==17268==    at 0x40177B7: (within /lib/ld-2.8.90.so)
[10:59] <Keybuk> oh, yay
[11:08] <lamont> pitti: I'll make a pass through my bugs this week at some point
[11:09] <pitti> lamont: shall I assign it to you? (it's in the sponsoring queue ATM)
[11:12] <slangasek> Keybuk: ld's always had a few of those that are innocuous in practice, neh?
[11:12] <slangasek> ld.so, I mean
[11:13] <lamont> sure
[11:13] <pitti> slangasek: you are currently doing syncs? can I smuggle one in?
[11:13] <Keybuk> slangasek: yeah, I just hate it when valgrind is out of sync with them ;)
[11:13] <slangasek> pitti: yes
[11:14] <slangasek> Keybuk: ah, heh
[11:15] <slangasek> pitti: what are you smuggling in? I'm done with the sync bug list now, just about to hit flush
[11:16] <pitti> slangasek: I'm done (nano and postgresql-common)
[11:16] <slangasek> ok
[11:21] <directhex> yay @ slangasek
[11:22] <Keybuk> slangasek: it makes my test suite full of FAIL
[11:22] <slangasek> aww :(
[11:24] <Keybuk> 13 of 13 tests failed
[11:24] <Keybuk> Please report to http://bugs.launchpad.net/libnih/
[11:24] <Keybuk> :-(
[11:29] <ebroder> Can somebody mark bug #333197 as fix released in Jaunty and confirmed in Intrepid?
[11:29] <ebroder> (I can't do that without being on ubuntu-dev or something, right?)
[11:31] <apw> bryce, you about?  wanted to talk about those i914 drm '*ERROR*' messages we have been seeing
[11:31] <slangasek> perhaps he has the sense to not be up at 3:30
[11:32] <apw> heh as you prove, its always worth asking
[11:32] <slangasek> :-)
[11:35] <\sh> there needs to be an whois field on freenode..that shows the timezone of the user ,-)
[11:35] <broonie> \sh: No, that shows their sleep cycle. Timezone is not a reliable indicator!
[11:36]  * slangasek records his as a parametric equation
[11:37] <ogra> slangasek, what about daily builds, do you plan to enable them again at some point ?
[11:37] <\sh> broonie: ok...much better
[11:38] <slangasek> ogra: they are enabled, except for those cronjobs that involve livefs builds for ports because infinity was doing maintenance
[11:38] <ogra> ah
[11:38] <slangasek> infinity: can we re-enable the ports livefs cronjobs?
[11:38] <ogra> right, i was indeed wondering about http://cdimage.ubuntu.com/ports/daily-live/ :)
[11:46] <infinity> slangasek: We can, although the sparc buildd exploded on upgrade, so you'll either need to artificially disable sparc for now, or suffer with failures (should fail quickly with No Route to Host)
[11:46] <slangasek> suffering with failures is fine
[11:46] <slangasek> thanks
[11:46] <ogra> great
[11:47]  * ogra needs to see if oo.o finally ends up in the livefs ... having image builds is extremely helpful
[11:55] <pitti> mvo: are you going to upload a new synaptic soon? if not, I'd like to do a no-change upload for bug 348225
[12:03] <mvo> pitti: I can do that, let me check if I have anything else pending
[12:04] <pitti> mvo: I'm already test building, so if you don't have anything else, I'll just upload it
[12:04] <pitti> mvo: I didn't see UNRELEASED stuff in bzr
[12:06] <mvo> pitti: ok, I have a pending bug but no fix yet (and it might be a problem with apt-xapina-index) so just go ahead
[12:06] <pitti> mvo: ok, thanks
[12:10] <slangasek> pitti, ArneGoetje: how is language pack generation meant to handle non-ascii characters in description fields? :)
[12:10] <slangasek> e.g., language-pack-oc, language-pack-nb
[12:10] <bluszcz> hi, where I can read about ttf packaging policy?
[12:11] <pitti> slangasek: -nb works just fine? (Bokmål)
[12:11] <pitti> slangasek: oh, ugh
[12:11] <bluszcz> for debian there is: http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.5
[12:11] <bluszcz> and for ubuntu is the same?
[12:11] <pitti> slangasek: the (post 1500) is part of the description (year)
[12:11] <slangasek> bluszcz: the same policy applies, yes
[12:12] <slangasek> pitti: yes, but it's supposed to say "Provençal", not "Proven" :)
[12:12] <bluszcz> great
[12:12] <pitti> slangasek: WFM..
[12:12] <bluszcz> there is no word about TTF fonts
[12:12] <pitti> slangasek: where are you looking at this? perhaps a system without locales, such as the DC?
[12:12] <bluszcz> only speedo etc
[12:13] <slangasek> pitti: ah, yes, was testing in a chroot without locales
[12:13] <slangasek> pitti: looks fine in a real system; ok, I'll do the same thing in gnome-user-docs
[12:15] <slangasek> bluszcz: correct; that section of policy talks about "packages providing fonts for the X Window System", which is not the case for truetype font packages in general - it refers to a more-or-less obsolete font handling method
[12:15] <slangasek> bluszcz: for truetype fonts, I don't think there's any policy spelled out; the convention is to create a per-package directory under /usr/share/fonts/truetype, and use fontconfig
[12:15] <pitti> seb128: ronne is back, fixing retracers now
[12:16] <seb128> pitti: excellent
[12:23] <kwwii> cjwatson, pitti: if you have an encrypted disk, when does it ask for your password?
[12:24] <pitti> kwwii: some seconds after usplash starts
[12:25] <kwwii> pitti: does it switch back to text mode or does it do it in the usplash?
[12:25] <pitti> kwwii: it asks in usplash
[12:25] <pitti> in the text area
[12:25] <kwwii> wow, when was that implemented? nice
[12:26] <kwwii> thanks for the info
[12:26] <pitti> kwwii: I did that ages ago, somewhere around gutsy
[12:26] <pitti> I haven't used an encrypted disk since after hardy any more, though
[12:26]  * pitti hugs ecryptfs
[12:26] <kwwii> cool, I'm adding that to my use cases of the new boot experience
[12:26] <pitti> but we need to account for that case in plymouth, yes
[12:27]  * pitti -> lunch, bbl
[12:29] <slangasek> pitti: when you're back and have some time, I have a cdbs question for you
[12:31] <slangasek> pitti: regarding gnome-user-docs; what I want to achieve is to install all the docs in a single tree, run fdupes over them, and then split the files up by language into separate packages, but I have no idea what cdbs targets I need to use for this
[12:39] <seb128> slangasek: why not using .install for each locale?
[12:40] <slangasek> seb128: will that let us run fdupes?
[12:40] <seb128> slangasek: cdbs does fdupes for you
[12:40] <slangasek> across packages?
[12:40] <seb128> yes, it consider depends iirc
[12:41] <elmo> how often should I be seeing the 'software out of date' stuff?
[12:41] <elmo> I haven't gotten a notification since I upgraded to jaunty, and it's been 3 days now
[12:41] <seb128> elmo: is that a dialog?
[12:41] <slangasek> seb128: ok, let's see
[12:41] <seb128> elmo: security updates daily, normal updates weekly
[12:41] <slangasek> elmo: 7 days if there are no security updates
[12:41] <slangasek> :(
[12:41] <elmo> err
[12:41] <elmo> that's insane
[12:42] <seb128> elmo: and there is no notification icon anymore, just update-manager auto-opening
[12:42] <seb128> elmo: yeah, try to convince the design team they are sitting near to you ... ;-)
[12:42] <slangasek> well, unless you run 'gconftool -s --type bool /apps/update-notifier/auto_launch false'...
[12:43] <elmo> seb128: yeah, I'll speak to them about it; though I suspect I'll be redirected upwards
[12:43] <directhex> gah @ preinst woe
[12:43] <hyperair> i really don't see the point of the update-notifier change in behaviour if everyone's going to type that and disable the new behaviour
[12:43] <seb128> the assumption is that only geeks will do that
[12:44] <directhex> hyperair, change is exciting!
[12:44] <seb128> and that normal users don't want to be pressured daily about non urgent updates
[12:44] <elmo> can't we increase the frequency during beta at least?
[12:44] <hyperair> seb128: keyword is assumption.
[12:44] <slangasek> except we don't actually have non-security SRUs happening on a daily basis...
[12:44] <seb128> well you can't know before trying
[12:45] <hyperair> seb128: i don't know how many times i'm gonig to have to explain this stupid behaviour to new converts
[12:45] <seb128> so it can only be assumptions
[12:45] <slangasek> and people who are running the devel release ought to be getting the latest fixes
[12:45] <seb128> slangasek: right unstable series are a different case and we could tweak settings there
[12:45] <seb128> the design team focussed on experience for normal users on stable
[12:46] <slangasek> seb128: except it's not a different case, because as I said, we don't have non-security SRUs happening daily
[12:46] <seb128> well for sure you have updates less often
[12:46] <seb128> for the record I don't like the change
[12:46] <slangasek> I really don't think waiting 7 days before they're offered for installation makes sense
[12:47] <amitk> less often but much bigger updates
[12:47] <slangasek> and "you can't know before trying" --> "trial and error", yuck
[12:47] <seb128> I don't think they care much about the number of days
[12:47] <directhex> bah, for some god-unknown reason, i have a preinst that isn't running when it should be
[12:47] <mvo> elmo: there is the /apps/update-notifier/auto_launch to get the old behaviour back
[12:47] <seb128> what they have been wanting to change is the icon to auto-opening
[12:47] <mvo> elmo: gconf key I should add
[12:47] <seb128> and the delay is reaction to users complaining about the thing opening too often
[12:48] <seb128> mvo: <slangasek> well, unless you run 'gconftool -s --type bool /apps/update-notifier/auto_launch false'...
[12:48] <seb128> mvo: already mentioned ;-)
[12:48] <mvo> heh :)
[12:48]  * mvo is too slow
[12:49] <slangasek> seb128: what's the best cdbs target to use for auto-generating my .install files?
[12:52] <ebroder> slangasek: Probably install/$PACKAGE
[12:53] <Keybuk> right, time to reboot into jaunty
[12:54] <seb128> slangasek: what ebroder wrote
[12:55] <slangasek> I'll give that a try, thanks
[12:59] <Keybuk> ok, that's weird
[12:59] <Keybuk> ^C has stopped working
[13:00] <elmo> seb128: do I need to talk to the DX team about dropping the 'days between notification' stuff for beta too?
[13:01] <seb128> elmo: I'm not sure to understand the question, is beta a special case there in your opinion?
[13:02] <elmo> seb128: sure, because there are no security updates
[13:02] <elmo> seb128: firefox 3.0.8 went into jaunty proper
[13:02] <slangasek> seb128, ebroder: 'install/gnome-user-guide-%::', is that not what I want?
[13:02] <seb128> elmo: well then you mean unstable cycle
[13:02] <elmo> so I wasn't notified about it
[13:03] <seb128> elmo: beta is just a special case in the unstable cycle
[13:03] <elmo> seb128: sure, I guess so
[13:03] <ebroder> slangasek: Uh...I think that would run once for each gnome-user-guide-foo package
[13:03] <seb128> elmo: right ;-)
[13:03] <ebroder> slangasek: That may be what you want - use $@ to your advantage :)
[13:03] <slangasek> ebroder: which is what I'm trying to achieve; but it doesn't run at all
[13:05] <slangasek> AFAICS, it's only running the stock cdbs rule
[13:05] <seb128> slangasek: "stock"?
[13:06] <slangasek> seb128: if I call 'fakeroot ./debian/rules install/gnome-user-guide-da', I see 'dh_installdirs -pgnome-user-guide-da' printed but I don't see the output from the rule I've added in debian/rules
[13:06] <seb128> what if you debian/rules install?
[13:07] <slangasek> install-indep, you mean?
[13:07] <seb128> right
[13:07] <slangasek> checking
[13:07] <slangasek> yeah, same thing
[13:07] <seb128> otherwise you might want to try "binary-install/binary::"
[13:08] <slangasek> (and calling binary-indep didn't do it, so...)
[13:08] <slangasek> seb128: generating all the .install files in a single pass, then?
[13:08] <seb128> binary being your actual binary package name
[13:08] <slangasek> oh
[13:08] <slangasek> but I don't want to encode that list of binaries anywhere in debian/rules
[13:08] <slangasek> since it changes whenever upstream adds a translation
[13:09] <seb128> well binary-install/binary-%:: then
[13:10] <slangasek> still no
[13:10] <seb128> otherwise I guess just use "pre-build::" to generate all the .install
[13:10] <seb128> you are sure that's run once before build
[13:10] <seb128> if you have the list in the LINGUAS or similar
[13:11] <seb128> ie if you know the list before building
[13:11]  * slangasek nods
[13:11] <slangasek> find gnome2-*-guide/ -maxdepth 1 -type d ;)
[13:12] <ebroder> Blargh. What do I do with a bug that's fixed in Jaunty but I want to reopen for an SRU? Should I just mark it as confirmed and let someone who actually has the right bits juggle the state between Jaunty and Intrepid?
[13:12] <slangasek> ebroder: target it to the release if you can; if not, subscribe ubuntu-sru
[13:13] <ebroder> slangasek: Who can target bugs? motu?
[13:14] <ebroder> (It's a universe package)
[13:14] <slangasek> ebroder: motu should be able to, yes.
[13:14] <ebroder> Ok. But if I can't, I just leave the bug closed?
[13:15] <slangasek> ebroder: hmm, I guess in that case you'll need to reopen it after all to get any attention on it
[13:15] <pitti> slangasek: I'd just use dh_install, but you can also create a programmatic install rule in install/<pkgname>:: or common-install-indep::
[13:16] <ebroder> slangasek: Ok, cool, that's kind of what I was thinking
[13:17] <\sh> asac: what magic curse do I have to use to have flash/flex back in ff on jaunty 64bit? ;)
[13:17] <slangasek> pitti: well, even if I use dh_install, it's going to be programmatic <shrug>
[13:18] <slangasek> pitti: anyway, pattern substitutions seem to be failing me for whatever reason :(
[13:19] <asac> \sh: sudo apt-get install --reinstall flashplugin-nonfree ?
[13:19] <\sh> asac: let's see :)
[13:19] <asac> let me know.
[13:20] <\sh> asac: you don't want to see that error message
[13:21] <slangasek> hah, and then the rule fails anyway because there's an upstream translation that's not in LINGUAS
[13:21] <slangasek> thbbt
[13:21] <lool> cjwatson: hey, not sure we have doko this week; I have a couple of issues with the ubuntu-toolchain glibc branch
[13:21] <\sh> asac: http://paste.ubuntu.com/140692/
[13:21] <lool> cjwatson: One is that my branch is still up for merging
[13:21] <\sh> asac: and it was installed and license was approved and worked in intrepid
[13:21] <lool> https://code.launchpad.net/~ubuntu-toolchain/ubuntu-toolchain/glibc-2.5-package/+merges
[13:21] <ebroder> \sh: dpkg-reconfigure flashplugin-nonfree?
[13:22] <pitti> slangasek: what are you trying to substitute?
[13:22] <lool> cjwatson: the other is that there's again a diff between what's in the archive and what's in the branch; e.g. in ./control.in/libc6.1 and other control files, the description was changed
[13:22] <\sh> ebroder: the same...it looks in the wrong location of the file...
[13:22] <slangasek> pitti: creating a common rule for install/gnome-user-guide-*:: or whatever
[13:23] <lool> cjwatson: http://paste.ubuntu.com/140693/ etc.
[13:23] <slangasek> eh, s/*/%/
[13:23] <\sh> grmpf
[13:24] <\sh> after removing the location of the tar.gz of flash it downloads it again..but no change in behaviour...ff is dimming itself..when browsing to a flash site..
[13:25] <asac> \sh: which flash site are you looking at?
[13:25] <\sh> asac: .xsession-errors: http://paste.ubuntu.com/140696/
[13:26] <\sh> asac: golem.de
[13:26] <ebroder> \sh: I'm making this up, but try `echo "flashplugin-nofree flashplugin-nonfree/httpget bool true" | debconf-set-selections`?
[13:26] <\sh> asac: but s/golem\.de/<any site with flash content>/
[13:26] <pitti> slangasek: $(patsubst %,install/%,$(DEB_INDEP_PACKAGES)):: doesn't work?
[13:27] <pitti> slangasek: but I guess if you jump through those hoops, using common-install-indep:: is easier
[13:27] <slangasek> pitti: I hadn't tried that; why does it have to be written that way?
[13:27] <asac> \sh: please check if you have some dangling symlinks in /usr/lib/mozilla/plugins/ or something
[13:27] <pitti> slangasek: well, how did you write it?
[13:27] <slangasek> pitti: exactly as I said
[13:27] <pitti> slangasek: I just stole that from buildcore.mk
[13:27] <slangasek> install/gnome-user-guide-%::
[13:27] <pitti> oh
[13:28] <pitti> slangasek: I'm not sure that % has a special meaning in make outside of $() substitution functinos
[13:28] <\sh> asac: http://paste.ubuntu.com/140698/ if this looks ok to you...no dangeling symlinks (only libtotem)
[13:28] <pitti> I'm not enough of a make guru for this, I'm afraid
[13:28] <slangasek> pitti: oh, I'm quite certain it does have a special meaning, but its meaning appears to be incompatible with whatever cdbs does :)
[13:28] <asac> \sh: where does the alternative point to?
[13:29] <\sh> asac: shermann@wz-pc-010:~$ ls -al /etc/alternatives/mozilla-flashplugin
[13:29] <\sh> lrwxrwxrwx 1 root root 56 2009-03-30 14:23 /etc/alternatives/mozilla-flashplugin -> /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so
[13:29] <asac> \sh: also check xulrunner-addons/plugins
[13:29] <asac> and firefox-addons/plugins ;)
[13:29]  * slangasek adds this to "reasons cdbs is too clever for my own good"
[13:29] <lool> slangasek: What's your diff / .dsc?
[13:29] <cjwatson> lool: ok, I'll look at it and sort it out
[13:29] <pitti> slangasek: cdbs by and large creates automatic dependencies to install/<packagename> targets, for all available packages in debian/control
[13:29] <lool> slangasek: Happy to take a look
[13:30] <lool> cjwatson: Thanks; then I'll poke you for merging of the neon stuff
[13:30] <slangasek> lool: don't worry about it; I'm still mid-composition anyway
[13:30] <slangasek> not worth the trouble to post it somewhere :)
[13:30] <\sh> asac: xulrunner-addons looks like mozilla/plugins , firefox-addons is empty (the plugin)
[13:30] <pitti> slangasek: it doesn't extend make in a way to match install/% for any install/foo
[13:30] <lool> slangasek: I have a decent toolbox of CDBS hackery in my pkg-gnome checkout; happy to have a look  ;)
[13:30] <slangasek> pitti: matching install/% isn't an extension though, it's standard target pattern matching :(
[13:31] <\sh> asac: bbl...
[13:31] <\sh> asac: more infos: it's just a dist-upgrade from intrepid
[13:31] <pitti> slangasek: hm; as I said, I don't know enough about make for this; I only ever used it with functions, and even that very rarely
[13:33] <cjwatson> lool: I wouldn't worry too much about the control desync, it's not that important
[13:41] <PecisDarbs> Someone willing to play with https://bugs.edge.launchpad.net/hardy-backports/+bug/267305?
[13:42] <PecisDarbs> 1.0 is very nice and stable release of django and it would rock to have it in hardy
[13:46] <slangasek> lool: lp:~vorlon/gnome-user-docs/ubuntu-jaunty, if you're particularly interested. :)  (works now)
[13:47] <slangasek> mdke: hrm, why is gnome-user-docs a native package?
[13:48] <slangasek> does upstream not release tarballs?
[13:49] <slangasek> pitti: do you want to review this package split at all before I upload it, or otherwise coordinate wrt langpacks?
[13:49] <pitti> slangasek: I'm happy to take a look, but if it works for you, go ahead :)
[13:50] <pitti> slangasek: once it's through new, I'll add the language-support-* dependencies
[13:50] <slangasek> ok, cool
[13:50] <pitti> slangasek: /me takes a look at the commit
[13:54] <pitti> slangasek: looks good to me, great work!
[13:54] <slangasek> thanks :)
[14:14] <slangasek> pitti: I guess this split saves us about 5MB on the alternate CDs, and $mumble on the desktop CDs
[14:14] <pitti> \o/
[14:21] <\sh> back
[14:25] <\sh> asac: any clue on that behaviour?
[14:41] <slangasek> pitti: ok, gnome-user-guide is out of NEW
[14:43] <asac> \sh: no. you could post a strace -f of firefox
[14:44] <asac> i suspect some bad links somewhere
[14:44] <\sh> asac: my pleasure...
[14:47] <\sh> asac: hmm...strace {firefox,firefox-3.0.8,/usr/lib/firefox-3.0.8/firefox} segfaults...but ff runs..grmpf..
[14:48] <asac> \sh: odd. sure you have all firefox properly killed before doing it?
[14:48] <\sh> asac: whatever I do...(even strace -p) the process with strace coredumps but is still running
[14:49] <asac> hmm
[14:49] <\sh> asac: yepp..checked twice..no trace of firefox..
[14:49] <\sh> asac: firefox started from cli...strace -p <ff pid> -> telling ff to http to whereever -> coredump
[14:50] <\sh> *** glibc detected *** strace: malloc(): memory corruption (fast): 0x000000000225f610 ***
[14:50] <\sh> select(Aborted (core dumped)
[14:50] <asac> so strace is broken?
[14:51] <cjwatson> Riddell: could somebody who knows about qt layout fix bug 344382? it isn't obvious to me how to do so, since the relevant QLabel does have wordWrap set to true, so I think it must be something more subtle
[14:51] <\sh> asac: good question...regarding the fact, that ff is still running, I would say yes, but I'm in no position to really say so...others will have a much better insight in strace ;
[14:51] <cjwatson> Riddell: ... actually, never mind, I think it's been fixed since the bug was reported, 'bzr cat -rtag:1.11.14' shows wordWrap set to false
[14:52] <slangasek> if strace core dumps, that's an strace bug, sure
[14:52] <cjwatson> heh, indeed you fixed it yourself
[14:53] <asac> \sh: maybe downgrading strace ...
[14:54] <asac> \sh: seems so
[14:55] <asac> i guess we should file a relese bug on that
[14:55] <asac> broken strace is a blocker imo
[14:55] <\sh> asac: much better: fix bug #316762 on strace
[14:55] <asac> is that the bug?
[14:56] <asac> yeah seems so
[14:56] <\sh> asac: yepp filed in january...and the attached logfile looks the very same to my output
[14:56] <asac> maybe its our direct.h patch?
[14:56] <asac> https://edge.launchpad.net/ubuntu/jaunty/+source/strace/4.5.17+cvs080723-2ubuntu1
[14:58] <\sh> asac: you mean the missing linux/dirent.h patch from pitti?
[14:58] <asac> \sh: not sure. just stabbing ni the dark. most likely its just because we have a cvs snapshot now ;)
[14:59] <pitti> slangasek: I'll add them in an hour, when they get published
[14:59] <\sh> asac: anyways...I can reproduce that on two machines, which had the very same upgrade path...so I'll check this evening on the other machine
[14:59] <kirkland> pitti: right
[14:59] <slangasek> pitti: cheers :)
[15:00] <pitti> kirkland: ECONTEXT?
[15:00] <kirkland> pitti: cjwatson agreed with you, i think the last package i uploaded should do what you want, and meet cjwatson's code critiques
[15:00] <pitti> kirkland: ah, thanks
[15:00] <kirkland> pitti: just woke up, reading scrollback, you highlighted me :-)
[15:01] <kirkland> pitti: re: deluser
[15:22] <tkamppeter> pitti, can you approve the -proposed package for bug 351630? I have already uploaded it and it waits for approval. Thanks.
[15:22] <pitti> tkamppeter: on my next SRU run, will do
[15:24] <tkamppeter> pitti, thanks.
[15:33] <seb128> pitti, slangasek: ok, I've a gnome-python-desktop split of gtksourceview and gnomeprint ready to be uploaded (we have to split gtksourceview too because it depends on gnomeprint), it wins 2.3megas on installed size
[15:34] <seb128> pitti, slangasek: libgnomeprint, libgnomeprintui, libgtksourceview would be out of the CD but still in main due to build-depends still being there
[15:34] <seb128> pitti, slangasek: not sure if that's worth for jaunty ...
[15:34] <slangasek> I don't know
[15:35] <slangasek> 2.3MB installed; but hard to know how much on the livefs
[15:37] <slangasek> seb128: if you think it's worthwhile, go ahead
[15:37] <slangasek> could you also drop the bug-buddy build-dep at the same time?
[15:38] <seb128> slangasek: that would mean stopping building the bug-buggy binding
[15:38] <slangasek> yeah
[15:38] <seb128> do we really want to do that?
[15:38] <slangasek> is there really any reason we shouldn't?
[15:38] <seb128> some gnome applications import it
[15:38] <slangasek> if you think it needs to stay, then I'll hack up a patch to build it without the bug-buddy build-dep
[15:38] <slangasek> ok
[15:38] <seb128> I need to check how it behaves if not installed
[15:39] <hyperair> pitti: could you take a look at the nautilus-share merge request? i accidentally diff'd against the wrong thing in my previous patch upload
[15:39] <slangasek> let's just go the safe route, I'll fix the configure script to build the binding even if bug-buddy's not installed
[15:40] <seb128> slangasek: ok, so I would say the CD space win is not worth the python bindings split
[15:40] <slangasek> ok
[15:41] <seb128> not sure about moving those 3 deprecated libs out of the CD though
[15:41] <seb128> would it mean we stop supporting those officially
[15:41] <seb128> which would be a win ...
[15:41] <seb128> though in practice they are not so much maintainship work
[15:42] <pitti> hyperair: looks fine now; seb128, you commented on the nautilus-share merge, do you want to do that yourself, or shall I take it?
[15:42] <hyperair> pitti: thanks
[15:42] <seb128> pitti: please do it
[15:43] <apw> pitti, hey ... why does apport refuse to file bugs when i have out of date packages?
[15:43] <seb128> pitti: I just commented because the bug wrongly requested a sync
[15:43] <seb128> and I didn't want somebody to ack the sync too quickly
[15:43] <apw> i only have out of date packages cause you lot are rebuilding everything
[15:43] <apw> thats just daft
[15:43] <pitti> apw: well, but for that very reason we also get a lot of broken stack traces :/
[15:44] <pitti> apw: it was an "emergency brake" for getting even more crash reports
[15:44] <apw> then its completely rediculous to do a beta release at the same time, no?
[15:44] <seb128> pitti: any opinion on python-gnome-desktop gnomeprint, etc?
[15:44] <apw> as noone who tests it (like me) can report any bugs, an indeed should expect instability
[15:44] <pitti> apw: also, it doesn't check for "any outdated package", just for "any outdated package in the crashed program's depenency chain"
[15:44] <apw> so its not a good time for a beta either
[15:44] <apw> right but you are rebuilding the world on me
[15:44] <slangasek> "the world"?
[15:45] <apw> oh an not popping up the update-manager for 5 days
[15:45] <apw> so i am bound to have out of date packages if i follow normal user experience
[15:45] <pitti> seb128: no strong one; if you want to do the work, go ahead, but I don't think it's urgent
[15:45] <apw> i thought we rebuilt everything 'now'
[15:45] <seb128> pitti: well as said before I've it read for upload if we want it
[15:45] <pitti> seb128: I see no reason not to upload it if you did it already and it works
[15:46] <seb128> pitti: that doesn't win us a lot and we still have to keep the lib in main due to build-depends
[15:46] <apw> my real point is are we not just wasting tester cycles by conenciding these two things?
[15:46] <pitti> apw: I don't think so
[15:46] <slangasek> apw: we do test rebuilds; we don't rebuild the packages in the archive except to fix bugs
[15:46] <pitti> apw: we rebuilt perhaps 50 packages since beta, but we have some 25.000 in teh archive
[15:46] <seb128> pitti: well, that could break third party softwares around which still use gnomeprint or gtksourceview1 and would need to update their depends
[15:46] <apw> oh hrm
[15:47] <apw> pitti, i have 193 updates pending since beta
[15:47] <pitti> apw: I'm aware that being able to report crash bugs involves daily dist-upgrades
[15:47] <apw> pitti, you are but even i am not
[15:47] <pitti> apw: but ATM I don't really see how else to do it
[15:47] <pitti> seb128: oh, I see
[15:47] <seb128> apw: you suggest that we stop fixing bugs so you can reply crashes?
[15:47] <seb128> reply -> report
[15:48] <slangasek> I think he's asking that apport not refuse to file crashes because of outdated packages
[15:48] <apw> seb128, heh no of course not.  i think if we are fixing so little then it should be safe to accept crashes
[15:48] <pitti> seb128: I thought you split out a gnome-python-desktop-main or so, with gnome-pyhton-desktop pulling in -main and -extra
[15:48] <apw> it makes apport useless it feels to me
[15:48] <seb128> pitti: hum, could do that
[15:48] <apw> anyhow i'll go hit update and see if indicator-applet poops self again
[15:48] <seb128> apw: export APPORT_IGNORE_OBSOLETE_PACKAGES
[15:49] <apw> seb128, thanks
[15:49] <cjwatson> apw: we don't typically expect people to install beta and then sit with it until we do the final release - we expect people to install it and then upgrade reasonably frequently to final
[15:49] <seb128> you're welcome
[15:49] <pitti> apw: ^ right, but pretty please don't report crashes against packages which were updated recently
[15:49] <pitti> apw: using that is okay if the oboslete package is deep down the dependency chain
[15:49] <apw> cjwatson, yeah i know, but the new update-manager works against that as i don't get told
[15:50] <seb128> apw: there is a reason why that is not set by default, if apport tell you that versions changed the retracing with probably fail and not be useful
[15:50] <apw> pitti, s'ok i won't do it...
[15:50] <apw> i am tryng to behave like a real user and report my experience to you
[15:50] <apw> i don't want to deviate from th
[15:50] <pitti> apw: thinking about it, we now auto-invalidate bugs with failed stack traces and obsolete dependencies, so reporting those probably don't hurt so much as it used to
[15:50] <apw> that.  but i can tell you  i was pretty annoyed whern it asked me to report, it muched for 2 mins and then told me to bugger off
[15:51] <cjwatson> (real users don't report bugs to #ubuntu-devel, mind you ;-) )
[15:51] <apw> and then didn't even wake up update-manager to get me updated
[15:51] <seb128> apw: that's one of the trade off of running an unstable distribution
[15:51] <apw> just re-rand the bust ones
[15:51] <pitti> apw: I don't particularly like the u-m silence for an entire week either; it's appropriate for stable, but not for a devel release
[15:51] <apw> seb128, yep ... i am fully aware
[15:51] <sladen> pdate-manager has been reported "Partial upgrade possible only" for the last couple of months.  SHould I care?
[15:52] <apw> i am completly capable of coping and not whining.  the purpose of my whine is to try and see what appears like my girlfriend would and behave the way she would
[15:52] <slangasek> mumble shouldn't be needed for stable releases either if our SRUs are reasonable
[15:52] <apw> and she would have come and shouted at me
[15:53] <seb128> apw: she souldn't be using an unstable distro ;-) apport is not running by default on stable
[15:53] <sladen> that APPORT_IGNORE_OBSOLETE_PACKAGES should really check if it's one of the involved packages that actually crashed
[15:53] <apw> yes she should, she was told it was really shiney and there was cute popups, how could she resist
[15:53] <seb128> apport does check only rdepends
[15:54] <pitti> slangasek: that's what it does if you *don't* specify it
[15:54] <pitti> erm, sladen, I mean ^
[15:54] <pitti> sladen: well, it checks the crashed package and its transitive dependencies
[15:55] <sladen> pitti: oh.  maybe it's libc or something.  I haven't had apport non-whinge (eg. succeed) for 3 weeks now
[15:55] <sladen> pitti: perhaps it needs an override button "report anyway" ... which given that it's only shown to development-release users would be useful
[15:56] <pitti> sladen: I'm not so sure about that
[15:56] <seb128> everybody would click it
[15:56] <pitti> sladen: it's not that we need to find ways to get even more bug reports
[15:56] <pitti> we have plenty
[15:56] <seb128> that would defeat the purpose of the check
[15:56] <apw> pitti, it would be nice if it at least told me what was out of date
[15:56] <slangasek> doesn't it?
[15:56] <apw> so i could make a judgement about updating
[15:56] <seb128> apw: it does
[15:56] <pitti> and reports about older versions aren't very useful
[15:56] <slangasek> it always did before
[15:56] <pitti> it should
[15:56] <seb128> it lists everything outdated in a dialog there
[15:57] <sladen> IIRC, it just says "some packages are out of date"
[15:57] <sladen> oh
[15:57] <seb128> and list those
[15:57] <apw> seb128, i think i would have noticed.  it said you have out of date packages only
[15:57] <seb128> apw: are you sure you don't have a dialog unfocussed somewhere?
[15:57] <seb128> apw: that seems a bug then, open an apport bug on launchpad
[15:57] <apw> not that ic an see
[15:58] <apw> why would it not be in the dalog which told me it was out of date
[15:58] <pitti>             report['UnreportableReason'] = _('You have some obsolete package \
[15:58] <pitti> versions installed. Please upgrade the following packages and check if the \
[15:58] <pitti> problem still occurs:\n\n%s') % ', '.join(old_pkgs)
[15:58] <pitti> and if old_pkgs is empty, it isn't shown at all
[15:58]  * sladen does a killall -SEGV evince  ... okay so that did tell me packages
[15:58] <pitti> so that indeed sounds like a curious bug
[15:59] <apw> pitti, well i must be blind then as that looks impossible
[15:59] <seb128> apw: http://people.ubuntu.com/~seb128/apport.png
[15:59] <seb128> apw: that's what I get there
[15:59] <pitti> apw: it could very well be a bug somewhere
[15:59] <apw> yeah i must have been too angry to read the second sentence
[15:59] <apw> as i deffo had the top
[16:00] <apw> dlinded by rage :)
[16:00] <apw> sorry for the noise.  /me crawls back under his rock
[16:01] <pitti> apw: no need to apologize; it's a valid concern, I just don't know how to make it better without increasing the bug tracker noise a lot
[16:01] <pitti> I guess the u-m silence contributes a lot to this
[16:01] <apw> pitti, would apport complaint about the things in apport as well as the thing you were using?
[16:02] <apw> pitti, i was very happy to find a way to get the little icon back
[16:02] <seb128> pitti: maybe add a "upgrade now" button to the apport dialog ;-)
[16:02] <pitti> apw: can you reformulate this, please?
[16:02] <sladen> on a related topic, would there be a good way to show users why their CPU has gone to 100% but firefo hasn't actually yet disappeared
[16:02] <sladen> (during the collection process)
[16:02] <seb128> compiz change the color of the dialog when not responding
[16:03] <seb128> do you find that a good visual clue?
[16:03] <apw> pitti, i was wondering if apport would whine about say python because apport uses it when reporting ... does it include its own deps
[16:03] <pitti> apw: only if you'd report a crash of apport itself
[16:04] <pitti> apw: if you report a crash in, say, libgtk, an outdated python doesn't matter at all
[16:04] <apw> i am hearing reports of python being reported as out of date for a kernel panic, but i've not seen it myself
[16:06] <slangasek> sladen: anything that would permit the crash handler to trace down the process's X windows and display something friendly would surely be comparably sluggish?
[16:08]  * slangasek attacks the OOo java build-dep tree with a chainsaw
[16:09] <sladen> slangasek: I was thinking about something more general such as changing the cursor to an hour glass Gtk-wide when CPU level >= 90%  (Mac / RiscOS had that for years and whislt it might be annoying, it at least show that the computer is *aware* that it is being slow)
[16:09] <sladen> ...the animation helping to convince the user that it hasn't actually crashed
[16:11] <directhex> slangasek, you're not trying to build OOo are you? with your bare hands?
[16:11] <directhex> sladen, the windows 95 busyish cursor!
[16:11] <slangasek> not at all; I'm using slave laborers to build it
[16:13] <sladen> seb128: just tried that a few times.  The window vanishes before it gets a chance to turn grey  (which took ~10-15 secodns)
[16:13] <seb128> ok
[16:16] <directhex> slangasek, slaves plural? calc is but one man!
[16:16] <sladen> seb128: so it's   15 seconds hang with 100% CPU.  "Gah damnit $#%@#$ where did my work go".  15 seconds more 100% CPU.  Pause.  Apport notification.  Click, report.  5 seconds CPU.  "Could not be reported"  blood boiling
[16:16] <seb128> that's one of the reason why we don't enable it on stable ;-)
[16:17] <sladen> :)
[16:18] <sladen> perhaps, apport could fire up a pulsing status icon in the top menu "collecting crash information".  Then this could change to solid when the report is ready
[16:19] <pitti> bryce: can you upload bug 320893 today/soon? If you are swamped, I can do it tomorrow morning
[16:22] <Tm_T> hi kids
[16:22] <pitti> slangasek: did you see the updated script in bug 295441? I don't think we need to mess with it further in SRUs, but it might be worthwhile for jaunty; WDYT?
[16:24] <slangasek> pitti: I saw, but since he attached a script instead of a diff I haven't had a chance to look into it yet
[16:25] <slangasek> pitti: I doubt it has any other changes that need to be applied to jaunty, though; I think I probably just missed a related change when cherry-picking for the SRU
[16:27] <Tm_T> I failed to find any related bug for this, so I wonder if there's been any other victims of 64bit(only?) gcc/g++ segfaults: internal compiler error: Segmentation fault
[16:27] <Tm_T> keep hitting on that in Jaunty now all the time
[16:29] <cjwatson> Tm_T: try with lower optimisation settings to start with
[16:29] <cjwatson> Tm_T: /usr/share/doc/gcc-4.3/README.Bugs
[16:31] <pitti> jdstrand: I'm a bit confused about bug 305264; ubuntu-sru is subscribed, it is apparently in -proposed and v-needed, but the SRU team never accepted it; is that a kind of "security update staging" procedure:
[16:31] <pitti> jdstrand: ?
[16:32] <pitti> jdstrand: is there anything the SRU team needs to do for those?
[16:32] <Tm_T> cjwatson: hmm, will try, thanks, apparently there's several bug reports, just failed to find them, let's see if this gets sorted out
[16:33] <cjwatson> Tm_T: don't assume your crash is the same as anyone else's
[16:33] <jdstrand> pitti: it should be pushed along with the openldap SRU that is in the same report
[16:34] <jdstrand> pitti: that was a bit of a twisty bug, but we are very close to being able to close it
[16:34] <jdstrand> pitti: I followed up with mathiaz on it last week, and he is preparing the openldap bits and I believe has uploaded them
[16:34] <jdstrand> pitti: to -proposed
[16:36] <jdstrand> pitti: so to fully answer your question, nothing needs to be done until openldap is verified and ready to go to updates, at which point, both gnutls and openldap whould go
[16:38] <pitti> jdstrand: I see, thanks
[16:45] <alex-weej> backlight level is reset to 100% after S3 resume, but g-p-m thinks it's still whatever it was
[16:46] <alex-weej> is this a general problem with bl drivers or just mbp_nvidia_bl?
[16:46] <alex-weej> need to work out whether to get g-p-m to reset bl level to what it thought it was before resume or whether to fix the bl module to be consistent
[17:06] <lool> cjwatson: Happy if you can review NEON hwcaps changes lp:~lool/ubuntu-toolchain/glibc-neon-and-misc-hwcaps they are building in a PPA ATM, and I'll test them tomorrow; if they work I'd like to push them tomorrow
[17:06] <lool> (I'm not offering them for merging just yet because of the bzr status I mentionned earlier and because I will test them first)
[17:10] <slangasek> ArneGoetje: so the deadline we give folks for langpack translations according to the schedule is the same day as RC; I know we talked about when to do the last full langpack rolling, I guess we definitely need one after RC then - should we also have one before RC, to get right sizes for the RC?
[17:11] <ArneGoetje> slangasek: probably
[17:12] <ArneGoetje> slangasek: that would mean this coming Friday.
[17:12] <bryce> pitti: yeah I can do the upload for that
[17:13] <ArneGoetje> slangasek: ah no... that would be for non-langpack translations...
[17:13] <ArneGoetje> slangasek: so, Friday 10th, right?
[17:14] <slangasek> ArneGoetje: RC is the 16th, so the 10th would work, yes
[17:14] <ArneGoetje> slangasek: ok
[17:35] <mdke> slangasek: still around?
[17:36] <slangasek> mdke: barely
[17:36] <mdke> slangasek: i was going to respond to your highlights about gnome-user-docs, but we can take it to email, or leave it for another day if you like
[17:36] <slangasek> mdke: whichever :)
[17:36] <mdke> slangasek: email then. enjoy your evening
[17:49] <apw> cjwatson, did i see someone talking about some automated location selection for the registry domain?
[17:50] <cjwatson> apw: YM the network-manager regulatory domain, or something else?
[17:50] <apw> well the kernel CRDA one, but thats probabally the same, something to do with your locale or something floated past
[17:51] <apw> i just cannot remember where i might have seen it
[17:57] <cjwatson> apw: there was a proposal that the installer should set it with a modprobe option, but I bounced that over to network-manager on the grounds that having the installer do it is bad for people who might travel between regulatory domains
[17:57] <cjwatson> apw: I don't know what happened to the bug after that
[17:58] <apw> yeah what i saw was some script which was looking at your home location or something
[17:58] <apw> but for the life of me i don't know if it was a bug, or a developer email or imaginary
[17:59] <cjwatson> no idea then :)
[18:03] <Tm_T> cjwatson: aye, I do not assume, I rather try to find it there is something useful for finding the root of the cayse
[18:03] <Tm_T> cause
[18:18] <tkamppeter> pitti, can you have a look at bug 348316?
[18:19] <tkamppeter> For many users USB printers get detected but it is not possible any more to print through the CUPS USB backend with Jaunty.
[18:20] <cjwatson> lool: I checked glibc bzr; I'm not sure why the package as uploaded has old text in control.in/libc<blah>, but all the files in bzr are correct so I think that can be ignored
[18:21] <tkamppeter> pitti, CUPS is the same in Intrepid and Jaunty. Only change is runloop-backchannel-eof-spin.dpatch, an upstream bug fix. I have already asked the reporter of the (probably duplicate) bug 350107 to test with the unpatched backend, but he has still the same issue.
[18:22] <cjwatson> lool: lp:~lool/ubuntu-toolchain/glibc-neon-and-misc-hwcaps looks fine to me if it tests out OK
[18:22] <tkamppeter> pitti, can it be that the kernel causes the problem?
[18:23] <pitti> tkamppeter: entirely possible; however, I think it's also worth asking for /var/log/kern.log, and trying with sudo aa-complain cups
[18:25] <pitti> tkamppeter: but if the printer gets detected properly (lpinfo -v has it), then the backend should work okay, permission-wise
[18:26] <bryce> pitti: I've uploaded bug 320893 -- would you mind shepherding it through the remainder of the sru process?
[18:27] <pitti> tkamppeter: posted a followup
[18:27] <pitti> bryce: thanks muchly; will do
[18:30] <mdz> pitti: I was just looking at bug 351024 and realized it would be a good idea to include the CD build number for reports done from the live CD
[18:31] <pitti> mdz: I agree, good idea; could you please file this as a bug report?
[18:31] <mdz> pitti: yes, I'll see if I can work up a patch as well
[18:31] <pitti> not that trivial, since it's ubuntu specific, but that's okay for now
[18:31] <pitti> I still haven't split it into trunk and ubuntu
[18:32]  * pitti disappears to Taekwondo, good bye everyone
[18:35] <mdz> cjwatson: any guess what's behind 351024?
[18:43] <cjwatson> mdz: I looked at that, who knows, could be anything, but looks like a busted live CD
[18:44] <cjwatson> mdz: we get loads of weird bugs like this on ubiquity
[18:44] <cjwatson> which AFAIK are not typical but CDs suck
[18:44] <mdz> cjwatson: even with no errors reported in the log?
[18:45] <cjwatson> mdz: far from unknown
[18:45] <cjwatson> mdz: I'll look into pygtk in more detail tomorrow and see if I can figure out anything more
[18:46] <mdz> cjwatson: would it be too brutish to force an integrity check before filing the report?
[18:47] <cjwatson> mdz: when I dig into this sort of problem, oftentimes it turns out that the integrity check passed
[18:47] <cjwatson> mdz: it seems that different CD read patterns often show up different bugs
[18:48] <mdz> cjwatson: *cry*
[18:48] <cjwatson> my sentiments exactly
[18:48] <cjwatson> hence "CDs suck"
[18:48] <cjwatson> so the error here is that gdk_cursor_new_from_pixmap returned NULL:
[18:48] <cjwatson>   g_return_val_if_fail (GDK_IS_PIXMAP (source), NULL);
[18:48] <cjwatson>   g_return_val_if_fail (GDK_IS_PIXMAP (mask), NULL);
[18:48] <cjwatson>   g_return_val_if_fail (fg != NULL, NULL);
[18:48] <cjwatson>   g_return_val_if_fail (bg != NULL, NULL);
[18:48] <cjwatson> well, either that or g_new failed
[18:49] <ScottK> "You must order a CD via shipit and wait 4 - 6 weeks.  If you can reproduce the bug with that CD, then you can report it."
[18:49] <ScottK> Note:  I'm not actually recommending that.
[18:49] <cjwatson> so I suppose it could be that one of the pixmaps couldn't be read
[18:49] <cjwatson> ScottK: ... and then you get the people who go "I got this with a pressed CD" and you panic for a bit and then it turns out that cleaning their CD drive fixes it
[18:50] <mdz> cjwatson: is it time to discuss deprecating CD installations in favour of USB sticks?  they seem much more reliable
[18:50] <ScottK> Yes, so not even being that annoying will do it.
[18:50] <ScottK> It's actually pretty hard to find good quality CD media.
[18:51] <cjwatson> mdz: maybe when we fix more of the USB installation bugs ;-) I think deprecate is too strong though; realistically I don't see people stopping using CDs any time soon
[18:51] <maswan> Stop supporting anything but network installs. Ship a tiny dhcp+tftp-server. ;)
[18:51] <mdz> cjwatson: "rank second in order of preference"
[18:52]  * cjwatson -> dinner
[18:53] <mdz> USB sticks large enough to install Ubuntu can now be had for USD 4 or less
[18:53] <maswan> Also, would it be possible to have a smarter integrity check which is more like a real access pattern?
[18:53] <mdz> which is still more than a CD-R, of course...
[18:54] <mdz> maswan: yes.  would it help? maybe not.
[18:54] <maswan> mdz: Yeah, I should get around to get one, one of these days.. Of course, once you're at the point where you already netboot a couple of computers, netbooting an installer is less work than remembering to get a stick. :)
[18:55] <maswan> mdz: Not quite a general solution though..
[19:01] <ebroder> I have a custom boot CD that's using the Jaunty alpha 6 kernel/initrd from the mini.iso (with custom arguments). I'm getting http://paste.ubuntu.com/140869/ when I try to boot onto a Dell 755. I know I'm in i-get-to-keep-both-pieces territory, but is this my fault, or Ubuntu's?
[19:02] <ebroder> I've used the CD in a VM, where it worked fine
[19:06] <pace_t_zulu> is there a way I can help with the notifications project?
[19:10] <pecisk> pace_t_zulu: test with all kind of apps and report misbehaviour
[19:11] <pace_t_zulu> pecisk: where can i find pidgin's code for interfacing with notifications? I believe it can be improved
[19:12] <pecisk> pace_t_zulu: it sends a D-BUS message, I suppose
[19:13] <pace_t_zulu> pecisk: so the code would exist in pidgin's source?
[19:15] <pecisk> pace_t_zulu: it has several parts. Code for D-BUS message which causes those shiny OSD notifications to appear and code for general notification
[19:16] <pace_t_zulu> pecisk: is there a guide for how to hack pidgin's source? is there a package i can install?
[19:17] <pecisk> pace_t_zulu: apt-get source pidgin will get you a source and diff of Ubuntu changes
[19:18] <pace_t_zulu> pecisk: thank you... apologies for my ignorance
[19:19] <pecisk> np :)
[19:20] <pecisk> pace_t_zulu: this Mark post on notifications will inform you about how it happens. There are several links to Ubuntu Wiki about this - read them all, they usually contain very useful info.
[19:20] <pace_t_zulu> ?
[19:22] <pecisk> pace_t_zulu: sorrry, forgot the link http://www.markshuttleworth.com/archives/265
[19:23] <pecisk> pace_t_zulu: how to hack pidgin propably read there http://developer.pidgin.im/
[19:24] <pace_t_zulu> thanks pecisk
[19:24] <pecisk> np
[19:31] <lool> cjwatson: (thanks for fixing and reviewing)
[19:41] <natewiebe> what is the best way to compile from source, then making a deb out of it?
[19:42] <natewiebe> ive tried checkinstall, but im wondering if there is a better way
[19:43] <c_korn> natewiebe: dh_make
[19:44] <natewiebe> does that work better than checkinstall?
[19:45] <ivoks> checkinstall is dirty, but can be used for fast deb
[19:45] <ivoks> those deb packages are flawed and shouldn't be used outside that single machine
[19:45] <natewiebe> okay.. thanks
[19:46] <ivoks> if you want to create deb package that would be usable outside, you should debianize the source
[19:46] <natewiebe> they havent made a gui yet have they?
[19:46] <ivoks> gui?
[19:46] <ivoks> :)
[19:46] <natewiebe> and i should do that using dh_make?
[19:46] <natewiebe> haha
[19:46] <ivoks> http://pwet.fr/man/linux/administration_systeme/dh_make
[19:47] <ivoks> start here: http://www.debian.org/doc/maint-guide/
[19:47] <natewiebe> awesome.. thanks
[19:49] <c_korn> I have a binary here and ldd says: libtinyxml.so => not found. why didn't dh_shlibdeps make the package depend on the lib package that contains this file?
[19:49] <c_korn> I used dh_makeshlibs to create the lib package
[19:51] <LordKow> c_korn, i think gencontrol does that.
[19:51] <LordKow> maybe im wrong
[19:52] <c_korn> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
[19:52] <c_korn> this is the all output of gencontrol
[19:52] <c_korn> no word about a missing dependecy
[19:54] <LordKow> and you can ignore those gencontrol warnings about misc:Depends... im pretty sure.
[19:56] <c_korn> yes, well I will just add the dependecy manually
[19:57] <c_korn> but it is odd anyway
[19:57] <LordKow> well yea i take back that first part you said... dh_shlibdeps *should* be adding that dep but sometimes you just have to add it manually.
[19:57] <LordKow> first part i said that is. i dont think i can take back what you said ;)
[20:02] <c_korn> LordKow: yeah, thanks.
[20:13] <jtisme> can anyone tell me the name of the installer file containing the  db_get db_go etc. shell functions
[20:14] <NCommander> cjwatson, is it possible we could get Kubuntu/Xubuntu CDs for ports (or at least PowerPC) this cycle? I realize that space on antimony might be at a premium, so if its not possible, could jidgo files be generated so users can assemble their own CDs?
[20:19] <cjwatson> mdz: sorry, I was in a rush for dinner earlier and didn't really mean to be dismissive of that bug. I will look at it properly (since Evan's on holiday); it didn't show up in my tests with today's daily build, but I suppose it could be that the icon ubiquity is asking for only exists on some images
[20:19] <cjwatson> jtisme: it's not specifically an installer file: /usr/share/debconf/confmodule
[20:19] <jtisme> cjwatson, thanks
[20:19] <cjwatson> NCommander: cdimage has been trying to build them for ages. If they aren't appearing, then it's because they're failing, not because they're not being tried
[20:23] <NCommander> cjwatson, it seems I'm an idiot (I didn't see the ports CD where it was, although I'm confused on why Kubuntu has a full set of CDs, and Xubuntu just got ARM and PowerPC, but this I shall figure out)
[20:23] <mdz> cjwatson: no worries, I'm just scanning over http://qa.ubuntu.com/reports/bugnumbers/bugs-since-2009-03-26.html for anything which looks actionable
[20:24] <cjwatson> mdz: ah, I was wondering where it came from; couldn't imagine you were looking over all ubiquity bugs ...
[20:24] <mdz> cjwatson: it caught my eye originally because I didn't notice 'beta' in the summary, and figured it could be a regression in the dailies
[20:25] <cjwatson> I did a sweep through newish ubiquity bugs today, since we needed an upload
[20:42] <Ng> am I reading pm-utils scripts right, and the existence of /var/run/pm-utils/pm-suspend/storage/inhibit prevents suspending?
[20:46] <james_w> Ng: looks like it to me
[20:48] <Ng> james_w: that was my reading too. I just removed it, ran pm-suspend again and it came back. Time to do more reading :)
[20:49] <james_w> Ng: /usr/lib/pm-utils/pm-functions:		# if the hook exited with an unknown exit code inhibit,
[20:49] <james_w> /usr/lib/pm-utils/pm-functions:		hook_exit_status $? && LAST_HOOK="$base" || inhibit
[20:50] <Ng> yeah
[20:51] <Ng> bam, one culprit found
[20:51] <Ng> + /etc/pm/sleep.d/07-stop-play.sh suspend suspend
[20:51] <Ng> kill: 4: Usage: kill [-s sigspec | -signum | -sigspec] [pid | job]... or
[20:54] <Ng> so the question is whether or not it's reasonable to only call kill if there actually is an argument, or if there should always be an argument. the ps is returning no matches here
[20:56] <james_w> Ng: why not use something like pkill?
[20:58] <Ng> james_w: that script is from a third party package, so I'll move along now
[20:59] <james_w> ah, well if you will insist on modifying an install of Ubuntu then of course you will find bugs :-)
[21:05]  * Ng wonders if there should be a notification of what caused the suspend process to fail
[21:22] <lamont> *qa.ubuntu.com going offline for a few minutes for maintenance.
[21:28] <lamont> and *qa.ubuntu.com is back online
[21:30]  * cjwatson hates it when people lie in bug reports (as proven by the logs they attach)
[21:32] <ScottK> If you're going to lie, at least be smart about it?
[21:33] <pwnguin> at least they were kind enough to attach logs
[21:35] <cody-somerville> People do that?
[21:36] <bryce> cjwatson: my favorite lie:  "I have the same issue."
[21:36] <bryce> usually followed by, "Well, except that..."
[21:37] <ScottK> My favorite one is "I wasn't watching pron"
[22:17] <slangasek> jpds: why are you proposing to add these apparmor profiles into the apparmor package, instead of into the package providing the binary?
[22:18] <jdstrand> slangasek: cause I told him too
[22:18] <jdstrand> :)
[22:18] <slangasek> oh?
[22:18] <slangasek> ok, why are *you* doing that then? :)
[22:18] <jpds> slangasek: Sorry, does it email everyone? Didn't know that.
[22:18] <jpds> slangasek: And what Jamie said. :)
[22:18] <jdstrand> slangasek: it is because they aren't ready yet. profiles-devel is simply a collecting area for in progress profiles, not ready for mass consumption
[22:18] <slangasek> it does, which is a known annoyance that I don't hold against you :), I'm just puzzled by where they're going
[22:19] <slangasek> ah, I see
[22:19] <jpds> Sorry about the spam folks.
[22:19] <jdstrand> actually, it is a good thing
[22:19] <jdstrand> that way people will know when new profiles are being developed
[22:20] <slangasek> no, it's not a good thing. :)
[22:21] <jdstrand> I acknowledge the spam factor, but if you look at it with the right pair of glasses, it is good :)
[22:21] <jdstrand> slangasek: I happen to own two pair. I can loan you one if you like :P
[22:22] <slangasek> heh
[22:49] <calc> this is probably a dumb question, why doesn't ssh to another box with my public/private key log me in without asking for my password?
[22:49] <wgrant> calc: Is it in .authorized_keys on the remote box?
[22:50] <wgrant> Have id_[rd]sa.pub isn't enough.
[22:50] <wgrant> s/Have/Having/
[22:51] <calc> wgrant: ah ok
[22:52] <wgrant> ~/.ssh/authorized_keys, I of course mean.
[22:52] <calc> that fixed it :)
[22:58] <Ampelbein> calc: you can use seahorse to setup your key automagically.
[22:59] <Ampelbein> calc: rightmouse-click on they -> "configure key for secure shell" (just in case you need it again)
[23:31] <mrooney> when do the karmic archives open?
[23:33] <jpds> mrooney: After 30/04: https://wiki.ubuntu.com/KarmicReleaseSchedule
[23:34] <mrooney> jpds: thanks! I was just thinking about you as I look for Barcelona flights
[23:34] <mrooney> I knew the flight was rough but, I didn't realize I leave on friday and get in on sunday :)
[23:35] <jpds> Hehe.
[23:37] <mdke> seb128: testing your theory on bug 264314 now, if it works I'll do a debdiff
[23:37] <seb128> mdke: thanks
[23:38] <seb128> mdke: I think it's just that the directory has not been listed in any .install when the package has been splited for the new library
[23:38] <seb128> mdke: just dh_install --list-missing after the build to see what is not installed
[23:38] <mdke> seb128: ok, thanks
[23:39] <mdke> seb128: I see that the bzr branch only has the debian directory, is there an easy way to get the source with it, or can I just use "apt-get source" for everything?
[23:40] <seb128> mdke: bzr-buildpackage
[23:41] <seb128> mdke: it does get the tarball etc for you and start the build
[23:41]  * mdke installs
[23:41] <seb128> mdke: https://wiki.ubuntu.com/DesktopTeam/Bzr
[23:42]  * mdke reads
[23:42] <seb128> mdke: if you are interested in a not to complicate description of how to use bzr for desktop packaging
[23:42] <mdke> seb128: I am, thanks