=== 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:
[00:04] <foli> The firewall maintenance is done now, all should be back.
=== jgrimm is now known as jgrimm-out
=== salem_ is now known as _salem
[01:30] <slangasek> rharper: 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] <ubottu> Launchpad bug 1649931 in systemd (Ubuntu Xenial) "systemd-networkd needs to ensure DNS is up before network-online.target" [Undecided,New] https://launchpad.net/bugs/1649931
=== juliank is now known as Guest71557
=== juliank_ is now known as juliank
[02:17] <rharper> slangasek: 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:23] <slangasek> rharper: see my last comment wrt ordering
[02:23] <slangasek> (last comment on bug)
[02:23] <slangasek> but if this patch has already been sanity-checked, it's a smaller change; I'm happy to go with it
=== JanC_ is now known as JanC
=== juliank_ is now known as juliank
[03:14] <jpleau> Hi. 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:15] <tumbleweed> another approach would be to backport the yakkety version to xenial
[03:15] <tumbleweed> PPA versioning is up to you. I usually try to make backports I do in PPAs sort before official backports
[03:16] <tumbleweed> ~ppa1 / ~yourppaname1 are reasonable suffixes
[03:17] <sarnold> if 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] <tumbleweed> that'll sort after an offical ubuntu backport
[03:18] <sarnold> 1.2.0-1ppa1.16.04.1 would sort between the debian version 1.2.0-1 and an 'official ubuntu version' 1.2.0-1ubuntu1
[03:19] <jpleau> okay, lots of good ideas here, thanks :)
[03:19] <sarnold> I'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. :)
=== BrAsS_mOnKeY is now known as g2
[05:39] <brendand> anyone ever seen the autopkgtest error:
[05:39] <brendand> autopkgtest-virt-qemu: DBG: cleanup...
[05:39] <brendand> qemu: terminating on signal 15 from pid 27417
[05:39] <brendand> <VirtSubproc>: failure: timed out waiting for "login prompt on ttyS0"
[06:35] <cpaelzer> brendand: yes I have seen that
[06:35] <cpaelzer> brendand: in my case I was runnin on s390x where the default console is sclp
[06:36] <cpaelzer> brendand: without special modification to the image after autopkgtest-buildvm I was not able to pass it
[06:36] <cpaelzer> brendand: as it did not spawn anything on ttyS0 in its default config
[06:36] <cpaelzer> brendand: now your case may be different, but it essentially means it doesn't spawn up a login on ttyS0 serial console
[06:37] <cpaelzer> brendand: you might start the qemu image directly in qemu and see what might be going on
[07:01] <brendand> cpaelzer, yeah actually it looks like it's shutting itself down. i'll have to debug it for sure
=== shuduo is now known as shuduo-afk
[07:54] <mantiena-baltix> hi
[07:55] <mantiena-baltix> Hi ricotz
[07:57] <mantiena-baltix> Why Ubuntu LibreOffice packaging isn't in sync with Debian? I'm about bug #1635847 - only 2 lines in debian/rules
[07:57] <ubottu> bug 1635847 in libreoffice (Ubuntu) "Please build libreoffice-systray package (re-enable quickstarter) - sync with Debian LibreOffice packaging" [Undecided,Confirmed] https://launchpad.net/bugs/1635847
[08:03] <mantiena-baltix> ricotz: 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] <ubottu> bug 1635847 in libreoffice (Ubuntu) "Please build libreoffice-systray package (re-enable quickstarter) - sync with Debian LibreOffice packaging" [Undecided,Confirmed] https://launchpad.net/bugs/1635847
[08:13] <ricotz> mantiena-baltix, which ubuntu version are you using?
[08:14] <ricotz> systray support is gtk2 only anyway, and gtk3 is used by default since 16.10/yakkety
[08:14] <mantiena-baltix> ricotz: I'm using 16.04 LTS releases in all schools and other institutions which I support :)
[08:15] <ricotz> mantiena-baltix, I see
[08:18] <ricotz> mantiena-baltix, alright, noted
[08:18] <mantiena-baltix> ricotz: 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 PPA
[08:19] <ricotz> mantiena-baltix, bugs which werent fixed with 5.1.6?
[08:19] <ricotz> https://launchpad.net/~libreoffice/+archive/ubuntu/libreoffice-5-1
[08:21] <mantiena-baltix> ricotz: 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:26] <ricotz> mantiena-baltix, ok
[08:39] <seb128> mantiena-baltix, hey, do you have a launchpad (or maybe upstream) bugreport about those LTS issues?
[08:42] <ricotz> seb128, this is only ppa related, and systray support was dropped with 5.2.x
[08:42] <seb128> ricotz, hey, I was speaking about "LTS has critical bugs, like crash after table of contents is inserted"
[08:42] <seb128> which from my understand is about 5.1
[08:42] <seb128> which is why mantiena-baltix installed 5.2
[08:43] <seb128> which is fine, but I would still like to see the LTS bugs fixed :p
[08:43] <ricotz> seb128, ah, yeah right, you know my opinion about björn's update strategy ;)
[08:45] <seb128> ricotz, 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 though
[08:47] <ricotz> seb128, of course, I am only referring to the lack of 5.1.x updates which is 2 releases behind
[08:47] <seb128> right, I'm not totally pleased with that as well :-/
[08:47] <seb128> but now Bjoern is on holidays so it's going to have to wait for next year
[08:47] <ricotz> snaps are simply circumventing the sru review process then to get updates ;)
[08:49] <seb128> not really, it's rather a different option for users
[08:50] <seb128> the 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] <seb128> snaps make it easy for users to follow upstream updates if they want to
[08:50] <ricotz> it will likely end up this way, when there are no updates for the archive packages
[08:50] <seb128> they also make rollback easy in case of issues which deb don't do
[08:51] <ricotz> right
[08:53] <ricotz> alright, is story is getting old ;), g2g for now
[08:56] <seb128> bye
[09:08] <mantiena-baltix> seb128: Bug #1627874
[09:08] <ubottu> bug 1627874 in libreoffice (Ubuntu) "Document crashes Libreoffice Writer" [Medium,Triaged] https://launchpad.net/bugs/1627874
[09:08] <seb128> mantiena-baltix, thanks
=== Guest14607 is now known as Zic
[09:38] <mantiena-baltix> seb128: I can't find reported bug about crashing when inserting table of content, because this bug appears not in all documents
[09:38] <seb128> mantiena-baltix, ok, well if you find an example feel free to report it so we can try to SRU a fix to xenial
[09:42] <mantiena-baltix> seb128: LO 5.1 is end of life since November 27, 2016, see https://wiki.documentfoundation.org/ReleasePlan/5.1
[09:42] <mantiena-baltix> what is the reason to fix bugs in outdated release? I think it's better to backport LibreOffice 5.2.x to 16.04 LTS
[09:43] <seb128> mantiena-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't
[09:44] <seb128> mantiena-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:46] <seb128> mantiena-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:48] <mantiena-baltix> seb128: could you tell me if you plan sync LO packaging with Debian? at least 2 lines for bug 1635847 to be fixed?
[09:48] <ubottu> bug 1635847 in libreoffice (Ubuntu) "Please build libreoffice-systray package (re-enable quickstarter) - sync with Debian LibreOffice packaging" [Undecided,Confirmed] https://launchpad.net/bugs/1635847
[09:49] <seb128> mantiena-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 now
[09:49] <seb128> mantiena-baltix, I assigned him the bug with a comment
[09:50] <mantiena-baltix> seb128: thanks
=== shuduo-afk is now known as shuduo
[09:50] <seb128> yw!
[09:53] <mantiena-baltix> seb128: 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/+packages
[09:53] <mantiena-baltix> :)
[09:53] <seb128> mantiena-baltix, Rico is working on the libreoffice ppa yes
[09:53] <seb128> and contributing to the Ubuntu package I think
[09:54] <seb128> but Bjoern is the maintainer of the Ubuntu version
=== _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
[16:41] <sil2100> hm, 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:44] <infinity> sil2100: Always failed means it's always failed. :)
[16:44] <infinity> sil2100: (With the silly exception of linux-meta-triggered stuff, because handwavy reasons, and we track those elsewhere)
[16:45] <infinity> sil2100: 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:46] <infinity> sil2100: Feel free to poke me and I'll look after I've found a bit of coffee/breakfast to fuel my day.
=== giraffe is now known as Guest17281
[16:51] <infinity> sil2100: Nice timing on the ping timeout.  Are you actually here now? :)
[16:58] <sil2100> Wow
[16:58] <sil2100> eh, love those IP changes
[16:58] <sil2100> Yeah, here now
[17:02] <sil2100> infinity: 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:25] <infinity> sil2100: Specifics are better than theory, here.  What package, what's wrong, why the argument for removal of package or ignoring of tests, etc.
[18:24] <infinity> sil2100: You have unreleased changes on the xenial branch of livecd-rootfs.  Are you okay with those going out with the next SRU?
[18:25] <infinity> cyphermox: ^--- And you didn't use the xenial bzr branch of livecd-rootfs with your last upload...
[18:27] <infinity> cyphermox: 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:32]  * sil2100 checks what changes those were
[18:33] <sil2100> infinity: yeah, those are good to go
[18:34] <sil2100> infinity: didn't release them as SRU yet as we had them on the -overlay already, but didn't want those to get missing
[18:34] <infinity> sil2100: Ta.
[18:52] <sil2100> infinity: 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 bindings
[18:53] <sil2100> infinity: at least that was what was written in the reason of removal: https://tracker.debian.org/news/822952
[18:53] <infinity> sil2100: 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] <sil2100> infinity: 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 again
[18:54] <infinity> sil2100: So, that should have been your starting point on the conversation, not talking about tests. :)
[18:54] <sil2100> Since the package is gone in Debian
[18:54] <sil2100> Ah, 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*' thing
[18:55] <infinity> sil2100: "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] <infinity> sil2100: Bonus points that it's a leaf package that never shipped in an LTS, so I deeply don't care about upgrade paths either. :P
[18:56] <infinity> sil2100: 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] <sil2100> infinity: 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] <sil2100> Or does it need some manual tinkering for britney to forget about node-zmq?
[18:56] <infinity> sil2100: britney might be a bit derpy about it, but I can massage it in.
[18:56] <sil2100> infinity: thanks, for both ;)
[19:44] <juliank> infinity: Didn't you say you want to look at unblocking apt 1.4~beta2 yesterday?
[19:49] <infinity> juliank: Yeah, yesterday might be today.  It's on the list. :P
[19:49] <infinity> juliank: Cleaning the pipes before the holidays for "important" packages (toolchain, kernel, apt, a few others) is on the very near TODO.
[19:53] <juliank> infinity: You have to read it as said "[...]" yesterday :) - I just wanted to make sure it made it to your list :)
[19:57] <juliank> infinity: 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] <infinity> juliank: 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:58] <juliank> Yeah, that makes more sense in German too :)
[19:59] <infinity> juliank: 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?!).
[20:00] <juliank> Right, it should do that daily
[20:00] <juliank> But apt might delay that by 12 hours or so
[20:00] <juliank> so 36 hours since the update came out seems reasonable
[20:01] <infinity> juliank: Yeah, even with systemd jitter, everyone with 24/7 uptime should have hit the issue long ago.
[20:01] <juliank> Right
[20:01] <infinity> juliank: 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] <juliank> heat is also low with 22/6
[20:01] <juliank> yep
[20:02] <juliank> And those are far more likely to run yakkety
[20:02] <juliank> That is, yakkety users are probably mostly laptop users
[20:02] <infinity> juliank: 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? :P
[20:02] <infinity> juliank: 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:03] <juliank> Hmm, hwat I could do is do an installability test
[20:03] <juliank> or rather, dependency satisfiability tests
[20:04] <infinity> juliank: 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] <juliank> Or I just compare deps against the 1.3.2ubuntu0.1 security upload
[20:05] <juliank> They should be the same
[20:05] <infinity> mdeslaur / 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] <infinity> juliank: Yeahp, that would satisfy me.
[20:05] <juliank> eww, lp does not show details for the binaries from the security release
[20:05] <juliank> boo
[20:06] <infinity> Downloading *ver*deb from pool/main/a/apt works. :P
[20:06] <infinity> Then debdiff binaries.
[20:06] <juliank> Diffing the build log works
[20:06] <juliank> that includes all deps
[20:07] <infinity> Diffing logs works too.  debdiffing debs is more readable, IMO, but also more bandwidth.
[20:07] <sarnold> infinity: I missed the original problem..
[20:08] <infinity> sarnold: 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] <juliank> sarnold: Installing the apt security update via unattended-upgrades kills u-a, breaking the upgrade, leaving system partially configured
[20:08] <infinity> sarnold: To minimize future ick, the SRU should probably also be in security to eliminate the problem entirely.
[20:08] <sarnold> ugh :/
[20:08] <sarnold> yeah that sounds like a good candidate for a regression usn
[20:08] <infinity> sarnold: So, the security update itself didn't technically have a regression, but it triggered a sleeper bug.
[20:10] <infinity> sarnold: 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] <infinity> s/about be/about me/
[20:11] <infinity> (ie: if it clearly has no deps from -updates, which it shouldn't)
[20:13] <sarnold> infinity: 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:15] <infinity> juliank: 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] <infinity> juliank: And if said diffing fails, I'll quickly reupload it through a security PPA with a version bump.
[20:18] <juliank> infinity: 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 enough
[20:19] <juliank> 1.3.2: deb-systemd-invoke $_dh_action apt-daily.service apt-daily.timer >/dev/null || true
[20:19] <juliank> 1.3.3: deb-systemd-invoke $_dh_action apt-daily.timer >/dev/null || true
[20:19] <juliank> where _dh_action=try-restart
[20:20] <juliank> The fix is old anyway, I just had not cherry-picked it yet :/
[20:20] <yofel> what's the replacement for syslinux-themes-ubuntu in yakkety and above? Or are the images still using the xenial theme?
[20:23] <slangasek> yofel: I would imagine we're just using the xenial theme; cyphermox or infinity might know more
[20:23] <yofel> ok, thanks
[20:23] <infinity> Yeah, looks like.
[20:24] <juliank> infinity: 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 numbers
[20:25] <juliank> on all architectures
[20:25] <infinity> juliank: Snazzy.
[20:25] <infinity> juliank: Then Ima release that now.
[20:25] <infinity> sarnold: 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:26] <sarnold> infinity: thanks
[20:28] <infinity> juliank: Iz released (pending publication).
[20:30] <juliank> infinity: neat
[20:33] <sarnold> is this the best 'how to repair the damage' advice? "dpkg --configure --pending and apt-get -f install"
[20:33] <infinity> sarnold: I tend to use dpkg --configure -a, but I suspect the end result is the samew.
[20:33] <infinity> same, too.
[20:33] <sarnold> infinity: thanks
[20:34] <infinity> sarnold: Oh, and indeed, they're aliases now. :P
[20:34] <infinity> sarnold: So, yeah, --pending is probably the better option as it's more verbosely obvious.
[20:35] <infinity> sarnold: 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] <sarnold> indeed
[20:36] <infinity> sarnold: (And, because this bug manifests with a new default option for unattended-upgrades, you shouldn't expect people to be super bright :/)
[20:37] <infinity> I 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] <sarnold> that sounds like a good idea
[20:38] <infinity> It's likely the one missing piece we have right now for flawless "my parents can do it" upgrades.
[20:39] <infinity> Windows 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] <sarnold> will running the graphical updater fix things? it'd be nice to have instructions for hte folks unfamiliar with the terminal too
[20:40] <sarnold> nod, I was thining of them, I think they released isos that just couldn't do unattended upgrades. ever. so people never upgraded...
[20:40] <infinity> sarnold: 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] <sarnold> it wouldn't take a big mistake to wind up in the same boat.
[20:40] <infinity> slangasek: 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?
=== salem_ is now known as _salem
[20:42] <infinity> I suspect this might be a "critical" bug we should have fixed 12 years ago. :P
[20:42] <infinity> So, a curious definition of "critical".
[20:43] <infinity> Oh, hey, look at that.
[20:43] <infinity> update-manager (1:0.87.4) hardy; urgency=low
[20: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 +0000
[20:44] <infinity> Oh.  That might be the dist-upgrade bits, that moved to ubuntu-release-upgrader.
[20:45] <slangasek> infinity: don't know; not sure I've seen it get into such a state locally
[20:45] <pdeee> rbasak, any chance RAOF is out for the holidays?
[20:46] <infinity> sarnold: Yeah.  update-manager doesn't do this.  Would be a valid wishcritical bug against u-m and u-a both, I think.
[20:46] <infinity> critlist?
[20:46] <slangasek> critlist.
[20:46] <infinity> wishical.
[20:47] <infinity> Really, if I had that 12 year time machine, I'd just have made Ubuntu require LVM on all installs and snapshotted all upgrades.
[20:48] <infinity> Would have papered over so many bugs.
[20:48] <infinity> Which 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] <infinity> s/dive/drive/
[21:27] <juliank> infinity: 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:29] <infinity> juliank: It'll get deleted when our little scripty things tell us to.
[21:29] <juliank> I see
[21:29] <infinity> juliank: http://people.canonical.com/~ubuntu-archive/pending-sru.html -- See "proposed cleanup" at the end.
[21:30] <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] <juliank> infinity: this page is really helpful
[21:32]  * juliank has to remember that
[21:35] <juliank> (I always wondered how to get a list of bugs that are not verified yet for an sru)
[21:39] <rbasak> pdeee: he could be. Your guess is as good as mine.
[23:34] <nacc> hrm, 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] <ubottu> Debian bug 845765 in wnpp "O: nagios3 -- host/service/network monitoring and management system" [Normal,Open]