| Mirv | tsimonq2: btw if you wondered why there was some unneeded patches not in series files, that happened sometimes since I used a lot of automation like http://pastebin.ubuntu.com/25218283/ which might have added files for the upload that I was actually not committing to git :) | 05:42 |
|---|---|---|
| Mirv | if there was uncommitted cruft locally | 05:43 |
| Mirv | tsimonq2: anyway, really nice to see silo 2819! :) | 05:43 |
| Mirv | if I had so called free time, I'd start to be really happy to help but life is way too busy these days | 05:47 |
| tsimonq2 | Mirv: Hey! :) | 05:49 |
| tsimonq2 | Mirv: Yeah, just waiting on some package removals and we can land it :D | 05:50 |
| tsimonq2 | I mean, the silo in and of itself *should* be ready to land. It just won't migrate from -proposed... | 05:52 |
| Mirv | "just" :D it'll be interesting to see if the migration will need some hinting this time or not. I'll gladly stare at update_output.txt with you. | 05:54 |
| Mirv | it's still painful to remember to Qt 5.6 migration | 05:54 |
| tsimonq2 | hehehehe :) | 05:56 |
| tsimonq2 | Mirv: yeah it might take some beating into submission to get through :P | 05:57 |
| tsimonq2 | Mirv: Any suggestions, suggestions, and patches are more than welcome :) | 05:59 |
| tsimonq2 | That's redundant. :P | 06:00 |
| tsimonq2 | suggestions, help, patches, that's three words that make sense :P | 06:00 |
| Mirv | tsimonq2: from the PPA you're missing AFAIK at least gammaray (qtbase-abi), musescore (qtbase-abi) rebuilds | 06:05 |
| Mirv | checked with artful they still have those deps | 06:06 |
| tsimonq2 | Mirv: Thank you | 06:06 |
| tsimonq2 | Mirv: Do you still have permissions to copy packages there? I'm not a Core Developer and I've just been poking my usual (Core Developer) victim^Msponsor ;) | 06:07 |
| Mirv | tsimonq2: sure, I'm as core developer as before, just with much less time for Ubuntu ;) | 06:13 |
| tsimonq2 | Mirv: Sure ;) | 06:13 |
| Mirv | tsimonq2: both uploaded, gammaray is something that often requires newer upstream version though | 06:16 |
| tsimonq2 | Mirv: Oh, thanks. :) | 06:16 |
| tsimonq2 | Mirv: I'm working on an updated telegram-desktop now | 06:17 |
| tsimonq2 | Mirv: ... so build-essential being uninstallable made those builds fail ... what | 06:36 |
| tsimonq2 | At least my Telegram build | 06:36 |
| * tsimonq2 retries | 06:36 | |
| tsimonq2 | Mirv: gammaray is FTBFS because we forgot to adjust the reverse dependencies for qt3d-assimpsceneio-plugin to the new package name | 06:40 |
| tsimonq2 | Luckily this was caught early, I'll try to take care of it in my PPA | 06:40 |
| Mirv | tsimonq2: ok. I uploaded gammaray ~2 with that fixed. meanwhile musescore has some other problem you should look into at some point. | 07:08 |
| Mirv | (gammaray also seems to have another problem) | 07:12 |
| tsimonq2 | Mirv: Sure. | 07:13 |
| tsimonq2 | Mirv: Also, thanks :) | 07:14 |
| === klebers_ is now known as klebers | ||
| Mirv | you're welcome! | 07:23 |
| sil2100 | Mirv: \o/ | 07:28 |
| Mirv | sil2100: o/ | 08:08 |
| === santa is now known as Guest62238 | ||
| tsimonq2 | Could someone from the SRU team please review bug 1641912? | 08:41 |
| ubottu | bug 1641912 in gtk+2.0 (Ubuntu Zesty) "Please backport two recent-manager patches" [Critical,In progress] https://launchpad.net/bugs/1641912 | 08:41 |
| sil2100 | tsimonq2: I could take a look in some moments | 09:26 |
| tsimonq2 | sil2100: Thanks :) | 09:27 |
| rbalint | xnox, juliank: mvo did not reply but i think sponsoring the tagged u-u 0.94 would be better than another nmu we have to integrate | 10:36 |
| xnox | rbalint, 0.94 into debian, or ubuntu, or both? | 10:37 |
| juliank | rbalint: The commits needed for the download-only stuff so far are already cherry-picked in artful, zesty, and xenial | 10:38 |
| xnox | juliank, however, that is only half of the critical story. we have other clients waiting for the rest of rbalint's fixes. | 10:38 |
| juliank | I think mvo probably had a reason not to upload 0.94 | 10:38 |
| juliank | true | 10:38 |
| rbalint | juliank, xnox: maybe he was waiting for test results, maybe he just does not have time | 10:41 |
| xnox | ogra, does mvo do irc these days at all? | 10:41 |
| xnox | see ^^^^^ | 10:41 |
| juliank | Well, you can just upload 0.94~ubuntu1 or something in either case and sync 0.94 when mvo uploads it to Debian or whatever | 10:45 |
| rbalint | xnox: to debian, then we can sync it | 10:45 |
| ogra | xnox, if he is not on vacation (or molten because of the heat) he does, yes | 10:46 |
| ogra | (i think the first one is true atm ) | 10:47 |
| juliank | Just do the ~ubuntu dance for 0.94, I don't think it's particularly nice to just upload it to Debian without mvo knowing | 10:47 |
| juliank | It's also a day faster this way | 10:48 |
| juliank | :D | 10:48 |
| xnox | juliank, checkout https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1707880 i hate dh_systemd_start | 10:49 |
| ubottu | Launchpad bug 1707880 in debhelper (Ubuntu Zesty) "newly installed additional units are not started on upgrade" [Undecided,New] | 10:49 |
| rbalint | juliank: not for me, i can upload to debian only yet :-\ | 10:49 |
| juliank | xnox: But that's a more general bug really, then | 10:51 |
| juliank | rbalint: Well, but others can :) | 10:54 |
| xnox | juliank, sure but i don't see how this can be fixed in dh-systemd itself. unless it injects things into preinst to detect new units that do get installed.... | 10:58 |
| rbalint | juliank: if someone uploads 0.94~ubuntu1 to artful please note that the fix for LP: #1649709 is not included because i think it is not a bug and not forwarded it upstream | 11:03 |
| ubottu | Launchpad bug 1649709 in unattended-upgrades (Ubuntu) "unatttended-upgrades 0.92ubuntu3 installs all updates but update-manager is set to only install security automatically" [Medium,Fix released] https://launchpad.net/bugs/1649709 | 11:03 |
| xnox | rbalint, what do you mean, it's not a bug?! =) | 11:05 |
| rbalint | xnox: i just fixed the description of LP: #1649709 | 11:06 |
| ubottu | Launchpad bug 1649709 in unattended-upgrades (Ubuntu) "unatttended-upgrades 0.92ubuntu3 installs all updates but update-manager is set to only install security automatically on development release" [Medium,Fix released] https://launchpad.net/bugs/1649709 | 11:06 |
| xnox | rbalint, but: | 11:06 |
| xnox | / This option will controls whether the development release of Ubuntu will be | 11:06 |
| xnox | / upgraded automatically. | 11:06 |
| xnox | Unattended-Upgrade::DevRelease "false"; | 11:06 |
| xnox | it got fixed by setting DevRelease to false, no? | 11:06 |
| xnox | (such that unattended upgrades does not upgrade on dev series) | 11:07 |
| rbalint | xnox: it is essentially removing u-u | 11:07 |
| xnox | yeah.... | 11:07 |
| xnox | it has a sour taste to it. | 11:07 |
| rbalint | so the fix is redundant | 11:07 |
| xnox | and dev series, kind of, have to upgrade. | 11:07 |
| xnox | i guess we need to reopen that bug, and mark it as won't-fix or opinion, if we are reverting it. | 11:07 |
| rbalint | yes, but was waiting for bdmurray to comment first | 11:08 |
| infinity | xnox, rbalint: I disagree with both of you, it seems. | 11:21 |
| infinity | The claim that "users will get no upgrades" is BS. update-manager still gives them upgrades. | 11:21 |
| infinity | But unattended-upgrades in a devel series, no matter how careful we are, has much more potential for breakage than in a stable series. | 11:22 |
| infinity | I suspect most devel series users want to be present, at the console, when upgrades happen. | 11:22 |
| * ogra wouldnt mind a present at the console when updates happen :) | 11:24 | |
| infinity | xnox, rbalint: I could maybe see a halfway argument, where unattended-upgrades on a devel series defaulted to download-only, so that you have seeded your cache when update-manager (or a manual apt-get run) is invoked. | 11:27 |
| infinity | Though, even then, with the churn of devel, you might end up downloading twice as many things as you ultimately install. | 11:27 |
| xnox | infinity, i believe the bdmurray's fix disables the download of updates as well. | 11:29 |
| infinity | xnox: Sure. Not super relevant, mind you. Like I said, that "halfway" compromise might be a bad idea anyway. It's not uncommon under heavy development for the same package to update 4 times in a week. I don't want to download all 4 just to install the last one if I upgrade weekly. | 11:30 |
| infinity | Anyhow, I would contend that daily upgrading the devel series noninteractively is not what most devel users want. There's a reason people screamed when that bug fix went in and it started happening. | 11:31 |
| infinity | And "just remove the package, then" is a cop-out because I don't want to install test devel media and then have to make it non-standard just to get it to not mess with me. | 11:32 |
| juliank | xnox: that's true, but I guess it should really detect "new" units and start them | 11:33 |
| juliank | Having to add hacks to every package that adds a systemd unit seems weird | 11:34 |
| xnox | infinity, and we cannot enable just o=beautiful-security suite, as it does really need o=beautiful and o=beautiful-security. | 11:34 |
| infinity | xnox: Yes... And? | 11:34 |
| xnox | infinity, or would it work fine for u-a against o=beautiful-security to pull in new deps from o=beutiful? | 11:34 |
| xnox | without configuring u-a to install from o=beatiful? | 11:34 |
| infinity | xnox: No. The whole reason this started happening is because we had to add the release pocket to get new deps from security. | 11:34 |
| xnox | ack. | 11:35 |
| infinity | xnox: I don't think returning to the "yay, devel series upgrades behind your back daily" behaviour is sane. | 11:35 |
| infinity | xnox: People disliked it. A lot. For very good reasons. | 11:35 |
| bdrung_work | rbasak, regarding http://cloud-images.ubuntu.com/daily/streams/v1/ – is this file format documented somewhere? which tools are available for it? I found python-simplestreams, but this doesn't really fit my needs. | 11:35 |
| juliank | Or well, I guess try-restart could check if the unit has ever been started, and if not (and it's enabled), start it | 11:36 |
| xnox | right, they are not supported either way; and they should dist-upgrade; and it's best they dist-upgrade interactively; and u-a only does upgrade hence for devel it should really not do anything non-interactive. | 11:36 |
| rbasak | smoser: ^ | 11:36 |
| rbasak | bdrung_work: there are CLI tools in simplestreams. What do you need, exactly? | 11:36 |
| xnox | juliank, something like that. I guess i need to forward this to debian BTS proper. | 11:36 |
| bdrung_work | rbasak, i want to query the stream information and extract the latest cloud images and their download location | 11:37 |
| juliank | xnox: But that must have been a problem when we first added apt-daily.timer, and nobody noticed that | 11:38 |
| rbasak | bdrung_work: python/python3-simplestreams can do that. In what way does it not fit your needs? | 11:38 |
| bdrung_work | so that i can compare the versions with the versions that I have (and an option to download them) | 11:38 |
| bdrung_work | rbasak, maybe i haven't found the function. is there some function/class that I can give a url (like http://cloud-images.ubuntu.com/releases/) and get the dict (gpg checked) back? | 11:40 |
| smoser | bdrung_work, usquery or image-status at https://github.com/smoser/talk-simplestreams/tree/master/bin are the closest thing to that. there is also sstream-mirror. | 11:41 |
| rbasak | bdrung_work: also "sstream-query http://cloud-images.ubuntu.com/releases/" does that, so you could start by looking at that implementation. | 11:41 |
| bdrung_work | okay. i will look at sstream-query | 11:42 |
| rbasak | bdrung_work: some documentation of the data model: http://bazaar.launchpad.net/~simplestreams-dev/simplestreams/trunk/view/head:/doc/README | 11:42 |
| bdrung_work | and got a traceback: http://paste.debian.net/979190/ | 11:45 |
| smoser | bdrung_work, http://paste.ubuntu.com/25219664/ | 11:46 |
| rbasak | bdrung_work: do you have ubuntu-cloudimage-keyring installed? | 11:46 |
| bdrung_work | no | 11:46 |
| smoser | right. you need that or need to add the cloud images keyring to your gpg keyring | 11:46 |
| bdrung_work | a nicer error message would be nice | 11:47 |
| rbasak | Agreed. | 11:47 |
| smoser | agreed. | 11:47 |
| smoser | bdrung_work, you can also hit it over https and skip gpg if you wanted. | 11:48 |
| smoser | sstream-query http://cloud-images.ubuntu.com/daily/streams/v1/com.ubuntu.cloud:daily:download.json | 11:48 |
| smoser | the client in lxc does metadata over https and data over http if possible falling back to data over https | 11:49 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| === sergiusens_ is now known as sergiusens | ||
| juliank | Do we want to keep apt-transport-https for artful? We can either drop it now, or keep it around for a release? If we want to keep it, should (can) we at least move the binary to universe? | 14:27 |
| * juliank vaguely recalls some binaries being in different components than their source packages, but not sure if src main and bin universe, other way around, or both | 14:28 | |
| juliank | Ah it's mentioned as "Binary only demotions to universe" in https://wiki.ubuntu.com/ArchiveAdministration#Component_Mismatches_and_Changing_Overrides | 14:29 |
| infinity | juliank: I'd rather see it dropped and have apt Provides/Conflicts/Replaces apt-transport-https for a smooth transition. | 14:58 |
| infinity | juliank: I mean, if it's a 100% replacement now. | 14:59 |
| elopio | Hello! Can somebody please approve snapcraft in -proposed? I want to finish the testing tonight. | 15:25 |
| nacc | slangasek: server team acks LP: #1700826 | 15:31 |
| ubottu | Launchpad bug 1700826 in ubuntu-meta (Ubuntu Zesty) "please include numactl on the ubuntu-server iso" [Undecided,In progress] https://launchpad.net/bugs/1700826 | 15:31 |
| nacc | dannf: --^ but with 16.04.3 frozen, it is going to miss that ISO | 15:31 |
| slangasek | nacc: will someone on server team also do the merge/ | 15:37 |
| nacc | slangasek: i can do that today, yeah | 15:38 |
| dannf | nacc: ok, thx (and bummer). do you know if it will start appearing in the xenial dailies shortly after 16.04.3? | 15:41 |
| nacc | dannf: i don't know --^ that's a good question for infinity / slangasek | 15:42 |
| slangasek | nacc, dannf: it would | 15:44 |
| dannf | cool, that's probably good enough for my needs. ta! | 15:45 |
| elopio | slangasek: sorry, RAOF is not around and I'm not sure who to ping today instead. Can you help us accepting snapcraft to proposed? | 15:46 |
| infinity | slangasek, dannf: If you approve and merge that today, I'm not against it magically appearing on the .3 ISOs iff I have a reason to re-spin. But, if today's images end up being final, obviously you missed the boat. | 15:55 |
| infinity | (Well, it would also need a copy-to-updates/pomote-to-main dance) | 15:56 |
| slangasek | infinity: ack. Meanwhile, TB meeting? | 16:01 |
| slangasek | (you're chair) | 16:01 |
| infinity | slangasek: Which is why I was there two minutes ago. :P | 16:01 |
| slangasek | but didn't start the meeting ;) | 16:01 |
| rbasak | nacc: ^ FYI | 16:11 |
| nacc | rbasak: yep, i saw, thanks | 16:11 |
| nacc | infinity: good to know, i plan on merging after our meeting, but yeah, will need AA help to copy/promote. | 16:12 |
| === led2 is now known as led1 | ||
| nacc | slangasek: infinity: fwiw, seeds updated | 16:36 |
| nacc | slangasek: still needs the pocket copy & promotion, though | 16:36 |
| slangasek | nacc: doing | 16:46 |
| nacc | slangasek: thanks! | 16:48 |
| nacc | dannf: --^ fyi | 16:48 |
| dannf | nacc, slangasek : thanks! | 16:49 |
| slangasek | nacc, dannf: done | 16:53 |
| nacc | slangasek: excellent, thanks | 16:53 |
| slangasek | elopio: looks like me dragging my feet to respond has paid off, and sergiusens_ has gotten apw to look at it now ;P | 16:55 |
| apw | slangasek, heh, thanks | 17:21 |
| elopio | slangasek: works for me :) | 17:32 |
| sergiusens_ | slangasek: oh, I didn't mean to do that, I didn't even care to look in #ubuntu-devel and since I didn't see elopio ping anyone on #ubuntu-release and a p w was around I thought I just ping him | 17:40 |
| === sergiusens_ is now known as sergiusens | ||
| slangasek | sergiusens: hey, it all works out great for me, so... :) | 17:40 |
| juliank | infinity: The idea of keeping it is to provide one release cycle of detecting any unknown issues and having a fallback in such a case, really | 18:06 |
| juliank | in 6 months we can then say: nobody missed it in the current release, so let's drop it :D | 18:06 |
| juliank | The question is: Is it still pulled in by seeds / in main? | 18:08 |
| juliank | If so, that should be fixed first | 18:08 |
| * juliank does not have an artful chroot atm | 18:08 | |
| === JanC_ is now known as JanC | ||
| xnox | slangasek, in an unpriviledged container (lxd default) everything appears to have CAP_IPC_LOCK capability, yet it does not work, as mlockall() returns ENOMEM which means - trying to lock more than permitted. | 23:20 |
| xnox | thus causing iscsid.service to fail to start. | 23:21 |
| xnox | should iscsid.service run in lxd container? should it ignore failure to lock memory in an unpriviledged container? | 23:21 |
| xnox | or should the Pre checks check if locking memory actually works? | 23:22 |
| sarnold | xnox: btw "unprivileged" -- fewer 'd's :) | 23:22 |
| sarnold | I'd think failure to lock memory would be a warning at worst | 23:22 |
| xnox | sarnold, tah. also thanks for an opinion. | 23:22 |
| nacc | sarnold: the problem is if iscsid is your root disk | 23:23 |
| nacc | sarnold: then getting swapped out might mean you lose your root disk :) | 23:23 |
| sarnold | oh, it's client-side thing? | 23:23 |
| nacc | sarnold: and i believe the granularity of iscsid is ... not great | 23:23 |
| xnox | nacc, not going to be the case for unpriviledged container. and also, what else can it do? | 23:23 |
| xnox | sarnold, yes client. | 23:23 |
| nacc | xnox: yeah, i agree, it's probably ok to ignore in unpriv. containers | 23:23 |
| nacc | xnox: that's just the intention of the code in iscsid (for sarnold's point) | 23:23 |
| xnox | so iff we are in a container, and failed to lock memory continue. | 23:24 |
| xnox | but do hard fail if we are not in a container. | 23:24 |
| xnox | sarnold, is it normal that unpriviledged container has capsh --print things listed in current and bounding set that do not work. | 23:24 |
| sarnold | xnox: I don't know containers real well but I think that's the conclusion I've come to before | 23:25 |
| xnox | it would make it much easier if the unprivileged containers did not have cap_sys_ipc and cap_sys_audit_read | 23:25 |
| nacc | xnox: i assume this is for LP: #1576341 ? | 23:25 |
| ubottu | Launchpad bug 1576341 in snapd (Ubuntu) "systemd in degraded state on startup in LXD containers" [Undecided,New] https://launchpad.net/bugs/1576341 | 23:25 |
| xnox | it would make it much easier if the unprivileged containers did not have cap_sys_ipc_lock and cap_sys_audit_read | 23:25 |
| nacc | xnox: yeah, it's confusing as to what is "real" caps and what is not | 23:25 |
| xnox | nacc, partially. that one is fixed now with https://github.com/systemd/systemd/pull/6503/files systemd would hard fail on not able to do setpriority() | 23:26 |
| xnox | despite having cap_sys_nice | 23:26 |
| sarnold | I still think that a warning would be best. "Warning: Don't put swap on iscsi devices due to risk of deadlock." maybe no swap. maybe swap on local disk. | 23:27 |
| xnox | but i now have iscsid.service and systemd-journald-audit.socket still to do. | 23:27 |
| sarnold | doing something brutal in either of those two cases would be mean. | 23:27 |
| nacc | xnox: i thought artful-proposed version of open-iscsi has the fixes | 23:27 |
| nacc | xnox: which is stuck due to a test regression (on my todo) | 23:27 |
| nacc | xnox: at least, that was my last comment in the bug -- i've not re-tested recently :) | 23:28 |
| nacc | xnox: with the fix actually coming from rbalint and incorporated into the most recent merge | 23:29 |
| xnox | oooh | 23:31 |
| slangasek | xnox: I don't think any service that asks for locked memory should ignore that failure | 23:31 |
| xnox | i like that condition in that patch from rbalint | 23:31 |
| xnox | private-users to check whether we are running in a user namespace... hm but that is not true. | 23:32 |
| nacc | xnox: yeah, it's pretty clean with that (or at least a bit cleaner than the generic condition) | 23:32 |
| xnox | cause e.g. priviledged containers, is still has user namespace, it's just ultimately container root is mapped to host root i think. | 23:32 |
| xnox | let me check that. | 23:32 |
| xnox | no actually that does the right thing it seems. | 23:34 |
| nacc | xnox: yeah, in my testing it seemed to work, but i'll admit to trusting rbalint as well :) | 23:37 |
| xnox | # systemctl is-system-running | 23:38 |
| xnox | running | 23:38 |
| xnox | win =) | 23:38 |
| nacc | xnox: nice | 23:40 |
| xnox | and https://github.com/systemd/systemd/pull/6508/files | 23:43 |
| nacc | xnox: cool, that makes sense based upon the conclusion in the other LP bug (LP: #1457054) | 23:44 |
| ubottu | Launchpad bug 1457054 in systemd (Ubuntu Wily) "journal is broken in unprivileged LXC and nspawn containers" [Medium,Fix released] https://launchpad.net/bugs/1457054 | 23:44 |
| xnox | now i need to figure out why the new system crashes amd64/i386 VMs, and fails to reboot 5 times in a row on s390x. | 23:46 |
| infinity | juliank: Keeping it for artful might be reasonable if you'd like people to have a fallback, but I'd like to see the forced P/C/R migration before the 18.04 release then. If enough data can be gathered to determine it's definitely no longer necessary or useful. | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!