=== timchen1` is now known as timchen119
[10:33] <didrocks> infinity: with xorg-server 2:1.17.1-0ubuntu3, all other systemd autopkgtests are now passing (there were some failures with xorg starting), so I guess it's safe to override now
[10:34] <didrocks> infinity: did you get any progress on the upstart package split?
[10:34] <didrocks> smoser: FYI ^
[10:35] <infinity> didrocks: I ended up sleeping (I'd been up for two days :/) instead of working on reworking upstart, but I should do that ASAP, if I can't find another sucker to do it, since the current split is pretty obviously wrong.
[10:36] <didrocks> infinity: tell me if I can be of any help
[10:36] <didrocks> I'm happy to deal with this (this afternoon/tomorrow morning)
[10:36] <infinity> didrocks: Well, I wouldn't complain if someone competent (like you) did the work and asked me to review it, but I imagine you're just as busy as I am.
[10:37] <didrocks> infinity: I'm fine, I succeeded to get some spare time for systemd-related work while pitti was away, so I'll be on it soonish and propose a fix to you
[10:39] <infinity> didrocks: Awesome.  So, the way I see it, the split just needs to be inverted.  upstart should contain all the non-conflicting bits (including jobs), and upstart-sysv should handle the conflicting stuff.  With some appropriate Breaks/Replaces (And Conflicts/Replaces in the case of getting upstart to force off upstart-bin) in place for smooth transition.
[10:39] <infinity> didrocks: And then a bit of mangling of other bits like livecd-rootfs and some seeds and the 'init' package to cope with the shuffle.
[10:40] <infinity> didrocks: I can help hunt down the "other bits" part of that without too much effort on my end, I have a pretty good handle on all the things that will break.
[10:40] <didrocks> infinity: makes sense, will do that upstart-sysv package and look at the seeds. I'll need you on the livecd-rootfs though
[10:40] <didrocks> ok :)
[10:41] <infinity> didrocks: Hrm, actually, we might have to suffer with an empty upstart-bin that depends on upstart (that would also make this a tiny bit smoother), so people who already don't have upstart installed don't get a weird non-upgrade path.
[10:41] <infinity> didrocks: That could go away for V+1, since trusty didn't have the split.
[10:42] <infinity> So, 14.04 -> 16.04 would be clean, it's just U->V that wouldn't be,.
[10:44] <didrocks> infinity: yeah, at least, LTS to LTS would be easier for apt, we just need to ensure we remember to kill it in V+1
[10:45]  * didrocks will put some comments in debian/control
[10:46] <infinity> And let me get that systemd migrated...
[10:48] <didrocks> thx!
[10:49] <infinity> didrocks: Alright, I'm going to go hide in a hole and finish polishing up this glibc upload, but poke me when you have something plausibly sane, and we'll talk next steps.
[10:51] <didrocks> infinity: sounds good, I'll start that either this afternoon or my tomorrow morning depending on what is still on my list. Good luck with glibc!
[12:21] <smoser> didrocks, i realliy want/need to get my changes in so that iscsi boot works.
[12:21] <smoser> what i'd like to do is just upload a new systemd with that change also, and a disabling of the test for upstart
[12:21] <smoser> i'll open a bug, and point at the bug in the disabling.
[12:22] <smoser> and then you fix that bug with your upstart work.
[12:34] <smoser> didrocks, ping
[12:39] <smoser> i really need my systemd changes in.. so what i'd like to propose is that I upload a systemd with my fix for http://pad.lv/1432829 . and with upstart test disabled.
[12:39] <ubot93> Launchpad bug 1432829 in systemd (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [High,Confirmed]
[12:40] <smoser> I've opened bug 1434058 and will reference that in the disabling of those tests.
[12:40] <ubot93> bug 1434058 in upstart (Ubuntu) "installation of upstart-bin and boot with init=/sbin/upstart does not fully boot" [Critical,Confirmed] https://launchpad.net/bugs/1434058
[12:40] <smoser> you can fix upstart and reference that test.
[12:41] <smoser> does anyone object to that ?
[12:55] <infinity> smoser: Or maybe it migrated an hour ago?
[12:55] <smoser> oh?
[12:55] <didrocks> smoser: yeah, that was what our discussion was about
[12:56] <didrocks> smoser: we discovered another issue btw when running the tests, so it worthed it (issue in xorg)
[12:56] <smoser> "worthed it" ?
[12:56] <didrocks> smoser: loosing my morning in running the adt tests manually
[12:56] <smoser> so you overrode and let it through, right?
[12:56] <didrocks> losing*
[12:56] <didrocks> yeah, that's done
[12:56] <smoser> ok.. but i still need the other fix.
[12:56] <infinity> smoser: Yeah, after all the manual testing, I let it in.
[12:57] <smoser>  as i've attached to bug http://pad.lv/1432829
[12:57] <didrocks> smoser: can you try to batch your fixes? we tend to do few upload, but extensive testing generally with pitti
[12:57] <infinity> smoser: If you need another upload, go for it.  We'll figure out what to do.
[12:57] <ubot93> Launchpad bug 1432829 in systemd (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [High,Confirmed]
[12:57] <didrocks> smoser: also we put all of them in debian experimental first
[12:57] <smoser> didrocks, ... the ubuntu package has a -XubuntuX version
[12:58] <didrocks> smoser: yeah, we have an ubuntu branch
[12:58] <smoser> so confused about debian/experiemental.
[12:58] <didrocks> but as told yesterday, everything is in debian git
[12:58] <didrocks> and we merge patches to experimental, when it makes sense for them
[12:58] <didrocks> and then, remerge in the ubuntu branch
[12:59] <didrocks> smoser: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/
[13:00] <smoser> didrocks, right. i can give you a git branch that has that if you want.
[13:00] <smoser> i have one locally
[13:00] <smoser> and http://paste.ubuntu.com/10627333/ is what i want to upload
[13:01] <smoser> i have not verified that the test will be disabled, but per doc/README.package-tests.rst in adt source:
[13:01] <smoser>   Any unknown fields will cause the whole stanza to be skipped.
[13:01] <didrocks> smoser: did you test extensively this config with manually setup network on a desktop machine?
[13:01] <didrocks> the unconditional creation of /run/network did trigger a lot of unit failure on desktop in the past
[13:02] <smoser> well, as it is right now, creation of that directory is pretty unconditional
[13:02] <smoser> if any network device attach event happens (ie, you have a NIC)
[13:03] <smoser> isn't it ? my change made it guaranteed, but the previous behavior was that any udev event would have created /run/network.
[13:04] <didrocks> smoser: why don't you let udev creating it when needed then?
[13:05] <didrocks> ah, the initramfs
[13:05] <smoser> udev didn't create it. systemd did. when that job ran. but by its use of RntimeDirectory, its purged on first run of that job
[13:05] <smoser> right.
[13:06] <didrocks> smoser: yeah sounds good, as long as you tested it extensively with and without network-manager on a vivid desktop, that's fine to me (we have other network issue to fix anyway and pitti started to look at them)
[13:10] <smoser> didrocks, ok. i'll install package here and do test on my laptop.
[13:10] <smoser> i do see a bug in the current ifup@.service job
[13:11] <smoser> if you have an interface described in /etc/network/interfaces, but it is not 'auto' or 'allow-hotplug', then the ifup@NIC job will fail.
[13:11] <smoser> my changes fix that bug also.
[13:12] <didrocks> smoser: yeah, I clearly remember that we had some issues in /etc/network regarding ifup@ units, but it's now too old for my small memory :) (we fixed it though IIRC)
[13:27] <smoser> didrocks, sorry to bother you.. but one question. the file i'm installing is not executable when installed via package. what would be the rigth way to do that ?
[13:29] <didrocks> smoser: hum weird, are you sure it's executable in the source tree? As we are using source format 3.0 (quilt), it shouldn't be an issue. Otherwise, you can chmod +x it in debian/rules, but ensure first it's executable in the source package I would say.
[13:29] <smoser> it is not executable in the soruce tree.
[13:29] <smoser> is that the right way to do it ? just to chmod it in debian/ ?
[13:30] <didrocks> yeah, for source format 3.0, it's fine
[13:31] <didrocks> (it's not a diff, so the perms are preserved)
[13:34] <smoser> thanks
[14:19] <davmor2> infinity: yelp is still showing the utopic help graphics any idea when that should change at all?
[14:19] <davmor2> infinity: https://bugs.launchpad.net/ubuntu/+source/yelp/+bug/1434087 incase you need to band it around a bit :)
[14:19] <ubot93> Launchpad bug 1434087 in yelp (Ubuntu) "Yelp in Vivid is still showing the Utopic Unicorn Image" [High,New]
[14:20] <infinity> davmor2: Should change soon, ideally. :P
[14:21] <infinity> Not sure where that content comes from...
[14:21] <davmor2> infinity: jibel just asked me to give vivid desktop a quick tyre kicking in readiness for beta next week only 2 issues so far is that and there are 2 languages eng_uk and eng_us rather than just eng_uk that I installed :0
[14:21] <davmor2> :)
[14:21] <davmor2> so not too bad :)
[14:22] <infinity> Looks like ubuntu-docs.
[14:23] <infinity> davmor2: Two languages where?
[14:23] <davmor2> infinity: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1434091
[14:23] <ubot93> Launchpad bug 1434091 in indicator-keyboard (Ubuntu) "mini.iso install of ubuntu desktop selecting only ENG_UK gives me eng_us and eng_uk" [Undecided,New]
[14:23] <infinity> Generally, when you install en, you get all the en variants, though I'm not sure about the keyboard indicator, and what it's meant to do.
[14:24] <davmor2> infinity: keyboard should only show eng_uk it does on other installs
[14:24] <davmor2> infinity: I pointed cyphermox at it anyway :)
[14:25] <infinity> I don't even appear to have a keyboard indicator here.
[14:25] <davmor2> infinity: hahahaha
[14:26] <infinity> Maybe it only shows up if you have more than one input source defined.
[14:26] <infinity> Hrm, nope, adding a second doesn't show it.  Weird.
[14:28] <davmor2> infinity: shows here on a fresh install did you upgrade for a few distros?
[14:28] <infinity> Yeah.
[14:29] <infinity> Though, I don't think it should show by default unless you have multiple anyway, that would also be a bug if it does, IMO.
[14:29] <davmor2> infinity: it show on my desktop all the time in utopic and vivid
[14:30] <infinity> Ick.
[14:30] <infinity> Well, if you're not finding more serious bugs yet, little bits of polish like that are easy to knock out.
=== doko_ is now known as doko
[14:31] <infinity> As for the unicorn, looks like ubuntu-docs hasn't seen an upload since utopic, so that would be why.  I assume there's an update in the works.
[15:35] <smoser> didrocks, still around ?
[15:35] <smoser> i'm ready to upload.
[16:21] <jderose> infinity: is 14.04.2 --> 14.10 supposed to be a supported upgrade path? there are some serious issues with the xorg*utopic-lts packages in that they're not transitioning correctly during the upgrade
=== seb128_ is now known as seb128
[16:27] <infinity> jderose: In theory, yes.  mlankhorst might be more interested in specifics.
[16:29] <infinity> jderose: Not that I'd consider it a common upgrade path, since people who want LTS+HWE aren't the sort that would be upgrading to every non-LTS release in between, but it should still be made to work.
[16:29] <infinity> mlankhorst: Guess you never tested 14.04+HWE-U to 14.10 upgrades?
[16:42] <jderose> the upgrade appears to work okay, but the first time you run apt-get upgrade after the reboot, there will be a bunch of wierdness with xorg packages
[16:43] <jderose> running apt-get upgrade twice seems to get things back to correct state, but there may still be some subtle problems
[18:17] <oSoMoN> could someone from the release team please review bug #1433141 (FFe request) and advise?
[18:17] <ubot93> bug 1433141 in webbrowser-app (Ubuntu) "[FFe] Bottom-edge gesture to open tabs list in the browser application" [Undecided,New] https://launchpad.net/bugs/1433141
[18:25] <mlankhorst> infinity: it' s not a supported upgrade path
[18:26] <infinity> mlankhorst: According to whom?
[18:26] <mlankhorst> infinity: the only supported path from 14.04 with lts stack is to the next lts
[18:26] <infinity> mlankhorst: If you install 14.04, untick the "LTS only" box in software-properties, you'll get offered an upgrade to utopic.
[18:27] <mlankhorst> odd..
[18:27] <infinity> mlankhorst: Why would that be odd?
[18:27] <mlankhorst> infinity: if you have the lts stack enabled you shouldn't upgrade to the next stable release..
[18:27] <infinity> mlankhorst: 14.04 to 14.10 is a supported upgrade path, we did nothing to intentionally break that in point releases.
[18:28] <mlankhorst> infinity: yes 14.04 without lts stack to 14.10 is a supported upgrade path
[18:28] <mlankhorst> that was the case with precise too
[18:28] <infinity> mlankhorst: Like I said above, I think it's rare that people using LTS+HWE would want to be upgrading to non-LTS releases, but it's certainly not something we prevent.
[18:28] <mlankhorst> we should prevent it, if they want to upgrade they have to remove the HWE stack first
[18:29] <infinity> mlankhorst: Instead of arguing about "supported", how hard would it be to just make it work the same way 14.04->16.04 is going to work?
[18:29] <mlankhorst> and imagine you're on 14.04.3 and trying to upgrade to utopic, while your hardware is not supported in utopic yet..
[18:29] <infinity> mlankhorst: Preventing it is harder than fixing it, I suspect.
[18:29] <infinity> mlankhorst: 14.04.3 to utopic is a no-go because utopic will EOL before 14.04.3 comes out.
[18:29] <infinity> mlankhorst: Only .2 has this overlap.
[18:31] <mlankhorst> infinity: just rebuild xorg-lts-transitional from trusty..
[18:32] <mlankhorst> and add a special case for libgbm
[18:33] <infinity> mlankhorst: Could we do that?  I know it's easier to say "well, don't do that thing", but if it's in the "simple UI", it should generally work, telling people "that's not supported" after it breaks isn't helpful.
[18:34] <infinity> mlankhorst: Optionally, we could SRU update-manager and software-properties with some hacks to not let people go non-LTS if there's an HWE stack installed, I guess.
[18:34] <infinity> jderose: Was this something one of your customers managed to do to themselves, or more of an idle question and experimentation on your part?
[18:40] <jderose> infinity: we haven't had problem reports from customers yet. this was be testing upgrades the nividia driver packages we deliver in our PPA... at first i thought i goofed
[18:40] <jderose> but the upgrade is broken even without the nvidia driver
[18:42] <infinity> jderose: Yeah, apparently "not supported", I was wrong.  Though I think we should either fix that or make it hard from the UI.
[18:43] <jderose> mlankhorst: infinity: okay, thanks for the clarification (was catching up above)
[18:45] <jderose> but to me if 14.04.2-->14.10 isn't supported (and is broken), the update manager really shouldn't offer it when you change "Notify me of a new Ubuntu version" to "For any new version"
[18:46] <infinity> jderose: Right, that was what I was saying.  Either we should fix the upgrade, or neuter update-manager.
[18:47] <infinity> jderose: Slightly less concerned about commandline upgrades, unless it's horribly broken, and your report sounded less "horribly" and more "annoyingly" broken.
[18:47] <infinity> But, "annoyingly broken" for CLI users is "completely screwed" for GUI people.
[18:48] <jderose> yeah, annoying and confusing for the experienced... but you can seemingly work around the issues without much trouble
[18:48] <jderose> er, confusing for the inexperienced, that is
[20:56] <smoser> can someone please ack my systemd upload that fails due to bug 1422681
[20:56] <ubot93> bug 1422681 in upstart (Ubuntu) "split out upstart-sysv" [Undecided,Triaged] https://launchpad.net/bugs/1422681
[21:00] <smoser> infinity, maybe?
[21:01] <infinity> smoser: I'll have a poke.
[21:46] <bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/component-mismatches-uploader/+merge/253587
[23:50] <smoser> infinity, thank you.