/srv/irclogs.ubuntu.com/2015/03/19/#ubuntu-release.txt

=== timchen1` is now known as timchen119
didrocksinfinity: 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 now10:33
didrocksinfinity: did you get any progress on the upstart package split?10:34
didrockssmoser: FYI ^10:34
infinitydidrocks: 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:35
didrocksinfinity: tell me if I can be of any help10:36
didrocksI'm happy to deal with this (this afternoon/tomorrow morning)10:36
infinitydidrocks: 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:36
didrocksinfinity: 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 you10:37
infinitydidrocks: 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
infinitydidrocks: 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:39
infinitydidrocks: 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
didrocksinfinity: makes sense, will do that upstart-sysv package and look at the seeds. I'll need you on the livecd-rootfs though10:40
didrocksok :)10:40
infinitydidrocks: 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
infinitydidrocks: That could go away for V+1, since trusty didn't have the split.10:41
infinitySo, 14.04 -> 16.04 would be clean, it's just U->V that wouldn't be,.10:42
didrocksinfinity: yeah, at least, LTS to LTS would be easier for apt, we just need to ensure we remember to kill it in V+110:44
* didrocks will put some comments in debian/control10:45
infinityAnd let me get that systemd migrated...10:46
didrocksthx!10:48
infinitydidrocks: 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:49
didrocksinfinity: 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!10:51
smoserdidrocks, i realliy want/need to get my changes in so that iscsi boot works.12:21
smoserwhat i'd like to do is just upload a new systemd with that change also, and a disabling of the test for upstart12:21
smoseri'll open a bug, and point at the bug in the disabling.12:21
smoserand then you fix that bug with your upstart work.12:22
smoserdidrocks, ping12:34
smoseri 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
ubot93Launchpad bug 1432829 in systemd (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [High,Confirmed]12:39
smoserI've opened bug 1434058 and will reference that in the disabling of those tests.12:40
ubot93bug 1434058 in upstart (Ubuntu) "installation of upstart-bin and boot with init=/sbin/upstart does not fully boot" [Critical,Confirmed] https://launchpad.net/bugs/143405812:40
smoseryou can fix upstart and reference that test.12:40
smoserdoes anyone object to that ?12:41
infinitysmoser: Or maybe it migrated an hour ago?12:55
smoseroh?12:55
didrockssmoser: yeah, that was what our discussion was about12:55
didrockssmoser: we discovered another issue btw when running the tests, so it worthed it (issue in xorg)12:56
smoser"worthed it" ?12:56
didrockssmoser: loosing my morning in running the adt tests manually12:56
smoserso you overrode and let it through, right?12:56
didrockslosing*12:56
didrocksyeah, that's done12:56
smoserok.. but i still need the other fix.12:56
infinitysmoser: Yeah, after all the manual testing, I let it in.12:56
smoser as i've attached to bug http://pad.lv/143282912:57
didrockssmoser: can you try to batch your fixes? we tend to do few upload, but extensive testing generally with pitti12:57
infinitysmoser: If you need another upload, go for it.  We'll figure out what to do.12:57
ubot93Launchpad bug 1432829 in systemd (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [High,Confirmed]12:57
didrockssmoser: also we put all of them in debian experimental first12:57
smoserdidrocks, ... the ubuntu package has a -XubuntuX version12:57
didrockssmoser: yeah, we have an ubuntu branch12:58
smoserso confused about debian/experiemental.12:58
didrocksbut as told yesterday, everything is in debian git12:58
didrocksand we merge patches to experimental, when it makes sense for them12:58
didrocksand then, remerge in the ubuntu branch12:58
didrockssmoser: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/12:59
smoserdidrocks, right. i can give you a git branch that has that if you want.13:00
smoseri have one locally13:00
smoserand http://paste.ubuntu.com/10627333/ is what i want to upload13:00
smoseri 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
didrockssmoser: did you test extensively this config with manually setup network on a desktop machine?13:01
didrocksthe unconditional creation of /run/network did trigger a lot of unit failure on desktop in the past13:01
smoserwell, as it is right now, creation of that directory is pretty unconditional13:02
smoserif any network device attach event happens (ie, you have a NIC)13:02
smoserisn't it ? my change made it guaranteed, but the previous behavior was that any udev event would have created /run/network.13:03
didrockssmoser: why don't you let udev creating it when needed then?13:04
didrocksah, the initramfs13:05
smoserudev didn't create it. systemd did. when that job ran. but by its use of RntimeDirectory, its purged on first run of that job13:05
smoserright.13:05
didrockssmoser: 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:06
smoserdidrocks, ok. i'll install package here and do test on my laptop.13:10
smoseri do see a bug in the current ifup@.service job13:10
smoserif 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
smosermy changes fix that bug also.13:11
didrockssmoser: 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:12
smoserdidrocks, 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:27
didrockssmoser: 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
smoserit is not executable in the soruce tree.13:29
smoseris that the right way to do it ? just to chmod it in debian/ ?13:29
didrocksyeah, for source format 3.0, it's fine13:30
didrocks(it's not a diff, so the perms are preserved)13:31
smoserthanks13:34
davmor2infinity: yelp is still showing the utopic help graphics any idea when that should change at all?14:19
davmor2infinity: https://bugs.launchpad.net/ubuntu/+source/yelp/+bug/1434087 incase you need to band it around a bit :)14:19
ubot93Launchpad bug 1434087 in yelp (Ubuntu) "Yelp in Vivid is still showing the Utopic Unicorn Image" [High,New]14:19
infinitydavmor2: Should change soon, ideally. :P14:20
infinityNot sure where that content comes from...14:21
davmor2infinity: 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 :014:21
davmor2:)14:21
davmor2so not too bad :)14:21
infinityLooks like ubuntu-docs.14:22
infinitydavmor2: Two languages where?14:23
davmor2infinity: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/143409114:23
ubot93Launchpad 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
infinityGenerally, 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:23
davmor2infinity: keyboard should only show eng_uk it does on other installs14:24
davmor2infinity: I pointed cyphermox at it anyway :)14:24
infinityI don't even appear to have a keyboard indicator here.14:25
davmor2infinity: hahahaha14:25
infinityMaybe it only shows up if you have more than one input source defined.14:26
infinityHrm, nope, adding a second doesn't show it.  Weird.14:26
davmor2infinity: shows here on a fresh install did you upgrade for a few distros?14:28
infinityYeah.14:28
infinityThough, 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
davmor2infinity: it show on my desktop all the time in utopic and vivid14:29
infinityIck.14:30
infinityWell, if you're not finding more serious bugs yet, little bits of polish like that are easy to knock out.14:30
=== doko_ is now known as doko
infinityAs 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.14:31
smoserdidrocks, still around ?15:35
smoseri'm ready to upload.15:35
jderoseinfinity: 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 upgrade16:21
=== seb128_ is now known as seb128
infinityjderose: In theory, yes.  mlankhorst might be more interested in specifics.16:27
infinityjderose: 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
infinitymlankhorst: Guess you never tested 14.04+HWE-U to 14.10 upgrades?16:29
jderosethe 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 packages16:42
jderoserunning apt-get upgrade twice seems to get things back to correct state, but there may still be some subtle problems16:43
oSoMoNcould someone from the release team please review bug #1433141 (FFe request) and advise?18:17
ubot93bug 1433141 in webbrowser-app (Ubuntu) "[FFe] Bottom-edge gesture to open tabs list in the browser application" [Undecided,New] https://launchpad.net/bugs/143314118:17
mlankhorstinfinity: it' s not a supported upgrade path18:25
infinitymlankhorst: According to whom?18:26
mlankhorstinfinity: the only supported path from 14.04 with lts stack is to the next lts18:26
infinitymlankhorst: If you install 14.04, untick the "LTS only" box in software-properties, you'll get offered an upgrade to utopic.18:26
mlankhorstodd..18:27
infinitymlankhorst: Why would that be odd?18:27
mlankhorstinfinity: if you have the lts stack enabled you shouldn't upgrade to the next stable release..18:27
infinitymlankhorst: 14.04 to 14.10 is a supported upgrade path, we did nothing to intentionally break that in point releases.18:27
mlankhorstinfinity: yes 14.04 without lts stack to 14.10 is a supported upgrade path18:28
mlankhorstthat was the case with precise too18:28
infinitymlankhorst: 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
mlankhorstwe should prevent it, if they want to upgrade they have to remove the HWE stack first18:28
infinitymlankhorst: 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
mlankhorstand imagine you're on 14.04.3 and trying to upgrade to utopic, while your hardware is not supported in utopic yet..18:29
infinitymlankhorst: Preventing it is harder than fixing it, I suspect.18:29
infinitymlankhorst: 14.04.3 to utopic is a no-go because utopic will EOL before 14.04.3 comes out.18:29
infinitymlankhorst: Only .2 has this overlap.18:29
mlankhorstinfinity: just rebuild xorg-lts-transitional from trusty..18:31
mlankhorstand add a special case for libgbm18:32
infinitymlankhorst: 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:33
infinitymlankhorst: 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
infinityjderose: Was this something one of your customers managed to do to themselves, or more of an idle question and experimentation on your part?18:34
jderoseinfinity: 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 goofed18:40
jderosebut the upgrade is broken even without the nvidia driver18:40
infinityjderose: Yeah, apparently "not supported", I was wrong.  Though I think we should either fix that or make it hard from the UI.18:42
jderosemlankhorst: infinity: okay, thanks for the clarification (was catching up above)18:43
jderosebut 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:45
infinityjderose: Right, that was what I was saying.  Either we should fix the upgrade, or neuter update-manager.18:46
infinityjderose: Slightly less concerned about commandline upgrades, unless it's horribly broken, and your report sounded less "horribly" and more "annoyingly" broken.18:47
infinityBut, "annoyingly broken" for CLI users is "completely screwed" for GUI people.18:47
jderoseyeah, annoying and confusing for the experienced... but you can seemingly work around the issues without much trouble18:48
jderoseer, confusing for the inexperienced, that is18:48
smosercan someone please ack my systemd upload that fails due to bug 142268120:56
ubot93bug 1422681 in upstart (Ubuntu) "split out upstart-sysv" [Undecided,Triaged] https://launchpad.net/bugs/142268120:56
smoserinfinity, maybe?21:00
infinitysmoser: I'll have a poke.21:01
bdmurrayslangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/component-mismatches-uploader/+merge/25358721:46
smoserinfinity, thank you.23:50

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!