[02:55] <micahg> Sweetshark: that was exactly my point
[05:08] <pitti> Good morning
[05:13] <ritz> heya, the oneiric branch of gtk+3 is broken
[05:14] <ritz> https://bugs.launchpad.net/udd/+bug/848064/comments/8
[05:18]  * ritz ghaa, wronmjg channel
[07:04] <dholbach> good morning
[07:15] <dholbach> @pilot in
[07:20] <Sweetshark> micahg: hah! that is so much missing the reality of libreoffice packaging. When you do that you are really not concerned about a rebuild that needs no changes to the package (and no updating the control file does not count, as for LibreOffice, control is generated). What you care for is LibreOffice breaking and requireing patching like http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=7856bf2ec6e24b43eba7b361c7
[07:35] <Sweetshark> (or doko uploading a multiarch libjpeg that requires patching libreoffice in the last days before natty beta freeze and then teasing me about 'using the buildds as testbuilds', when it broke because of _his_ change)
[07:36] <Sweetshark> so the question is like asking for the mileage of my vehicle and wondering why I dont praticulary care if its 5 l/100km or 7 l/100km ... when my vehicle is a tank.
[07:39] <doko> Sweetshark, stop whining, don't dlopen
[07:45] <Sweetshark> doko: ;)
[07:58] <Sweetshark> doko: wrong again btw, this wasnt dlopening btw, but a workaround for some stupid Java implementations injecting an unversioned libjpeg in the linker path.
[08:47] <pitti> cjwatson: wrt bug 963460, it's fine to just throw it the locale as it is; it filters out the .UTF-8 and whatnot stuff itself
[08:47] <pitti> cjwatson: in the medium term it's probably easier to just use the language_support_pkgs python module instead of calling the script, but that's not urgent at all
[08:48] <cjwatson> well, it would actually be awkward to put the .UTF-8 back in here, but it's easy to call it with en_GB rather than en
[08:48] <pitti> ah, I see; I just thought you'd do some special pre-processing for the arguments there
[08:48] <pitti> so whichever is easiest
[08:48] <cjwatson> all I'm planning on doing is http://paste.ubuntu.com/901821/
[08:49] <cjwatson> actually looking at this it might have . in it before preprocessing
[08:49] <cjwatson> sometimes
[08:49] <cjwatson> locale_to_language_pack is http://paste.ubuntu.com/901822/
[08:49] <cjwatson> so yeah, I'll just feed it straight to c-l-s without any of that
[08:50] <pitti> cjwatson: btw, you can probably drop taht as well; c-l-s adds langauge-pack-[gnome...]* itself
[08:51] <TLE> pitti: Hallo, we haven't had the best feedback on the Natty language packs. I'm currently trying to clear up whether the bad reviews concern regressions. I'll keep you informed when I know which ones, if any, should be copied
[08:51] <cjwatson> pitti: not really
[08:51] <pitti> TLE: ah, thanks; note that we can also copy them individually as results come in
[08:51] <cjwatson> pitti: I need that function to do set operations on the packages that are already installed, which ubiquity does need to know about
[08:51] <pitti> ah
[08:52] <TLE> pitti: Yes, I know, but there has actually only been tested two language packs, so I'll clear them both up right away
[09:19] <dholbach> can somebody please reject https://code.launchpad.net/~kroq-gar78/ubuntu/precise/lincity-ng/fix-674519/+merge/99151 based on the last comment I added?
[09:35] <pitti> dholbach: done
[09:35] <dholbach> thanks pitti
[09:42] <TLE> Hallo guys. After restarting my precise beta desktop today (after doing the usual upgrades) multi-monitor support broke. It was also a problem earlier in the cycle but at some point got fixed, but now it is broken again
[09:43] <TLE> what happens is that the primary screen shows the background and nothing else, and on the secondary screen parts of the background flickes by at a high rate depending on where the mouse is
[09:44] <TLE> do you know if this is a known problem, and if not, which component should i report this against
[09:45] <TLE> I'm only asking because I think for graphcis related issues it can be a little tricky to figure out what programs are responsible for what
[09:58] <dholbach> tkamppeter, do you know if https://launchpad.net/bugs/857663 only affects lucid or if it's something that should be fixed in more releases?
[10:12] <dholbach> hallyn, I'll mark https://code.launchpad.net/~serge-hallyn/ubuntu/precise/pulseaudio/pa-upstart/+merge/95664 as 'work in progress' to get it off the queue for precise - is that OK?
[10:14] <dholbach> can somebody please set https://code.launchpad.net/~tjvries/ubuntu/natty/mawk/fix-for-955791/+merge/98069 as 'merged'?
[10:15] <dholbach> it's in http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/mawk/natty-proposed/revision/11
[10:16] <StevenK> dholbach: You need a member of ~ubuntu-branches.
[10:17] <dholbach> :-(
[10:17] <StevenK> Or you can bug an admin in -ops if it's important.
[10:17] <dholbach> no, not important, but it'll stay in the sponsoring queue until it gets set as merged
[10:21] <StevenK> dholbach: Member of the tech board or james_w. So cjwatson can probably do it if you ask him.
[10:22] <dholbach> can we maybe extend the u-branches team? it feels weird having to bother the TB with stuff like this
[10:23] <cjwatson> it's stupid that it has to be a member of ubuntu-branches at all
[10:23] <cjwatson> I'd rather not work around the problem by granting more people the privilege to arbitrarily muck about with importer branches :)
[10:24] <cjwatson> I've marked that mawk MP as merged
[10:24] <dholbach> thanks cjwatson
[10:25] <cjwatson> (https://bugs.launchpad.net/launchpad/+bug/618448)
[10:25] <cjwatson> that even points to the method that needs to be fixed, so maybe somebody with a bit of time could do that
[10:25] <cjwatson> doesn't have to be a Launchpad developer
[10:33] <hrw> bug 966103 goes to the sponsors queue
[10:45] <ev> cyphermox: any idea why is network manager using at_console to determine whether a user can do *anything* with its dbus interface? That seems a bit silly.
[10:45] <ev> isn't this why we have policykit? :)
[10:54] <bdrung> tumbleweed: do you have time to fix W: ubuntu-dev-tools: binary-without-manpage usr/bin/reverse-build-depends
[11:02] <tkamppeter> dholbach, this is Lucid-only. The bug description tells that CUPS 1.4.4 and later is not affected.
[11:02] <tumbleweed> bdrung: it's really not necessary
[11:02] <bdrung> tumbleweed: a man page telling the user to use a different command would be nice
[11:08] <soren> I'm having trouble working out what the difference is between stating "Breaks: b" in package a vs. "Breaks: a" in package b.
[11:08] <soren> Is there even a difference?
[11:13] <soren> Specifically, in OpenStack we have a number of different daemons. One of them is sort of an all-in-one daemon that includes the functionality of 4 others (listening on the same ports and everything).
[11:13] <soren> I want to avoid people installing the all-in-one along with any of the others.
[11:13] <soren> ...and I can't work out which way to point the Breaks: relationship.
[11:17] <janimo`> seb128, do the new gtk/gnome versions which are in precise-proposed land before or after 12.04 is released?
[11:18] <Daviey> soren: Don't you want Conflicts?
[11:18] <seb128> janimo`, before, we use proposed a stacking area for after beta2
[11:18] <seb128> janimo`, why?
[11:18] <janimo`> seb128, just curious, it is the first time  I noticed uploads to proposed so long before release date
[11:19] <seb128> janimo`, right, that's something we would like to standardize on
[11:19] <fatal> someone please reassign LP#960497 to the kernel
[11:19] <Daviey> soren: Ah no, Breaks is probably better
[11:20] <dholbach> tkamppeter, is this worth to be fixed in an sru?
[11:34] <cjwatson> soren: a Breaks: b means that a cannot be unpacked unless b is deconfigured.  b Breaks: a means that b cannot be unpacked unless a is deconfigured.  If you have no maintainer script ordering to consider then it doesn't much matter, but sometimes you do.
[11:34] <cjwatson> soren: Do these two (sets of) packages share files?
[11:35] <cjwatson> soren: Actually, never mind, that probably doesn't matter.  In your case I'd be inclined to use Conflicts in both directions.
[11:38] <soren> cjwatson: No, they share no files.
[11:38] <soren> cjwatson: Conflicts? Really? Why?
[11:39] <soren> cjwatson: I thought this was exactly the sort of thing we added Breaks to accommodate.
[11:39] <cjwatson> Not really, no.
[11:40] <cjwatson> We added Breaks to avoid having to entirely remove packages during upgrades only to reunpack them again later, when simply deconfiguring them would be enough.
[11:41] <cjwatson> Would you ever want to be in a state where both daemon packages were unpacked but only one of them was configured?  It doesn't sound like it.
[11:41] <Daviey> Oddly, i think i'm yet to see a Breaks without a Replaces.. Anyone seen it separately ?
[11:41] <StevenK> I have, yes.
[11:41] <StevenK> It doesn't turn up often,
[11:41] <StevenK> s/,$/./
[11:41] <Daviey> StevenK: Have an example?
[11:41] <soren> cjwatson: I have no desire for that scenario, but it wouldn't hurt anyting.
[11:41] <cjwatson> initramfs-tools Breaks: a load of stuff with no Replaces
[11:41] <Whoopie> cjwatson: I found the reason for the sflphone build failure on armel/armhf. It needs an up-to-date config.guess. If I prepare a new debdiff, would you mind sponsoring it again?
[11:42] <cjwatson> soren: The difference between Breaks and Conflicts here is mainly academic, so it's probably not worth a long discussion.  At any rate I would have the relationship in both directions rather than trying to pick one.
[11:42] <Whoopie> cjwatson: as suggested by tumbleweed, I test-compile it in a qemu chroot at the moment.
[11:42] <cjwatson> Whoopie: sure
[11:42] <StevenK> Haha, and s390-tools. I bet that impacts us somehow. :-P
[11:43] <soren> cjwatson: Cool. Thanks.
[11:52] <dholbach> can somebody please reject https://code.launchpad.net/~kroq-gar78/ubuntu/precise/freedict/fix-568333/+merge/98963 (explained in last comment)?
[11:55] <cjwatson> dholbach: done
[11:55] <dholbach> thanks cjwatson
[12:00] <dholbach> @pilot out
[12:08] <tkamppeter> dholbach, it can be fixed easily, as the patch is attached, but on the other side it seems to happen only rarely, as it has no duplicates.
[12:11] <dholbach> tkamppeter, ok, I'll leave the decision up to you then
[12:42] <hrw> janimo`: thx for dash
[12:43] <janimo`> hrw, you're welcome. Probably needs to go to Debian too at one point
[12:47] <Mavrik> Hey... if there is a (imo) significant regression from 11.10 to 12.04 beta, where should I write to to get attention from the team?
[12:49] <hrw> janimo`: reported there
[12:49] <janimo`> hrw, nice.
[12:51] <hallyn> dholbach: sure.  but this points to a bug in my sponsoring workflow :)
[13:27] <cyphermox> ev: don't know. feel free to suggest an alternate configuration if it helps you
[13:32] <ev> cyphermox: no worries. pitti suggested using libck-connector, which is working a treat.
[13:32] <cyphermox> ok
[13:32] <pitti> or just changing the NM d-bus policy to allow reading the properties for "whoopsie"?
[13:32] <pitti> which seems even easier?
[13:33] <cyphermox> yeah
[13:33] <cyphermox> I do think it should be changed, but perhaps not now when it's been working properly. I'll mention it to dcbw once he's back from vacation though
[13:33] <ev> whatever you guys think works best for ck/nm. Just provide me with a working API and I shall use it :)
[13:54] <pitti> cyphermox: I think it's less risky/intrusive to just open this up to "whoopsie"; this certainly needs to be a distro patch to the policy
[13:55] <cyphermox> right
[13:55] <cyphermox> pitti: you mean whoopsie as a user right?
[14:01] <alvin> mvo: I was directed to you from #kubuntu-devel. I'm looking for a workaround for bug 966226 I just reported.
[14:02] <mvo> alvin: I would suspect that be.archive.ubuntu.com has a incomplete precise mirror (at least that is what I read from the log in the bug)
[14:03] <alvin> mvo: That might be the case. I'll switch mirrors and try again.
[14:03] <mvo> alvin: note that this is not about ubuntu-minimal on your system, but about ubuntu-minimal availalble for download after the upgrade, its a precaution
[14:03] <mvo> alvin: thanks
[14:17] <retoaded> cjohnston, ping
[14:17] <cjohnston> hey there
[14:17] <cjohnston> 5 minutes?
[14:18] <cjohnston> trying to finish with an issue real quick retoaded :-)
[14:18] <retoaded> cjohnston, np
[14:21] <barry> ScottK: https://bugs.launchpad.net/ubuntu/+source/flufl.enum/+bug/966257
[14:22] <ScottK> barry: Approved.
[14:22] <barry> ScottK: thanks
[14:23] <ScottK> You're welcome.  Please go fix the other ones now ...
[14:23] <barry> working on it ;)
[14:27] <barry> ScottK: % syncpackage -d sid flufl.enum
[14:27] <barry> syncpackage: Error: Debian version 3.3.1-2 has not been picked up by LP yet. Please try again later.
[14:27] <barry>  
[14:27] <ScottK> It's slow.
[14:27] <barry> yep, just fyi
[14:27] <ScottK> OK.
[14:32] <cjohnston> Mornin retoaded.
[14:32] <retoaded> morning
[14:32] <cjohnston> retoaded, are you familiar with what I need to setup?
[14:51] <alvin> mvo: Thanks. Switching mirrors worked. ubuntu-minimal is indeed missing on the Belgian mirror. I'll update the bug report.
[14:56] <mvo> alvin: thanks
[14:57] <pitti> cyphermox: yes
[15:30] <ogra_> vanhoof, you pinged last night ?
[15:33] <vanhoof> ogra_: yeah nothing urgent, just wanted to bounce a question off of you if you have a few minutes
[15:35] <ogra_> sure
[15:41] <janimo`> Sweetshark, I just noticed libo ftbfs on armel, are there still (minor) differences in the packaging between armel/armhf by any chance?
[15:45] <Sweetshark> janimo`: no, actually I dont think it is something 'real' at all. If you look at the buildlog it is a unittest failing very high in the build which didnt fail before. It could very well be that the builder box just had a bad day. I tried to reproduce the issue on the armel-porter box, but that one went MIA during the build (couldnt login), so I didnt look into it any further for now.
[15:46] <janimo`> Sweetshark, that's what I suspect too. Given back to the builders
[15:47] <Sweetshark> janimo`: so you just retry? yes, might be worth a shot.
[15:48] <Sweetshark> janimo`: I just did not want to be guilty of hugging the builder (esp. in the pre-beta) without even trying on a porter to fix it.
[15:50] <janimo`> Sweetshark, less time wasted this way imho, there are still plenty pandas to carry other builds
[15:54]  * Sweetshark imagines an army of cute, but grim-looking pandas.
[15:55] <dantti> RAOF: ping
[16:05] <dholbach> congratulations adam_g
[16:05] <dholbach> shouldn't you be in ~ubuntu-dev now?
[16:29] <tumbleweed> dholbach: I left DMB minutes to cody-somerville, but I'll sort out the actions now
[16:29]  * dholbach hugs tumbleweed
[16:35] <tumbleweed> dholbach, adam_g: done
[16:35] <dholbach> yoohoo
[16:59] <PaoloRotolo> Hi all!
[17:07] <bdrung> jdstrand: distro-info 0.7.1 is in precise now (re bug #964008)
[17:08] <jdstrand> bdrung: thanks
[17:10] <bdrung> yw
[18:22] <infinity> TheMuso: A long shot, given timezones, but are you around to update the -lowlatency kernel?
[18:33] <Daviey> bdrung: woot!
[19:34] <bdrung> Daviey: woot about what?
[19:38] <Daviey> bdrung: distro-info
[20:00] <bdrung> Daviey: wait until i will rewrite it in C. ;)
[20:00] <Daviey> bdrung: Everyone really wants to see it in golang.
[20:06] <bdrung> Daviey: let's check if it passes the initial test
[20:11] <smoser> anyone see this: *** VTE ***: Failed to load terminal capabilities from '/etc/termcap'
[20:12] <bdrung> Daviey: it has a fast startup time
[20:13] <Daviey> smoser: close and re-open gnome-terminal
[20:14] <Daviey> smoser: If it still does it, reboot, then phone customer support back.
[20:14] <smoser> bah.
[20:14] <smoser> yeah.
[20:14] <smoser> i see bug 961977
[20:14] <smoser> er...
[20:14] <smoser> bug 961997
[20:16] <Laney> comment #5 is right
[20:16] <Laney> you need to quit all of your terminals
[20:17] <broder> mdz got it slightly backwards - the bug is that the old libvte already loaded into the gnome-terminal process is looking for a file that's no longer part of the new libvte and is therefore gone
[20:17] <broder> (the new libvte embeds the content into the libvte binary)
[20:17] <mdz> broder, aha
[20:18] <broder> and as of a few (ubuntu) releases ago, gnome-terminal is a single process for all of your terminals, so you're stuck with it until you kill off all of your terminals (this killing the gnome-term process)
[20:20] <smoser> Daviey, regarding speed... http://paste.ubuntu.com/902787/
[20:21] <smoser> ubuntu-distro-info --supported is roughly 6 times as slow to run as '/bin/true'
[20:21] <smoser> that includes 1 fork to 'date', which accounts for 30%-ish of its time
[20:22] <smoser> so there is only so much that can be shaved off.
[20:26] <nemo> https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/226885  <- this says fix released (after many years)
[20:27] <nemo> is there any way to get that fix into ubuntu?
[20:27] <nemo> I guess I could just install the debian .deb and cross my fingers...
[20:29] <bdrung> Daviey: bug #966570
[20:30] <Daviey> wow.  just. wow.
[20:34] <bdrung> Daviey: that's not enough. there is gccgo-4.6 too
[20:35] <bdrung> Daviey: this fails too: bug #966578
[20:41] <meerkats> where do I find a unity channel?
[20:48] <Daviey> bdrung: is it fmt or fml ?
[20:49] <bdrung> Daviey: fmt
[21:21] <soren> Say I'm using debconf to configure a package. Using puppet, I preseed debconf with the appropriate answers prior to installing the package. This all works well. However, say I wanted to change something later on. How would I do this noninteractively? Luckily the package has no questions of critical debconf priority, so re-preseeding followed by "dpkg-reconfigure -pcritical" would probably do the trick, but I have to wonder how I'd manage if there we
[21:22] <soren> When does a question get marked as seen? When it's shown interactively or would it be considered seen even if the package is configure with the noninteractive frontend?
[21:23] <soren> If the latter, I guess dpkg-reconfiure --unseen-only almost solves it (unless I've added more questions in the mean time).
[21:23] <soren> Although, in that case I guess those would have been answered (and thus seen) during a package upgrade?
[21:37] <slangasek> soren: packages are not supposed to overwrite existing config files with debconf answers; when there's a disagreement between the two, the .config script should be overwriting the debconf question, and your post-preseeding would be for naught
[21:37] <slangasek> as long as you're using puppet, I think you should just make the config file changes directly
[21:40] <soren> slangasek: Err... What is the purpose of dpkg-reconfigure, then?
[21:40] <slangasek> soren: to let users *interactively* change the values :)
[21:40] <soren> pft
[21:40] <soren> :)
[21:40] <slangasek> I mean, if you wanted to you could write a puppet debconf frontend
[21:41] <slangasek> so that dpkg-reconfigure asks puppet instead of the user
[21:41] <slangasek> but jamming new answers into /var/cache/debconf is not *supposed* to propagate them to the config files
[21:41] <soren> This makes me sad. I've spent quite a bit of time moving all this logic into debconf so that regardless of config mgmt system, the results would be the same.
[21:41] <slangasek> cf. "Debconf Is Not A Registry™"
[21:42] <soren> ..but if that means that I can't make changes post install... That sucks.
[21:43] <slangasek> you just have to approach debconf from a different angle.  A config-system-specific debconf frontend or backend would do the job.
[21:44] <soren> How would another backend help?
[21:44] <slangasek> because the backend could ignore what was written to it ;)
[21:44] <soren> Oh. By backend you're not referring to db driver.
[21:44] <slangasek> yes I am
[21:44] <soren> Right.
[21:44] <soren> Hm.
[21:45] <slangasek> your backend would cheerfully accept answers from the user, then discard any that disagree with puppet's policy
[21:45] <slangasek> and when re-queried with db_get, it would give the answer it wants the system to have
[21:46]  * soren ponders
[21:46] <slangasek> (N.B., this sort of thing is exactly why the DbDriver interface exists, and yet I think only two or three people have ever written drivers... so there may be a reason, I haven't looked at the code myself :)
[21:52] <soren> Good grief, I'm going to have to write perl.
[21:52] <kirkland> ScottK: any idea what's the replacement for dkim-filter in Ubuntu 12.04?
[21:53] <kirkland> ScottK: opendkim maybe?
[21:54] <soren> slangasek: I guess adding a new db with my answers in it, setting it to read-only and putting it at the top of a Stack...
[21:54] <soren> slangasek: Answers would pass through to the underlying (non-read-only) db, but when read back out, my static answers take precedence.
[21:55] <soren> Or so the hypothesis goes.
[21:55] <slangasek> soren: my arms-length understanding of this side of debconf thinks this sounds reasonable
[21:56] <bdrung> Unity is broken in my precise system. When i login, there is no sidebar and no menu bar.
[21:57] <soren> slangasek: Are you familiar with $DEBCONF_DB_OVERRIDE?
[21:58] <slangasek> soren: nope
[21:58] <soren> slangasek: Ok.
[21:58] <soren> slangasek: SEems to be what I need.
[21:58] <soren> slangasek: ...but if you knew it, but didn't suggest it, that would be useful information.
[21:59] <soren> slangasek: (It's mentioned in man debconf(7))
[22:00] <slangasek> yeah, seems to be the right tool
[22:00] <slangasek> I knew there were facilities for this, but it's been a while since I read that manpage and have never actually done it in practice ;0
[22:00] <slangasek> ;)
[22:01] <soren> It does feel like somewhat unchartered territory.
[22:01] <soren> Not entirely HBD, but close.
[22:03] <soren> slangasek: Thanks a lot for your insight!
[22:03] <slangasek> sure thing
[22:04] <slangasek> soren: I look forward to seeing the results blogged/packaged, I imagine there are a few other people who would like better puppet+debconf integration ;)
[22:09] <soren> slangasek: I certainly hope this will serve as an example others will follow. Debconf seems somewhat overlooked and I think it'll serve well as a lowest common denominator, drastically reducing the divergence between the result of an OpenStack (in my case) deployment done with Puppet vs Chef vs The-Next-Big-Thing-In-Cfg-Mgmt.
[22:10] <soren> It, of course, rests on the assumption that the invariant is the underlying operating system.
[22:11] <soren> Others might have defined Puppet (or Chef or whatever) as the invariant. That's just not my style :)
[23:46] <slangasek> Daviey: still patch piloting?
[23:48] <Daviey> slangasek: no :/
[23:48] <Daviey> @patch out
[23:48] <udevbot> Error: "patch" is not a valid command.
[23:48] <Daviey> @pilot out
[23:48] <Daviey> thanks
[23:48] <slangasek> ah, darn ;)  ok, thanks anyway :)