=== slank is now known as slank_away === mako_ is now known as mako [04:25] mhall119: I'm around now, missed you on G+ [04:43] mfisch: ? [04:52] mhall119: you invited me to a hangout [04:52] mhall119: about an hour ago [05:05] I did? I didn't mean to [05:06] I hope it didn't invite the entire community :( [05:06] I was just trying it out, to see if it could be made on-air === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === stan_ is now known as stan [07:45] good morning [07:46] dholbach: good morning [07:46] hey achiang === doko_ is now known as doko === Tonio_ is now known as Tonio_aw [08:44] Good morning === yofel_ is now known as yofel === mcclurmc_away is now known as mcclurmc === nitro is now known as Guest44401 === mcclurmc is now known as mcclurmc_away === tkamppeter_ is now known as tkamppeter === henrix_ is now known as henrix [09:48] ev: https://code.launchpad.net/~daisy-pluckers/+recipe/apport-test-crashes === nitro is now known as Guest66980 [10:03] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage, mterry [10:36] * dholbach hugs jamespage and mterry === infinity1 is now known as infinity [11:16] jdstrand: Have you had a chance to consider bug 1077484? [11:16] Launchpad bug 1077484 in shadow (Ubuntu) "[MIR] libsemanage (shadow's rdep to continue SELinux support in shadow)" [Undecided,Confirmed] https://launchpad.net/bugs/1077484 [11:21] ev, please update bug 1084624 with the conclusion of yesterday's discussion (I don't know what it was, exactly) [11:21] Launchpad bug 1084624 in Apport "Can't provide comments when submitting an error report" [High,Triaged] https://launchpad.net/bugs/1084624 [11:22] will do [11:25] * apw wonders where /etc/mailcap comes from, which package ... (so he can file a bug against it) [11:25] 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] seb128, that's a known bug, let me find it [11:26] seb128, that said, I still don't understand why it happens *now* === cpg is now known as cpg|away [11:27] seb128, I think it's bug 1078543 [11:27] Launchpad bug 1078543 in pulseaudio (Ubuntu) "[raring] Pulse audio fails to start with error 'Failed to open module "module-esound-protocol-unix": file not found'" [Undecided,Confirmed] https://launchpad.net/bugs/1078543 [11:28] seb128, I believe the problem is that the esound compat file is the wrong arch [11:29] diwic, correct, from jason's log [11:29] ii pulseaudio 1:2.1-0ubuntu4 amd64 PulseAudio sound server [11:29] ii pulseaudio-esound-compat 1:2.1-0ubuntu4 i386 PulseAudio ESD compatibility layer [11:29] diwic, thanks === _salem is now known as salem_ === Tonio_aw is now known as Tonio_ === mcclurmc_away is now known as mcclurmc [12:23] 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) === odifis is now known as oDiafanos [12:30] dpkg-blame should be a command ;-) [12:31] mlankhorst: heh [12:38] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry [12:39] cjwatson: not yet, hope to get to it today [12:46] arges, OK if I steal the rsyslog merge for raring from you? [12:53] could somebody set those "work in progress": [12:53] https://code.launchpad.net/~brightbox/ubuntu/quantal/lvm2/fix-for-1075994/+merge/133645 [12:53] https://code.launchpad.net/~brightbox/ubuntu/quantal/lvm2/fix-for-1076304/+merge/133438 [12:53] https://code.launchpad.net/~lqs/ubuntu/precise/tcc/tcc-fix-mmap-leak/+merge/134058 [12:53] thanks [12:54] stgraber, pitti, cjwatson: ^ [12:54] https://code.launchpad.net/~andrikos/ubuntu/quantal/fglrx-installer/fix-switch-to-igpu/+merge/132962 as merged as well [12:55] WIPs done. Where's that been merged? === Tonio_ is now known as Tonio_aw === mnepton is now known as mneptok === cpg|away is now known as cpg [13:06] 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... === cpg is now known as cpg|away [13:07] cjwatson, well http://www.phorogit.com/index.php?p=fglrx-packaging.git&a=commitdiff&h=9eaed4a5fee3d67c8ca8cd026189f8cc461a532a&hb=a1d481315f8ffffcd3ca67f9d6c581f1cf44b9fa rather [13:07] seb128: is it uploaded? [13:08] xnox, not yet, but it doesn't need to stay in the sponsoring queue... [13:08] ok. [13:08] xnox, isn't "merged in the vcs" equivalent to "merged"? [13:08] xnox, if you merge to lp:ubuntu/ without uploading launchpad would set it to merged as well [13:09] 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] xnox, well, tseliot commented yesterday saying it's fixed upstream with a link to git diff url [13:12] good enough for merged status then =) [13:12] jamespage, hey. are you talking about bug 1059592 ? I thought raring was already fixed in comment #8 [13:12] Launchpad bug 1059592 in rsyslog (Ubuntu Quantal) "Message and memory corruption in rsyslog" [High,Fix committed] https://launchpad.net/bugs/1059592 [13:13] arges, no - there is a new upstream version in Debian I want to merge; it fixes that problem [13:13] jamespage, yea that'd work too if its > 5.8.7 [13:14] arges, 5.8.11 - I'll merge it if thats OK with you (polite to check with last uploader before stealing merges :-)) [13:14] jamespage, yup no problem. I figured that's what would happen for that one anyway [13:17] seb128: OK, marked as merged then [13:19] cjwatson, thanks === Tonio_aw is now known as Tonio_ === mnepton is now known as mneptok === pcarrier_ is now known as pcarrier === soren_ is now known as soren === Quintasan_ is now known as Quintasan [13:54] 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:54] Launchpad bug 1035219 in Baltix "In System Settings preference tool/keyboard layouts page automaticaly wrong language selectedGNOME" [High,In progress] [13:56] The patch looks ugly and big, so I guess probably not. [13:57] marga, hey, "bengali"... that sounds like a different bug [13:57] It's what the bot said [13:57] what bot? [13:58] the wrong language gets selected if you go to the regional settings and don't click on anything, using gnome/cinnamon [13:58] marga, that bug is about having the wrong language selected when you open the region capplet [13:58] Up there ubottu [13:58] marga, yeah, and you wrote "the bengali issue outside of Unity" [13:58] Yeah, bengali is the first in the list. [13:58] So, everything turns to bengali. At least here. [13:58] oh, ok ... it's chinese for most people [13:58] yeah, depends of the langpacks installed [13:59] marga, I got confused because I was reading https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/991002 earlier [13:59] Oh... Right, I guess we have more languages installed. [13:59] Launchpad bug 991002 in lightdm (Ubuntu) "Change name for bn-BD from 'Bengali(Bangladesh)' to 'Bangla(Bangladesh)')" [Undecided,In progress] [13:59] 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] marga, in any case I didn't fix that bug, the comment that closed the bug is confusing [14:00] gnome-control-center (1:3.6.3-0ubuntu3) raring; urgency=low [14:00] * debian/patches/60_ubuntu_nav_bar.patch: [14:00] - restore the navigation bar interface [14:00] that's nothing to do with that issue [14:00] ok, I guess it's the workaround from jbicha in 1:3.6.3-0ubuntu1 [14:00] Oh. I thought it was a very complicated way of fixing the widget. [14:01] marga, it seems like it was workaround in http://bazaar.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu/revision/505 [14:01] Ah, I see... Silly me. It's patch 52 [14:02] marga, I'm fine SRUing the workaround, it's not perfect but better than the bug for sure [14:02] marga, is there any chance you could test if that fix your issue? [14:03] Sure, yes. [14:03] I can test the patch for precise and quantal [14:03] Prepare the package and stuff [14:04] marga, that would be great, thanks [14:04] Ok, I'll get on with that. Thanks to you :) [14:04] yw ;-) [14:05] ScottK, micahg: taking a look at sikuli now [14:26] 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] (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] ) [14:28] hallyn: will that ^ affect lxc? [14:46] * xnox ponders if stgraber has lxc highlight or not ^ [14:48] xnox: thanks [14:48] 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:48] Launchpad bug 943502 in whois (Ubuntu Oneiric) "whois doesn't properly query .hr/.sx/.pe TLDs and incorrect format for whois.arin.net" [Medium,In progress] https://launchpad.net/bugs/943502 [14:50] jdstrand: yup, more than likely. [14:52] xnox: no but I pretty much always read the scrollback for this channel :) [14:53] stgraber: I am so sorry, sir. I will improve, sir. =) [14:54] seb128, if the package version was ubuntu1, should the version in my debdiff be ubuntu2 or ubuntu1.1 ? [14:54] marga, 1.1 for a SRU [14:54] ok, tnx [14:54] yw === slank_away is now known as slank [15:00] 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] jodh, you might be interested in having a chat with the guy in https://plus.google.com/109795858099658821877/posts/192eMwxNAtF [15:02] dholbach: thanks - on it. [15:02] jodh, awesome :-D [15:03] 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] seb128: not particularly, but interesting. [15:03] * hallyn goes to read [15:04] give the guy a hug! :) [15:04] * dholbach likes the new G+ communities already [15:05] too much brightness and pictures, can i get a text feed? :) [15:05] right :) [15:09] hallyn: that's fine-- no rush on my end [15:13] dholbach: I've provided some details for David now. [15:15] jodh, great - I hope he'll become an active contributor! [15:17] 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] marga, looking [15:23] Writing Regression Potentials is always the hardest part of filing an SRU [15:23] I have no idea of the regression potentials that this might have. [15:25] 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] Yes, and I know that it's important, but most of the time I have no idea of what to put there. [15:26] 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] But that's the test case [15:26] Regression potential is other stuff that could break [15:27] well, there is little potential to impact on anything else [15:27] I often end up by writing lame "regression potential" sections and I guess others do the same... [15:29] Well, there, I did my best. [15:29] Let me know if I need to do anything else. [15:32] marga, looks good to me, I'm sponsoring the updates, thanks [15:32] Thanks for the sponsoring :) [15:33] marga, btw " * Non-maintainer upload." ... that's not needed in Ubuntu ;-) [15:34] heh, I wasn't sure, that's dch -n default behaviour. [15:34] I'll keep it in mind for the next time. [15:54] 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] if i have bpkg.preinst, postinst and postrm doing mv_confile apkg.conf bpkg.conf 1.0 apkg, then nothing happens... [15:54] trying calling them apkg.* now... [15:56] hm maybe that works === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ [15:58] hallyn: dpkg-maintscript-helper doesn't quite work across package renames. [16:01] yay it works [16:01] xnox: it did! [16:01] oh it's not a pkg rename [16:01] the confile is moved to another pkg [16:02] hallyn: Hmm.. See interesting discussion about ~ similar issue here: http://debian.2.n7.nabble.com/Renaming-packages-maintscripts-td1058526.html#none [16:03] looking [16:04] hallyn: Having it in apkg.preinst probably works, except for the unwind cases, I suspect. [16:06] 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] 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] hallyn: (This is all just trying to follow the logic through in my head, anyway) [16:07] hallyn: Ultimately, I think the answer here is that mv_conffile can't quite do this right. [16:08] 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] hallyn: It handles the first upgrade right, or so you think. [16:11] xnox: infinity: actually apg-et install bpkg worked too. [16:11] 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] infinity: no they were not, [16:11] and i changed them locally, [16:11] and dpkg -S bpkg.conf shows owned by bpkg now [16:12] Yeah, but it's a modified conffile by default now. [16:12] apt-get install --reinstall bpkg still works [16:12] If apkg.conf and bpkg.conf aren't the same. [16:12] hm [16:12] good point [16:12] So, the next time you change bpkg.conf, people who never modified apkg.conf will get a prompt. [16:12] And they shouldn't. [16:12] now, in the case i care about, [16:12] which is qemu, they will be identical :) [16:12] are you sure? what does it compare against? [16:13] It compares the dpkg database to the file on disk. [16:13] note i am note getting a prompt at all. not sure if i'm doing something funky [16:13] If they don't match, you get prompts. [16:13] ok, not the dpkg-preinst or somesuch? [16:13] You won't get prompts on the moves. [16:13] I meant the next upgrade that changes the conffile. [16:13] oh [16:13] i see [16:13] But, if they're the same in old and new packages, that's not going to be a problem. [16:14] infinity: which means it's worth making sure they're identical [16:14] Yes. [16:14] If they're not identical, this really won't work. [16:14] problem: does this mean they have to be identicl for a whole LTS cycle? [16:14] For the move to work without later prompting, yeah. [16:15] Now, there are clever ways around that. [16:15] But mv_conffile won't do them for you. [16:15] You can work up a hash of every packages version of the old conffile. [16:15] And on upgrade to the new package (in preinst), check if their current one matches one of those hashes. [16:16] If so, delete it outright, and let dpkg create the new one as it was going to. [16:16] If it doesn't match, move it to a temp file, then copy it to the new location in postinst. [16:16] 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] These are some of the same steps mv_conffile takes, but with the addition of maintaining history. [16:17] 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] Wait, are you actually changing the file name, or just moving it from one package to another? [16:18] cjwatson: filename and package move, in one shot. [16:18] If you can get away with not changing the filename, I think Replaces is enough these days [16:18] cjwatson: So neither replaces nor mv_conffile is a fit. [16:19] uh. well. but maybe i don't need to [16:19] hallyn: But yes, Colin has a point, Replaces will take over conffiles if you don't rename them. [16:19] hallyn: And if the name offends you in two years, you can mv_conffile it then. :P [16:19] then i'll just keep it as qemu-kvm.conf! thanks === rickspencer3_ is now known as rickspencer3 [16:20] but if i have several pkgs doing Replaces: qemu-kvm, will it know to use the one which ships that file? [16:20] Yes. [16:20] Replaces just means "if there's an overlap, this one wins". [16:20] cool, thanks. so taht issue is solved :) [16:20] leaving only the original problem [16:20] This is a problem if more than two packages provide a file and have replaces, but. Uhm. Don't do that. [16:21] infinity: the upgrades still aren't working. but when i mimick the situation with dummy pkgs it seems to work [16:21] hallyn: Curious. Is this all in the PPA again? [16:21] it seems like 'apt-get dist-upgrade' is saying "qemu-kvm depends on qemu-system which recommends qemu-utils", [16:21] Right, which is correct... [16:21] "and qemu-utils breaks qemu-kvm so let me uninstall that, now i don't need qemu-sytem any more" [16:21] or something [16:22] That shouldn't happen if all the versions are sane now. [16:22] 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] they're all in same source pkg [16:22] Let me have a look after I go abuse my lungs. [16:22] :) [16:35] hallyn: qemu-common has gone away completely, right? [16:42] infinity: yes [16:42] 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] infinity: at soren's suggestion, in case apt is doing something funky with the extra constraint [16:44] 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] jdstrand: libseccomp> yeah, nothing is passing NEW in debian because they're stuck in freeze. *roll eyes* [16:49] infinity: yeah that's why i took jamespage's advice and tried to reproduce with dummy pkgs [16:49] seb128: it's all merged and uploaded [16:50] tseliot, thanks a lot! [16:50] but i'm clearly missing some aspect of it in my dummy versions === Tonio_ is now known as Tonio_aw [16:52] now i'm not accounting for qemu-keymaps in my dummies, maybe it changes something [16:52] 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] hallyn: If you can gimme a $while to test this theory, I'll get back to you. [16:53] infinity: awesome, thanks [16:53] * hallyn loves software smarter than myself === Tonio_aw is now known as Tonio_ [16:54] 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] huh [16:55] One I'd have solved by now if this didn't take SO LONG to build. Wow. [16:56] 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] Or maybe everything's just very similar looking. [17:00] infinity: it does build a whoel slew of targets [17:00] infinity: tried to reproduce the qemu-commnon bit, didn't reproduce the problem (bu ti probably did it wrong) [17:02] hallyn: Also, why does qemu-system Break and Replace itself? :P [17:03] * infinity fixes that while he's in here. [17:04] infinity: oops, yeah that's mine, not from original debian. [17:12] hallyn: I'm not *sure* it's doable either, but I think it *should* work :) [17:25] kees: hrmm, that is a bummer. I figured it could go to unstable or experimental [17:26] kees: fyi, you might be interested in the conditional ack of bug #1082431 [17:26] Launchpad bug 1082431 in libseccomp (Ubuntu) "[MIR] libseccomp" [Undecided,In progress] https://launchpad.net/bugs/1082431 [17:27] kees: that says, doesn't sound like it can get into Ubuntu until lxc is fixed [17:27] s/says/said/ [17:27] kees: and hi! :) === attente is now known as attente_zzz [17:28] ScottK, that FTBFS is due to that specific method call being remove in jgoodies >= 1.5.0 [17:51] seb128, hi [17:51] stgraber, is there any chance you could review/get off the list the edubuntu misc:Depends item in the queue? [17:51] arges, hey [17:52] seb128, regarding bug 943502, I have a branch linked for the oneiric sru [17:52] Launchpad bug 943502 in whois (Ubuntu Oneiric) "whois doesn't properly query .hr/.sx/.pe TLDs and incorrect format for whois.arin.net" [Medium,In progress] https://launchpad.net/bugs/943502 [17:52] 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] 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] so the latest branch should be the right one. I can make a debdiff [17:54] arges, ok, I will just sponsor that branch and let the SRU team decide on the SRU validity [17:54] seb128, sounds good thanks [17:56] arges, btw you want to target -proposed for srus, not the stable serie (which is closed for uploads) [17:57] seb128, ok should i fix my branch? or will you change that [17:57] arges, I'm fixing it, it's just a fyi for next time [17:58] seb128, cool i'l write it down : ) thanks [17:58] 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] ok i just did ' dch -i ' [18:00] persia: ping [18:03] 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] 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:07] Launchpad bug 245728 in runit (Ubuntu) "runit doesn't stop and /var isn't umounted on shutdown" [Medium,Confirmed] === Tonio_ is now known as Tonio_aw [18:08] 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] 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] stgraber, it would just be good to get it out of the sponsoring queue since it has been there for several weels [18:10] stgraber, thanks [18:12] seb128: Targetting the stable series instead of -proposed is fine now. [18:12] seb128: It rewrites the same way it does for the dev series. [18:12] arges: ^ [18:12] infinity, oh ok [18:13] infinity, ack [18:13] 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] seb128: I used to always do that and tweak .changes, but yeah, on tweaking required now. [18:14] infinity, good to know, thanks [18:14] I figure if we socialize this hard enough, we may stop seeing -proposed in changelogs by, oh, say, 2015. [18:14] seb128, and thanks for the uploads btw : ) [18:14] arges, yw === henrix is now known as henrix_ [18:15] infinity, lol, announcing that it's possible on u-d or u-d-a would be a first step for sure ;-) [18:16] 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] 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] I just find it slightly prettier not to both, cause the archive DTRT. [18:16] s/both/bother/ [18:18] seb128: ok, thanks === mcclurmc is now known as mcclurmc_away [18:21] jdstrand: kees: where is the new package source for new libseccomp? [18:22] hallyn: http://ftp-master.debian.org/new.html has 1.0.0-1 [18:23] I imagine that is good enough for the lxc work, but 1.0.1 is available upstream [18:23] I suspect the uupdate from 1.0.0 to 1.0.1 would be clean and trouble-free. [18:24] Of course, the part where one can't download from the NEW queue makes it problematic to play around. [18:24] hallyn: (to get the package itself, go to http://ftp-master.debian.org/new/) [18:24] Unless kees still has the sources somewhere. [18:25] oh wait [18:25] that's right [18:25] hmm [18:25] hallyn: please disregard the parenthetical :) [18:25] kees: You haz seccomp upload on a hard drive somewhere? [18:26] 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] s/are/aren't/ [18:40] 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] hallyn: http://paste.ubuntu.com/1417371/ [18:41] infinity: even if apt was happy, update-manager wouldn't be, so your solution is best [18:43] micahg: Yeah, this is definitely the safest solution in the face of all possible resolver confusions. [18:53] 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] 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] s/it much/is much/ [18:58] infinity: i wonder if my tests failed because my qemu-common dummy pkg was empty... [18:58] and apt was smart enough to say "ok then delete it" [18:58] infinity: thanks, pushed to ppa. hopefully this all works and i can send out final call for testing! [19:08] infinity: yeah, on my disk. I can upload 1.0.1 to experimental, sure. [19:08] jdstrand: what would be best for lxc? you want me to upload to ubuntu too? [19:09] kees: Just giving hallyn and stgraber the sources so they can play might be good, rather than uploading and forcing a transition. [19:09] 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] (Unless you really have reasons to want it in wheezy) [19:10] it's already been removed from testing. :P [19:10] Oh, so not much harm in it getting into sid. Fair enough. I hadn't checked. [19:11] that's why I'm so confused about why it's not in unstable. why can't they just deNEW it? [19:11] Perhaps someone dislikes you personally. :P [19:11] Given your history with kernel patches, that could be a few someones. :) [19:11] haha [19:12] It's one of the only old ones in the queue, which is curious. [19:12] Maybe you dropped an email on the floor with feedback? [19:13] maybe [19:13] I'll go review the bugs [19:13] kees: thanks, i'll look in experimental for it in awhile [19:14] kees: Or just hunt down a friendly ftpmaster for a realtime WTF. [19:14] kees: But given it's been removed from testing, 1.0.1 to unstable makes perfect sense, no need to go experimental. [19:14] 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] 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] dude was reconnect storming last week. [19:20] autopasting the works of Cervantes to the channel upon connect will have that effect [19:20] 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] slangasek: hahah [19:21] kees: You could do that, or just add a new changelog entry for 1.0.1 and -v the .changes [19:25] stgraber: does pastebinit use debian's xmlrpc interface? === hggdh_ is now known as hggdh [19:25] paste.debian.net [19:25] stokachu: no, it uses the form [19:25] thats what i figured [19:25] http://paste.debian.net/paste.pl?show_template=clients [19:25] says its xmlrpc [19:26] it'll be at some point ;) the paste.debian.net maintainer has been complaining about it for a while now [19:27] thats cool i was just looking at some of the bugs on lp for the app [19:27] and came across 1055522 === deryck is now known as deryck[lunch] [19:35] infinity: cool, yeah, I wasn't sure if debian DTRT for that or not. I only ever learned that for LP :) [19:47] infinity: just to double-check, but "i386" means "linux-i386" not "any-i386", right? [19:53] kees: Right. i386 refers to the dpkg arch. [19:53] kees: (As is true of any bare arch words) [19:55] kees: Oh, is hardening-wrapper still your baby? If so, it's probably about time it learn about gcc-4.8 [19:56] yeah, I'd like to start getting people to move off it now that dpkg-buildflags is mostly sensible. [19:56] 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] is 4.8 in raring already? [19:57] No, but doko has a PPA, and an upload to experimental. [19:57] righto [20:07] hrm, how did xserver-xorg-dev-lts-quantal land in universe === carif_ is now known as carif [20:22] infinity: mostly seemed to work only one issue - /etc/init/qemu-kvm.conf is still owned by qemu-kvm . oh, maybe i need to call it qemu-system.qemu-kvm.upstart. [20:23] hallyn: If it's not actually being installed by the new package... [20:23] infinity: debian/rules had dh_installinit -pqemu-system --name qemu-kvm [20:24] i figured that would be enough [20:24] (it was enough in the dummy tests) [20:24] I haz no idea what magic dh employs there. [20:25] And I'd look at my local packages, but I baleeted them all. [20:25] i'm going to have to play with that tonight [20:25] infinity: thanks very much! [20:27] hallyn: pointer to the debian/ directory you're using? [20:29] slangasek: https://launchpad.net/~serge-hallyn/+archive/crossc/+files/qemu_1.2.0.dfsg-4.dsc === salem_ is now known as _salem [20:29] i'm pretty confident that renaming the file will work... [20:30] confident enough to leave for a walk and come back later :) [20:37] hallyn: I uploaded it to unstable, hopefully it'll deNEX [20:37] W [20:39] kees: thx. i'll have to look at this later this weekend or monday [20:40] * hallyn bbl tonight === deryck[lunch] is now known as deryck [21:06] jamespage: Can you see what needs to be done to fix it? [21:19] 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] slangasek: Cervantes> I should totally do that some day. In Latin === attente_zzz is now known as attente [21:47] cjwatson: Cervantes in Latin? Heresy! [21:48] hallyn: so yes, you need to name the file debian/qemu-system.qemu-kvm.upstart for this to work [21:48] hallyn: you decided not to rename the upstart job? [21:49] slangasek: well, y'know, I can't read Spanish so that would be *silly* [21:54] slangasek: Not renaming it avoided a lot of potential hassle. [21:55] ScottK, I think so [21:56] jamespage: Excellent. [21:59] infinity: yep, clearly avoids hassle, I just missed the memo that the goal had changed [22:14] ScottK, fix uploaded to raring [22:14] * jamespage feels dirty as he had to patch IDE generated code [22:27] HELP!!! software-center doesn't find a program, but apt-get does!! what file is missing (the desktop file is present) [22:27] what files does the software-center look at to display a program?? I am at a loss [22:27] I was assured that the desktop file is the key componant for the software center [22:27] this is not the case [22:29] Anyone have any clue??? [22:31] israeldahl_: what is the example search search and the program that is found/not found? [22:31] israeldahl_: what is the example search string and the program that is found/not found? [22:31] in raring ringtail lmms. [22:32] lmms the program is NOT EVEN FOUND! [22:32]