=== ChanServ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
foliThe firewall maintenance is done now, all should be back.00:04
=== jgrimm is now known as jgrimm-out
=== salem_ is now known as _salem
slangasekrharper: LP: #1649931 - I note that the systemd unit being patched here is dropped in yakkety in favor of debian/extra/units/systemd-resolved.service.d/resolvconf.conf; did you consider whether we should do the same in xenial?01:30
ubottuLaunchpad bug 1649931 in systemd (Ubuntu Xenial) "systemd-networkd needs to ensure DNS is up before network-online.target" [Undecided,New] https://launchpad.net/bugs/164993101:30
=== juliank is now known as Guest71557
=== juliank_ is now known as juliank
rharperslangasek: if it's functionally equivalent, I'm fine with dropping the delta; looking at the systemd file in yakkety (232) it's not immeditately clear that this provides the ordering and dependencies that we're trying to achieve;02:17
slangasekrharper: see my last comment wrt ordering02:23
slangasek(last comment on bug)02:23
slangasekbut if this patch has already been sanity-checked, it's a smaller change; I'm happy to go with it02:23
=== JanC_ is now known as JanC
=== juliank_ is now known as juliank
jpleauHi. I maintain a package in debian, and someone asked for a newer version for Xenial. I'm going to setup a ppa for this, but I'm unsure what's the standard for versionning. If the version is 1.2.0-1 in debian, what would it be in my ppa for xenial?03:14
tumbleweedanother approach would be to backport the yakkety version to xenial03:15
tumbleweedPPA versioning is up to you. I usually try to make backports I do in PPAs sort before official backports03:15
tumbleweed~ppa1 / ~yourppaname1 are reasonable suffixes03:16
sarnoldif it were going into the archive it'd probably something like 1.2.0-1ubuntu1.16.04.1  -- maybe instead of 'ubuntu' you'd use 'ppa' or something that'd still sort 'higher' than the debian version, lower than 'ubuntu' in case it were to be SRU'd back to xenial, and the 16.04 part lets you then push the same version to yakkety and on with 16.10 or 17.04 numbers later on...03:17
tumbleweedthat'll sort after an offical ubuntu backport03:17
sarnold1.2.0-1ppa1.16.04.1 would sort between the debian version 1.2.0-1 and an 'official ubuntu version' 1.2.0-1ubuntu103:18
jpleauokay, lots of good ideas here, thanks :)03:19
sarnoldI'm not sure if that's ideal or not :) your ~ppa proposal sorts the debian version higher. it might not matter. yours is certainly easier on the eyes. :)03:19
=== BrAsS_mOnKeY is now known as g2
brendandanyone ever seen the autopkgtest error:05:39
brendandautopkgtest-virt-qemu: DBG: cleanup...05:39
brendandqemu: terminating on signal 15 from pid 2741705:39
brendand<VirtSubproc>: failure: timed out waiting for "login prompt on ttyS0"05:39
cpaelzerbrendand: yes I have seen that06:35
cpaelzerbrendand: in my case I was runnin on s390x where the default console is sclp06:35
cpaelzerbrendand: without special modification to the image after autopkgtest-buildvm I was not able to pass it06:36
cpaelzerbrendand: as it did not spawn anything on ttyS0 in its default config06:36
cpaelzerbrendand: now your case may be different, but it essentially means it doesn't spawn up a login on ttyS0 serial console06:36
cpaelzerbrendand: you might start the qemu image directly in qemu and see what might be going on06:37
brendandcpaelzer, yeah actually it looks like it's shutting itself down. i'll have to debug it for sure07:01
=== shuduo is now known as shuduo-afk
mantiena-baltixHi ricotz07:55
mantiena-baltixWhy Ubuntu LibreOffice packaging isn't in sync with Debian? I'm about bug #1635847 - only 2 lines in debian/rules07:57
ubottubug 1635847 in libreoffice (Ubuntu) "Please build libreoffice-systray package (re-enable quickstarter) - sync with Debian LibreOffice packaging" [Undecided,Confirmed] https://launchpad.net/bugs/163584707:57
mantiena-baltixricotz: I see build errors with new LibreOffice 5.2.4 RC2 at ppa:ricotz/ppa , could you sync packaging code with Debian and fix bug #1635847 - only 2 lines in debian/rules ?08:03
ubottubug 1635847 in libreoffice (Ubuntu) "Please build libreoffice-systray package (re-enable quickstarter) - sync with Debian LibreOffice packaging" [Undecided,Confirmed] https://launchpad.net/bugs/163584708:03
ricotzmantiena-baltix, which ubuntu version are you using?08:13
ricotzsystray support is gtk2 only anyway, and gtk3 is used by default since 16.10/yakkety08:14
mantiena-baltixricotz: I'm using 16.04 LTS releases in all schools and other institutions which I support :)08:14
ricotzmantiena-baltix, I see08:15
ricotzmantiena-baltix, alright, noted08:18
mantiena-baltixricotz: and LibreOffice 5.1, which is by default in Ubuntu 16.04 LTS has critical bugs, like crash after table of contents is inserted, so, I installed LO 5.2.x from libreoffice PPA08:18
ricotzmantiena-baltix, bugs which werent fixed with 5.1.6?08:19
mantiena-baltixricotz: these bug wasn't fixed in 5.1.5, I didn't tested with 5.1.6, but users are happy with 5.2 except slow startup :)08:21
ricotzmantiena-baltix, ok08:26
seb128mantiena-baltix, hey, do you have a launchpad (or maybe upstream) bugreport about those LTS issues?08:39
ricotzseb128, this is only ppa related, and systray support was dropped with 5.2.x08:42
seb128ricotz, hey, I was speaking about "LTS has critical bugs, like crash after table of contents is inserted"08:42
seb128which from my understand is about 5.108:42
seb128which is why mantiena-baltix installed 5.208:42
seb128which is fine, but I would still like to see the LTS bugs fixed :p08:43
ricotzseb128, ah, yeah right, you know my opinion about björn's update strategy ;)08:43
seb128ricotz, yeah, he's on the conservative side, we should have got 5.1.6 by now, but it's not clear those issues are fixed in that version ... and updating a LTS to another major serie as 5.2 is a no go not only by Bjoern but by standard Ubuntu practice, users can get that from ppas or snaps if they want though08:45
ricotzseb128, of course, I am only referring to the lack of 5.1.x updates which is 2 releases behind08:47
seb128right, I'm not totally pleased with that as well :-/08:47
seb128but now Bjoern is on holidays so it's going to have to wait for next year08:47
ricotzsnaps are simply circumventing the sru review process then to get updates ;)08:47
seb128not really, it's rather a different option for users08:49
seb128the Ubuntu releases and especially LTS versions focus on stability (in the sense of not creating regressions but also not changing the UI or workflow which would have an impact on a class of users)08:50
seb128snaps make it easy for users to follow upstream updates if they want to08:50
ricotzit will likely end up this way, when there are no updates for the archive packages08:50
seb128they also make rollback easy in case of issues which deb don't do08:50
ricotzalright, is story is getting old ;), g2g for now08:53
mantiena-baltixseb128: Bug #162787409:08
ubottubug 1627874 in libreoffice (Ubuntu) "Document crashes Libreoffice Writer" [Medium,Triaged] https://launchpad.net/bugs/162787409:08
seb128mantiena-baltix, thanks09:08
=== Guest14607 is now known as Zic
mantiena-baltixseb128: I can't find reported bug about crashing when inserting table of content, because this bug appears not in all documents09:38
seb128mantiena-baltix, ok, well if you find an example feel free to report it so we can try to SRU a fix to xenial09:38
mantiena-baltixseb128: LO 5.1 is end of life since November 27, 2016, see https://wiki.documentfoundation.org/ReleasePlan/5.109:42
mantiena-baltixwhat is the reason to fix bugs in outdated release? I think it's better to backport LibreOffice 5.2.x to 16.04 LTS09:42
seb128mantiena-baltix, not sure where you want to go with this info, 5.1 is the version in the LTS and we don't switch between major series so we need to maintain it even if upstream doesn't09:43
seb128mantiena-baltix, there might be differences of functionalities/workflow/UI between major series and it's too much change for some of the corporate users (need to update company documentations, re-do training for staff etc)09:44
seb128mantiena-baltix, we usually don't update to other series but fix issues, as an user you can opt it from 5.2 using e.g snaps (the snap is still new so might not be perfect but we are working on it and it should be a good way for users who want new versions to get those)09:46
mantiena-baltixseb128: could you tell me if you plan sync LO packaging with Debian? at least 2 lines for bug 1635847 to be fixed?09:48
ubottubug 1635847 in libreoffice (Ubuntu) "Please build libreoffice-systray package (re-enable quickstarter) - sync with Debian LibreOffice packaging" [Undecided,Confirmed] https://launchpad.net/bugs/163584709:48
seb128mantiena-baltix, I don't know sorry but Sweet5hark should know, I'm going to ask him when he's around but I think he's on holidays since yesterday evening so that might be after the end of year now09:49
seb128mantiena-baltix, I assigned him the bug with a comment09:49
mantiena-baltixseb128: thanks09:50
=== shuduo-afk is now known as shuduo
mantiena-baltixseb128: I tought, that ricotz is responsible for building new LO releases in libreoffice PPA - I've noticed Rico name in changelog at https://launchpad.net/~ricotz/+archive/ubuntu/ppa/+packages09:53
seb128mantiena-baltix, Rico is working on the libreoffice ppa yes09:53
seb128and contributing to the Ubuntu package I think09:53
seb128but Bjoern is the maintainer of the Ubuntu version09:54
=== _salem is now known as salem_
=== scottt is now known as Guest84702
=== shuduo is now known as shuduo-name
=== shuduo-name is now known as shuduo-afkk
=== shuduo-afkk is now known as shuduo-afk
sil2100hm, what are the criteria to consider an autopkgtest as 'Always failed'? Meaning: can I poke someone and convince them that the selected failure should be ignored?16:41
infinitysil2100: Always failed means it's always failed. :)16:44
infinitysil2100: (With the silly exception of linux-meta-triggered stuff, because handwavy reasons, and we track those elsewhere)16:44
infinitysil2100: Regressions shouldn't be ignored without solid reason, but the release team are who you should poke if you think you have valid reasons.16:45
infinitysil2100: Feel free to poke me and I'll look after I've found a bit of coffee/breakfast to fuel my day.16:46
=== giraffe is now known as Guest17281
infinitysil2100: Nice timing on the ping timeout.  Are you actually here now? :)16:51
sil2100eh, love those IP changes16:58
sil2100Yeah, here now16:58
sil2100infinity: I could potentially try to fix the package (or simply disable the failing tests), but not sure if it makes sense for a package that we'd likely just want to have removed?17:02
infinitysil2100: Specifics are better than theory, here.  What package, what's wrong, why the argument for removal of package or ignoring of tests, etc.17:25
infinitysil2100: You have unreleased changes on the xenial branch of livecd-rootfs.  Are you okay with those going out with the next SRU?18:24
infinitycyphermox: ^--- And you didn't use the xenial bzr branch of livecd-rootfs with your last upload...18:25
infinitycyphermox: Which might actually be okay in this case, because I suspect we want to punt that version from -proposed, given it was tied to the shim-signed update.  Concur?18:27
* sil2100 checks what changes those were18:32
sil2100infinity: yeah, those are good to go18:33
sil2100infinity: didn't release them as SRU yet as we had them on the -overlay already, but didn't want those to get missing18:34
infinitysil2100: Ta.18:34
sil2100infinity: as for the node-zmq thingy - so it seems the tests started failing after we uploaded the new zeromq3 (which shouldn't actually change anything), I looked at how Debian dealt with this and what they did is remove and deprecate the node-zmq package in overall in favor of the native zeromq3 bindings18:52
sil2100infinity: at least that was what was written in the reason of removal: https://tracker.debian.org/news/82295218:53
infinitysil2100: Oh.  "Removed from Debian" is all the reason we need for an Ubuntu removal, unless it has rdeps we're not willing to remove.18:53
sil2100infinity: so I was opting for ignoring the test failure as I'm not sure if I should, in this case, invest time in trying to get the tests working again18:53
infinitysil2100: So, that should have been your starting point on the conversation, not talking about tests. :)18:54
sil2100Since the package is gone in Debian18:54
sil2100Ah, ok, I was talking about tests as I didn't think deletion of a package is such an 'yeah, let's just do it. *done*' thing18:54
infinitysil2100: "Ignoring the tests" is never the right answer.  But "remove the package entirely" can sometimes be, and very much is when it's removed from Debian and is a leaf package (both true in this case).18:55
infinitysil2100: Bonus points that it's a leaf package that never shipped in an LTS, so I deeply don't care about upgrade paths either. :P18:55
infinitysil2100: So, https://packages.qa.debian.org/n/node-zmq/news/20161210T172937Z.html would be the right thing to point at, and I'll JFDI the removal (doing now).18:56
sil2100infinity: excellent, I guess package removal would fix my problem as well - do you know if when the node-zmq package gets removed, will britney notice that and just finally let the new zeromq3 out of -proposed?18:56
sil2100Or does it need some manual tinkering for britney to forget about node-zmq?18:56
infinitysil2100: britney might be a bit derpy about it, but I can massage it in.18:56
sil2100infinity: thanks, for both ;)18:56
juliankinfinity: Didn't you say you want to look at unblocking apt 1.4~beta2 yesterday?19:44
infinityjuliank: Yeah, yesterday might be today.  It's on the list. :P19:49
infinityjuliank: Cleaning the pipes before the holidays for "important" packages (toolchain, kernel, apt, a few others) is on the very near TODO.19:49
juliankinfinity: You have to read it as said "[...]" yesterday :) - I just wanted to make sure it made it to your list :)19:53
juliankinfinity: A second report of the unattended-upgrade breakage came in today, I'm not sure if we should reconsider moving 1.3.3 from y-proposed to y-security (how often do unattended-upgrades run by default?)19:57
infinityjuliank: Ahh.  Today's English Lesson for German Speakers, then: "Didn't you say yesterday that [...]" is the usual way to ask that and get the linguistic order of operations correct. ;)19:57
juliankYeah, that makes more sense in German too :)19:58
infinityjuliank: Huh.  So, I'd expect all the unattended-upgrades fallout to have fallen out within 24h of the security update.  But I guess we didn't take into account people who turn off their computers (weirdos!) or people who aren't always connected to the internet (aliens?!).19:59
juliankRight, it should do that daily20:00
juliankBut apt might delay that by 12 hours or so20:00
juliankso 36 hours since the update came out seems reasonable20:00
infinityjuliank: Yeah, even with systemd jitter, everyone with 24/7 uptime should have hit the issue long ago.20:01
infinityjuliank: But those weirdos who turn on their computers twice a week or connect to the internet via strange whistling devices may be behind.20:01
juliankheat is also low with 22/620:01
juliankAnd those are far more likely to run yakkety20:02
juliankThat is, yakkety users are probably mostly laptop users20:02
infinityjuliank: Probably still worth considering bouncing 1.3.3 to both updates and security, though.  Can you do a manual check on all binaries on all arches to make sure that's safe, so we don't have to rebuild in a hurry? :P20:02
infinityjuliank: I'm sure we can get the security team signoff to release it as a USN regression update if you deem it binary safe.20:02
juliankHmm, hwat I could do is do an installability test20:03
juliankor rather, dependency satisfiability tests20:03
infinityjuliank: Yeah, given your deps (libstdc++, gnutls, etc), I trust that shlibs are sane and if it's installable, it's also not broken.20:04
juliankOr I just compare deps against the 1.3.2ubuntu0.1 security upload20:04
juliankThey should be the same20:05
infinitymdeslaur / sarnold : ^-- If juliank proves installability for apt 1.3.3 on all arches, any qualms about me releasing it to security as a USN regression fix?20:05
infinityjuliank: Yeahp, that would satisfy me.20:05
juliankeww, lp does not show details for the binaries from the security release20:05
infinityDownloading *ver*deb from pool/main/a/apt works. :P20:06
infinityThen debdiff binaries.20:06
juliankDiffing the build log works20:06
juliankthat includes all deps20:06
infinityDiffing logs works too.  debdiffing debs is more readable, IMO, but also more bandwidth.20:07
sarnoldinfinity: I missed the original problem..20:07
infinitysarnold: Due to a bug in apt in yakkety, the security update in yakkety broke unattended-upgrades users.  The damage is done for those who are broken (and they needed a manual apt run to clean up), but there are still reports trickling in, which means some people still haven't upgraded (people with power or network cut off since the security update went out).20:08
julianksarnold: Installing the apt security update via unattended-upgrades kills u-a, breaking the upgrade, leaving system partially configured20:08
infinitysarnold: To minimize future ick, the SRU should probably also be in security to eliminate the problem entirely.20:08
sarnoldugh :/20:08
sarnoldyeah that sounds like a good candidate for a regression usn20:08
infinitysarnold: So, the security update itself didn't technically have a regression, but it triggered a sleeper bug.20:08
infinitysarnold: So, assuming installability is sane, any qualms about be releasing from -proposed, despite it not having been built in a security-only PPA?20:10
infinitys/about be/about me/20:10
infinity(ie: if it clearly has no deps from -updates, which it shouldn't)20:11
sarnoldinfinity: that sounds fine -- granted, normally it's other people making the call, but I suspect "infinity says it's a good idea" would be sufficient :)20:13
infinityjuliank: Kay, do whatever diffing will satisfy us (on all arches), and make sure the bug itself is verified, and we'll push it as a asecurity update.20:15
infinityjuliank: And if said diffing fails, I'll quickly reupload it through a security PPA with a version bump.20:15
juliankinfinity: Actually not reproducing  it would be somewhat hard, but I checked the postinst only restarts the timer and not the service, I think that's enough20:18
juliank1.3.2: deb-systemd-invoke $_dh_action apt-daily.service apt-daily.timer >/dev/null || true20:19
juliank1.3.3: deb-systemd-invoke $_dh_action apt-daily.timer >/dev/null || true20:19
juliankwhere _dh_action=try-restart20:19
juliankThe fix is old anyway, I just had not cherry-picked it yet :/20:20
yofelwhat's the replacement for syslinux-themes-ubuntu in yakkety and above? Or are the images still using the xenial theme?20:20
slangasekyofel: I would imagine we're just using the xenial theme; cyphermox or infinity might know more20:23
yofelok, thanks20:23
infinityYeah, looks like.20:23
juliankinfinity: I just wdiffed all the control file line in the build logs (greped for lines starting with " [A-Za-z_]:") and there were no changes apart from apt version numbers20:24
juliankon all architectures20:25
infinityjuliank: Snazzy.20:25
infinityjuliank: Then Ima release that now.20:25
infinitysarnold: I leave it up to you if you feel issuing a USN-2 is worth it to explain the new version popping into existence in the security pocket.20:25
sarnoldinfinity: thanks20:26
infinityjuliank: Iz released (pending publication).20:28
juliankinfinity: neat20:30
sarnoldis this the best 'how to repair the damage' advice? "dpkg --configure --pending and apt-get -f install"20:33
infinitysarnold: I tend to use dpkg --configure -a, but I suspect the end result is the samew.20:33
infinitysame, too.20:33
sarnoldinfinity: thanks20:33
infinitysarnold: Oh, and indeed, they're aliases now. :P20:34
infinitysarnold: So, yeah, --pending is probably the better option as it's more verbosely obvious.20:34
infinitysarnold: So, that tangent aside, yes, that sounds like the right advice to give people.  Perhaps add a sprinking of "sudo"s in there, if you feel your readers aren't super bright.20:35
infinitysarnold: (And, because this bug manifests with a new default option for unattended-upgrades, you shouldn't expect people to be super bright :/)20:36
infinityI wonder if unattended-upgrades or update-manager or both should also have a self-healing option that attempts to JFDI a --configure --pending and install retry.20:37
sarnoldthat sounds like a good idea20:37
infinityIt's likely the one missing piece we have right now for flawless "my parents can do it" upgrades.20:38
infinityWindows Update isn't much better here, mind you, I've been stuck in upgrade loops on Windows machines for weeks, but they do seem to have some way to force themselves out of it, and I'm pretty sure we don't.20:39
sarnoldwill running the graphical updater fix things? it'd be nice to have instructions for hte folks unfamiliar with the terminal too20:39
sarnoldnod, I was thining of them, I think they released isos that just couldn't do unattended upgrades. ever. so people never upgraded...20:40
infinitysarnold: Well, that's the "maybe update-manager should ..." bit.  Maybe it already does, and I'm not aware because I don't really use it.20:40
sarnoldit wouldn't take a big mistake to wind up in the same boat.20:40
infinityslangasek: You use update-manager.  Do you know if it can force itself out of a broken configure by just trying again the next time it runs, or does it get stuck needing terminal love?20:40
=== salem_ is now known as _salem
infinityI suspect this might be a "critical" bug we should have fixed 12 years ago. :P20:42
infinitySo, a curious definition of "critical".20:42
infinityOh, hey, look at that.20:43
infinityupdate-manager (1:0.87.4) hardy; urgency=low20:43
infinity  * DistUpgrade/DistUpgradeController.py, DistUpgradeCache.py:20:43
infinity    - if dpkg was interrupted, run "dpkg --configure -a"20:43
infinity -- Michael Vogt <michael.vogt@ubuntu.com>  Fri, 25 Jan 2008 15:59:53 +000020:43
infinityOh.  That might be the dist-upgrade bits, that moved to ubuntu-release-upgrader.20:44
slangasekinfinity: don't know; not sure I've seen it get into such a state locally20:45
pdeeerbasak, any chance RAOF is out for the holidays?20:45
infinitysarnold: Yeah.  update-manager doesn't do this.  Would be a valid wishcritical bug against u-m and u-a both, I think.20:46
infinityReally, if I had that 12 year time machine, I'd just have made Ubuntu require LVM on all installs and snapshotted all upgrades.20:47
infinityWould have papered over so many bugs.20:48
infinityWhich is also the direction MS went when they realised they can never ship a perfect upgrade.20:48
infinity(Though, they still retry the failed ones enough times to dive their users crazy)20:48
juliankinfinity: will 1.3.3 get deleted from proposed eventually, now that it's published in both updates and security, or do you need to nudge it first?21:27
infinityjuliank: It'll get deleted when our little scripty things tell us to.21:29
juliankI see21:29
infinityjuliank: http://people.canonical.com/~ubuntu-archive/pending-sru.html -- See "proposed cleanup" at the end.21:29
infinity(We don't do copy+delete in one operation because if the copy fails, it's entirely non-obvious... If we ever teach LP how to "move", then we'll be in business. :P)21:30
juliankinfinity: this page is really helpful21:30
* juliank has to remember that21:32
juliank(I always wondered how to get a list of bugs that are not verified yet for an sru)21:35
rbasakpdeee: he could be. Your guess is as good as mine.21:39
nacchrm, should we delete nagios3 from ubuntu? it's gone from debian unstable it seems (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845765)23:34
ubottuDebian bug 845765 in wnpp "O: nagios3 -- host/service/network monitoring and management system" [Normal,Open]23:34

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