[04:25] <mfisch> mhall119: I'm around now, missed you on G+
[04:43] <mhall119> mfisch: ?
[04:52] <mfisch> mhall119: you invited me to a hangout
[04:52] <mfisch> mhall119: about an hour ago
[05:05] <mhall119> I did?  I didn't mean to
[05:06] <mhall119> I hope it didn't invite the entire community :(
[05:06] <mhall119> I was just trying it out, to see if it could be made on-air
[07:45] <dholbach> good morning
[07:46] <achiang> dholbach: good morning
[07:46] <dholbach> hey achiang
[08:44] <pitti> Good morning
[09:48] <pitti> ev: https://code.launchpad.net/~daisy-pluckers/+recipe/apport-test-crashes
[10:03] <jamespage> @pilot in
[10:36]  * dholbach hugs jamespage and mterry
[11:16] <cjwatson> jdstrand: Have you had a chance to consider bug 1077484?
[11:21] <mpt> ev, please update bug 1084624 with the conclusion of yesterday's discussion (I don't know what it was, exactly)
[11:22] <ev> will do
[11:25]  * apw wonders where /etc/mailcap comes from, which package ... (so he can file a bug against it)
[11:25] <seb128> diwic, hey, do you know what configuration file tells pulseaudio what components to load? jason is having an issue where pulseaudio refuses to start without pulseaudio-esound-compat ... or the esound compat shouldn't be required
[11:26] <diwic> seb128, that's a known bug, let me find it
[11:26] <diwic> seb128,  that said, I still don't understand why it happens *now*
[11:27] <diwic> seb128, I think it's bug 1078543
[11:28] <diwic> seb128, I believe the problem is that the esound compat file is the wrong arch
[11:29] <seb128> diwic, correct, from jason's log
[11:29] <seb128> ii  pulseaudio                                1:2.1-0ubuntu4                              amd64        PulseAudio sound server
[11:29] <seb128> ii  pulseaudio-esound-compat                  1:2.1-0ubuntu4                              i386         PulseAudio ESD compatibility layer
[11:29] <seb128> diwic, thanks
[12:23] <cjwatson> LoganCloud: Do you think you could merge dpkg-cross from Debian experimental?  Looks like you touched it last (if I've got the right Logan)
[12:30] <mlankhorst> dpkg-blame should be a command ;-)
[12:31] <vibhav> mlankhorst: heh
[12:38] <jamespage> @pilot out
[12:39] <jdstrand> cjwatson: not yet, hope to get to it today
[12:46] <jamespage> arges, OK if I steal the rsyslog merge for raring from you?
[12:53] <seb128> could somebody set those "work in progress":
[12:53] <seb128> https://code.launchpad.net/~brightbox/ubuntu/quantal/lvm2/fix-for-1075994/+merge/133645
[12:53] <seb128> https://code.launchpad.net/~brightbox/ubuntu/quantal/lvm2/fix-for-1076304/+merge/133438
[12:53] <seb128> https://code.launchpad.net/~lqs/ubuntu/precise/tcc/tcc-fix-mmap-leak/+merge/134058
[12:53] <seb128> thanks
[12:54] <seb128> stgraber, pitti, cjwatson: ^
[12:54] <seb128> https://code.launchpad.net/~andrikos/ubuntu/quantal/fglrx-installer/fix-switch-to-igpu/+merge/132962 as merged as well
[12:55] <cjwatson> WIPs done.  Where's that been merged?
[13:06] <seb128> cjwatson, thanks,http://www.phorogit.com/index.php?p=fglrx-packaging.git&a=commitdiff&h=a1d481315f8ffffcd3ca67f9d6c581f1cf44b9fa&hb=8bf73d7de86f2ee105ece1daa2a143e9c55cb255 where tseliot seems to maintain his vcs...
[13:07] <seb128> cjwatson, well http://www.phorogit.com/index.php?p=fglrx-packaging.git&a=commitdiff&h=9eaed4a5fee3d67c8ca8cd026189f8cc461a532a&hb=a1d481315f8ffffcd3ca67f9d6c581f1cf44b9fa rather
[13:07] <xnox> seb128: is it uploaded?
[13:08] <seb128> xnox, not yet, but it doesn't need to stay in the sponsoring queue...
[13:08] <xnox> ok.
[13:08] <seb128> xnox, isn't "merged in the vcs" equivalent to "merged"?
[13:08] <seb128> xnox, if you merge to lp:ubuntu/<source> without uploading launchpad would set it to merged as well
[13:09] <xnox> unless you haven't already, comment on the merge proposal such that the sponsoree knows it's merged there and will be in the next upload.
[13:09]  * xnox not fully sure about the correct application of double negative above....
[13:11] <seb128> xnox, well, tseliot commented yesterday saying it's fixed upstream with a link to git diff url
[13:12] <xnox> good enough for merged status then =)
[13:12] <arges> jamespage, hey. are you talking about bug 1059592 ? I thought raring was already fixed in comment #8
[13:13] <jamespage> arges, no - there is a new upstream version in Debian I want to merge; it fixes that problem
[13:13] <arges> jamespage, yea that'd work too if its > 5.8.7
[13:14] <jamespage> arges, 5.8.11 - I'll merge it if thats OK with you (polite to check with last uploader before stealing merges :-))
[13:14] <arges> jamespage, yup no problem. I figured that's what would happen for that one anyway
[13:17] <cjwatson> seb128: OK, marked as merged then
[13:19] <seb128> cjwatson, thanks
[13:54] <marga> seb128, I'm looking at https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1035219 (the bengali issue outside of Unity).  It says that you made an upload fixing it, for raring, posibly.  Are there plans to push it to quantal/precise?
[13:56] <marga> The patch looks ugly and big, so I guess probably not.
[13:57] <seb128> marga, hey, "bengali"... that sounds like a different bug
[13:57] <marga> It's what the bot said
[13:57] <seb128> what bot?
[13:58] <marga> the wrong language gets selected if you go to the regional settings and don't click on anything, using gnome/cinnamon
[13:58] <seb128> marga, that bug is about having the wrong language selected when you open the region capplet
[13:58] <marga> Up there ubottu
[13:58] <seb128> marga, yeah, and you wrote "the bengali issue outside of Unity"
[13:58] <marga> Yeah, bengali is the first in the list.
[13:58] <marga> So, everything turns to bengali.  At least here.
[13:58] <seb128> oh, ok ... it's chinese for most people
[13:58] <seb128> yeah, depends of the langpacks installed
[13:59] <seb128> marga, I got confused because I was reading https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/991002 earlier
[13:59] <marga> Oh... Right, I guess we have more languages installed.
[13:59] <marga> Anyway, that patch looks like it probably fixes what needs to be fixed, but it's an aweful lot of code for an SRU.
[13:59] <seb128> marga, in any case I didn't fix that bug, the comment that closed the bug is confusing
[14:00] <seb128> gnome-control-center (1:3.6.3-0ubuntu3) raring; urgency=low
[14:00] <seb128>   * debian/patches/60_ubuntu_nav_bar.patch:
[14:00] <seb128>     - restore the navigation bar interface
[14:00] <seb128> that's nothing to do with that issue
[14:00] <seb128> ok, I guess it's the workaround from jbicha in 1:3.6.3-0ubuntu1
[14:00] <marga> Oh.  I thought it was a very complicated way of fixing the widget.
[14:01] <seb128> marga, it seems like it was workaround in http://bazaar.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu/revision/505
[14:01] <marga> Ah, I see... Silly me.  It's patch 52
[14:02] <seb128> marga, I'm fine SRUing the workaround, it's not perfect but better than the bug for sure
[14:02] <seb128> marga, is there any chance you could test if that fix your issue?
[14:03] <marga> Sure, yes.
[14:03] <marga> I can test the patch for precise and quantal
[14:03] <marga> Prepare the package and stuff
[14:04] <seb128> marga, that would be great, thanks
[14:04] <marga> Ok, I'll get on with that.  Thanks to you :)
[14:04] <seb128> yw ;-)
[14:05] <jamespage> ScottK, micahg: taking a look at sikuli now
[14:26] <jdstrand> kees: hey, libseccomp has an MIR and I noticed that 1.0.0-1 has been sitting in Debian NEW for 4 months and we don't have it in Ubuntu yet. can you elaborate?
[14:26] <jdstrand> (I do see this in the changelog: Change the API to be context-aware; eliminates all internal state but breaks compatibility with the previous 0.1.0 release
[14:26] <jdstrand> )
[14:28] <jdstrand> hallyn: will that ^ affect lxc?
[14:46]  * xnox ponders if stgraber has lxc highlight or not ^
[14:48] <jdstrand> xnox: thanks
[14:48] <arges> micahg, infinity : just to triple check, are you guys ok with SRUing bug 943502 ? Or did we want to go forward with the backports?
[14:50] <hallyn> jdstrand: yup, more than likely.
[14:52] <stgraber> xnox: no but I pretty much always read the scrollback for this channel :)
[14:53] <xnox> stgraber: I am so sorry, sir. I will improve, sir. =)
[14:54] <marga> seb128, if the package version was ubuntu1, should the version in my debdiff be ubuntu2 or ubuntu1.1 ?
[14:54] <seb128> marga, 1.1 for a SRU
[14:54] <marga> ok, tnx
[14:54] <seb128> yw
[15:00] <hallyn> jdstrand: unless stgraber wants to do it, i guess i'll put looking at the new seccomp api on my todo list, but i've *got* to figure out the qemu mess first
[15:00] <dholbach> jodh, you might be interested in having a chat with the guy in https://plus.google.com/109795858099658821877/posts/192eMwxNAtF
[15:02] <jodh> dholbach: thanks - on it.
[15:02] <dholbach> jodh, awesome :-D
[15:03] <seb128> hallyn, ^ in the URL dholbach just pointed the guy mentioned working on "seccomp filter support to Upstart" ... not sure if that's related with what you were talking about
[15:03] <hallyn> seb128: not particularly, but interesting.
[15:03]  * hallyn goes to read
[15:04] <dholbach> give the guy a hug! :)
[15:04]  * dholbach likes the new G+ communities already
[15:05] <hallyn> too much brightness and pictures, can i get a text feed? :)
[15:05] <dholbach> right :)
[15:09] <jdstrand> hallyn: that's fine-- no rush on my end
[15:13] <jodh> dholbach: I've provided some details for David now.
[15:15] <dholbach> jodh, great - I hope he'll become an active contributor!
[15:17] <marga> seb128, there, built and tested it for both precise and quantal, uploaded the diffs to the bug.  I'll add the SRU header now.  Let me know if I need to do anything else.
[15:18] <seb128> marga, looking
[15:23] <marga> Writing Regression Potentials is always the hardest part of filing an SRU
[15:23] <marga> I have no idea of the regression potentials that this might have.
[15:25] <seb128> marga, yeah, that section is not easy, it's meant to be a "what should the person doing the verification test for regression"
[15:26] <marga> Yes, and I know that it's important, but most of the time I have no idea of what to put there.
[15:26] <seb128> marga, so for those sort of bug it's something around the line of "using the region panel, in a non unity session, to change languages and check that the result is the one wanted"
[15:26] <marga> But that's the test case
[15:26] <marga> Regression potential is other stuff that could break
[15:27] <seb128> well, there is little potential to impact on anything else
[15:27] <seb128> I often end up by writing lame "regression potential" sections and I guess others do the same...
[15:29] <marga> Well, there, I did my best.
[15:29] <marga> Let me know if I need to do anything else.
[15:32] <seb128> marga, looks good to me, I'm sponsoring the updates, thanks
[15:32] <marga> Thanks for the sponsoring :)
[15:33] <seb128> marga, btw "  * Non-maintainer upload." ... that's not needed in Ubuntu ;-)
[15:34] <marga> heh, I wasn't sure, that's dch -n default behaviour.
[15:34] <marga> I'll keep it in mind for the next time.
[15:54] <hallyn> slangasek: so i'm trying to use dpkg-maintscript-helper mv_confile (in some dummy test pkgs).  I want an upgrade from v1 to v2 to move apkg.conf from pkg apkg to bpkg.conf owned by bpkg.  I'm not sure that's doable?
[15:54] <hallyn> if i have bpkg.preinst, postinst and postrm doing mv_confile apkg.conf bpkg.conf 1.0 apkg, then nothing happens...
[15:54] <hallyn> trying calling them apkg.* now...
[15:56] <hallyn> hm maybe that works
[15:58] <xnox> hallyn: dpkg-maintscript-helper doesn't quite work across package renames.
[16:01] <hallyn> yay it works
[16:01] <hallyn> xnox: it did!
[16:01] <hallyn> oh it's not a pkg rename
[16:01] <hallyn> the confile is moved to another pkg
[16:02] <xnox> hallyn: Hmm.. See interesting discussion about ~ similar issue here: http://debian.2.n7.nabble.com/Renaming-packages-maintscripts-td1058526.html#none
[16:03] <hallyn> looking
[16:04] <infinity> hallyn: Having it in apkg.preinst probably works, except for the unwind cases, I suspect.
[16:06] <infinity> hallyn: The reason it needs to be in apkg.preinst, FWIW, and not in bkpg, is because dpkg won't remove the ref to the conffile from apkg.list if it's still on-disk (it'll just list it as obsolete), so it needs to be moved before apkg is unpacked.
[16:06] <infinity> hallyn: But that would, I suspect, lead to other surprising oopses because if apkg depends on bpkg, then you're unpacking the new one before overwriting it, thus creating a potential conffile prompt on the next upgrade of bpkg.
[16:07] <infinity> hallyn: (This is all just trying to follow the logic through in my head, anyway)
[16:07] <infinity> hallyn: Ultimately, I think the answer here is that mv_conffile can't quite do this right.
[16:08] <hallyn> infinity: it handles 'apt-get dist-upgrade' with modified confile right.  but the link suggests that 'apt-get install bpkg' might not work - testing now
[16:10] <infinity> hallyn: It handles the first upgrade right, or so you think.
[16:11] <hallyn> xnox: infinity: actually apg-et install bpkg worked too.
[16:11] <infinity> hallyn: My bet it that the NEXT upgrade of bpkg will get confused.  But maybe not, if apkg.conf and bpkg.conf were identical in the original packaging (were they?)
[16:11] <hallyn> infinity: no they were not,
[16:11] <hallyn> and i changed them locally,
[16:11] <hallyn> and dpkg -S bpkg.conf shows owned by bpkg now
[16:12] <infinity> Yeah, but it's a modified conffile by default now.
[16:12] <hallyn> apt-get install --reinstall bpkg still works
[16:12] <infinity> If apkg.conf and bpkg.conf aren't the same.
[16:12] <hallyn> hm
[16:12] <hallyn> good point
[16:12] <infinity> So, the next time you change bpkg.conf, people who never modified apkg.conf will get a prompt.
[16:12] <infinity> And they shouldn't.
[16:12] <hallyn> now, in the case i care about,
[16:12] <hallyn> which is qemu, they will be identical :)
[16:12] <hallyn> are you sure?  what does it compare against?
[16:13] <infinity> It compares the dpkg database to the file on disk.
[16:13] <hallyn> note i am note getting a prompt at all.  not sure if i'm doing something funky
[16:13] <infinity> If they don't match, you get prompts.
[16:13] <hallyn> ok, not the dpkg-preinst or somesuch?
[16:13] <infinity> You won't get prompts on the moves.
[16:13] <infinity> I meant the next upgrade that changes the conffile.
[16:13] <hallyn> oh
[16:13] <hallyn> i see
[16:13] <infinity> But, if they're the same in old and new packages, that's not going to be a problem.
[16:14] <hallyn> infinity: which means it's worth making sure they're identical
[16:14] <infinity> Yes.
[16:14] <infinity> If they're not identical, this really won't work.
[16:14] <hallyn> problem: does this mean they have to be identicl for a whole LTS cycle?
[16:14] <infinity> For the move to work without later prompting, yeah.
[16:15] <infinity> Now, there are clever ways around that.
[16:15] <infinity> But mv_conffile won't do them for you.
[16:15] <infinity> You can work up a hash of every packages version of the old conffile.
[16:15] <infinity> And on upgrade to the new package (in preinst), check if their current one matches one of those hashes.
[16:16] <infinity> If so, delete it outright, and let dpkg create the new one as it was going to.
[16:16] <infinity> If it doesn't match, move it to a temp file, then copy it to the new location in postinst.
[16:16] <hallyn> given that these are actually upstart jobs, i wonder if i'm better off having qemu-system.conf gracefully do nothing (and be commented) if qemu-kvm.conf exists
[16:16] <infinity> These are some of the same steps mv_conffile takes, but with the addition of maintaining history.
[16:17] <infinity> hallyn: If you read the manpage and understand what mv_conffile is trying to achieve, homebrewing it with the addition of the sums checks will make the moving between packages thing work, even if you have several potential pristine files to move from.
[16:18] <cjwatson> Wait, are you actually changing the file name, or just moving it from one package to another?
[16:18] <infinity> cjwatson: filename and package move, in one shot.
[16:18] <cjwatson> If you can get away with not changing the filename, I think Replaces is enough these days
[16:18] <infinity> cjwatson: So neither replaces nor mv_conffile is a fit.
[16:19] <hallyn> uh.  well.  but maybe i don't need to
[16:19] <infinity> hallyn: But yes, Colin has a point, Replaces will take over conffiles if you don't rename them.
[16:19] <infinity> hallyn: And if the name offends you in two years, you can mv_conffile it then. :P
[16:19] <hallyn> then i'll just keep it as qemu-kvm.conf!  thanks
[16:20] <hallyn> but if i have several pkgs doing Replaces: qemu-kvm, will it know to use the one which ships that file?
[16:20] <infinity> Yes.
[16:20] <infinity> Replaces just means "if there's an overlap, this one wins".
[16:20] <hallyn> cool, thanks.  so taht issue is solved :)
[16:20] <hallyn> leaving only the original problem
[16:20] <infinity> This is a problem if more than two packages provide a file and have replaces, but. Uhm.  Don't do that.
[16:21] <hallyn> infinity: the upgrades still aren't working.  but when i mimick the situation with dummy pkgs it seems to work
[16:21] <infinity> hallyn: Curious.  Is this all in the PPA again?
[16:21] <hallyn> it seems like 'apt-get dist-upgrade' is saying "qemu-kvm depends on qemu-system which recommends qemu-utils",
[16:21] <infinity> Right, which is correct...
[16:21] <hallyn> "and qemu-utils breaks qemu-kvm so let me uninstall that,  now i don't need qemu-sytem any more"
[16:21] <hallyn> or something
[16:22] <infinity> That shouldn't happen if all the versions are sane now.
[16:22] <hallyn> infinity: yeah, in ppa - right now it's got a broken mv_confile line, but you don't get that far with 'apt-get dist-upgrade' so i gues that's ok
[16:22] <hallyn> they're all in same source pkg
[16:22] <infinity> Let me have a look after I go abuse my lungs.
[16:22] <hallyn> :)
[16:35] <infinity> hallyn: qemu-common has gone away completely, right?
[16:42] <hallyn> infinity: yes
[16:42] <infinity> hallyn: So, I have a theory I'm testing here.  But while I'm on that.  Why did you remove the versioned dep on qemu-system?
[16:44] <hallyn> infinity: at soren's suggestion, in case apt is doing something funky with the extra constraint
[16:44] <infinity> No, pretty sure that's not the issue.  But gimme a few minutes here.  This silly thing takes a while to build.
[16:47]  * infinity kills firefox and reclaims half his laptop.
[16:48] <kees> jdstrand: libseccomp> yeah, nothing is passing NEW in debian because they're stuck in freeze. *roll eyes*
[16:49] <hallyn> infinity: yeah that's why i took jamespage's advice and tried to reproduce with dummy pkgs
[16:49] <tseliot> seb128: it's all merged and uploaded
[16:50] <seb128> tseliot, thanks a lot!
[16:50] <hallyn> but i'm clearly missing some aspect of it in my dummy versions
[16:52] <hallyn> now i'm not accounting for qemu-keymaps in my dummies, maybe it changes something
[16:52] <infinity> hallyn: I'm almost positive I know what the issue is, as I've seen it before.  dist-upgrade is outsmarting you here in an attempt to not break your system.
[16:53] <infinity> hallyn: If you can gimme a $while to test this theory, I'll get back to you.
[16:53] <hallyn> infinity: awesome, thanks
[16:53]  * hallyn loves software smarter than myself
[16:54] <infinity> You'll note, though, that "apt-get install qemu-kvm qemu-system" works fine.  Pretty sure dist-upgrade's just unwilling to remove common, and that's a solvable problem.
[16:55] <hallyn> huh
[16:55] <infinity> One I'd have solved by now if this didn't take SO LONG to build.  Wow.
[16:56] <infinity> I swear I'm just seeing the same files over and over again in the build log here.  Does it build N flavours or something?
[16:56] <infinity> Or maybe everything's just very similar looking.
[17:00] <hallyn> infinity: it does build a whoel slew of targets
[17:00] <hallyn> infinity: tried to reproduce the qemu-commnon bit, didn't reproduce the problem (bu ti probably did it wrong)
[17:02] <infinity> hallyn: Also, why does qemu-system Break and Replace itself? :P
[17:03]  * infinity fixes that while he's in here.
[17:04] <hallyn> infinity: oops, yeah that's mine, not from original debian.
[17:12] <slangasek> hallyn: I'm not *sure* it's doable either, but I think it *should* work :)
[17:25] <jdstrand> kees: hrmm, that is a bummer. I figured it could go to unstable or experimental
[17:26] <jdstrand> kees: fyi, you might be interested in the conditional ack of bug #1082431
[17:27] <jdstrand> kees: that says, doesn't sound like it can get into Ubuntu until lxc is fixed
[17:27] <jdstrand> s/says/said/
[17:27] <jdstrand> kees: and hi! :)
[17:28] <jamespage> ScottK, that FTBFS is due to that specific method call being remove in jgoodies >= 1.5.0
[17:51] <arges> seb128, hi
[17:51] <seb128> stgraber, is there any chance you could review/get off the list the edubuntu misc:Depends item in the queue?
[17:51] <seb128> arges, hey
[17:52] <arges> seb128, regarding bug 943502, I have a branch linked for the oneiric  sru
[17:52] <seb128> arges, so you want that branch to be sponsored? the bug is confusing, it has a bunch of debdiff and no clear summary
[17:53] <arges> seb128, yea I apologize that bug has gone back and forth between being a backport and an SRU. It seems that an SRU is the correct direction now.
[17:54] <arges> so the latest branch should be the right one. I can make a debdiff
[17:54] <seb128> arges, ok, I will just sponsor that branch and let the SRU team decide on the SRU validity
[17:54] <arges> seb128, sounds good thanks
[17:56] <seb128> arges, btw you want to target -proposed for srus, not the stable serie (which is closed for uploads)
[17:57] <arges> seb128, ok should i fix my branch? or will you change that
[17:57] <seb128> arges, I'm fixing it, it's just a fyi for next time
[17:58] <arges> seb128, cool i'l write it down : ) thanks
[17:58] <seb128> arges, the version number, also it's better to append .1 that to increment ... e.g 0ubuntu3 -> 0ubuntu3.1 and not 0ubuntu4, since the next number is often already used in a new serie of Ubuntu and can't be reused
[17:59] <arges> ok i just did ' dch -i '
[18:00] <Quintasan> persia: ping
[18:03] <seb128> mdeslaur, hey, you might want to sponsor https://code.launchpad.net/~nobuto/ubuntu/raring/ecryptfs-utils/record-passphrase-dialogue-translatable/+merge/133860 ... the contributor added the changelog you asked for and you seemed happy with the other changes?
[18:07] <seb128> jodh, hey, is the debdiff on https://bugs.launchpad.net/ubuntu/+source/runit/+bug/245728 maybe something you would feel like reviewing when you have some time next week? it's an upstart job patch and in the sponsoring queue for a while
[18:08] <stgraber> seb128: yeah, I'll have a look. When I first saw the MP my thought was that it was somewhere between useless and inappropriate as those are meta packages, but I need to have a closer look to be sure.
[18:09] <seb128> stgraber, well, feel free to reject it, it seems wrongly targetted anyway since the packages are autogenerated so it's not the right vcs to change
[18:10] <seb128> stgraber, it would just be good to get it out of the sponsoring queue since it has been there for several weels
[18:10] <seb128> stgraber, thanks
[18:12] <infinity> seb128: Targetting the stable series instead of -proposed is fine now.
[18:12] <infinity> seb128: It rewrites the same way it does for the dev series.
[18:12] <infinity> arges: ^
[18:12] <seb128> infinity, oh ok
[18:13] <arges> infinity, ack
[18:13] <seb128> that explains why I saw a SRU from ev which was targetting the stable serie and went in ... I though he had tweaked the .changes or something
[18:13] <infinity> seb128: I used to always do that and tweak .changes, but yeah, on tweaking required now.
[18:14] <seb128> infinity, good to know, thanks
[18:14] <infinity> I figure if we socialize this hard enough, we may stop seeing -proposed in changelogs by, oh, say, 2015.
[18:14] <arges> seb128, and thanks for the uploads btw  : )
[18:14] <seb128> arges, yw
[18:15] <seb128> infinity, lol, announcing that it's possible on u-d or u-d-a would be a first step for sure ;-)
[18:16] <infinity> It may have come up in Colin's mail about the whole proposed-migration thing, but if it did, it would have been a bit of an aside.
[18:16] <infinity> But it doesn't bug me if people discover this on their own, either.  It's not "wrong" to have series-proposed in your changelog, after all.
[18:16] <infinity> I just find it slightly prettier not to both, cause the archive DTRT.
[18:16] <infinity> s/both/bother/
[18:18] <mdeslaur> seb128: ok, thanks
[18:21] <hallyn> jdstrand: kees: where is the new package source for new libseccomp?
[18:22] <jdstrand> hallyn: http://ftp-master.debian.org/new.html has 1.0.0-1
[18:23] <jdstrand> I imagine that is good enough for the lxc work, but 1.0.1 is available upstream
[18:23] <infinity> I suspect the uupdate from 1.0.0 to 1.0.1 would be clean and trouble-free.
[18:24] <infinity> Of course, the part where one can't download from the NEW queue makes it problematic to play around.
[18:24] <jdstrand> hallyn: (to get the package itself, go to http://ftp-master.debian.org/new/)
[18:24] <infinity> Unless kees still has the sources somewhere.
[18:25] <jdstrand> oh wait
[18:25] <jdstrand> that's right
[18:25] <jdstrand> hmm
[18:25] <jdstrand> hallyn: please disregard the parenthetical :)
[18:25] <infinity> kees: You haz seccomp upload on a hard drive somewhere?
[18:26] <infinity> kees: (Also, that NEW may have gone a bit quicker if it was to experimental, where people are concerned about ABI transitions in the middle of freezes)
[18:26] <infinity> s/are/aren't/
[18:40] <infinity> hallyn: So, I couldn't actually find a magical combination of Replace/Break/Conflict/etc that would make apt happily remove -common from the system, and I settled on this (which works):
[18:40] <infinity> hallyn: http://paste.ubuntu.com/1417371/
[18:41] <micahg> infinity: even if apt was happy, update-manager wouldn't be, so your solution is best
[18:43] <infinity> micahg: Yeah, this is definitely the safest solution in the face of all possible resolver confusions.
[18:53] <hallyn> infinity: thanks, i still don't understand why i can't reproduce it with a set of empty packages with teh same relations, which suggests id on't actually fully understand hwo qemu-common and qemu-keymaps are doing it, but that's not to say I don't beleive you :)
[18:57] <infinity> hallyn: The problem is that to successfully complete the upgrade, -common needs to go away or be upgraded.  The latter is something apt is happy to do, the former is something it ends up in a tizzy about because of the interdependencies of the previous versions.  This corner case may arguably be a resolver bug (as it does handle removals in more simple cases), but the workaround it much safer anyway, and will work for all resolvers.
[18:58] <infinity> s/it much/is much/
[18:58] <hallyn> infinity: i wonder if my tests failed because my qemu-common dummy pkg was empty...
[18:58] <hallyn> and apt was smart enough to say "ok then delete it"
[18:58] <hallyn> infinity: thanks, pushed to ppa.  hopefully this all works and i can send out final call for testing!
[19:08] <kees> infinity: yeah, on my disk. I can upload 1.0.1 to experimental, sure.
[19:08] <kees> jdstrand: what would be best for lxc? you want me to upload to ubuntu too?
[19:09] <infinity> kees: Just giving hallyn and stgraber the sources so they can play might be good, rather than uploading and forcing a transition.
[19:09] <infinity> kees: But yeah, uploading 1.0.1 to experimental, and asking ftpmaster to remove 1.0.0 from the unstable queue may go well for you.
[19:09] <infinity> (Unless you really have reasons to want it in wheezy)
[19:10] <kees> it's already been removed from testing. :P
[19:10] <infinity> Oh, so not much harm in it getting into sid.  Fair enough.  I hadn't checked.
[19:11] <kees> that's why I'm so confused about why it's not in unstable. why can't they just deNEW it?
[19:11] <infinity> Perhaps someone dislikes you personally. :P
[19:11] <infinity> Given your history with kernel patches, that could be a few someones. :)
[19:11] <kees> haha
[19:12] <infinity> It's one of the only old ones in the queue, which is curious.
[19:12] <infinity> Maybe you dropped an email on the floor with feedback?
[19:13] <kees> maybe
[19:13] <kees> I'll go review the bugs
[19:13] <hallyn> kees: thanks, i'll look in experimental for it in awhile
[19:14] <infinity> kees: Or just hunt down a friendly ftpmaster for a realtime WTF.
[19:14] <infinity> kees: But given it's been removed from testing, 1.0.1 to unstable makes perfect sense, no need to go experimental.
[19:14] <infinity> kees: I assumed (incorrectly) that there might actually be an older version in testing/unstable that you didn't want to force a transition on.
[19:15] <kees> infinity: yeah, nothing was using it yet, so that's why I did the 1.0.0 upload and asked for the bump into testing, but they opted for the other direction, which is fine.
[19:18]  * infinity raises an eyebrow at kees.
[19:19] <kees> dude was reconnect storming last week.
[19:20] <slangasek> autopasting the works of Cervantes to the channel upon connect will have that effect
[19:20] <kees> infinity: so... with 1.0.0 in NEW, should I upload 1.0.1 and merge the changelog like 1.0.0 never happened?
[19:20] <kees> slangasek: hahah
[19:21] <infinity> kees: You could do that, or just add a new changelog entry for 1.0.1 and -v the .changes
[19:25] <stokachu> stgraber: does pastebinit use debian's xmlrpc interface?
[19:25] <stokachu> paste.debian.net
[19:25] <stgraber> stokachu: no, it uses the form
[19:25] <stokachu> thats what i figured
[19:25] <stokachu> http://paste.debian.net/paste.pl?show_template=clients
[19:25] <stokachu> says its xmlrpc
[19:26] <stgraber> it'll be at some point ;) the paste.debian.net maintainer has been complaining about it for a while now
[19:27] <stokachu> thats cool i was just looking at some of the bugs on lp for the app
[19:27] <stokachu> and came across 1055522
[19:35] <kees> infinity: cool, yeah, I wasn't sure if debian DTRT for that or not. I only ever learned that for LP :)
[19:47] <kees> infinity: just to double-check, but "i386" means "linux-i386" not "any-i386", right?
[19:53] <infinity> kees: Right.  i386 refers to the dpkg arch.
[19:53] <infinity> kees: (As is true of any bare arch words)
[19:55] <infinity> kees: Oh, is hardening-wrapper still your baby?  If so, it's probably about time it learn about gcc-4.8
[19:56] <kees> yeah, I'd like to start getting people to move off it now that dpkg-buildflags is mostly sensible.
[19:56] <infinity> Can't disagree there.  I just saw it's diversion madness scroll by in a build log, which is why I thought of it.
[19:56] <kees> is 4.8 in raring already?
[19:57] <infinity> No, but doko has a PPA, and an upload to experimental.
[19:57] <kees> righto
[20:07] <slangasek> hrm, how did xserver-xorg-dev-lts-quantal land in universe
[20:22] <hallyn> infinity: mostly seemed to work only one issue - /etc/init/qemu-kvm.conf is still owned by qemu-kvm <shrug>.  oh, maybe i need to call it qemu-system.qemu-kvm.upstart.
[20:23] <infinity> hallyn: If it's not actually being installed by the new package...
[20:23] <hallyn> infinity: debian/rules had dh_installinit -pqemu-system --name qemu-kvm
[20:24] <hallyn> i figured that would be enough
[20:24] <hallyn> (it was enough in the dummy tests)
[20:24] <infinity> I haz no idea what magic dh employs there.
[20:25] <infinity> And I'd look at my local packages, but I baleeted them all.
[20:25] <hallyn> i'm going to have to play with that tonight
[20:25] <hallyn> infinity: thanks very much!
[20:27] <slangasek> hallyn: pointer to the debian/ directory you're using?
[20:29] <hallyn> slangasek: https://launchpad.net/~serge-hallyn/+archive/crossc/+files/qemu_1.2.0.dfsg-4.dsc
[20:29] <hallyn> i'm pretty confident that renaming the file will work...
[20:30] <hallyn> confident enough to leave for a walk and come back later :)
[20:37] <kees> hallyn: I uploaded it to unstable, hopefully it'll deNEX
[20:37] <kees> W
[20:39] <hallyn> kees: thx.  i'll have to look at this later this weekend or monday
[20:40]  * hallyn bbl tonight
[21:06] <ScottK> jamespage: Can you see what needs to be done to fix it?
[21:19] <cjwatson> hallyn: yeah, you don't want to use completely empty packages for testing - you might trigger dpkg's "disappeared" state which will change things around.  a trivial doc dir with changelog/copyright should be enough to avoid that
[21:20] <cjwatson> slangasek: Cervantes> I should totally do that some day.  In Latin
[21:47] <slangasek> cjwatson: Cervantes in Latin?  Heresy!
[21:48] <slangasek> hallyn: so yes, you need to name the file debian/qemu-system.qemu-kvm.upstart for this to work
[21:48] <slangasek> hallyn: you decided not to rename the upstart job?
[21:49] <cjwatson> slangasek: well, y'know, I can't read Spanish so that would be *silly*
[21:54] <infinity> slangasek: Not renaming it avoided a lot of potential hassle.
[21:55] <jamespage> ScottK, I think so
[21:56] <ScottK> jamespage: Excellent.
[21:59] <slangasek> infinity: yep, clearly avoids hassle, I just missed the memo that the goal had changed
[22:14] <jamespage> ScottK, fix uploaded to raring
[22:14]  * jamespage feels dirty as he had to patch IDE generated code
[22:27] <israeldahl_> HELP!!!  software-center doesn't find  a program, but apt-get does!!  what file is missing (the desktop file is present)
[22:27] <israeldahl_> what files does the software-center look at to display a program??  I am at a loss
[22:27] <israeldahl_> I was assured that the desktop file is the key componant for the software center
[22:27] <israeldahl_> this is not the case
[22:29] <israeldahl_> Anyone have any clue???
[22:31] <sladen> israeldahl_: what is the example search search and the program that is found/not found?
[22:31] <sladen> israeldahl_: what is the example search string and the program that is found/not found?
[22:31] <israeldahl_> in raring ringtail lmms.
[22:32] <israeldahl_> lmms the program is NOT EVEN FOUND!
[22:32] <freedomrun> is there a way to enable minimise on click function in ubuntu 12.10 Unity??!
[22:34] <israeldahl_> sladen: I merged a new version into raring... however now software center cannot see it.
[22:35] <sladen> israeldahl_: so the package is 'lmms'.  Exactly what "apt-get search ..." string are you typing, and exactly what search are you typing in Software Centre?
[22:36] <israeldahl_> sladen: in USC I type "lmms"  and for apt-get I type "sudo apt-get install lmms"
[22:37] <israeldahl_> sladen:  the package doesn't exist in the USC.
[22:38] <xnox> israeldahl_: desktop file data needs a refresh & reupload after that it will appear in USC.
[22:39] <xnox> israeldahl_: an easy way to check for this mismatch is by install lmms & then trying to look it up in the USC. Does it appear then?
[22:39] <israeldahl_> xnox: what do you mean?  it was freshly merged in.  the version I merged in is 0.4.13  the one in quantal and precise is 0.4.10
[22:39] <israeldahl_> xnox: no I tried that
[22:39] <xnox> israeldahl_: package in the archive and package appearing in USC is not an instant transition.
[22:40] <israeldahl_> xnox: so it may just be a delay??
[22:40] <xnox> give me a second to look at the package.
[22:40] <israeldahl_> xnox: OK... it is for RARING, not the LTS or quantal
[22:40] <xnox> israeldahl_: yes, i know.
[22:41] <israeldahl_> xnox: OK.. sorry I just wanted to be absolutely sure
[22:42] <xnox> israeldahl_: dpkg-deb -c lmms_0.4.13-0ubuntu1_amd64.deb | grep desktop returns nothing.
[22:42] <israeldahl_> xnox: well how does it install the desktop file?  I know the desktop file was in the source?
[22:43] <xnox> israeldahl_: the desktop file is in the lmms-common package, which is incorrect. It should be together with the executable it points to.
[22:44] <xnox> israeldahl_: and then there is propagation delay to refresh USC data. (which I am not sure how long it is).
[22:44] <israeldahl_> OH... so the lmms.install file should have the pointer, not lmms-common.install! :)
[22:44] <israeldahl_> xnox:: does that seem right?
[22:45] <xnox> israeldahl_: yes.
[22:45]  * xnox needs to make sure USC is documented somewhere.
[22:46] <israeldahl_> xnox: I feel really quite silly.... ok, can I just recommit it back into my bzr branch and it will send the fix to the merge???
[22:46] <israeldahl_> xnox: yes.. USC documentation would be awesome (as well as changelog formatting)
[22:47] <xnox> israeldahl_: please push a branch & make a new merge proposal (that way it will end up in the sponsorship queue for sponsors to re-upload)
[22:48] <israeldahl_> xnox: So, I have to go through the same thing again?  Can I just use the same branch?
[22:48] <xnox> israeldahl_: what do you mean by changelog formatting?
[22:49] <xnox> israeldahl_: yes you can use the same branch, but open a new merge proposal, if the previous one is already completed (status = "merged")
[22:49] <israeldahl_> xnox: Oh...  the "dch -i" then I have to use minus signs and only so many characters per line, and other stuff
[22:49] <israeldahl_> xnox: it is merged... I will do this right now
[22:50] <xnox> israeldahl_: the changelog formatting is documented here http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog and there is a general sense of "style" but inherently it's not structured.
[22:51] <israeldahl_> xnox: Ok, well I was told to format my changelog entry differently than I had... I differently than I had.
[22:52] <xnox> israeldahl_: can you point me to the comment?
[22:53] <xnox> israeldahl_: generally a tool lintian can tell me many small things about changelog & etc. Run $ lintian -i -I -E --pedantic -v lmms*.dsc
[22:54] <xnox> israeldahl_: you can also run against lintian against lmms*.changes file.
[22:54] <israeldahl_> xnox: well someone changed the way I had it.  I used TAB instead of spacing (python) and I used + instead of  -
[22:54] <israeldahl_> xnox: OK... I am running that now... I noticed lintian warnings when I used pbuilder
[22:56] <israeldahl_> xnox: where do I run that command from?
[22:56] <israeldahl_> xnox: oh wait
[22:59] <israeldahl_> xnox: http://ubuntuone.com/3kwVRUIm2CTjEI8P0ouKOd
[23:01] <ScottK> jamespage: Thanks.
[23:03] <israeldahl_> xnox: that is the lintian.  I just finished proposing the merger... the warnings seemed light enough
[23:04] <xnox> israeldahl_: the ones that are W: are important enough to fix.
[23:04] <xnox> israeldahl_: ideally you should fix all of them.
[23:04] <israeldahl_> xnox: Yeah... well this is my first time of doing anything like this.
[23:05] <xnox> israeldahl_: =) I'm trying to nudge you to improve your skills =)))) for upload after this one, ok ? ;-)
[23:06] <israeldahl_> xnox: yeah sure!!  the next version 0.4.14 is coming out next.. and I will try to fix it for that merger,
[23:07] <israeldahl_> xnox: if they can wait?
[23:18] <israeldahl_> xnox: does lmms-common.install still need /usr/share/applications as well as lmms.install?
[23:47] <darkxst> Sarvatt, whenever you get a chance can you review/merge these https://code.launchpad.net/~darkxst/ppa-purge/bash-completion  https://code.launchpad.net/~darkxst/ppa-purge/lp706774
[23:50] <achiang> jtaylor: hi, still around?
[23:50] <jtaylor> achiang: yes?
[23:52] <achiang> jtaylor: hey, i'm looking to make a patch for valgrind for the R cycle, recommendations on how to proceed? the patch i want landed in upstream valgrind trunk this week. debian is still in a freeze so i'm thinking just make a debdiff against most recent valgrind in raring (which is still the Q) version and subscribe u-sponsors to bug?
[23:53] <jtaylor> I'd prefer to get the debian exp version of valgrind in raring
[23:53] <jtaylor> what kind of patch?
[23:53] <achiang> https://bugs.kde.org/show_bug.cgi?id=310792
[23:54] <achiang> jtaylor: this will be extremely helpful for our "ubuntu pilates" effort centered around the nexus 7
[23:56] <jtaylor> achiang: I'm no coredev so I have no rights to valgrind, but I'm sure they'd appreciate if you could get the patch in via debian
[23:56] <jtaylor> it should be no problem to add it when we merge though
[23:57]  * achiang groans to self...
[23:57] <achiang> i guess i've never worked with the valgrind maintainer in debian. maybe that person is fast :)
[23:58] <jtaylor> he is very fast in uploading new versions
[23:58] <infinity> jtaylor: I don't see a valgrind in experimental...
[23:58] <jtaylor> oh unstable even
[23:59] <infinity> Oh indeed, we seem to be a bit behind.
[23:59] <infinity> I should bug that Julian Taylor guy, he's TIL.