[00:43] <stokachu> is there a way to just manually change the version string in a debian/changelog file with dch? basically i can do "dch -v 0.1+git-aaabbb-0ubuntu1" but without loading up the editor and appending a extra * at the end of the entry
[02:01] <ScottK> mitya57: For the new sip API version it's a transition.  You'll need to rebuild all the packages that depend on the API.  It definitely needs an FFe and please test rebuild everything before you ask because that'll be my first question.
[02:51] <mitya57> ScottK: Ok, will do
[03:15] <RAOF> Man I wish our python pretty-printers for STL containers weren't all busted to hell.
[05:35] <pitti> Good morning
[05:45] <RAOF> Aloha, pitti!
[05:45] <pitti> hey RAOF
[05:55] <RAOF> How does that umockdev sync interact with the STOP THE WORLD!! from phone CI?
[05:55] <pitti> RAOF: umockdev isn't (I hope) on any image
[05:55] <infinity> libumockdev0 (from umockdev) is seeded in:
[05:55] <infinity>   ubuntu-touch: daily-preinstalled
[05:55] <pitti> RAOF: also, I only read that afterwards
[05:55] <RAOF> But is in all the CI stuff.
[05:56] <infinity> That said, you can see my opinion of the stop the line thing in my followup post...
[05:56] <pitti> RAOF: yes, sure; as I said, the three syncs (postgresql and umockdev) were the first things I did this morning before attacking my mailboxes
[05:56] <pitti> as yesterday evening they still weren't imported into LP
[05:56] <pitti> but I fully agree with infinity here
[05:56] <RAOF> Yeah, I've certainly done similar things in the past.
[05:57] <pitti> I think we dialed the "no regressions" slider way too far into the other direction now, it's incredibly hard to land anything these days
[05:58] <infinity> pitti: Yes, ScottK brought that point up nicely.
[06:01] <RAOF> Oh, *that's* what he meant!
[06:41] <Mirv> I'd need a packaging ack from a core-dev, ubuntu-download-manager adding a QML plugin http://162.213.34.102/job/landing-001-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-download-manager_0.3+14.04.20140321-0ubuntu1.diff
[06:44] <RAOF> Mirv: = ${binary:Version}?
[06:45] <RAOF> Ah, we've already decided that ABI is for chumps? :)
[06:46] <Mirv> good point, that may be too strict
[06:47] <Mirv> I don't think we've that in others
[06:47] <RAOF> No, you do have that in others.
[06:48] <Mirv> thank you, I'll note that on the branch. darn.
[06:49] <RAOF> The package description isn't consistent with the other ones, either.
[06:49] <RAOF> But I wouldn't block on that.
[06:51] <Mirv> it might be of course that the '0' in lib means they aren't really committing themselves to an ABI yet
[07:16] <pitti> RAOF: umockdev 0.8 just made it into trusty, so happy evemu events recording/replaying :)
[07:19] <dholbach> good morning
[07:29] <zyga> doko_: good morning
[07:29] <zyga> doko_: regarding your question yesterday, how can I reproduce that build failure of bzr?
[07:59] <pitti> zyga: I get the same failure with
[08:00] <pitti> $ bzr selftest -v bzrlib.tests.test_email_message.TestEmailMessage.test_multipart_message
[08:00] <pitti> zyga: in current trusty
[08:00] <pitti> (with apt-get install bzr python-bzrlib.tests)
[08:05] <zyga> pitti: thanks
[08:05] <zyga> pitti: I recall that bzrlib was failing on tests in trunk a while ago (when I looked at bzr3)
[08:05] <zyga> pitti: but I don't assume that it was packaged without running tests
[08:06] <pitti> zyga: the package skips a few tests
[08:06] <zyga> pitti: ok, I reproduce the failure the same way
[08:06] <zyga> pitti: python 2.7 gets very few changes
[08:07] <zyga> pitti: so if this worked before (and bzr was updated and ran the test suite) then it must be something python related
[08:07]  * zyga looks
[08:27] <diwic> Hmm, after today's updates "unity-control-center sound" crashes with "Settings schema 'com.canonical.indicator.sound' is not installed" and then a SIGTRAP.
[08:28] <zbenjamin> cjwatson: ping
[08:28] <pitti> diwic: works here; do you have "indicator-sound" installed?
[08:28] <pitti> indicator-sound: /usr/share/glib-2.0/schemas/com.canonical.indicator.sound.gschema.xml
[08:29] <diwic> pitti, thanks. It's not installed here, how can indicator-sound be not installed if ubuntu-desktop is installed?
[08:30]  * diwic installs indicator-sound manually unless you want to troubleshoot further first
[08:30] <pitti> it's just a recommends
[08:30] <pitti> diwic: so I suppose u-c-c now needs a hard depends on it
[08:30] <diwic> pitti, ah, ok. thanks for the troubleshooting
[08:30] <pitti> diwic: or the schema needs to go someplace else; I'm not sure which is right (I'm not involved in this), so I think reporting a bug about that and prodding seb128 is a good approach
[08:31] <diwic> pitti, will do
[08:40] <tjaalton> is cmocka something that could be more useful and moved to main, or should I drop it from sssd build-depends?
[08:40] <tjaalton> used for some tests
[08:41] <pitti> oh, surprising that samba isn't using that too
[08:41] <tjaalton> probably because of that
[08:41] <tjaalton> it's in universe
[08:41] <pitti> should be fairly harmless in main IMHO
[08:41] <tjaalton> yeah
[08:41] <tjaalton> I'll add a MIR bug
[08:42] <tjaalton> sssd isn't there yet either, should fix that before release
[08:50] <tjaalton> is anyone else having issues with ecryptfs taking ~5min to stop on shutdown?
[08:52] <pitti> not 5 min here, but can easily take 20 s; not sure if I'm seeing the same
[08:58] <tjaalton> yeah that sounds normal
[09:14] <cjwatson> Mirv,RAOF: ABI or not, I tend to think that it's reasonable and appropriate for dependencies within a source package to be (= ${binary:Version}) ...
[09:14] <cjwatson> zbenjamin: hi
[09:14] <cjwatson> zbenjamin: (please include content with your pings, it's quicker)
[09:21] <zbenjamin> cjwatson: ok , just a quick question , can a click package have more than one desktop file?
[09:24] <cjwatson> zbenjamin: yes, you can have multiple apps in a single click package and each would have its own .desktop file
[09:25] <Mirv> cjwatson: RAOF: not having it would allow upgrading the library from the source package without upgrading the QML plugin, but I'm not sure if that's useful of course
[09:25] <cjwatson> zbenjamin: (now, whether stuff in the stack above click all handles multi-app packages gracefully, I can't be certain as I'm not sure I know of any real examples - but we made sure support for this was in the design)
[09:25] <cjwatson> Mirv: yeah, in general I don't think this is a useful thing to support for different binaries from the same source, though of course there are exceptions
[09:26] <zbenjamin> cjwatson: ok thank you
[09:26] <Sweetshark> doko: So about libreoffice-voikko: Cant reproduce that with the libreoffice 4.2.3 prelease I current have from a PPA. It guess it was already fixed by https://gerrit.libreoffice.org/#/c/8368/ for 4.2.2.
[09:26] <Sweetshark> doko: so should be fine with the next LibreOffice upload.
[09:26] <Mirv> cjwatson: ok, thanks for your input. not blockin on that then.
[09:27] <cjwatson> cf.
[09:27] <cjwatson> $ apt-cache show gir1.2-click-0.4 | grep -m1 Depends
[09:27] <cjwatson> Depends: gir1.2-gee-0.8, gir1.2-glib-2.0, gir1.2-json-1.0, libclick-0.4-0 (= 0.4.19)
[09:27] <cjwatson> which I think is spiritually similar
[09:28] <doko> Sweetshark, ok, let me know when I can retry
[09:30] <Sweetshark> doko: will do.
[09:35] <maxiaojun> anyone to look at usb-creator?
[09:35] <seb128> xnox did some work on it this cycle, why?
[09:36] <maxiaojun> Erase Disk still broken
[09:40] <zbenjamin> cjwatson: any idea when we will be able to build in the chroots again?
[09:45] <xnox> seb128: yeah. I am planning to look into usb-creator today.
[10:02] <dakira> hi. can you please change the status of LP:729979. It says "Fix Released" but that fix never worked for anyone.
[10:02] <dakira> This bug affects all users of nvidia binary drivers. It should either be fixed or worked around for 14.04.
[10:04] <darkxst> dakira, it would be more useful, if you put a comment on the bug, rather than here!
[11:45] <ScottK> cjwatson: Thanks for taking care of mplayer/arm64.  I just noticed the lack of it was blocking a -proposed -> -release migration and there it was, fixed (I hope) already.
[11:46] <cjwatson> yeah, turned out to be easier than I'd thought.  I hadn't done it before because gigantic dependency chain and a lot of that wasn't ported until recently.
[11:49] <rbasak> slangasek, stgraber, xnox: so for mysql-5.5, AIUI it automatically broke when debhelper behaviour changed. No upload was required for that.
[11:50] <rbasak> When it was brought to my attention I asked about it (at our sprint in London) and understood that it would be fixed by changing the lsb function, so I left it.
[11:50] <rbasak> So that's one example.
[11:57] <dakira> darkxst: this bug is being ignored. it was marked "fix released" in february 2013. Since then there have been 40 comments stating that the bug is not fixed.
[11:57] <cjwatson> doko,xnox: looks like gcc-arm-linux-androideabi needs to be switched from libppl0.12 to libppl-dev; will one of you take care of that?
[11:59] <dakira> darkxst: I came here as a last resort. My first comment on the bug was in early 2011. This bug makes Unity look broken on all machines that use nvidia binary drivers.
[11:59] <xnox> cjwatson: i'll do it.
[12:00] <doko> cjwatson, yes, and remove the isl b-d
[12:00] <doko> compilers up to 4.7 use ppl, newer ones isl
[12:01] <xnox> cjwatson: so looking at the command-not-found data which mvo's account is still generating..... It not generating things for trusty, and it's only generating against main-archive, as the account got disabled on the ports machine (or the machine is gone)
[12:02] <xnox> cjwatson: can we move command-not-found generator to someplace owned by ~ubuntu-archive which happens to have access to the unsplit mirror?
[12:02] <cjwatson> xnox: it would be simplest to wait for mvo to restart and do it then
[12:02] <cjwatson> we have time :)
[12:02] <xnox> cjwatson: true. Ok then. I'll upload a small bugfix, and that's it.
[12:02] <xnox> (without data update)
[12:29] <cjwatson> cool, porting mplayer to arm64 cleared 15 uninstallables
[12:29] <cjwatson> ten more of those ...
[12:34] <seb128> bdmurray, pitti: can we do anything to get https://code.launchpad.net/~brian-murray/aptdaemon/bug-1266844/+merge/207276 moving forward? it's the most report trusty issue on e.u.c
[13:15] <pitti> seb128: I'm afraid I don't understand enough what that patch is doing
[13:16] <pitti> it looks like a bandaid, but doesn't explain the reason *why* the model isn't available
[13:16] <seb128> pitti, we need mvo back ;-)
[13:16] <pitti> +1
[13:16] <pitti> and it's not clear that the program/UI would then behave sensibly after just returning
[13:20] <ogra_> seb128, one more week, isnt it ?
[13:20] <ogra_> :)
[13:24] <seb128> ogra_, yeah, can't wait!
[13:24] <ogra_> same here :)
[13:37] <xnox> ogra_: seb128: do we need a blueprint with work-items we'd want mvo to finish by 14.04 release ;-)))))
[13:37] <xnox> ?
[13:37] <seb128> ;-)
[13:38] <pitti> xnox: I'm not sure whether a single BP can hold that many WIs
[13:39] <xnox> pitti: he can fix launchpad and work-items tracker in one go as well to resolve that bug =)
[13:39] <pitti> oh, of course!
[13:39] <pitti> xnox: I keep thinking too small :)
[13:41] <ogra_> there are only two WIs , arent there ?
[13:41] <ogra_> fix all click issues
[13:41] <ogra_> fix all apt issues
[14:42] <tseliot> pitti: hi, any ideas as to why we haven't updated util-linux? LP: #1012081
[14:43] <pitti> tseliot: I poked lamont about it several times
[14:43] <pitti> tseliot: I think the biggest problem is that the package is incredibly hard to update as there aren't broken-out patches, but there is just a single huge patch in debian.diff.gz
[14:43] <tseliot> oh...
[14:43] <pitti> tseliot: I think lamont has some git magic to tell them apart, but I wouldn't know it
[14:45] <tseliot> pitti: I see
[14:50] <mdeslaur> cjwatson: are you planning an openssh update to 6.6, or shall I upload the fix for CVE-2014-2532?
[14:50] <cjwatson> mdeslaur: I have it staged in git already
[14:50] <mdeslaur> cjwatson: great, thanks
[14:51] <cjwatson> though thanks for the CVE ref :)
[14:51] <cjwatson> I'll insert that into my changelog
[14:51] <mdeslaur> great
[14:52] <cjwatson> mdeslaur: I'm waiting for translations of the debconf template in https://lists.debian.org/debian-ssh/2014/03/msg00024.html before uploading, at this point
[14:53] <cjwatson> utlemming,smoser: Do you have any thoughts on the matter raised in https://lists.debian.org/debian-ssh/2014/03/msg00029.html ?
[14:54] <cjwatson> mdeslaur: (http://anonscm.debian.org/gitweb/?p=pkg-ssh/openssh.git, for future reference)
[14:55] <mdeslaur> cjwatson: thanks
[14:55] <utlemming> cjwatson: interesting....from a cloud-image perspecitve, cloud-init would disable that by default for our cloud images, unless the user wants it. Generally, the cloud market is split between allowing and disallowing root logins.
[14:56] <smoser> cjwatson, will have no affect on us. either way.
[14:57] <cjwatson> utlemming: Would you do just just by sedding sshd_config, or equivalent?
[14:57] <smoser> on cloud-iamge boots, cloud-init stuffs the provided ssh key into root's authorized keys, but disables login to it by a ssh key options (gives a message that says 'login as ubuntu')
[14:57] <cjwatson> utlemming: Or do you mean you're already disallowing root logins anyway?
[14:57] <cjwatson> Or disallowing password auth to root anyway
[14:57] <smoser> already disallowing root login. as that.
[14:58] <smoser> we don't change the root password login
[14:58] <smoser> so this would then allow the user to get in as root, but there is no root password in the images unless the user has set one.
[14:59] <cjwatson> OK, so no effect in default configuration.  Thanks
[15:01] <cjwatson> mdeslaur: If you think this is urgent, I guess I could do 6.6 first and then the root login change in a separate upload
[15:01] <mdeslaur> cjwatson: not urgent at all, not a big issue
[15:01] <cjwatson> Right, I didn't think it was too terrible.  Thanks
[15:03] <cjwatson> (Can't think of any especially horrible env vars that contain "LC_")
[15:04] <mdeslaur> yeah, me neither
[15:09] <doko> jamespage, should we sync tomcat8 from unstable?
[15:11] <doko> cking, could I have some feedback about lp: #1294669 ?
[15:12] <cking> nope, it does not exist :-(
[15:12] <cjwatson> it does, it's just private so the bot can't see it
[15:12] <cjwatson> but you filed it so you should be able to :)
[15:12] <cking> ah, sorry, it does, heh doko, will do, sorry
[15:13] <doko> cking, ohh, and 4.3-4ubuntu1 is currently building
[15:15] <cking> doko, unfortunately my history is probably way out of date, I'll try and reproduce it
[15:22] <Laney> doko: http://people.canonical.com/~laney/weird-things/webkit-preprocessed.xz
[15:22] <Laney> I just built wk on harris.debian.org & got that for you re: the ftbfs I pointed out yesterday
[15:23] <doko> ahh, nice
[15:23] <Laney> you should be able to grab it from my homedir there too if you want
[15:23] <Laney> to save building it again
[15:23] <cking> doko, I'm finding it hard to reproduce this issue, where as the day I filed it i could trigger it randomly quite frequently
[15:58] <jamespage> doko, hmmm
[15:58] <jamespage> doko, I'd be hesitant; its just going to sit in universe
[16:02] <doko> ok
[16:13] <doko> Laney, looks you can avoid that by not passing -fno-tree-dce
[16:14] <Laney> doko: turning off dead code elimination? what kind of an impact will that have?
[16:14] <Laney> do you think it's a gcc bug?
[16:15] <doko> no, turning on
[16:15] <doko> every ICE is a gcc bug
[16:15] <Laney> oh, I missed the double negation
[16:16] <doko> but I miss the background why you turned it off
[16:16] <Laney> I thought it could have been webkit generating some invalid asm
[16:16] <doko> just to confirm. you did see this in unstable too?
[16:17] <Laney> It was built in experimental but I don't think it actually installed any build-deps from there, only unstable
[16:18] <Laney> and I don't know why it's disabled, let me see if upstream knows
[16:21] <doko> can't see this with 4.7 and trunk
[16:24] <Laney> mmm, https://github.com/WebKit/webkit/commit/7678ecfd0590c406e43f1b7b8ab8c923d9bd26ab
[16:24] <Laney> so compiler bugs, let me see if they filed them upstream
[16:25] <Laney> bugs without, bugs with, what fun
[16:26] <doko> -fno-omit-frame-pointer doesn't help for the register pressure
[16:27] <slangasek> rbasak: no, it broke when 1) debhelper behavior changed, and then 2) somebody reuploaded mysql-5.5 without making the necessary source changes as described in that mail to ubuntu-devel.  In retrospect it seems we were not proactive enough in making sure that job-containing packages did get the necessary init script source changes, and given where we are now the way forward is to fix it centrally as an lsb functions hook
[16:27] <Laney> the comment there says 'incorrectly compiled operationCallEval'
[16:30] <doko> Laney, https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1295738
[16:32] <Laney> doko: thank you, will look out for a fix
[16:56] <cornfeedhobo> hello. I am trying to nail down an issue I am having so I can decide if I should patch this and manually compile, or what.  I am trying to find out if the NetworkManager openvpn plugin has any ipv6 support, and i just dont know how to enable it, or if that is slated for patching soon?
[16:56] <maxiaojun> xnox: any news for usb-creator?
[16:57] <cornfeedhobo> there are some chats about a patch available on the mailing list
[17:06] <jamespage> rbasak
[17:06] <jamespage> oh - nm
[17:12] <hallyn> cking: forkstat looks awesome.  relatedly, comment system on your blog site sucks :)  i cannot get the capchas right.
[17:12] <hallyn> (or, my eyes suck <shrug>)
[17:13] <cking> oh, yeah, sorry about the capchas, but it gets load of spam otherwise
[17:14] <cking> the proc connector interface is poorly documented, hopefully the source of forkstat is some help :-)
[17:15] <hallyn> yes, i think it'll make a big difference in # people looking into it, a good thing
[17:17] <hallyn> cking: anyway to get it to tell who the fork parent was?
[17:17] <hallyn> oh heh there it is
[17:17] <cking> it's all there :-)
[17:18] <hallyn> just used it to look at that virtmanager bogosity.  I say, WTF!
[17:18] <ogra_> xnox, i think i asked you already, but forgot the answer, are you working on getting python-apt from the image (we have python3-apt)
[17:19] <cking> hallyn, that will keep you busy
[17:19] <xnox> ogra_: yes, but e.g. blocked by blockages. See my latest email in response to asac.
[17:20] <ogra_> xnox, yes, that remineded me that i wanted to ask you again :)
[17:20] <xnox> ogra_: yeah, _all_ of it is going, as soon as things land.....
[17:21] <ogra_> xnox, yeah, as soon as davmor2 is done testing i'll promote an image
[17:21] <xnox> ogra_: 250?
[17:21] <ogra_> he is just doing an additional verification test run
[17:21] <ogra_> yeah
[17:21] <xnox> ogra_: i don't see new gallery-app on image 250. So no good for me.
[17:21] <ogra_> i guess 251 will then have it
[17:23] <cjwatson> ogra_: click uses it to parse framework dependencies, that probably won't go away soon
[17:23] <cjwatson> ogra_: oh, sorry, that's only python3-apt
[17:23] <ogra_> :)
[17:26] <davmor2> ogra_, popey, sil2100: can you have a quick scan over the list other than the scopes that I'm about to start can you see anything else missing?  https://docs.google.com/a/canonical.com/document/d/1VkoSTUStDDPN84rwLztHIgSEK2HlbvXghZDBkBYVxTU/edit#
[17:27] <davmor2> sorry wrong channel
[17:28] <ogra_> davmor2, looks good
[17:40] <cyphermox> cornfeedhobo: it's already in the archive, in trusty
[17:43] <cornfeedhobo> cyphermox: orly?
[17:44] <cornfeedhobo> I was just starting to look into how to make a debian style package... i have a patch ready
[17:46] <cornfeedhobo> cyphermox: huzzah!
[17:47] <cornfeedhobo> thanks!
[17:47] <cornfeedhobo> now how should i install just that one package from trusty? can i just dpkg the deb?
[17:52] <seb128> bdmurray, ev: hey, do you know how e.g https://errors.ubuntu.com/problem/dae59d0805bf3202f10977ead46c964a07bb53be can have 0 report in its trusty column but trusty report in the examples list?
[17:53] <bdmurray> seb128: looking
[17:53] <seb128> bdmurray, thanks
[17:54] <bdmurray> seb128: well at least the first couple are missing Package: info in the report
[17:54] <seb128> bdmurray, do you know how that can happen?
[17:56] <bdmurray> seb128: not immediately
[17:56] <seb128> k
[17:56] <seb128> thanks anyway ;-)
[17:56] <seb128> that's probably not on the e.u.c side
[17:57] <bdmurray> it could be apport, I'd try manually causing a crash in hplip-data
[17:58] <bdmurray> actually a lot of 13.10 ones are missing them also
[18:08] <bdmurray> seb128: I setup a crash in hplip-data and my .crash files have the information so I don't really now
[18:08] <seb128> bdmurray, ok, thanks for looking
[18:08] <seb128> it's weird, but it seems only that package so no a big deal either
[18:09] <bdmurray> I know aptdaemon and the release upgrader have their own crash handlers but I don't see anything like that in hplip
[18:15] <arges> bdmurray: hey. i can start taking a look at the sru queue
[18:17] <bdmurray> arges: sounds good, no pending stuff today since its friday
[18:17] <cornfeedhobo> cyphermox: so, that patch seems to deal with not messing up ipv6 routes, which is good, but does not add a tab to the gui to control it
[18:18] <cornfeedhobo> and it does seem to expose ipv6 capability to all plugins, which is also good
[18:21] <cornfeedhobo> the gui layout file /usr/share/gnome-vpn-properties/openvpn/nm-openvpn-dialog.ui doesnt even mention ipv6
[18:23] <cyphermox> no, it doesn't have to
[18:23] <cornfeedhobo> okay
[18:23] <cyphermox> it's detected by NM from the capabilities of the VPN plugin
[18:23] <cornfeedhobo> hmm... let me update the core NM
[18:24] <cornfeedhobo> is trusy going to be systemd based?
[18:24] <ScottK> No
[18:30] <cornfeedhobo> any words on when that transition may start?
[18:31] <ScottK> Later
[18:39] <cornfeedhobo> cyphermox: my apologies. the problem appears to be with plasma-nm
[18:39] <cornfeedhobo> thanks
[18:39] <cornfeedhobo> i have been trying to narrow this down
[19:00] <juliank> bdmurray: Did you already find out why the tests with the pkg.is_upgradable are failing?
[19:01] <bdmurray> juliank: no, not yet
[19:40] <paulb> Is this the correct channel to get help with creating a ppa?
[19:42] <stgraber> paulb: nope
[19:42] <stgraber> paulb: #launchpad maybe
[19:42] <paulb> K, thanks stgraber
[19:51] <bdmurray> jamespage: this upload of juju-core looks a bit like a micro release and I don't see a MRE for juju.
[19:51] <bdmurray> jamespage: this being the one in the saucy proposed queue
[20:00] <jamespage> bdmurray, I agree that it is bordering on needing a MRE (which I have on my list to apply for)
[20:06] <jamespage> bdmurray, park it for the moment; I'll work through the linked bugs and do test-cases
[20:17] <YokoZar> Are archive admins the one to talk to if I want to add a package to the debian import blacklist?
[20:22] <infinity> YokoZar: Yep.
[20:22] <infinity> YokoZar: Also helps if you specify what it is, though.
[20:22] <infinity> YokoZar: (guessing something wine-related?)
[20:22] <YokoZar> infinity: Please add winetricks there, yeah
[20:23] <infinity> YokoZar: Seems we've had that all the way back to precise.  Why is it suddenly a problem?
[20:23] <infinity> (Or was it always, and we just didn't notice...?)
[20:23] <YokoZar> infinity: I'm readapting the debian package but it needs to fork at this point
[20:24] <YokoZar> infinity: basically it's going to keep recommending the debian wine package names (eg wine-unstable)
[20:24] <infinity> YokoZar: Okay, but if you fork it, there's no need to blacklist it.
[20:24] <infinity> blacklisting only makes sense if we're removing it.
[20:24] <YokoZar> infinity: err you're right
[20:24] <YokoZar> infinity: mom won't auto import it
[20:24] <YokoZar> infinity: which will be good enough
[20:25] <infinity> Right, go forth and fork.
[20:25] <YokoZar> actually
[20:25] <YokoZar> I'm wondering how the debian one got synced on top of ours to begin with
[20:25] <YokoZar> in precise
[20:26] <YokoZar> maybe someone did it manually (maybe even me) and I forgot
[20:27] <infinity> I don't see any ubuntu revisions in precise history.
[20:27] <infinity> There was one in quantal.
[20:28] <infinity> And it was indeed you who synced over the quantal delta.
[20:28] <infinity> https://lists.ubuntu.com/archives/quantal-changes/2012-August/007325.html
[20:29] <YokoZar> Well it did work at some level.  But now it needs to be in merge mode dropping the debian patches and making changes to the control file (and we may be upstream ahead of debian too)
[20:29] <YokoZar> Thanks infinity
[20:29] <infinity> YokoZar: If I were you, I'd just make the package clever enough to DTRT on both distros.
[20:30] <YokoZar> DTRT?
[20:30] <YokoZar> do the right thin
[20:30] <infinity> Do The Right Thing.
[20:30] <infinity> YokoZar: Since the build-dep is just debhelper, it's obviously only binary and runtime things you care about, and that can all be handled sanely by substituting things in debian/rules based on dpkg-vendor
[20:30] <YokoZar> I have plans to bring my wine packages to debian/steamos as well (via external apt repo) so it's not a bad idea
[20:31] <YokoZar> infinity: that's actually a clever idea, I forgot about variable substitutions like that
[20:41] <debfx> cyphermox: some patches in network-manager rely on TARGET_DEBIAN being defined, however that has been removed upstream: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=012c5f4b271b935852267ed865933ea3bb6983ba
[21:07] <marrusl> anyone happen to know if there's a PPA with a pre-release version of the HWE trusty x-stack for 12.04?
[21:13] <tarpman> marrusl: looks like canonical-x/x-staging has something like it
[21:13] <marrusl> thanks tarpman, I will take a look
[21:14] <marrusl> tarpman, why I do believe that is exactly it.  sweet!
[22:03] <ekarlso> can someone tell me why my interfaces in 14.04 are named "rename<some number>" vs em3 and em4 as they should be ?!
[22:04] <jpds> ekarlso: New scheme.
[22:05] <ekarlso> jpds: but why the crap does it make it "renameX" instead of em?
[22:05] <ekarlso> i have a em3 which is the 3rd port on the port which _should_ be em3
[22:05] <ekarlso> ibstead it's em2 as a kernel name...
[22:06] <ekarlso> it even ignores my persistent udev rules
[22:12] <infinity> ekarlso: dmesg should have a bit of enlightenment as to which renames were attempted and why.
[22:12] <infinity> ekarlso: A persistent scheme that results in loops can sometimes lead to renames getting "stuck".
[22:14] <ekarlso> nope infinity
[22:14] <ekarlso> http://paste.openstack.org/show/74048/
[22:14] <ekarlso> it's freakin' frustrating
[22:15] <infinity> And what's in /etc/udev/rules.d/70-persistent-net.rules ?
[22:15] <ekarlso> nothing on the mentioned host
[22:15] <ekarlso> it doesn't write rules even
[22:16] <infinity> ekarlso: Is biosdevname in play here?
[22:16] <ekarlso> I have biosdevname installed ye
[22:16] <ekarlso> comes with 14.04 as stock it seems
[22:18] <infinity> Right, so that's where the bug lies, at least.  I'd file one, if I were you.
[22:18] <infinity> It does look like a logical fail with the rename hitting a loop, but that shouldn't happen in your case, I'd think.
[22:19] <infinity> Sadly, I don't know much about biosdevname, so a bug would be better to make sure the right person/people see it.
[22:19] <ekarlso> which udev rule calls it ?
[22:20] <infinity> ekarlso: It'll be something in /lib/udev/rules.d
[22:20] <infinity> I don't have it installed here, so don't recall for sure.
[22:20] <infinity> 71-biosdevname or something.
[22:20] <ekarlso> well I can't see it there..
[22:20] <ekarlso> oh, nvm there it is .
[22:24] <ekarlso> where to report that infinity ?
[22:25] <infinity> ekarlso: ubuntu-bug biosdevname
[22:27] <infinity> jtaylor: Man, that python-cffi testsuite takes an impressively long time to run when it doesn't fail. :P
[22:27] <jtaylor> yes but you only need to run two of them to see the failure
[22:28] <jtaylor> of the files
[22:28] <infinity> jtaylor: Well, I just did a full package build to make sure it worked with my local glibc build.
[22:29] <infinity> jtaylor: The two things you were waiting on were the backport of Siddesh's sin() fixes, and this no-regmove hack, right?  I have both of those staged, just pondering one or two unrelated fixes, but will upload in the next ~24h, so you'll be unblocked before beta freeze.
[22:29] <jtaylor> I wanted to try and bisect gcc-4.7..4.8 but for some reason every checkout failed to build so I gave up
[22:29] <jtaylor> yes I only have those two issues on my want-fixed list :)
[22:30] <infinity> Kay, then I have you covered.
[22:30] <ekarlso> stupid ass bisodevname
[22:30] <ekarlso> sucks balls
[22:30] <jtaylor> thx
[22:31] <jtaylor> does glibc do bugfix releases?
[22:32] <infinity> jtaylor: They do point releases, yeah, though we've been amazingly bad about maintaining the stable branches upstream.
[22:32] <infinity> jtaylor: There's been ongoing discussion over the last month or two about us doing better on that score.
[22:32] <jtaylor> I think this one would be a good reason to do one
[22:32] <jtaylor> the sin issue
[22:32] <jtaylor> wrong math is very bad
[22:32] <infinity> jtaylor: It's in the stable branch already, it'll make it in .1, if/when Allan decides to cut a release.
[22:33] <jtaylor> now that I know how to test glibc dev releases I'm going to run the stuff I care about against git head :)
[22:33] <jtaylor> the ./testrun.sh is quite convinient
[22:34] <infinity> jtaylor: Yeah, now that we're pretty much caught up with upstream, my plan next cycle is to be doing snapshot builds in a PPA.
[22:34] <infinity> jtaylor: And if I can get 2.19 to unstable soon, snapshot builds in experimental too.
[22:35] <infinity> (Should make rebasing patches a bit less painful if we're doing it incrementally instead of in a panic with each new release)
[22:50] <Noskcaj> Is anyone able to give me a testimonial for MOTU? https://wiki.ubuntu.com/Noskcaj#MOTU