[00:00] <slangasek> I think the reason we keep the snapshots is primarily to ensure we can satisfy the license requirements for the point release ISOs after the fact
[00:00] <slangasek> fbond: that's not published either, except in the .manifest and .list files that accompany the ISOs (which are the only packages we care about for the snapshot, really)
[00:00] <fbond> slangasek: I see.
[00:01] <fbond> slangasek: What is the likelihood of at least making a list of package versions public?
[00:01] <fbond> (I'll even write the script if you want. ;)
[00:03] <slangasek> fbond: you really care about the full list of packages, including those not included in the point release ISOs?  I could publish the Packages files somewhere, I'm just confused why you would want that list
[00:03] <slangasek> the manifests for the ISOs are already public
[00:04] <fbond> slangasek: My builds may pull any package from the archives, and they do not build ISOs.
[00:04] <slangasek> fbond: but then, why do you want the lists for those particular snapshots?
[00:04] <fbond> slangasek: Mostly because it is a convenient way to declare release points.
[00:04] <slangasek> hmm
[00:05] <slangasek> well, let me grab those Packages files out for you, then and publish them somewhere
[00:05] <slangasek> which archs do you care about?
[00:05] <fbond> slangasek: I only care about x86 right now.
[00:06] <fbond> slangasek: I'd rather not have to bug you again after every release.
[00:06] <slangasek> "x86" as in "i386", or as in "i386 and amd64"?
[00:06] <fbond> i386, sorry.
[00:06] <slangasek> well, you can always pull the Packages files yourself the day of the point release then? :)
[00:06] <fbond> I would only want to trouble you with this if you feel it is something that is appropriate to do both now and in the future.
[00:06] <fbond> slangasek: Ah, sure, I don't mind doing that.
[00:06] <fbond> How long is the window where I am guaranteed to have correct contents?
[00:08] <slangasek> given that security updates can happen at any time and be published to -updates, not long
[00:08] <fbond> slangasek: Right, that is my concern (and maybe I'm being nitpicky).
[00:08] <slangasek> is it really a bad thing if you end up with an extra security update in your snapshot compared to the Ubuntu point release?
[00:09] <fbond> slangasek: Um, no, I suppose not.  Okay, you're right, I can live with that.
[00:09] <fbond> In that case, I only need the most recent release now.
[00:09] <fbond> (I'm not making retroactive releases.)
[00:09] <fbond> I can pull it myself for future releases.
[00:10] <fbond> slangasek: Err, not the most recent.
[00:10] <fbond> The most recent hardy point release.
[00:11] <fbond> 8.04.3, then.
[00:19] <slangasek> fbond: http://people.canonical.com/~vorlon/8.04.3
[00:26] <fbond> slangasek: Thanks, that's perfect!
[00:26] <dtchen> TheMuso: i've rolled a newer git snapshot of PA due to the last-minute fixes; it WFM in lp:~ubuntuaudiodev/pulseaudio/ppa
[00:27] <TheMuso> dtchen: Ok thanks.
[00:28] <TheMuso> dtchen: I'll fetch the orig from the ppa and use what you committed to bzr.
[00:29] <dtchen> TheMuso: great, thanks
[00:35] <sbeattie> bryce: bah, xorg-server upload failed to build due to: libdrm-dev: Depends: libdrm-radeon1 (= 2.4.12+git20090801.45078630-0ubuntu1) but it is not installable
[00:36] <cjwatson> sbeattie: fixed archive-side; should succeed if retried in ~1.5 hours
[01:29] <Ampelbein> cjwatson: could you do a promotion of libpolkit-gtk-1-dev to main? the source (https://edge.launchpad.net/ubuntu/+source/policykit-1-gnome) is already in it and it is needed for the gnome-system-tools build to start.
[01:30] <TheMuso> Ampelbein: I think he has gone to bed.
[01:31] <TheMuso> GOing by a comment he made in #ubuntu-installer.
[01:31] <Ampelbein> TheMuso: oh, ok. i think it can wait till tomorrow.
[01:31] <Ampelbein> thanks
[01:33] <jtimberman> how often does the NEW queue get reviewed by AA?
[01:43] <kees> jtimberman: AA queue is processed daily, but source and binary NEW can take longer sometimes.
[01:43] <jtimberman> kees: I only ask because I'm eager for my packages to get into Universe before Karmic Feature Freeze.
[01:45] <kees> jtimberman: I suspect if they're uploaded before FF, you'll be okay, but I'm not an archive admin, so I may be wrong.
[01:47] <jtimberman> kees: Here's hoping. They were advocated / uploaded to new by at least one AA each, so I'd think they're fine at this point :-)
[01:53]  * ccheney didn't realize until today that url icons could be animated
[02:15] <slangasek> siretart: the new ffmpeg package build-depends on openjpeg, which is not in main. Are you preparing an MIR for that?
[02:20] <slangasek> siretart: or should the build-dep be dropped? (I notice --enable-libopenjpeg is specifically not set in debian/confflags)
[03:07] <superm1> mathiaz, ping.  are you planning on bringing 38_scripts__mysqld_safe.sh__signals.dpatch to mysql server 5.1?
[03:07] <mathiaz> superm1: hmmm - yes.
[03:08] <mathiaz> superm1: could you open a bug task for mysql-dfsg-5.1?
[03:08] <superm1> mathiaz, sure
[03:09] <superm1> bug 418396
[04:18] <ScottK> slangasek: siretart is just about to leave/just left for 3 weeks of vacation.  I believe sistpoty volunteered to help out, but I'm pretty sure it didn't include that exact question.
[04:58] <ScottK> doko: I just uploaded the python2.5 fix in 395321, but I don't have access to your bzr repo, so please don't forget to update it.
[05:04] <ScottK> ebroder: python2.5 uploaded.  Thanks for pointing it out.
[05:08] <dtchen> as a heads-up, 2.6.31-7-generic breaks encrypted lvm really, really badly.
[05:15] <slangasek> ScottK: ah.  well, my best guess in his absence is that the openjpeg build-dep should be dropped
[05:16]  * StevenK grumbles at readline-common now wanting a version of dpkg that doesn't exist in Ubuntu
[05:19] <StevenK> Oooh, it's better. A version of dpkg that doesn't even exist in Debian.
[05:22] <Hobbsee> uh oh.  I think i upgraded my karmic yesterday, with encrypted lvm
[05:23] <TheMuso> Hobbsee: You'd be fine, since 7-generic would have only been deployed a few hours ago.
[05:23] <Hobbsee> oh, excellent
[05:23] <TheMuso> If that.
[05:25] <StevenK> slangasek: Have you heard about the readline-common issue?
[06:02] <slangasek> StevenK: only what you've said here; but looking at the dep, I see only that it wants dpkg (>= non-existent-version) | install-info
[06:02] <slangasek> StevenK: so where is this failing?
[06:46] <dholbach> good morning
[06:48] <highvoltage> good morning dholbach
[06:48] <dholbach> hola highvoltage!
[06:53] <pitti> Good morning
[07:00] <siretart> slangasek: I've already dropped the build-dep on openjpeg in my packaging branch
[07:01] <siretart> doh, I've dropped yasm, not openjpeg. but yasm is in the same situation...
[07:14] <slangasek> siretart: hmm, I didn't notice yasm in components-mismatches, but ok:)
[07:14] <siretart> slangasek: uploading new package with same version number now
[07:15] <slangasek> what do you mean, same version number?
[07:15] <slangasek> ffmpeg wasn't in new, reuploading with the same version number will be rejected
[07:16] <siretart> oh, doh
[07:16]  * siretart just wike up. sorry
[07:18] <siretart> uploading ffmpeg_0.5+svn20090706-1ubuntu2 now...
[08:17] <tkamppeter> Any bluez expert around?
[09:25] <lool> kees: Assigned you to LP #418223; good to go for me but related to web services security so I'd prefer if you'd have a look
[09:25] <lool> (C library)
[09:32] <ogra> doko, the deps in readline-common on dpkg 1.15.4 break image builds, are you updating dpkg too ?
[09:32] <ogra> doko, (we have 1.15.3.1ubuntu1 atm)
[09:38] <cjwatson> ogra: hope not, it's not released upstream yet
[09:38] <ogra> ouch
[09:38] <ogra> well, then the dep needs to be bumped down
[09:39] <ogra> (if that doesnt break readline indeed)
[09:39] <cjwatson> be careful of http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo
[09:40] <ogra> hrm, all that extra fun ...
[09:41] <ogra> do we actually *need* the new readline ?
[10:10] <iulian> Could someone please moderate my mail sent to ubuntu-desktop?
[10:19] <doko> cjwatson, ogra: this is lintian's suggestion. should we just turn around the dependency for now?
[10:20] <ogra> i'd be fine with that but dont know how the install-info changes cjwatson referred to might break then
[10:22] <cjwatson> lintian may be running a little ahead of implementation
[10:23] <ogra> ah, well, then lets just give it a try
[10:23]  * ogra prepares a package with flipped dep
[10:49] <cjwatson> ogra,doko: see also http://bugs.debian.org/538665 which was the policy bug
[11:16] <quadrispro> james_w: hi! are you around here?
[11:16] <james_w> yeah
[11:19] <quadrispro> james_w: regarding bug #417631, I received a mail from Harry Rickards right now, he updated the debian/control again and I need to re-upload the package, so please drop lives from the queue
[11:19] <ogra> cjwatson, hmm, d-i seems not happy with the new naming scheme of imx51
[11:19] <james_w> quadrispro: what queue?
[11:19] <quadrispro> karmic NEW, I think
[11:20] <ogra> i wonder why it picks up dove just fine with the high abi number
[11:21] <cjwatson> ogra: dunno, can one of you guys figure it out?
[11:21] <ogra> just looking
[11:21] <SteveA> I just updated my desktop machine and now X won't start.  Failed to load module "nvidia".
[11:22] <ogra> cjwatson, looks like NCommander hardcoded all armel versioning to 2.6.31-200 ignoring subarches :/
[11:22]  * ogra digs around
[11:23] <SteveA> commenting out the nvidia line in xorg.conf gets me X
[11:24] <ogra> ah, no i'm wrong, phew
[11:24] <cjwatson> ogra: no, not as far as I can see - he put it in build/config/armel/dove.cfg
[11:24] <ogra> yep
[11:25] <quadrispro> james_w: the package is lives_1.0.0-4ubuntu1
[11:25] <james_w> rejected
[11:25] <quadrispro> thanks!
[11:25] <StevenK> SteveA: What happens when you 'sudo modprobe nvidia' ?
[11:26] <SteveA> StevenK: sorry -- too late. I got X working by commenting out the line mentioning nvidia in xorg.conf, then started x with startx.  Then I tried turning on Visual Effects in the Appearance Preferences
[11:27] <SteveA> it asked me if it's okay to download and install a driver, so I clicked okay, entered my sudo password
[11:27] <SteveA> and it's downloading and installing a driver
[11:28] <SteveA> it's now asking me to restart the computer in a very confusing an round-about way
[11:29] <SteveA> StevenK: I just stopped x.  If I do "sudo modprobe nvidia" I get the response FATAL: Module nvidia not found.
[11:30] <StevenK> SteveA: This is on Karmic?
[11:30] <SteveA> yes, latest packages from the archive
[11:30] <SteveA> 64 bit
[11:39] <SteveA> StevenK: after rebooting, I still don't get X.  X tries to load the nvidia module, but cannot, because it is not found.
[11:40] <StevenK> SteveA: Is the 'nvidia-common' package installed?
[11:40] <ogra> sigh, why doesnt bzr tags spit out its list ordered by commit ?
[11:40] <SteveA> yes, apt-cache policy reports 0.2.15
[11:40] <StevenK> ogra: | sort -k 2 ?
[11:41] <ogra> pfft, it should do that iself
[11:41] <ogra> instead of ordering by tag
[11:43] <StevenK> SteveA: That's odd. File a bug using 'ubuntu-bug nvidia-common'
[11:44] <pitti> tkamppeter: I removed hal-cups-utils from karmic FYI, no reverse dependencies any more, and it's obsolete
[11:44] <tkamppeter> pitti, OK, thanks.
[11:45] <tkamppeter> pitti, others to remove are foomatic-db-hpijs and cupsddk
[11:45] <cjwatson> Keybuk: FYI I'm just uploading a debhelper 7.3.15 merge now, mostly because it has a bunch of other stuff I want, but it also includes some changes to dh_installudev. I've merged it very carefully and test-built it with two packages one of which uses --priority and one of which doesn't; some autoscript code changes but I think the changes are correct. If you notice any weirdness, though, please let me know ...
[11:45] <Keybuk> ok will do
[11:45] <pitti> tkamppeter: cupsddk not before the new cups is uploaded, no?
[11:46] <tkamppeter> pitti, yes
[11:46] <pitti> tkamppeter: the printconf and ebox-printers packages still depend on foomatic-db-hpijs (plus some *-desktop packages which are just seed fixes)
[11:48] <tkamppeter> pitti, do printconf and ebox-printers depend on foomatic-db? The functionality of our current foomatic-db-hpijs package is completely replaced by foomatic-db.
[11:49] <pitti> tkamppeter: they do apparently
[11:49] <tkamppeter> pitti, if so, it is enough to let printconf and ebox-printers depend only on foomatic-db.
[11:49] <pitti> tkamppeter: ok, so I'll remove the package; would you mind uploading these two with the dependencies dropped?
[11:49] <pitti> (both universe)
[11:50] <tkamppeter> pitti, I can do so.
[11:50] <pitti> tkamppeter: thanks; removed
[11:50] <tkamppeter> pitti, are the two maintained upstream?
[11:50] <pitti> tkamppeter: I don't know, but it's a packaging-only change anyway, I guess
[11:51] <pitti> I don't know whether that functionality merging was done in debian, though
[11:51] <tkamppeter> printer setup tools directly depending on Foomatic smell like CUPS 1.1.x.
[11:51] <pitti> printconf sounds stale, ebox I'm not sure about
[11:52] <pitti> tkamppeter: I blacklisted it now, so that it won't come back through autosyncs
[11:52] <sistpoty|work> cjwatson: do you maintain p-a-s for ubuntu? If so, could you please restrict faumachine to amd64 i386 lpia? (needs to get ported to non-x86 arches, which is sadly non-trivial)
[11:52]  * ogra thought we dont have our own p-a-s
[11:53] <sistpoty|work> ogra: we certainly do, as faumachine is restricted to amd64 i386 in debian
[11:53] <sistpoty|work> (and I still get failed build logs from ubuntu from time to time)
[11:53] <tkamppeter> pitti, printconf (source package name foomatic-gui) is synced with Debian and it seems that Debian is also upstream, as there is no .diff.gz.
[11:54] <Keybuk> cjwatson: heh, looks like automake1.11 clobbers the old automake1.10 package
[11:55] <cjwatson> Keybuk: I just sponsored a merge of the updated automake1.10 from Debian that creates an automake1.10 binary
[11:55] <Keybuk> ahh
[11:55] <Keybuk> I was about to do one
[11:55] <Keybuk> heh
[11:55] <cjwatson> sistpoty|work: 'bzr checkout lp:~ubuntu-core-dev/packages-arch-specific/ubuntu'
[11:56] <Keybuk> and suddenly your 11:16 mail turns up
[11:56] <cjwatson> sistpoty|work: please forward any changes made there to Debian
[11:56] <sistpoty|work> cjwatson: oh, cool, thanks! will do
[11:56] <SteveA> StevenK: thanks.  bug 418521
[12:03] <sebner> pitti: grr, I'd like to but I can't provide the information you need (comment 42, external SATA USB thing)
[12:04] <pitti> sebner: oh, still broken even with the udev rules moved aside?
[12:04] <sebner> pitti: no, moving aside the rules worked *always* but this is still the "workaround" and I can't provide you information to debug it :\
[12:05] <pitti> sebner: why? calling skdump doesn't work?
[12:05] <SteveA> how odd... my machine isn't shutting down properly either
[12:05] <sebner> pitti: yep, I told you some weeks ago: Failed to open disk /dev/sdb: No such file or directory  (sdb is sane, but safely tried sdb1 too)
[12:06] <pitti> sebner: if you still get USB timeouts even with the udev rules moved aside, this seems like a completely different problem then, and a real kernel bug
[12:06] <pitti> hmm
[12:07] <Laney> If I p-a-s ghc6 to non-ia64, will I also have to list all of the rdeps too?
[12:07] <pitti> Keybuk: (reviewing sreadahead) uh, you really don't like patch systems, do you?
[12:08] <Keybuk> pitti: no
[12:08] <Keybuk> I like revision control systems
[12:08] <sebner> pitti: It was working some time ago though
[12:08] <Keybuk> bzr diff lp:sreadahead lp:~ubuntu-core-dev/sreadahead/ubuntu
[12:09] <pitti> Keybuk: it's promoted now; should I demote or remove readahead?
[12:09] <Keybuk> you can remove if you like ;-)
[12:09] <pitti> it's just the metapackages sucking it in, no real rdepends
[12:09] <Keybuk> yeah
[12:10] <pitti> ok, then away with it :)
[12:12] <pitti> so i'll rebuild meta once the main promotion gets published
[12:13] <sebner> pitti: ok, strange thing. Pluggin in works now. pops up in /media etc. But if I run skdump etc it get's ejected etc. I can use it if I power off the the external harddrive and re-plug
[12:13] <pitti> sebner: right, that behaviour of skdump is what upstream is interested in (together with the output)
[12:13] <pitti> is jmicron:/dev/sdb any better?
[12:14] <sebner> pitti: both suck. Either Failed to open disk jmicron:/dev/sdb: No such device or Failed to open disk /dev/sdb: Invalid argument
[12:14] <pitti> ok; well, if /dev/sdb isn't even present it won't work at all, of course
[12:16] <sistpoty|work> Laney: yes, as ghc6 then won't be available on ia64...
[12:16] <sebner> pitti: As I said, I start the commands, disk gets ejected, fail messages appear
[12:16] <pitti> sebner: right, please copy the output and dmesg and describe the behaviour in the bug report, I'll forward it to upstream
[12:17] <sebner> pitti: dmesg before or after the eject?
[12:17] <pitti> after
[12:17] <sebner> pitti: aye aye Sir
[12:18] <sistpoty|work> Laney: however we still have 6.8.2 (binary) on ia64 available, so I don't think p-a-s for ghc6/ia64 is the right thing
[12:25] <sebner> pitti: grr LP is slow :P· done :)
[12:28] <Keybuk> HAHA! I get a Timeout Error whenever I visit bugs.lp/~scott
[12:28] <Keybuk> no more bug fixing for _me_ today :D
[12:29] <sistpoty|work> Keybuk: I can send you a screenshot :P
[12:30] <Daviey> Keybuk: AFAIK .lp isn't a TLD.. so no wonder you are having issues. :)
[12:31] <Keybuk> Daviey: well, ICANN are saying they'll let anyone buy TLDs
[12:31] <Keybuk> then we *could* have .lp
[12:31] <Keybuk> and .egg
[12:31] <Daviey> !
[12:31]  * Daviey hides.
[12:41] <Keybuk> bdmurray: is Pedro away today?
[12:57] <Laney> sistpoty|work: I thought a b-d on a p-a-sed package would have that effect
[12:57] <Laney> and I'm just a bit wary about having an outdated binary that we can't fix
[12:58] <sistpoty|work> Laney: a b-d is only a b-d. it will fail if the package is unavailable. Otherwise you'd need to have a b-d with an arch-restriction ala ghc6 [amd64 i386 ... ]
[12:58] <sistpoty|work> Laney: but there aren't any plans to drop support for ia64 entirely in ghc6, are there?
[12:59] <Laney> no
[12:59] <sistpoty|work> Laney: having the old version is imho still better than nothing, as otherwise we'd need to bootstrap ghc6 on ia64 again (or rather pester a buildd admin with that), once it's working ok
[13:00] <Laney> nah, ghc's buildsystem can handle that
[13:00] <sistpoty|work> oh, cool, so that changed nowadays :)
[13:00] <Laney> it builds itself in two stages
[13:00] <Laney> stage 1 can use an existing ghc, but I don't think we do that for our builds anyway
[13:01] <Laney> https://lists.ubuntu.com/archives/ubuntu-devel/2008-December/027076.html - see from "But please aware"
[13:01] <Laney> makes me think that it does cascade through build-deps
[13:04] <sistpoty|work> Laney: I don't think so, but that this rather refers to an arch restricted b-d line of mono
[13:04] <Laney> dunno
[13:31] <sebner> pitti: the error with jmicron was done *after* unplugging/replugging the drive  ;)
[13:36] <Keybuk> urgh
[13:37] <Keybuk> pitti: the majority of bugs filed against udev are now keyboard related
[13:37] <Keybuk> lol
[13:40] <sebner> pitti: btw, new bug filed #418571
[13:40] <sebner> pitti: grr, bug 418571
[13:45] <pitti> sebner: hm, I thought you said that'd make /dev/sdb appear
[13:45] <pitti> sebner: thanks
[13:46] <sebner> pitti: nope, with both commands, the drive disappears/gets ejected
[13:47] <pitti> sebner: ah, so /dev/sdb existed before, and if you do the skdump jmicron:/dev/sdb you actually get that "doesn't exist" error message, even though it did exist before?
[13:48] <sea-gull> why .pc files are included in *-dev packages?
[13:48] <pitti> sea-gull: where else would they be?
[13:48] <sebner> pitti: right ^^, I move the rules thing away and the plug the harddrive in and it appears in /media which means that /dev/sdb is present. If I run these commands sdb is ejected which (I think?) leads to this error messages
[13:49] <pitti> sebner: ah, ok; thanks; that wasn't clear; can you please get an strace of the jmicron one as well?
[13:49] <sebner> pitti: sure
[13:49] <sea-gull> pitti: for example, why pango.pc is included in libpango-dev, no in libpango?
[13:49] <sea-gull> pitti: if we're installing lib then it should be possible to link them
[13:50] <sea-gull> pitti: why do I need *-dev package if I don't change the sources?
[13:51] <pitti> sea-gull: the .pc file isn't necessary at runtime
[13:51] <pitti> just if you build apps against a library, in which case you'll need the other files in -dev as well (header files, and the .so at least, but also the pkgconfig file)
[13:52] <sea-gull> pitti: hm, right. I forgot about header files: it's logical that they're in -dev.
[13:52] <sebner> pitti: attached
[13:53] <pitti> sebner: danke
[13:54] <sebner> pitti: gerne :), Why do I have a different problem but the same error messages (-71), moving rules works around etc?
[13:57] <pitti> sebner: you said that after moving the udev rules away, pluggin in the device would still get timeouts and missing /dev/sdb for you
[13:57] <pitti> that isn't what this bug is about
[14:02] <sebner> pitti: nah, I said moving udev rules away and plugging in makes the drive to appear and make it usable so no timeouts. xD You should really read more carefully xD
[14:04] <pitti> sebner: right, and the other issue is that other people didn't get their hd ejected with skdump; the command actually succeeded, but caused usb resets afterwards
[14:04] <sebner> pitti: right
[14:05] <pitti> well, this bug has become pretty confusing anyway, with different people having different results, so it's easier to track each problem separately
[14:06] <sebner> right
[14:07] <sebner> pitti: anyways, I'm off now. still thankful for all your work
[14:19] <ttx> ubuntu-archive: I reviewed component-mismatches for any Eucalyptus-related MIR that I would have missed -- I don't get why the old "eucalyptus-javadeps" stills shows in the list, however. It generates a lot of bogus entries.
[14:19] <ttx> it says [Reverse-Depends: eucalyptus-cloud] but it's no longer true
[14:20] <james_w> since when?
[14:20] <ttx> since Monday. and eucalyptus was added to seed after that.
[14:20] <james_w> "Generated: Tue Aug 25 13:35:02 BST 2009"
[14:20] <james_w> ok
[14:21] <ttx>  /scary/ bogus entries, I might add.
[14:24] <cjwatson> because it's out of date on ia64. component-mismatches checks all architectures.
[14:25] <soren> Oh? I didn't think it ever built on ia64.
[14:26] <soren> I only checked i386, amd64, lpia.
[14:26] <soren> cjwatson: How do you check that easily? rmadison only shows amd64 and i386.
[14:26] <cjwatson> lp_archive@cocoplum:/srv/launchpad.net/ubuntu-archive/ubuntu-germinate$ grep ^eucalyptus-javadeps all_*
[14:27] <cjwatson> :-)
[14:28] <soren> cjwatson: Ah :)
[14:28] <cjwatson> (only ask questions whose answers you believe you will like)
[14:29]  * soren needs to adjust his expections
[14:39] <Keybuk> I hate looking at e2fsprogs git
[14:40] <Keybuk> it's so utterly confusing
[14:40] <Keybuk> I think Ted does it deliberately
[14:40] <Keybuk> he has three branches "master", "next" and "maint"
[14:40] <Keybuk> and ALL THREE are tagged with the release number
[14:40] <Keybuk> but the release may be off any one of them
[14:44] <directhex> you'd prefer a naming scheme like "donut" "eclair" and "flan"?
[14:45] <evand> he would
[14:45] <ogra> yummy
[14:46] <jtimberman> Any AA able to accept for upload new packages chef, merb, stompserver for Karmic?
[14:46] <ScottK> jtimberman: They just need to be uploaded by feature freeze, they can go through New after.
[14:47] <Keybuk> directhex: I'd prefer names like "stable" or "v1.14" ;)
[14:47] <Keybuk> and I'd prefer "patches that are headed for 1.14.x go into one branch, and ALL 1.14.x releases are made off that branch"
[14:48] <jtimberman> ScottK: If there's any last minute / final changes required, that's okay?
[14:48] <ScottK> jtimberman: Bug fixes can come after.
[14:48] <ScottK> That includes getting rejected and having to upload again.
[14:48] <jtimberman> ScottK: Cool. It wasn't clear to me.
[14:49] <Amaranth> ah, feature freeze
[14:49] <Amaranth> aka "upload new broken stuff and claim everything afterward is just a bug fix" :)
[14:50] <ScottK> Let's see, compiz hacker, right?
[14:50]  * Amaranth hides
[14:50] <Amaranth> ScottK: We've been stuck on that second step for a couple years ;)
[14:52] <cjwatson> which reminds me, better get my arse in gear with man-db 2.5.6
[14:53] <jtimberman> Amaranth: Hopefully not for Chef! I work for the company that wrote it, and I've tested it w/ the packages *quite* extensively.
[14:53] <Amaranth> jtimberman: oh, not talking about your stuff specifically
[14:53] <Amaranth> but there are two times my karmic system is most likely to stop working: initial debian import and feature freeze :P
[14:53] <jtimberman> Amaranth: I'm sure, I was interjecting anyway ;)
[14:54] <jtimberman> Hopefully not due to optional packages in universe :D
[15:07] <jdstrand> dholbach: hi! so, I've got ufw being translated in LP (https://translations.launchpad.net/ufw/trunk) and want some advice. As an upstream, I'd like to include these translations in my upstream tarball. However, some are far from complete. In your opinion, is it better to include only the mostly translated ones or to include all (to possibly encourage others to participate)?
[15:08] <dholbach> jdstrand: you could ask pitti, afaik there's some sniplet of code that takes care of that
[15:08] <dholbach> hey mako
[15:08] <dholbach> pitti: where was that code again - was it in ubuntu-docs?
[15:10] <mako> dholbach: hey there
[15:16] <jdstrand> dholbach: thanks, I'll wait for pitti :)
[15:24] <Tonio_> siretart: ping ?
[15:25] <siretart> Tonio_: pong
[15:25] <Tonio_> siretart: don't know if you saw my messages yesterday, but there is a pretty hdge problem with ffmpeg...
[15:26] <Tonio_> siretart: seen them ?
[15:27] <Tonio_> siretart: the unstripped packages have been removed, but there are still internal deps on it
[15:27] <siretart> Tonio_: note sure, but did you recheck after my latest uploads have been accepted? and did you read my recent mail to ubuntu-devel?
[15:27] <Tonio_> siretart: see for example : sudo apt-get install libavformat-dev libavformat-unstripped-52
[15:28] <Tonio_> siretart: hum no I didn't check out today, let me have a look :)
[15:28] <siretart> Tonio_: if you have some time, please change ubuntu-restricted-extras to depend on 'libavcodec-extra-52'. The other packages (avutil, avformat) are pretty identical to their counterparts in main. no need to depend on them AFAIUI
[15:29] <siretart> it might still make sense to help apt's dependency solver, though
[15:29] <Tonio_> siretart: yes that was my plan (also with kubuntu)
[15:29] <siretart> thanks
[15:29] <Tonio_> but probably the conditional deps on the unstripped packages hould be dropped from the control file in ffmpeg package right ?
[15:30] <siretart> they are auto generated by dpkg-shlibdeps
[15:30] <Tonio_> siretart: nope :)
[15:30] <siretart> they are :-)
[15:30] <siretart> ah, not in the metapackage, right
[15:31] <Tonio_> siretart: Depends: libavcodec52 (>= 4:0.5+svn20090706-1ubuntu2) | libavcodec-unstripped-52
[15:31] <siretart> this comes from the .shlibs file
[15:32] <Tonio_> siretart: hum you don't get my point I think :) afaics, this is simply manually added to the control file
[15:33] <siretart> tell me the line, then
[15:33] <Tonio_> siretart: 161 for example
[15:34] <TonyTheTiger> hey can someone help me write a driver for the xbox 360 hori ex2 fighting stick.
[15:34] <siretart> oh, for the -dev packages only. right
[15:34] <siretart> doh, you're right. after the rename these deps need to be updated as well. my bad
[15:34] <Tonio_> siretart: yep
[15:35] <Tonio_> siretart: will you do that or should I ?
[15:35] <Tonio_> I'll take care of the ubuntu restricted packages
[15:35] <siretart> I'm on it
[15:35] <Tonio_> great
[15:36] <siretart> OTOH, the provided transitional packages should prevent further damage...
[15:39] <ScottK> siretart: Did you see slangasek's question last night about ffmpeg depends?
[15:40] <siretart> ScottK: I've seen his mail on the mailing list...
[15:40] <ScottK> OK.
[15:40] <ScottK> He also had another on last nigh.
[15:40] <ScottK> t
[15:40] <ScottK> Let me see if I can find it.
[15:40] <siretart> ScottK: ah, that was about libopenjpeg. already fixed this morning
[15:41] <ScottK> OK.  Good.
[15:41] <ScottK> That's the one.
[15:49] <pitti> jdstrand: for my projects I usually just download the entire translation tarball for my project and add them
[15:49] <pitti> jdstrand: but if you want to go ahead and only select well-translated ones, that's possible of course
[15:49] <Tonio_> ScottK or siretart, any idea where the sources for the restricted-extra packages are stored ?
[15:50] <pitti> jdstrand: it won't affect the langpacks, though, they just take everything
[15:50] <jdstrand> pitti: re langpacks> ack
[15:50] <Tonio_> it is structure like a seed package, so I suspect there's a bzr branch somewhere, but I can't find it, therefore not fix it :)
[15:50] <pitti> jdstrand, dholbach: I'm not aware of a script; however, nowadays LP can create a "translation branch" for you which you can just merge from
[15:50] <jdstrand> pitti: what is your reasoning to import all of them?
[15:50] <pitti> jdstrand: partly "common practice", partly "I don't want to check and judge"
[15:51] <jdstrand> pitti: heh, fair enough. I'll do the same. thanks! :)
[15:51] <siretart> Tonio_: apt-get source kubuntu-restricted-extras works just fine for me
[15:52] <Tonio_> siretart: yep, sure, I was just wondering if there's a place to commit to :)
[15:53] <siretart> no VCS field, no commit
[15:53] <dholbach> jdstrand, pitti: http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-docs/ubuntu-karmic/annotate/head%3A/debian/rules
[15:54] <Riddell> Tonio_: I'm pretty sure there sin't
[15:54] <Riddell> isn't
[15:54] <jdstrand> dholbach: cool, thanks :)
[15:55] <Tonio_> Riddell: oki :)
[15:55] <pitti> dholbach: how does that fetch translations from LP?
[15:55] <tkamppeter> pitti: I have uploaded foomatic-gui and ebox-printer without foomatic-db-hpijs dependency now. foomatic-gui is not completely obsolete. It is not recommended for CUPS 1.2 and newer, nowadays it servs for users of non-CUPS spoolers, like the LPRng in Debian and in Ubuntu Universe.
[15:55] <pitti> tkamppeter: I saw, thank you
[15:56] <dholbach> pitti: I dunno
[15:57] <tkamppeter> superm1: hi
[15:59] <pitti> tkamppeter: oh, can you please put your cups 1.4 orig.tar.gz somewhere? (I guess it's an svn snapshot with autoconf etc. run, but I'd rather use your tested one)
[16:01] <tkamppeter> pitti, should be on http://www.linuxfoundation.org/~till/tmp/cups_1.4.0~svn8773.orig.tar.gz now. Please wait for my upload to complete.
[16:07] <pitti> tkamppeter: I'll use "pkg-config --atleast-version=0.11 poppler", that should suffice as test whether to apply the patch, right:?
[16:15] <tkamppeter> pitti, yes. Only Ubuntu-only dependency of pdftoopvp is Poppler 0.11.x.
[16:21] <tkamppeter> pitti, the tarball is completely uploaded. Did you already download it?
[16:21] <ScottK> Tonio_: Just in the archive, AFAIK
[16:21] <Tonio_> ScottK: yup seems like :)
[16:22] <pitti> tkamppeter: got it
[16:23] <pitti> tkamppeter: I re-added the ubuntu check to ubuntu-disable-browsing.dpatch, too; should be okay now
[16:28] <tkamppeter> pitti, sorry, I have overlooked that there was a check in the patch when I have regenerated all the patches.
[16:31] <tkamppeter> pitti, please remove the entry "Everything except the handling of the now integrated CUPS DDK is done." from the beginning of the debian/changelog, I have forgotten to remove it.
[16:33] <pitti> tkamppeter: done
[16:34] <pitti> tkamppeter: hm, package FTBFSes for me
[16:35] <tkamppeter> pitti, what did you change in debian/control?
[16:35] <pitti> tkamppeter: I added the pkg-config b-dep
[16:35] <pitti> tkamppeter: http://people.canonical.com/~pitti/tmp/cups_1.4.0~svn8773-1_i386.build -> do you get the same?
[16:36] <tkamppeter> pitti, I have built it without your changes (my commit of yesterday evening) on my current Karmic and there it works.
[16:38] <pitti> tkamppeter: hm, i just reenabled pdftoopvp
[16:38] <pitti> something seems to be utterly wrong with the test sutie
[16:38] <pitti> E [25/Aug/2009:17:38:06.297790 +0200] [cups-driverd] Bad driver information file "/usr/share/ppd/openprinting/Kyocera/ReadMe.htm"!
[16:38] <pitti> E [25/Aug/2009:17:38:06.587960 +0200] [cups-driverd] Skipping "/usr/share/ppd/1-local-admin": loop detected!
[16:39] <sebner> pitti: I'm wondering if both traces are useful for you. jmicron one is a funny one with: write(2, "Failed to open disk jmicron:/dev/sdb: Success\n", 46) = 46
[16:39] <tkamppeter> This has nothing to do with the presence of pdftoopvp. Problem is the following:
[16:40] <pitti> lrwxrwxrwx 1 root root 20 2009-07-31 20:59 /usr/share/ppd/1-local-admin -> /usr/local/share/ppd
[16:40] <pitti> eww, that looks wrong
[16:41] <pitti> ah, you removed them from postinst already
[16:41] <tkamppeter> The links /usr/share/ppd/1-local-admin and /usr/share/ppd/2-third-party make parts of the PPD repo read twice by CUPS. CUPS finds inodes which it has already read and thinks there is a link loop. For this it logs an error message.
[16:42] <tkamppeter> In addition, from CUPS 1.4.0 on no non-PPDs in the PPD repo are permitted.
[16:42] <pitti> tkamppeter: so if I have openprinting-ppds installed, cups' test suite fails?
[16:42] <pitti> is that a bug in the test suite, in cups, or in openprinting-ppds ?
[16:43] <tkamppeter> You have to manually delete /usr/share/ppd/1-local-admin, /usr/share/ppd/2-third-party, and /usr/share/ppd/openprinting/Kyocera/ReadMe.htm, then CUPS will build.
[16:43] <pitti> (I guess in openprinting-ppds)
[16:43] <pitti> tkamppeter: so perhaps the Readme should be moved to /usr/share/doc/ ?
[16:43] <tkamppeter> Once it is a bug of the test suite, it should not check the health of the system but only of the CUPS package.
[16:43] <pitti> *nod*
[16:44] <tkamppeter> Second, the 2 links are part of CUPS. I have modified the maintainer scripts of CUPS to drop these links.
[16:45] <bdmurray> Keybuk: I don't believe so
[16:45] <tkamppeter> Third, the /usr/share/ppd/openprinting/Kyocera/ReadMe.htm is part of openprinting-ppds, source package foomatic-db. I will upload a fixed version today or tomorrow.
[16:45] <pitti> DktrKranz, pochu: congrats to your new DD badge!
[16:45] <pitti> tkamppeter: ok, great; thanks!
[16:46] <pochu> pitti: :D thanks!
[16:46] <tkamppeter> pitti, can you report a CUPS STR on the test suite? The test suite's results should not depend on the installed system, but only on the CUPS package itself.
[16:46] <pitti> tkamppeter: so now it just fails with "PPD import FAILED"
[16:46] <pitti> Dateien ppd/stcolor.ppd und ppd2/stcolor.ppd sind verschieden.
[16:46] <pitti> etc.
[16:46] <ogra> evand, is usb-creator to do anything if i give it a .img file and point it to my SD mmc card ? i seem to just get a stuck progressbar window
[16:47] <pitti> tkamppeter: can do, it should use the local ppd directory only indeed
[16:47] <evand> ogra: is there anything relevant in /var/crash or ~/.usbcreator.log?
[16:48] <ogra> its sittring there, i doubt it created any crash report
[16:48]  * ogra digs
[16:48] <tkamppeter> pitti, this one I did not get. Does CUPS ship ready-made PPDs of its sample drivers and tries to regenerate them from its .drv file?
[16:48] <tkamppeter> pitti, perhaps it uses system resources here, too.
[16:48]  * pitti tries to buildl with C locale
[16:49] <DktrKranz> pitti: thanks!
[16:49] <ogra> evand, http://paste.ubuntu.com/259338/ is the log
[16:49] <tkamppeter> I succeeded to build CUPS on Ubuntu Karmic. Are you trying on Debian Unstable?
[16:49] <directhex> go go gadget jaunty
[16:50] <ogra> evand, thats an old logfile it seems, timestamp is from aug. 16th
[16:50] <pitti> tkamppeter: hah, that was it; apparently it doesn't like being run in a German locale
[16:50] <evand> ogra: what version are you using?
[16:50] <pitti> tkamppeter: I'll report this, too
[16:50] <tkamppeter> pitti, one should do away with translated logs, the cause a lot of problems, including bug reports which are not understandable.
[16:50] <ogra> evand, 0.2.2
[16:51] <pitti> tkamppeter: I guess the tests regenerate the PPDs somehow and compare them to the original, to ensure that the regeneration works; but that introduces German strings, causing them to differ
[16:51] <tkamppeter> pitti, my boxes are all set up in English.
[16:51] <pitti> tkamppeter: s/I guess/it looks like/
[16:51] <tkamppeter> pitti, strange that these PPDs are not globalized.
[16:51] <lool> pitti: Hey would you mind looking at NEW binaries for linux-meta-mvl-dove on armel?
[16:52] <pitti> tkamppeter: "globalized"? it does use the local ppds for the tests, as it seems
[16:52] <pitti> lool: to main, I presume?
[16:53] <lool> pitti: Yes
[16:53] <lool> pitti: Thanks a lot
[16:53] <tkamppeter> pitti: Globalized PPDs are an invention of Mike Sweet, PPDs containing translations into many languages, see CUPS PPD extensions.
[16:54] <tkamppeter> Perhaps I am promoting them more than Mike, once having moved the Gutenprint project to use them and second supporting them in the Common Printing Dialog.
[16:54] <pitti> lool: ugh, that's an entirely new kernel
[16:55] <lool> pitti: Yes, like linux-fsl-imx51
[16:55] <lool> pitti: I'm sorry you discover about this now; the kernel team discussed this plan with slangasek during the sprint I believe
[16:56] <lool> pitti: I just know I need the new meta packages for the dove image build for A5  :)
[16:56] <pitti> lool: yes, I heard about it, don't worry
[16:56] <lool> Ok cool
[16:56] <pitti> it'll just take a bit more than 30 seconds, that's what I meant
[16:56] <lool> Ok
[16:56] <tkamppeter> pitti, all you FTBFS problems should not occur on the build servers, they should not have CUPS and openprinting-ppds installed, and they should also use English locale.
[16:57] <pitti> tkamppeter: right, but I like the package to be buildable on my system, too :)
[16:57] <pitti> I'll fix the locale issue
[16:57] <pitti> W: libcupsppdc1-dev: spelling-error-in-changelog contraints constraints
[16:57] <pitti> wow, lintian is really good these days
[16:57] <superm1> hi tkamppeter, what's up?
[16:58] <tkamppeter> piit, me too. Would be bad to run a pbuilder only to try out a small fix.
[16:59] <tkamppeter> superm1, it is an incompatibility of bluez with the new CUPS 1.4, bug 418465.
[17:00] <tkamppeter> The thing what has to be done is that the bluetooth CUPS filter should run less than 10 seconds in discovery mode.
[17:00] <pitti> tkamppeter: hm, it's not just translations, indeed most of the numbers in the ImageableArea are wrong; I'll file a bug upstream
[17:01] <tkamppeter> superm1: One would need to set its timeout to 8 seconds, so that it finishes in less then 10 seconds.
[17:01] <tkamppeter> pitti: Then I am wondering why the tests got passed for me.
[17:01] <pitti> tkamppeter: you aren't usin German locale
[17:02] <tkamppeter> pitti: The numbers in ImageableArea change with locale?
[17:02] <pitti> apparently so
[17:03] <tkamppeter> pitti: Does a comma get inserted instead of the decimal point? Then the PPDs built on systems with non-English locale are completely broken.
[17:06] <pitti> tkamppeter: see http://www.cups.org/str.php?L3300
[17:06] <pitti> tkamppeter: no, most paper format boundaries are "0,00"
[17:10] <pitti> tkamppeter: so I won't workaround this for now, and wait for Mike's response
[17:11] <pitti> tkamppeter: but I'll upload it to Debian experimental and karmic
[17:12] <tkamppeter> pitti, the boundaries should be 0.00 and not 0,00.
[17:16] <pitti> lool: why does it produce a package "linux-headers-2.6.31-201"? that looks weird
[17:16] <pitti> or in general, why does it use such a weird abi?
[17:17] <cjwatson> pitti: can you confirm whether a blacklist in pkgstriptranslations would be a reasonable way to stop bombarding Rosetta with a load of .po files that are in the source package but shouldn't be imported?
[17:17] <cjwatson> pitti: I see that it fishes out .po files already
[17:18] <pitti> tkamppeter: in my sid chroot it fails with "E [25/Aug/2009:16:17:48.540155 +0000] [CGI] Unable to create avahi client: No such file or directory
[17:18] <pitti> tkamppeter: I guess that's just a missing build dep, like avahi-utils or so? did you happen to get this already? (if not, I'll figure it out)
[17:19] <tkamppeter> pitti, no for me all works correctly.
[17:20] <pitti> tkamppeter: urgh, I bet it needs a running d-bus or something such
[17:20] <robbiew> Keybuk: nice "inutes"
[17:20] <robbiew> heh
[17:20] <pitti> tkamppeter: you didn't test it in a pbuilder or so, I take it?
[17:20] <tkamppeter> No, no pbuilder test.
[17:21] <Keybuk> robbiew: the meeting confirmed that we couldn't agree on what "M" means
[17:21] <Keybuk> so I felt it best to omit it
[17:21] <pitti> cjwatson: right now it doesn't remove any po files, but we can certainly teach it to; what do you have in mind?
[17:21] <robbiew> lol
[17:21] <cjwatson> pitti: ubiquity/d-i/source/...
[17:22] <pitti> cjwatson: originally we said we'd be cautious, get everything, and leave it to LP to decide which it wants, so that we avoid having to rebuild a thousand packages if the importer has a bug
[17:22] <cjwatson> apparently the volume of files that have to be reviewed there is a serious problem for Arne :-/
[17:22] <Keybuk> cjwatson: boy do I have a *brilliant* bug; you'll like this one.  bug #412972
[17:22] <cjwatson> Keybuk: there's a not dissimilar bug on openssh that alleges that sshd's signal mask is wrong
[17:23] <cjwatson> I haven't looked into it yet ...
[17:23] <cjwatson> (largely because most of the analysis happened while I was on holiday)
[17:23] <Keybuk> why would that make kill() return -ESRCH though
[17:24] <Keybuk> it's the same reporter, interestingly
[17:25] <Keybuk> if it were the signal mask, the kill() should succeed from the client side but just not be delivered to the receiving side
[17:25] <Keybuk> (it'll be still queued)
[17:26] <Keybuk> to me, -ESRCH starts to imply that there's something funny with pid namespaces going on
[17:26] <cjwatson> hmm
[17:26] <cjwatson> I'd be astonished if sshd messed around with that
[17:26] <cjwatson> maybe some PAM session stuff?
[17:27] <Keybuk> dunno
[17:27] <Keybuk> the reporter says that if he runs "sleep 100"
[17:27] <Keybuk> then attempts to kill -TERM that pid, he gets -ESRCH
[17:29] <Keybuk> he hasn't elaborated which of the sleep or kill is running under ssh yet
[17:30] <pitti> lool: so, packages look okay to me except for the weird ABI; if that is intended, I'll new them
[17:33] <superm1> tkamppeter, did cups previously kill backends?
[17:33] <superm1> or just let them keep running?
[17:34] <chrisccoulson> who do i subscribe to a bug report requesting a package be demoted from main to universe?
[17:34] <Keybuk> chrisccoulson: that takes place automatically
[17:34] <Keybuk> well, entirely manually
[17:34] <Keybuk> but the people who do it manually do it automatically
[17:35] <chrisccoulson> Keybuk - so i shouldn't need to explicitly request it?
[17:36] <Keybuk> chrisccoulson: assuming that nothing in main depends on that package (including ubuntu-meta), no
[17:36] <Keybuk> it'll be flagged for removal and the archive admins will get around to it
[17:36] <chrisccoulson> Keybuk - thanks
[17:46] <mathiaz> Keybuk: hi - I've got an issue with a daemon that is using dbus
[17:46] <mathiaz> Keybuk: https://fedorahosted.org/pipermail/sssd-devel/2009-August/000257.html
[17:46] <mathiaz> Keybuk: one of the upstream dev noted it may be related to the version of libdbus in karmic
[17:47] <mathiaz> Keybuk: https://fedorahosted.org/pipermail/sssd-devel/2009-August/000261.html
[17:47] <mathiaz> Keybuk: how can I debug this thing to figure out where the problem may be?
[17:49] <Keybuk> I doubt it
[17:49] <Keybuk> it's far more likely a bug in whatever security policy they've installed with the daemon
[17:50] <Keybuk> you can rebuild libdbus with --enable-verbose-mode and then use DBUS_VERBOSE=1 to see what each end is doing
[17:50] <mathiaz> Keybuk: ok - where can I find the security policy?
[17:50] <Keybuk> /etc/dbus-1/system.d
[17:52] <mathiaz> Keybuk: hm - AFAICT there isn't any security policy installed.
[17:52] <Keybuk> then that's why it fails ;-)
[17:52] <Keybuk> if there's no security policy, then the bus daemon will *deny* all messages
[17:53] <Keybuk> tbh, it's probably even refused the service from registering any name on the bus to begin with
[17:53] <Keybuk> /etc/dbus-1/system.d/Upstart.conf is as good an example of a security policy as any
[17:54] <Keybuk> note that it's all <allow...>, because the default for everything on the system bus is <deny...>
[17:54] <ion> SSSD – more precisely, offline caching of network credentials – seems exactly what i’ve wanted for a long time.
[17:55] <mathiaz> Keybuk: great - thanks for the help.
[18:04] <Keybuk> mathiaz: in particular, note that it allows the root user to own the "com.ubuntu.Upstart" name
[18:04] <Keybuk> (even root needs permission to take a name)
[18:05] <ogra> pitti, didnt you promote the dove package today ?
[18:05] <Keybuk> and that it allows the root user to send messages to "com.ubuntu.Upstart" using the "com.ubuntu.Upstart0_6" interface
[18:05] <Keybuk> (even root needs permission to send messages)
[18:05] <pitti> ogra: I checked the dove kernel in NEW, and asked lool about the weird ABI number (201)
[18:06] <pitti> ogra: if that's intended, I'll NEW it
[18:06] <debfx> any chance pidgin 2.6.1 makes it into karmic? (bug #415908)
[18:06] <ogra> pitti, oh, i thought you promoted them to main too
[18:06] <ogra> pitti, reading my backscroll lool apparetnly only asked for de-newing
[18:07] <pitti> ogra: sure, I set it to main, but didn't accept them yet
[18:07] <ogra> oh, please do so :)
[18:07] <pitti> ogra: I asked him for "main?" and he said yes
[18:07] <ogra> the ABI numbers were chosen by the kernel team
[18:07] <pitti> ogra: okay
[18:07] <ogra> 100+ for imx51 200+ for dove
[18:08] <ogra> 300+ for netbook i think
[18:08] <ogra> or some such ...
[18:08] <ogra> pitti, the depending linux-image-dove needs to go to main too
[18:11] <pitti> ogra: hm, linux-image-dove is already in karmic universe (just -z0 are NEW)
[18:11] <pitti> was that intended?
[18:11] <ogra> no, but it happened :P
[18:11] <ogra> it was intended by the kernel team though
[18:11] <ogra> so its all fine as is
[18:12] <ogra> but we need all of that in main to build livefs'es
[18:12] <pitti> so why should one kernel be in main, the other in universe?
[18:12] <ogra> we dont build z0 images
[18:12] <ogra> and never will
[18:12] <pitti> so why shold -dove-z0 go to main, and -dove stay in unverse?
[18:12] <ogra> z0 is a dead architecture, but some of us have that board
[18:12] <pitti> that doesn't make sense to me then
[18:12] <ogra> no, all -dove to main
[18:13] <ogra> all -dove-$suffix can stay where it is
[18:13] <pitti> but that's not what happened
[18:13] <pitti> -dove *is* in karmic, and in universe
[18:13] <pitti> -dove-z0 is NEW
[18:13] <ogra> i think lool assumed the -dove stuff was in main already
[18:13] <ogra> so meta for -dove and linux-image for -dove are needed in main
[18:13] <ogra> the rest i totally dont care where it lands
[18:14] <pitti> okay
[18:14] <ogra> sorry for that chaos
[18:14] <pitti> so I'll move the existing -dove meta packages to main
[18:14] <pitti> and -z0 to universe
[18:14] <ogra> -dove and -imx51 are a mess atm
[18:14] <ogra> yes, please
[18:15] <pitti> all done
[18:16]  * ogra hugs pitti 
[18:16] <tkamppeter> superm1: Previously CUPS left backends running as long as they wanted, making device discovery very long.
[18:17] <tkamppeter> superm1: Now CUPS starts all backends at once and kills all backends which remain running after 10 seconds.
[18:17] <pitti> tkamppeter: ah, Mike ack'ed the locale bug
[18:18] <tkamppeter> superm1: So a CUPS backend must finish quicker than 10 seconds, or it must report each discovered device immediately when it discovers the device.
[18:20] <tkamppeter> pitti, great. There seem to be two problems, ',' as decimal separator and also different numbers.
[18:22] <lool> pitti: Sorry was in calls
[18:23] <lool> pitti: Kernel team said they wanted to avoid namespace clashes and so used 0/100/200 for ABI base numbers in subarches
[18:23] <pitti> lool: don't worry, all settled
[18:23] <ogra> lool, all sorted now
[18:23] <lool> pitti: I dont know why exactly since we have a prefix of imx51 or dove already, but I trust them that it's needed
[18:23] <lool> pitti, ogra: Cool thanks
[18:25] <tkamppeter> pitti, is all working with the CUPS upload now?
[18:25] <pitti> tkamppeter: got interrupted by desktop team meeting, resuming cups work now
[18:26] <tkamppeter> pitti: OK.
[18:26] <pitti> tkamppeter: no, still need to figure out the broken package build (avahi failure)
[18:26] <tkamppeter> I have added two avahi libraries to the build dependencies. Does this not do everything needed.
[18:28] <tkamppeter> pitti: ^^
[18:28] <pitti> avahi_client_new() fails
[18:28] <pitti> tkamppeter: as I said, I need to strace it and see where it fails
[18:29] <tkamppeter> pitti: Strange, I have updated my Karmic before working on CUPS 1.4.
[18:29] <pitti> tkamppeter: I already said, it only happens in a chroot or pbuilder
[18:29] <pitti> I suspect it needs some running dbus or so
[18:34] <pitti> Keybuk: udev> thanks for cleaning up my bug list
[18:35] <Keybuk> pitti: :D
[19:22] <superm1> tkamppeter, well i'm not sure where the timeout is defined, you might need to talk to upstream about it
[19:22] <superm1> it might be something like a default dbus timeout too
[19:23] <tkamppeter> superm1: The other alternative is to output a printer's entry as soon as it gets discovered.
[19:24] <superm1> tkamppeter, well i think you'll need to find out where the hang up is then first
[19:25] <tkamppeter> superm1: All output which the program produces in the first 10 seconds will be captured by CUPS, everything coming out later not.
[19:29] <cody-somerville> How do I make the fonts in the latest firefox not so ugly?
[19:32]  * ogra hands cody-somerville some nice calligraphic quill and some waterproof ink for his screen
[19:33] <cody-somerville> :)
[19:33] <mathiaz> james_w: hey - could your bump the dbus import in the packaging branch queue?
[19:34] <james_w> mathiaz: no, sorry
[19:34] <james_w> mathiaz: LP going down at the weekend caused a lot of problems for it, and I'm busy with other things to bring it back up
[19:34] <jjohansen> cody-somerville: you can try changing the default font, or try chrome
[19:34] <james_w> mathiaz: I'll try and get to it soon, but don't block on having it to do your work
[19:34] <mathiaz> james_w: sure - it's not urgent
[19:35] <cody-somerville> jjohansen, I tried but it still looks weird
[19:35] <cody-somerville> jjohansen, I wish firefox would just use the system default font like it used to
[19:35] <mathiaz> james_w: just more convenient - and I'm not blocked at all by this.
[19:35] <james_w> great
[19:35] <jjohansen> cody-somerville: yeah
[19:36] <jjohansen> cody-somerville: have you tried editing via about:config
[19:37] <cody-somerville> no
[19:39] <sgallagh> Keybuk: ping
[19:39] <ogra> cody-somerville, didnt change here
[19:39] <ogra> for me it uses the system default
[19:39] <cody-somerville> ogra, are you using firefox 3.5.2?
[19:39] <ogra> whatever fontconfig uses for sans, serif and mono
[19:39] <ogra> yup, thats what the about win says
[19:40] <ogra> looks like it always did
[19:41] <ogra> cody-somerville, probably fontconfig doesntg get along with your nvidia driver or something
[19:41] <cody-somerville> ogra, well, as soon as I upgraded, it started using font size 16
[19:42] <cody-somerville> ogra, firefox wouldn't happen to maybe looking to gconf for defaults would it?
[19:42] <ogra> not that i know of
[19:42] <ogra> but DPI settings might change between releases
[19:42] <ogra> thats X related
[19:43] <ogra> mine defaults to 16 here
[19:43] <ogra> but doesnt look any different from the rest of the screen
[19:43] <ogra> is that gnome or xfce ?
[19:44] <ogra> afaik gnome leaves the DPI size totally to the X server nowadays
[19:44] <Keybuk> sgallagh: hi
[19:44] <mathiaz> Keybuk: it turns out that sssd doesn't use the dbus daemon
[19:44] <ogra> while it didnt use to before
[19:45] <kirkland> Keybuk: around?
[19:45] <mathiaz> Keybuk: http://paste.ubuntu.com/259439/
[19:45] <sgallagh> Keybuk: Hi, mathiaz asked me to talk to you about D-BUS
[19:45] <Keybuk> gah
[19:45] <Keybuk> the Keybuk Deli Counter queue begins -> there
[19:45] <mathiaz> Keybuk: this is what sgallagh was doing to debug the dbus issue with sssd
[19:45] <kirkland> "no soup for you!"
[19:45] <Keybuk> right :)
[19:46] <Keybuk> sgallagh: so you're using a peer-to-peer dbus connection?
[19:46] <sgallagh> Keybuk: Yes, the monitor acts as a server in this case.
[19:47] <sgallagh> Keybuk: (also the Data Provider has a server for other portions of the code as well, but it's exhibiting the same behavior, so it's easier to just talk about the monitor)
[19:48] <Keybuk> ok
[19:48] <Keybuk> can you pastebin the strace you were talking about
[19:48] <Keybuk> http://paste.ubuntu.com/259440/
[19:49] <Keybuk> is what I see when establishing a peer-to-peer connection
[19:50] <sgallagh> Keybuk: Do you want both the working and non-working versions for comparison
[19:50] <sgallagh> Also, probably easier to email them, as they're fairly large...
[19:51] <Keybuk> just cut the relevent bit out of the strace
[19:51] <Keybuk> but sure
[19:51] <Keybuk> (socket through to the first write() after BEGIN is fine)
[19:52] <sgallagh> Actually, might take a few. My VM got hosed as I tried to drop the 1.2.12 version of libdbus in place to see if it fixed things. Big mistake.
[19:52] <kirkland> Keybuk: so i encountered a regression after upgrading today ... i'm using encrypted swap, boot is hanging trying to modprobe padlock-sh
[19:52] <kirkland> Keybuk: the module is in my /lib/modules dir
[19:53] <Keybuk> kirkland: nothing to do with me
[19:53] <kirkland> Keybuk: nothing to do with initramfs?
[19:53] <Keybuk> kirkland: no idea, I've not touched it certainly
[19:53] <kirkland> Keybuk: cool, thanks.
[19:53] <kees> kirkland: does ecryptfs need a hook to copy that module into the initramfs?
[19:54] <kirkland> kees: hmm, i've never had to copy it there before
[19:56] <mr_pouit> mayb/w 14
[19:56] <mr_pouit> grr
[19:57]  * kirkland thanks pitti
[19:58] <NCommander> Riddell, ping, can you please promote linux-dove (and all the binaries from linux-meta-mvl-dove)) to main ASAP? (hopefully before the next publisher cycle
[19:59] <sgallagh> Keybuk: http://paste.ubuntu.com/259446/ (the Karmic version)
[19:59] <NCommander> or any archive admin?
[20:00] <sgallagh> Keybuk: http://paste.ubuntu.com/259449/ (the working Fedora version)
[20:01] <pitti> NCommander, Riddell: but I already did?
[20:01] <NCommander> pitti, LP says its still in universe
[20:01] <NCommander> (the binaries that is)
[20:01] <pitti> NCommander: only the -z0 stuff, as per ogra's request
[20:02] <NCommander> pitti, https://edge.launchpad.net/ubuntu/karmic/armel/linux-dove/2.6.31.201.2 - Component: universe
[20:06] <pitti> $ change-override.py -c main linux-dove linux-headers-dove linux-image-dove
[20:06] <pitti> hmm
[20:06] <pitti> that's in my bash history
[20:06] <pitti> me does again
[20:06] <NCommander> pitti, that time it bumped to main
[20:07] <NCommander> pitti, Component: main/Status: Pending
[20:07] <NCommander> pitti, BTW, are you using your g10code PGP smartcart yet?
[20:07] <pitti> NCommander: no, just returned from holidays, and zero time to play with it this week :/
[20:07] <pitti> are you?
[20:08] <NCommander> pitti, I wrote a guide on how to generate subkeys and set it up, BUT, there seems to be a bug when using a 3072 encryption keys
[20:08] <NCommander> (3072 authentication and signing keys seem to be ok)
[20:11] <sgallagh> Keybuk: I'm not sure the problem is in libdbus anymore. I just dropped the .so from my fedora rawhide machine (also running 1.2.16) onto the Karmic VM and got the same results.
[20:21] <Tonio_> siretart: should I replace the all "unstripped" stuff in the restricted extra packages ? that also concerns libavformat, libpostproc and libswscale (I don't know much about ffmpeg, so better asking !)
[20:26] <Keybuk> sgallagh: no, it doesn't look to me like it is
[20:26] <Keybuk> looks like libdbus is fine
[20:27] <sgallagh> Keybuk: I'm kind of at a loss why this is failing on Ubuntu only. It works just fine on Fedora and opensuse.
[20:46] <kirkland> bryce: rock!
[20:47] <kirkland> bryce: 1024x768 karmic guest today :-)
[20:52] <bryce> kirkland, excellent
[21:08]  * YokoZar wants to read the Ubuntu User magazine article about Wine...
[21:33] <jpds> YokoZar: Red or white?
[21:33] <jdstrand> kees: regarding libdrools-core-java MIR: it looks ok from a packaging perspective. I am curious about debian/patches/drools-compiler-compilation.patch since it is undocumented, but other than that no issues
[21:35] <NCommander> are there any known issues with publisher at the moment?
[21:35] <NCommander> I have a package resolutely stuck in universe
[21:38] <kees> jdstrand: cool, can you add your notes to the MIR wiki: https://wiki.ubuntu.com/EucalyptusInMainSpec/Packages
[21:39] <jdstrand> kees: sure, np. I've yet to do eucalyptus-commons-ext
[21:40] <kees> jdstrand: cool.  My eyes have started to cross, so I'm done with MIRs for the moment.
[21:40] <cjwatson> NCommander: looks fine. what package?
[21:41] <NCommander> cjwatson, linux-dove, and all the linux-meta-mvl-dove binary packages except the z0 ones
[21:41] <cjwatson> NCommander: madison-lite on cocoplum shows all those as being in main
[21:41] <NCommander> cjwatson, any idea why its still in universe in ports.u.c?
[21:42] <cjwatson> the universe link will hang around for a while. have you checked main as well?
[21:42] <NCommander> cjwatson, not there
[21:42]  * ogra goes mad trying to find all occurences of "babbage" in any code to peel it out with a toothpick
[21:43] <NCommander> cjwatson, correction
[21:43] <cjwatson> NCommander: the files are in http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-meta-mvl-dove/
[21:43] <ogra> god, why did we every change that name
[21:43] <NCommander> cjwatson, there as of 10 minutes ago
[21:43] <NCommander> cjwatson, I'm starting to think I have a proxy between me and the UK
[21:43] <cjwatson> seems plausible
[21:43] <NCommander> (its not the first time I've had this issue)
[21:43] <NCommander> cjwatson, sorry for the noise
[21:43] <cjwatson> np
[21:44] <ogra> * Chose mouse-modules-2.6.31-0-babbage-di, mouse-modules-2.6.31-100-imx51-di out of mouse-modules to satisfy rootskel-gtk
[21:44]  * ogra falls over in tears
[21:44] <NCommander> cjwatson, I do have some debian-cd changes that need merging to get dove images spinning. If my rootfs's properly build, would you be interested in helping do the merge?
[21:44] <ogra> i dont think i have ever seen a bigger mess in all my ubuntu years
[21:45] <cjwatson> NCommander: not before tomorrow morning
[21:45] <cjwatson> but then, sure
[21:45] <ogra> cjwatson, thats a very good statement ...
[21:45] <pitti> tkamppeter: I didn't test the new cups 1.4 on Ubuntu yet; I take it you did? (takes me quite some effort to test with a real printer)
[21:46] <pitti> tkamppeter: it's uploaded to Debian experimental now, about to uplaod to karmic
[21:46]  * ogra decides to follow that hidden suggestion and go on fixing the mess with a clear head 
[21:46] <tkamppeter> pitti, OK.
[21:46] <NCommander> ogra, is there anything I can do to help?
[21:46] <pitti> tkamppeter: I finally got it to build, and sent the sugested avahi patch change upstream
[21:47] <ogra> NCommander, no, i think i solved the last issue for imx51 live builds now, i'll dig deeper into d-i tomorrow
[21:47] <tkamppeter> pitti, it principally works, but there are some things to polish. I have already done some adaptations on s-c-p (today's upload).
[21:47] <tkamppeter> pitti, I have seen it in CUPS bug 3066.
[21:48] <NCommander> ogra, I think dove will work since I can finally see the metapackages in main here
[21:48] <ogra> NCommander, great and it looks like your livefs build will complete too, so lets merge that debian-cd stuff tomorrow ...
[21:48] <tkamppeter> ubottu went sleeping already.
[21:49] <ogra> and we need to chase lamont it seems, clementine got its clock wrong again
[21:49] <ogra> but thats for tomorrow too
[21:49] <tkamppeter> CUPS STR 3066
[21:50] <NCommander> ogra, <lamont> totally right, it just thinks it's in taipei
[21:50] <ogra> NCommander, i thought he fixed that a few days ago
[21:51] <lamont> ogra: it still thinks it's in taipei
[21:51] <ogra> we talked about it on the weekend already
[21:51] <ogra> lamont, ah, ok
[21:51] <lamont> does it matter lots and lots?
[21:52] <ogra> if it remains like that i'm fine and wont be surprised again if my logs are from tomorrow :)
[21:52] <lamont> though I should fix it I suppose, it's kinda low on the ZOMG scale
[21:52] <ogra> no, only for the log timestamps
[21:52] <ogra> right, put it on very low importance level :)
[21:53] <pitti> tkamppeter: ok, basic tests work fine here, too; uploading to karmic now
[21:55] <ogra> NCommander, http://people.canonical.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu-dove/ should have a build log to inspect in about 1h or so, if you see it rolling a squashfs at the end thats a good sign :)
[21:55]  * ogra is off for the day
[21:55] <NCommander> ogra, thanks, I'm running one here too.
[21:55] <NCommander> ogra, I  may ask Steve to handle merging the d-cd changes if I'm still awake
[21:56] <kees> pitti: if you have a moment, can you do MIR assignments for https://wiki.ubuntu.com/EucalyptusInMainSpec/Packages ?
[21:56] <pitti> kees: about to fall to bed, but I'll attack it ASAP
[21:57] <kees> pitti: ah! no worries, I made a bunch of headway on it today.
[21:57] <pitti> kees: FYI, lool and I decided to promote the lot tomorrow, and do reviews afterwards, to take the pressure out (FF crunch)
[21:58] <kees> pitti: sounds good
[21:58] <pitti> kees: I also hope to get some done soon, but there's some higher-urgency FF stuff that I have to do
[21:58] <pitti> kees: (not to the least, security-apport-abort-handler :) )
[21:58] <kees> pitti: yeah, that's why I hadn't gotten to it yet.  but I got a ton of stuff done yesterday to clear the way
[21:58] <pitti> kees: thanks muchly
[21:59] <kees> pitti: yea, I'd love to see that get in too.
[21:59] <pitti> kees: if the stuff is in main already, we can review the packages after FF
[21:59] <pitti> (IMHO)
[21:59] <kees> my "before FF" list is waaay too long, like everyone else's.  :)
[21:59]  * kees nods
[21:59] <kees> excepting libxml-security-java, most of the stuff I've found is minor.
[22:00] <pitti> good night everyone
[22:01] <ion> ght
[22:02] <jdstrand> kees: fyi only-- all the reviewneeded NEW re-review should be done. james_w did the lion's share of that, and I finished the 2 he left for me
[22:02] <kees> jdstrand: cool, great.  I worked through most of the ones he hit plus all the security-review ones
[22:02] <kees> (and then I colorized the wiki!_
[22:02] <jdstrand> kees: I saw that. it's purty
[22:03] <kees> I was thinking it was actually blinding, but useful.  :)
[22:03]  * jdstrand finds it blindingly beautiful
[22:04] <kees> haha
[22:04] <kees> this is ... strangely familiar.
[22:04]  * jdstrand nods
[22:20] <jpds>  /13
[23:28] <slangasek> StevenK: so is readline-common's dep a problem in practice, and if so why?
[23:31] <StevenK> slangasek: ogra uploaded a new one -- but livecd-rootfs really wasn't dealing with it well
[23:31] <slangasek> hrm, ok