=== BrAsS_mOnKeY is now known as g2
[03:34] <sarnold> What could cause this? https://gist.github.com/11619c37f334005d1681295aa940d8dd a guy in #ubuntu-server got "Processing triggers for systemd (229-4ubuntu19) ... dpkg: error: dpkg status database is locked by another process" from an apt-get install
[03:38] <tsimonq2> sarnold: first thought that comes to mind (just a theory) is unattended-upgrades being triggered and it steals the lock
[03:38] <tsimonq2> I would consider that a bug if unattended-upgrades actually did that, but you never know...
[03:48] <juliank> tsimonq2: Yes, that can happen.
[03:48] <juliank> see https://lists.debian.org/debian-dpkg/2017/01/msg00044.html
[03:49] <tsimonq2> juliank: Oh ok, so I'm not far off ;)
[03:49] <tsimonq2> That's interesting
[03:49] <tsimonq2> Thanks for the link!
[03:50] <sarnold> juliank: thanks
[03:50] <sarnold> I'm reminded of https://deadlockempire.github.io
[03:52] <tsimonq2> sarnold: hahahahahahaha
=== JanC_ is now known as JanC
[08:32] <seb128> hum, in artful when I use "debuild clean" I get
[08:32] <seb128> "dpkg-buildpackage: error: unknown option or argument clean"
[08:33] <seb128> is that me using tools wrong or a bug?
[08:54] <sary> reporting bugs in 17.10 concerns #ubuntu+1 , -devel , or both!
[08:55] <mbiebl> I got an issue with ibus under 17.04
[08:55] <seb128> hum, python packaging question
[08:56] <seb128> if a package is shipping python files to a private dir, is it useful to byte compile those and if so is that something the tools can do for you or that you need a postinst/rm for?
[08:56] <mbiebl> when I log out, I still have an ibus-daemon (+ ibus-dconf and ibus-engine-simple) process
[08:56] <mbiebl> which don't want to exit
[08:56] <mbiebl> so the logind session is not stopped
[08:56] <seb128> or asked differently is there a better way to do what https://github.com/fossfreedom/alternative-toolbar/blob/debian/debian/postinst is doing? (that was raised as weird in a review)
[08:56] <mbiebl> unfortunately, ibus can't easily be uninstalled
[08:56] <seb128> mbiebl, is that https://bugzilla.gnome.org/show_bug.cgi?id=764029 ?
[08:56] <ubottu> Gnome bug 764029 in general "goa-daemon (and most other D-Bus services) not stopped when the user session goes away" [Critical,New]
[08:57] <mbiebl> seb128: those are systemd user services
[08:58] <mbiebl> as long as a session scope is still active, those services are not stopped
[08:58] <sary> well, this just happened , https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/1709572
[08:58] <ubottu> Launchpad bug 1709572 in system-config-printer (Ubuntu) "system-config-printer.py crashed with ValueError in require_version(): Namespace Secret not available" [Medium,New]
[08:58] <seb128> sary, launchpad is the right place to report bugs, no need to ping about them on IRC as well
[08:58] <mbiebl> so the problem is, that a process from the session does not want to die on logout
[08:59] <sary> seb128: Noted. thank you!
[08:59] <mbiebl> seb128: couldn't find a but about this ibus issue in the debian bts or launchpad
[08:59] <mbiebl> a bug...
[09:02] <seb128> that's the first time I saw it mentioned I think
[09:08] <mbiebl> seb128: it's an ibus bug i'd say
[09:09] <seb128> happyaron might know
=== rumble is now known as grumble
[11:32] <rbasak> juliank: opinion on bug 1709603 please? This is in response to a few people in Canonical agreeing and asking what we can do to make it happen.
[11:32] <ubottu> bug 1709603 in apt (Ubuntu) "apt {upgrade,install} require an update call first" [Wishlist,New] https://launchpad.net/bugs/1709603
[11:32] <rbasak> (and I haven't yet heard any dissenting opinions apart from yours)
[11:34] <Unit193> There's already a freaking timer, why on earth would...OOh nevermind, as long as it's easy to disable it's not the end of the world anyway.  Just another thing to fix...
[11:34] <Unit193> rbasak: Thanks for the LE srus.
[11:36] <rbasak> Unit193: you're welcome. Are you suggest some improvement to adding the systemd timer in the SRU?
[11:36] <rbasak> *suggesting
[11:39] <Unit193> rbasak: No, unrelated topics.  Apt does pretty well now of keeping the indexes up to date, an 'automatic' call to 'update' is excessive.
[11:39] <rbasak> Unit193: how so?
[11:40] <juliank> rbasak: It's really one of the things that annoys me the most when using yum and friends. We update the indices automatically once per day any way; the only time this would really have any effect is after a new installation (or on systems not using unattended-upgrades).
[11:40] <rbasak> Unit193: my main issue is the call of "apt install ..." on a fresh instance, such as a container. It's a very common case (anyone doing "cloud" anything, really).
[11:40] <rbasak> juliank: right, but that's a very common case.
[11:41] <persia> Perhaps the sensible solution is to add an `apt update` call to the installer, after the archive mirrors are selected?
[11:41] <Unit193> rbasak: Ah, well if the recommendation is to ship an apt config snippet in one of the cloud packages, fine by me.
[11:41] <rbasak> juliank: what if --is-necessary did not update if less than a day old? Then my proposal wouldn't introduce any functional change except in the failure case.
[11:41] <rbasak> persia: that unnecessarily slows down the boot of cloud instances.
[11:42] <rbasak> persia: or introduces a race in the system being ready to accept an "apt install", which is immediately necessary in this use case.
[11:42] <rbasak> Unit193: I think the config snippet would need to be Ubuntu-universal. We don't want a behaviour difference between Ubuntu on cloud and not-cloud by default. That's be infuriatingly confusing.
[11:42] <persia> rbasak: I thought the issue was that `apt install` didn't work on first install because the indecies were out of date.  I leave you to your previously planned work.
[11:43] <juliank> I don't really see how spawning a new cloud instance and then immediately having to run apt manually is a common thing to do. I'd expect people to script their cloud building, and then it's easy to add an update command first
[11:43] <Unit193> Better than the proposed option..
[11:43] <rbasak> persia: I want 1) if I start a container for development, it starts straight away; 2) if I subsequently run "apt install", it does the necessary things. It's not possible to have both if cloud-init blocks on updating apt first.
[11:44] <rbasak> juliank: it's a common thing to do when developing or debugging any automation.
[11:44] <persia> rbasak: So, automatically update the indices if they are too old or something?
[11:44] <rbasak> persia: correct. Automatically on "apt install" or "apt upgrade".
[11:44] <rbasak> That's what I want.
[11:44] <mdeslaur> I'd really hate for 4 apt installs in a row to download the indices each time
[11:45] <persia> For folk running production series, it oughtn't matter: the non-updated versions should be self-consistent for installation, even without a refresh of the updates.  Updates would become available at first time check.
[11:46] <rbasak> Folks running production expect the initial deployment to include all security updates.
[11:46] <persia> Perhaps, for the short-lived use case, it would be appropriate to check for updated packages a few minutes after boot, or similar.
[11:46] <rbasak> This requires a local index update.
[11:46] <juliank> I think that having an option like -u but disabled is a better choice. That's how paca
[11:46] <juliank> *pacman works
[11:47] <persia> rbasak: If the initial install is to have the security updates, the solution is to A) have the installer do the updates or B) if using image-based instantiation, update the image on every publisher run.
[11:47] <juliank> and automatically do the update if there are *no* lists
[11:47] <persia> Anything else means that the deployed instance has a security problem most of the time.
[11:48] <juliank> So apt install foo will run update on first apt use; and apt install -u foo will run update unconditionally
[11:48] <rbasak> juliank: that may be sufficient for my failure cases.
[11:48] <persia> That implies the deployed image has a window of vulnerability (between deployment and update), which may not be very useful for short-lived images.
[11:49] <rbasak> Though it depends on unattended-upgrades not being configured away from the default, and that dependency is IMHO surprising to users.
[11:49] <juliank> I'm not sure how to make that no lists part work best with cdrom:// though
[11:49] <rbasak> juliank: perhaps disable all of this if cdrom:// is present?
[11:50] <persia> That makes use of cdrom:// inherently less secure.
[11:50] <rbasak> So deprecate it.
[11:50] <juliank> rbasak: Maybe this, or maybe we should just ignore cdrom:// URIs and check if "all (other) sources are missing"
[11:50] <rbasak> That'd work fine for my case I think.
[12:23] <rbasak> juliank, persia, Unit193, mdeslaur: thank you for the discussion. Some good ideas on adjustments.
[15:09] <nacc> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Zesty 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-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: nacc
[15:37] <slangasek> nacc: were the build profile patches for php-directory-scanner sent upstream to Debian?
[15:42] <nacc> slangasek: hrm, it looks like I didn't send it, but all of the infra for building the php* has been adjusted to be better capable of handling the upgrades (or building with two different versions). I expect it'd be ok to sync if you want -- or I can submit those to Debian
[15:43] <slangasek> nacc: your call
[15:43] <nacc> slangasek: go ahead and sync it
[15:44] <slangasek> done
[15:48] <nacc> slangasek: if i'm reading the update_output.txt correctly, does php7.1 getting skipped mean that cacti-spine and php7.1-snmp become uninstallable with the binaries from src:php7.1 on s390x? but php7.1-snmp is from src:php7.1 itself
[15:51] <slangasek> nacc: on update_excuses, Depends: php7.1 net-snmp
[15:52] <slangasek> nacc: so php7.1 and net-snmp have to go in together; if there's a relevant 'Trying easy from autohinter' in the update_output, that will be more instructive
[15:53] <slangasek> nacc: and I see that net-snmp is in the big hint
[15:53] <slangasek> nacc: so doko's gcc-7 is blocking you ;)
[16:39] <slangasek> oSoMoN: hi, I see that libreoffice amd64 autopkgtest fails with gcc-7 because of new warnings (and stderr output considered a failure).  I will be overriding this test for the toolchain transition, which means libreoffice/amd64 autopkgtests will be failing in the meantime.  Would you be the person to fix this failure?
[16:41] <bdmurray> slangasek: Any ideas about why test_is_child_of_process_name in update-manager would fail on !amd64 or !i386? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/u/update-manager/20170808_003647_cf6bd@/log.gz
[16:46] <slangasek> bdmurray: !amd64 !i386, or !s390x !armhf?
[16:46] <slangasek> bdmurray: it might be that pid1's name is different inside of a container
[16:47] <bdmurray> slangasek: it fails on s390x too
[16:48] <slangasek> bdmurray: sorry, I meant "!amd64 !i386, or s390x armhf" - yes, I checked the ppc64el failure and it seems unrelated; so this test fails on the two container archs so I guess that's the difference
[16:50] <slangasek> bdmurray: http://paste.ubuntu.com/25277940/
[16:54] <nacc> slangasek: got it, thanks, would that also cover cacti-spine?
[16:54] <slangasek> nacc: I imagine so
[16:54] <nacc> slangasek: ok, i'll let that sit for a bit, then
[16:55] <bdmurray> slangasek: hrm, these tests test function in update-manager's utils.py but update-manager doesn't use them ubuntu-release-upgrader does.
[17:00] <slangasek> bdmurray: should they be moved to python3-distupgrade, then?
[17:02] <bdmurray> slangasek: I think they should be moved because I was thinking about removing the functions and the tests but I don't know if its a priority.
[17:04] <slangasek> bdmurray: at the very least, I don't think a test testing the name of pid1 is a good test
[17:05] <bdmurray> slangasek: sorry, could you elaborate?
[17:08] <slangasek> bdmurray: sorry, now reading the test and code and need to re-collect my thoughts, because my pid1 on zesty host is also /sbin/init so why would it be have differently
[17:08] <slangasek> bdmurray: but generally, the point I'm trying to make is that the test is asserting things about the system, not about the correctness of the code under test
[17:09] <slangasek> bdmurray: a proper test of this code would mock /proc
[17:11] <bdmurray> slangasek: okay
[17:22] <oSoMoN> slangasek, yes, that would be me
[17:22] <oSoMoN> putting that on my list
[17:28] <slangasek> oSoMoN: thanks
[18:32] <slashd> Is there any coredev who have some cycle atm to sponsor a patch for logrotate in devel release (artful) ? then I'll be able to proceed with the upload myself for stable release.
[18:33] <nacc> slashd: yeah, do you have a bug open?
[18:33] <nacc> slashd: i'm piloting right now anyways (see /topic)
[18:33] <slashd> nacc, https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1709670
[18:33] <ubottu> Launchpad bug 1709670 in logrotate (Ubuntu Artful) "logrotate never recovers if the statefile is corrupted" [Medium,In progress]
[18:33] <nacc> slashd: ok, i'll do that one next
[18:33] <slashd> nacc, thanks much appreciated
[18:33] <slashd> nacc, I'll take care of the SRU afterward
[18:34] <nacc> slashd: sounds good
[18:59] <nacc> slashd: iiuc, then, you don't need sponsorship to the sru series, right?
[18:59] <slashd> nacc, right I can sponsor myself on sru series
[19:02] <nacc> slashd: ack, unsubbing sponsors thanks!
[19:03] <slashd> nacc, thanks
=== Pharaoh_Atem is now known as Conan_Kudo
=== Conan_Kudo is now known as Pharaoh_Atem
[19:24] <nacc> slangasek: question re: src:numactl. I thnk we can technically sync it, except that debian dropped the arch-specication for the binary packages in favor of linux-any in 2.0.11-2.1. It specifically says 'armel and armhf are still not supported'. We don't currently build numactl on armhf anyways, but I assume for our purposes that will show up as  FTBFS?
[19:25] <nacc> slangasek: and so we do need to keep delta that switches from linux-any to the explicit list of architectures we know it builds on?
[19:25] <nacc> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Zesty 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-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
[19:26] <slangasek> nacc: it's fine for the package to be FTBFS on those archs; it wastes some builder time to try to build it and fail, but that's not usually worth carrying a delta
[19:27] <Unit193> nacc: Thanks!
[19:28] <nacc> slangasek: ok, good to know, thanks!
[19:44] <kyoder> when I report a crash in ubuntu, is it better to turn that off after one report, or do the stats increase when I keep sending the same report?
[19:49] <tyhicks> bdmurray: hey! I'm curious about the answer to kyoder's question and I suspect that you may know it ^
[20:09] <bdmurray> kyoder: If you are using a stable release of Ubuntu (e.g. 16.04, 17.04) then the stats do increase, if you are using a development release of Ubuntu (Artful Aardvark) then the stats, in Launchpad, do not increase
[20:10] <tyhicks> thanks
[20:17] <kyoder> thanks bdmurray
[20:17] <kyoder> and tyhicks
[20:26] <tsimonq2> nacc_: yay patch pilot \o/
[20:29] <nacc_> tsimonq2: i might do some more later today, just stopping for lunch
=== nacc_ is now known as nacc
[20:31] <tsimonq2> :D
[20:34] <bdmurray> jdstrand: what release did you discover bug 1707645 on?
[20:34] <ubottu> bug 1707645 in util-linux (Ubuntu) "system with high numbered uids has huge sparse /var/log/lastlog" [Undecided,New] https://launchpad.net/bugs/1707645
[20:50] <slangasek> hmm, if it's sparse, why is that a problem?
[20:50] <slangasek> oh, non-sparse rsync
[20:51] <slangasek> doesn't seem like something we'd try to fix in util-linux; the format of /var/log/lastlog is fossilized
[21:00] <Unit193> cpaelzer: Oh, g'luck on core-dev!
[21:17] <ahasenack> just checking, but a package in main cannot have a build-depends on something that is in universe, right?
[21:19] <sarnold> ahasenack: it was changed to be more nuanced; it's okay if it is strictly build-time, but if it results in binary package .. dependencies? changes? .. then the dep should be dropped or the universe package brought nito main
[21:19] <Unit193> IIRC, it can if it's only a *buildtime* depend, eg doesn't link to it.  I may be wrong.
[21:19] <ahasenack> hm
[21:19] <ahasenack> ok, good
[21:20] <ahasenack> I'll check that
[21:20] <ahasenack> what about if it's for DEP8 tests?
[21:20] <sarnold> ahasenack: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-April/001179.html
[21:21] <Unit193> Of course, sarnold beats me and says it better. \o/
[21:22] <ahasenack> try apt autoremove
[21:22] <ahasenack> it should do the right thing. But double check
[21:22] <ahasenack> I think it will even leave one kernel behind installed, in case you need to downgrade
[21:23] <sarnold> ahasenack: heh, I think you meant for those to go to #ubuntu-server instead? :)
[21:24] <ahasenack> oh, wow
[21:24] <ahasenack> it must be late :)
[21:24] <valorie> persia: looooooooooooooooooong time, no see! o/
[21:25] <ahasenack> ok, I think thid builddep that debian added (libcmocka-dev) is used only for tests
[21:25] <ahasenack> but I have to check for real. grep shows it only being used in test files
[21:26] <ahasenack> but I'll want to check the final build with ldd and the Depends header of the built package
[21:49] <jdstrand> bdmurray: artful
=== Foxtrot is now known as foxtor
=== foxtor is now known as foxtrot