=== BrAsS_mOnKeY is now known as g2 | ||
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:34 |
---|---|---|
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:38 |
juliank | tsimonq2: Yes, that can happen. | 03:48 |
juliank | see https://lists.debian.org/debian-dpkg/2017/01/msg00044.html | 03:48 |
tsimonq2 | juliank: Oh ok, so I'm not far off ;) | 03:49 |
tsimonq2 | That's interesting | 03:49 |
tsimonq2 | Thanks for the link! | 03:49 |
sarnold | juliank: thanks | 03:50 |
sarnold | I'm reminded of https://deadlockempire.github.io | 03:50 |
tsimonq2 | sarnold: hahahahahahaha | 03:52 |
=== JanC_ is now known as JanC | ||
seb128 | hum, in artful when I use "debuild clean" I get | 08:32 |
seb128 | "dpkg-buildpackage: error: unknown option or argument clean" | 08:32 |
seb128 | is that me using tools wrong or a bug? | 08:33 |
sary | reporting bugs in 17.10 concerns #ubuntu+1 , -devel , or both! | 08:54 |
mbiebl | I got an issue with ibus under 17.04 | 08:55 |
seb128 | hum, python packaging question | 08:55 |
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:56 |
mbiebl | seb128: those are systemd user services | 08:57 |
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:58 |
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... | 08:59 |
seb128 | that's the first time I saw it mentioned I think | 09:02 |
mbiebl | seb128: it's an ibus bug i'd say | 09:08 |
seb128 | happyaron might know | 09:09 |
=== rumble is now known as grumble | ||
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:32 |
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:34 |
rbasak | Unit193: you're welcome. Are you suggest some improvement to adding the systemd timer in the SRU? | 11:36 |
rbasak | *suggesting | 11:36 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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. | 11:50 |
rbasak | juliank, persia, Unit193, mdeslaur: thank you for the discussion. Some good ideas on adjustments. | 12:23 |
nacc | @pilot in | 15:09 |
=== 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 | ||
slangasek | nacc: were the build profile patches for php-directory-scanner sent upstream to Debian? | 15:37 |
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:42 |
slangasek | nacc: your call | 15:43 |
nacc | slangasek: go ahead and sync it | 15:43 |
slangasek | done | 15:44 |
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:48 |
slangasek | nacc: on update_excuses, Depends: php7.1 net-snmp | 15:51 |
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:52 |
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 ;) | 15:53 |
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:39 |
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:41 |
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:46 |
bdmurray | slangasek: it fails on s390x too | 16:47 |
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:48 |
slangasek | bdmurray: http://paste.ubuntu.com/25277940/ | 16:50 |
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:54 |
bdmurray | slangasek: hrm, these tests test function in update-manager's utils.py but update-manager doesn't use them ubuntu-release-upgrader does. | 16:55 |
slangasek | bdmurray: should they be moved to python3-distupgrade, then? | 17:00 |
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:02 |
slangasek | bdmurray: at the very least, I don't think a test testing the name of pid1 is a good test | 17:04 |
bdmurray | slangasek: sorry, could you elaborate? | 17:05 |
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:08 |
slangasek | bdmurray: a proper test of this code would mock /proc | 17:09 |
bdmurray | slangasek: okay | 17:11 |
oSoMoN | slangasek, yes, that would be me | 17:22 |
oSoMoN | putting that on my list | 17:22 |
slangasek | oSoMoN: thanks | 17:28 |
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:32 |
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:33 |
nacc | slashd: sounds good | 18:34 |
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 | 18:59 |
nacc | slashd: ack, unsubbing sponsors thanks! | 19:02 |
slashd | nacc, thanks | 19:03 |
=== Pharaoh_Atem is now known as Conan_Kudo | ||
=== Conan_Kudo is now known as Pharaoh_Atem | ||
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:24 |
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 | 19:25 |
=== 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: | ||
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:26 |
Unit193 | nacc: Thanks! | 19:27 |
nacc | slangasek: ok, good to know, thanks! | 19:28 |
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:44 |
tyhicks | bdmurray: hey! I'm curious about the answer to kyoder's question and I suspect that you may know it ^ | 19:49 |
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:09 |
tyhicks | thanks | 20:10 |
kyoder | thanks bdmurray | 20:17 |
kyoder | and tyhicks | 20:17 |
tsimonq2 | nacc_: yay patch pilot \o/ | 20:26 |
nacc_ | tsimonq2: i might do some more later today, just stopping for lunch | 20:29 |
=== nacc_ is now known as nacc | ||
tsimonq2 | :D | 20:31 |
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:34 |
slangasek | hmm, if it's sparse, why is that a problem? | 20:50 |
slangasek | oh, non-sparse rsync | 20:50 |
slangasek | doesn't seem like something we'd try to fix in util-linux; the format of /var/log/lastlog is fossilized | 20:51 |
Unit193 | cpaelzer: Oh, g'luck on core-dev! | 21:00 |
ahasenack | just checking, but a package in main cannot have a build-depends on something that is in universe, right? | 21:17 |
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:19 |
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:20 |
Unit193 | Of course, sarnold beats me and says it better. \o/ | 21:21 |
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:22 |
sarnold | ahasenack: heh, I think you meant for those to go to #ubuntu-server instead? :) | 21:23 |
ahasenack | oh, wow | 21:24 |
ahasenack | it must be late :) | 21:24 |
valorie | persia: looooooooooooooooooong time, no see! o/ | 21:24 |
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:25 |
ahasenack | but I'll want to check the final build with ldd and the Depends header of the built package | 21:26 |
jdstrand | bdmurray: artful | 21:49 |
=== Foxtrot is now known as foxtor | ||
=== foxtor is now known as foxtrot |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!