| cpaelzer | rbalint: in systemd is a patch debian/patches/test-expect-mmap-to-fail-in-seccomp-test-on-s390-and-s390.patch of yours | 06:40 |
|---|---|---|
| cpaelzer | rbalint: it says "cherry picked from commit a81f7aad9a5ddeebbce002e2da36e1dd84f51b36" in which repo would that commit be? | 06:40 |
| cpaelzer | ah found https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd - that might be it ... | 06:42 |
| cpaelzer | no not in that repo either | 06:50 |
| cpaelzer | rbalint: bonus question - was this patch ever brought up/referenced in some upstream discussion? | 06:54 |
| mwhudson | uhhhh can rust 1.38 not bootstrap itself? | 08:32 |
| * mwhudson sets things on fire | 08:33 | |
| mwhudson | ah https://github.com/rust-lang/rust/issues/63911 | 08:37 |
| Unit193 | Issue 63911 in rust-lang/rust "1.38 beta fails to bootstrap itself" [Closed] | 08:40 |
| didrocks | mwhudson: hey, do plan to have golang 1.13 set as default for focal? (maybe even 1.14 in January, once out?) | 09:05 |
| didrocks | mwhudson: I'm asking because the alternative doesn't seem to work well: if you install golang-1.13-go for instance, you don't have /usr/bin/go pointing at it (only part of golang-go default, which has a hard dep on 1.12) | 09:06 |
| mwhudson | didrocks: ah yes i should make 1.13 the default | 09:06 |
| mwhudson | didrocks: if you want to build with 1.13 though you need to add /usr/lib/go-1.13/bin to PATH | 09:07 |
| mwhudson | didrocks: (also yes, i want 1.14 to be the default in focal) | 09:07 |
| didrocks | mwhudson: shouldn't we use an alternative for /usr/bin/go rather? | 09:07 |
| mwhudson | didrocks: no | 09:07 |
| didrocks | mwhudson: also, another question, if you want me to change the default, I'm happy to do it. It seems the delta with debian is small, I'm unsure though about what kind of tests you are doing before uploading | 09:07 |
| mwhudson | didrocks: alternatives are a bad idea for toolchain packages | 09:08 |
| mwhudson | didrocks: yes, happy for you to make the change | 09:08 |
| mwhudson | (it's getting late here) | 09:08 |
| didrocks | mwhudson: will do then! | 09:08 |
| didrocks | on alternative: I thought this was what we were doing for gcc, but I may be wrong | 09:08 |
| didrocks | otherwise yeah, adding to PATH | 09:08 |
| didrocks | anyway, will change the default on focal | 09:09 |
| mwhudson | no gcc hasn't done this for ... uh 10 years? | 09:09 |
| rbasak | cpaelzer: I sent you a MR for review feedback for mdevctl. Take the commits you like, though I think the debian/copyright adjustment is mandatory. | 09:19 |
| rbasak | See the commit for an explanation. | 09:19 |
| rbasak | With that commit I'm happy to upload. | 09:19 |
| rbasak | cpaelzer: from https://ftp-master.debian.org/REJECT-FAQ.html -> https://lists.debian.org/debian-devel-announce/2006/03/msg00023.html -> https://lists.debian.org/debian-devel-announce/2003/12/msg00007.html -> https://lists.debian.org/debian-legal/2003/12/msg00194.html "Copy that statement _verbatim_ into the copyright file" | 09:23 |
| rbasak | Not that I consider that statement normative of Debian ftpmaster policy, but I also do agree with it - since there is a statement, we must use it and the intent to use the example licensing statement provided in the licence is not being implied. | 09:24 |
| cpaelzer | rbasak: thanks reviewing the MR now | 09:58 |
| cpaelzer | I hate dependencies all in one line TBH | 09:59 |
| cpaelzer | but if that is the default I'm fine to follow | 09:59 |
| * cpaelzer appreciates on diffs to just have the line==package listed | 10:00 | |
| cpaelzer | ah, when checkign in detail git is only needed for the .spec and tag target | 10:02 |
| cpaelzer | thanks for spotting rbasak | 10:02 |
| cpaelzer | I'm ok with all changes then and merging | 10:02 |
| cpaelzer | rbasak: I already gut my upstream MR acceped (changes for lsmdev) | 10:03 |
| cpaelzer | so this (Debian)delta can be dropped on the next version | 10:04 |
| cpaelzer | and I got upstreams IRC ping that they are happy to see it being pacakged | 10:04 |
| cpaelzer | let me know if you need anything else for sponsoring this | 10:04 |
| cpaelzer | rbasak: I pushed a debian/0.50-1 tag to be sure on what we agree upon | 10:05 |
| rbasak | cpaelzer: you're welcome to use a different convention for wrapping if you like. wrap-and-sort has some options. It was only a suggestion. | 10:27 |
| rbasak | cpaelzer: sounds like you want -a|--wrap-always :) | 10:29 |
| cpaelzer | already on it | 10:30 |
| cpaelzer | writing a README.source about it before committing | 10:30 |
| rbasak | Maybe -t|--trailing-comma too? | 10:30 |
| rbasak | It'd be nice if wrap-and-sort supported a config file | 10:31 |
| cpaelzer | yep | 10:31 |
| cpaelzer | rbasak: new tag debian/0.50-2 | 10:34 |
| cpaelzer | I can wrap it into 0.50-1 instead if that is needed/preferred | 10:34 |
| rbasak | I would prefer -1 please | 10:37 |
| rbasak | -2 implies a -1 was uploaded | 10:37 |
| rbalint | cpaelzer, yes, it was on my TODO list to upstream the patch, now it is done: https://github.com/systemd/systemd/pull/14162 | 10:45 |
| cpaelzer | rbalint: thanks for the info, but this will vastly change due to https://bugs.launchpad.net/libseccomp/+bug/1853852 | 10:51 |
| ubottu | Launchpad bug 1853852 in systemd (Ubuntu) "hard to reproduce issues in systemd autopkgtest against new libseccomp 2.4.2" [Undecided,New] | 10:51 |
| cpaelzer | but now I can refer to your MR for this part of the changes | 10:52 |
| rbalint | cpaelzer, ok thanks, i was wondering why you became curious :-) | 10:58 |
| rbasak | cpaelzer: want me to squash debian/changelog and upload? | 11:00 |
| rbasak | cpaelzer: also, "benfit of mroe readable diffs" :-/ | 11:00 |
| rbasak | cpaelzer: or I can just upload your commit 642c436? | 11:01 |
| rbalint | cpaelzer, does your fix work on bionic? | 11:02 |
| seb128 | rbasak, hey. I don't know if you saw the ping on #ubuntu-desktop earlier. When you do your SRU shift, can you get https://launchpad.net/ubuntu/+source/jsunit/0.2.2-1~ubuntu0.18.04.1 migrated to updates? thunderbird was copied to security/update so it probably makes sense to move that one as well (it's a new source in bionic only needed for autopkgtests enablement) | 11:02 |
| rbasak | Ah good timing | 11:02 |
| rbasak | I was just looking for and failing to find that ping :) | 11:03 |
| rbasak | Looking now | 11:03 |
| seb128 | thx | 11:03 |
| rbasak | seb128: is there a bug reference for jsunit? | 11:03 |
| rbasak | https://people.canonical.com/~ubuntu-archive/pending-sru.html doesn't list one | 11:03 |
| seb128 | rbasak, oSoMoN can probably provide details/reply to question if you have any | 11:03 |
| rbasak | So this is somehow falling out of normal SRU process | 11:04 |
| seb128 | oSoMoN, ^ | 11:04 |
| seb128 | indeed | 11:04 |
| seb128 | as said the package is new to bionic and only needed for autopkgtest, but we should probably have had a bug reference to describe that | 11:04 |
| cpaelzer | rbasak: let me fix and retag 0.50-1, just a sec | 11:04 |
| rbasak | sil2100: ^ (jsunit) please could you take a look? | 11:05 |
| rbasak | Without a bug reference I can't see if you left any notes for me :) | 11:05 |
| cpaelzer | rbalint: I'm working on it for 20.04 and prior to the new libseccomp you wouldn#t even be affected | 11:05 |
| cpaelzer | rbalint: I have run the test on the old seccomp, and it works at least in my tests | 11:05 |
| cpaelzer | not sure if in 18.04 there will be more that makes it behave even different to that | 11:06 |
| rbasak | oSoMoN, seb128: ah, it was a PPA copy? I think this is too complex to touch without consulting with others for the background, sorry. Hopefully sil2100 will be available to sort it for you. | 11:06 |
| seb128 | rbasak, no worry, thanks | 11:06 |
| rbasak | kanashiro: looks like rrdtool is stuck in proposed. It's not obvious to me why. Please could you take a look? | 11:09 |
| rbasak | I can look deeper if you need any help. | 11:10 |
| rbalint | cpaelzer, could you please rebase you change on mine and send the PR upstream that way to preserve the commit id? | 11:10 |
| cpaelzer | rbasak: pushed the (new) 0.50-1 tag | 11:12 |
| cpaelzer | rbalint: I already rebased onto your retaining your commit as-is | 11:15 |
| cpaelzer | but before sending anything for mine I'll need more testing with old/new libseccomp to be sure | 11:15 |
| cpaelzer | and on x86 as at least this morning I only ran s390x so far | 11:15 |
| rbalint | ok, thanks! | 11:15 |
| rbasak | cpaelzer: :-/ | 11:18 |
| rbasak | cpaelzer: you missed the second typo in "benfit of mroe readable diffs" | 11:19 |
| rbasak | But I'm happy to upload anyway | 11:19 |
| rbasak | FWIW I avoid tagging until an upload is accepted to avoid this kind of thing | 11:19 |
| rbasak | ftpmasters may want changes too | 11:19 |
| cpaelzer | oh so tagging is backwards in time | 11:20 |
| cpaelzer | ok, I will kill the tag then | 11:20 |
| cpaelzer | I have fixed one mroe | 11:20 |
| cpaelzer | lets see where the second one is | 11:21 |
| rbasak | Actually what I do is tag at the time of upload, but I do not push it until after the upload is accepted | 11:21 |
| rbasak | Which from the perspective of everyone else is to not tag until after I guess, apart from the timestamp | 11:21 |
| cpaelzer | tag removed (from git repo) - should be d943ccd444e3c6c18acbb4b403f41551b5df6659 now | 11:21 |
| cpaelzer | there should be no mroe left in that | 11:22 |
| rbasak | benfit | 11:22 |
| cpaelzer | oO | 11:22 |
| rbasak | Anyway it doesn't matter | 11:22 |
| rbasak | You can fix that later | 11:22 |
| cpaelzer | rbasak: pushed already | 11:23 |
| cpaelzer | 99abec1 is the head to sponsor | 11:23 |
| rbasak | OK | 11:23 |
| cpaelzer | and yes, ftpmasters might want even more | 11:23 |
| rbasak | Uploaded | 11:27 |
| cpaelzer | thanks rbasak | 11:27 |
| sil2100 | oSoMoN, rbasak: hey! Yes, it's on my plate, I missed the chance to take care of it on Monday | 11:44 |
| sil2100 | oSoMoN: IIRC chrisccoulson was fine with getting it out to -security, right? | 11:44 |
| rbasak | cpaelzer: oh, whoops. I need to upload binaries too. I forgot. I'll do that. | 11:52 |
| cpaelzer | rbasak: wait | 11:58 |
| rbasak | kanashiro: I advise against tagging uploads until accepted by the archive | 11:58 |
| cpaelzer | rbasak: unless you have done already, since we just changed the repo | 11:58 |
| rbasak | kanashiro: see the mess caused by this above ;) | 11:58 |
| rbasak | cpaelzer: no, I haven't | 11:58 |
| cpaelzer | I have that reflected in d/control | 11:58 |
| cpaelzer | rbasak: should we rebuild then to reflect the new repo correctly in this initial upload? | 11:58 |
| rbasak | Sure, if you wamt | 11:59 |
| rbasak | Where's the new repo? | 11:59 |
| cpaelzer | rbasak: https://salsa.debian.org/debian/mdevctl | 11:59 |
| cpaelzer | rbasak: new head at b6692181 contains the VCS updates | 11:59 |
| rbasak | OK | 11:59 |
| cpaelzer | kanashiro: since we moved it to the more official space, I can now delete my project that I had under my own user right? | 12:01 |
| kanashiro | rbasak, usually I tag right after I do the upload, for instance in this case if you don't rebuild the package from the new master (adding the new changes) I'd not now the exact content of the source package you uploaded just looking at the git repo | 12:02 |
| kanashiro | cpaelzer, of course | 12:02 |
| cpaelzer | kanashiro: if only I'd find delete project in this UI then ... | 12:02 |
| * kanashiro is checking rrdtool in proposed | 12:03 | |
| rbasak | kanashiro: yeah, of course you need to tag the commit you uploaded. I'm just saying that the tag should be pushed after archive accept, not before. | 12:03 |
| rbasak | This avoids problems if the upload is rejected - by a sponsor, by ftpmasters, or by queue management software | 12:03 |
| rbasak | (in a way that requires changes) | 12:04 |
| cpaelzer | kanashiro: found the remove action in the UI | 12:05 |
| kanashiro | rbasak, sure, but you can also recreate tags. maybe I am a more git oriented person and like things been reflected in the repo all the time :p | 12:08 |
| rbasak | kanashiro: changing tags is very severely frowned upon though. That's not what anyone following a git repository expects to see. | 12:10 |
| kanashiro | rbasak, you are right, but in this specific case where probably no one is tracking your changes yet is not a huge problem IMO | 12:11 |
| rbasak | Agreed | 12:13 |
| kanashiro | rbasak, I also have no clue about why rrdtool is stuck in proposed, it says python3-rrdtool (= 1.7.2-3) is not satisfiable but this binary is generated by the proposed source package | 12:21 |
| rbasak | Yes that's how far I got too. | 12:22 |
| * rbasak looks deeper | 12:22 | |
| rbasak | Ah | 12:44 |
| rbasak | It's because python-rrdtool-dbg is in main for some reason | 12:45 |
| rbasak | python3-rrdtool-dbg rather | 12:45 |
| rbasak | It doesn't appear in https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html but that page is out of date | 12:47 |
| cpaelzer | rbasak: that might be the auto-promotion due to wildcards | 13:07 |
| cpaelzer | rbasak: if the source is in main for any reason certain packages will be auto-promoted | 13:07 |
| cpaelzer | that can be overrules in the seeds IIRC | 13:07 |
| cpaelzer | rbasak: look for Extra-Exclude in https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu | 13:09 |
| cpaelzer | and I see rrdtool itself is in main, wich implies that the source is | 13:10 |
| rbasak | cpaelzer, kanashiro: ah, OK, so we need to add entry like https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/supported#n175 to counter https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/supported#n175 for python3-rrdtool-dbg I think? | 13:16 |
| rbasak | Because python3-rrdtool-dbg depends on python3-rrdtool which is in universe | 13:17 |
| cpaelzer | yes | 13:17 |
| rbasak | And it doesn't make sense to have python3-rrdtool-dbg in main if python3-rrdtool isn't presumably | 13:17 |
| rbasak | to counter https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/supported#n127 I mean | 13:17 |
| cpaelzer | you get this all the time on merges of sources in main with binaries being in main only partial | 13:18 |
| rbasak | I've never seen this before! | 13:18 |
| cpaelzer | hmm, like 2-3 per cycle I'd think | 13:18 |
| cpaelzer | maybe my perception is skewed and it was less | 13:18 |
| rbasak | kanashiro: would you like to sort out an MP for that please? | 13:18 |
| === ricab is now known as ricab|bbl | ||
| oSoMoN | sil2100, yes, I think chrisccoulson was fine with getting it out to -security, he did all the other related packages (thunderbird, enigmail, mozilla-devscripts) but he left that one out, not sure if intentionally or not | 13:46 |
| chrisccoulson | oSoMoN, sil2100, oh, which one did I leave out? | 13:47 |
| oSoMoN | chrisccoulson, jsunit | 13:48 |
| chrisccoulson | also, we could really do with pushing an update for disco. I know it's EOL in january, but the current situation isn't great for upgrades | 13:48 |
| chrisccoulson | ah, sorry about that | 13:48 |
| oSoMoN | chrisccoulson, I prepared a 60.9.1 update for disco to address the gmail authentication issue which was the most pressing one, once it's in disco-updates I can prepare a 68.x upload | 13:49 |
| oSoMoN | speaking of which, rbasak if you're still doing your SRU shift would you mind looking at the thunderbird 60.9.1 uploads to xenial and disco? | 13:50 |
| oSoMoN | that's an upstream point release that fixes one single issue, bug #1850651 | 13:51 |
| ubottu | bug 1850651 in thunderbird (Ubuntu Disco) "[SRU] Authentication constantly re-requested for Google" [High,In progress] https://launchpad.net/bugs/1850651 | 13:51 |
| kanashiro | rbasak, sorry for the delay, and yes, I will prepare a MP adding python3-rddtool-dbg to this supported file in ubuntu-seeds | 14:10 |
| === ricab|bbl is now known as ricab | ||
| zyga | stgraber: hello, I'm trying to get systemd --user to work inside a container but fail; do you know what's the magic that spawns it for user sessions I get, for example, when ssh-ing into a box? | 15:21 |
| stgraber | Possibly some logind magic? | 15:22 |
| zyga | do you know who might be able to teach me about it? | 15:22 |
| zyga | I realized that systemct --user and friends doesn't work inside my containers | 15:23 |
| Laney | zyga: logind sessions are normally started by pam_systemd | 15:24 |
| Laney | pam_systemd(8) might help you? | 15:24 |
| zyga | ah, thanks for that, I'll dig | 15:24 |
| zyga | stgraber: is lxd exec doing any login-like things or is it just a setns into the container? | 15:40 |
| zyga | stgraber: I'm trying to figure out if I should set everything up and then ssh into the container | 15:40 |
| zyga | stgraber: or try to manage to get "lxc exec" to end up behaving the way I need to | 15:41 |
| stgraber | zyga: effectively just setns, technically quite a bit more as we also match seccomp/apparmor profiles, join the right cgroups, drop the right capabilities, ... | 15:41 |
| zyga | right | 15:41 |
| stgraber | zyga: but as far as what we do inside the container, it's just spawning the command | 15:41 |
| zyga | right | 15:41 |
| zyga | ok | 15:41 |
| zyga | thank you :) | 15:42 |
| Laney | could a pam session be started or is that a bad idea for some reason? | 15:42 |
| stgraber | zyga: LXD's design is to never assume anything about what's present in the container and never to have the host trust any file inside the container (or even attempt to open anything prior to joining) | 15:42 |
| zyga | Laney: I think I want to but I need to understand more first | 15:42 |
| zyga | Laney: I'm working on a test that checks how snapd can track apps inside lxd containers | 15:42 |
| Laney | I mean by lxd itself when execing | 15:42 |
| zyga | Laney: (when snapd is inside a container) | 15:42 |
| Laney | nod | 15:42 |
| zyga | Laney: and it works great for things running as root talking to systemd in the container | 15:43 |
| zyga | but I need to prod the "now as the user" variant as well | 15:43 |
| stgraber | Laney: that would require lxd to know about pam which we'd rather not do | 15:43 |
| stgraber | Laney: we do have the "lxc shell" alias which uses "su" and will typically go through pam as a result (so long as "su" exists in the container) | 15:43 |
| zyga | ohh | 15:43 |
| * zyga didn't know about lxc shell | 15:44 | |
| stgraber | it's a default built-in alias for "exec @ARGS@ -- su -l" | 15:44 |
| zyga | yeah, that's a much saner environment (for my needs) | 15:44 |
| zyga | I now have a seat | 15:44 |
| zyga | and cgroups are typical (exec just gave me /) | 15:45 |
| Laney | w00t | 15:47 |
| === led_dark_2 is now known as led_dark_1 | ||
| ahasenack | is there a way to have debootstrap in ubuntu consider the *-updates and *-security repositories? I get just the release pocket | 18:00 |
| ahasenack | with --components I can add restricted,universe etc, but not the other repositories | 18:00 |
| doko | LocutusOfBorg: the pycxx Breaks/replaces relation for pycxx needs adjustment | 18:03 |
| arunpyasi | Hi there, Do we need to ask Ubuntu in order to maintain an unofficial flavour of Ubuntu ? | 18:07 |
| connor_k | arunpyasi, I think for it to be considered a flavor, it must be approved by Ubuntu. I think most flavors start out as "remixes" | 18:16 |
| arunpyasi | Oh like, Budgie Remix ? | 18:17 |
| connor_k | arunpyasi, this link might be useful: https://wiki.ubuntu.com/RecognizedFlavors | 18:17 |
| connor_k | arunpyasi, it might have been (?) a remix at first but I see Budgie listed here as a flavor: https://wiki.ubuntu.com/UbuntuFlavors | 18:18 |
| arunpyasi | https://en.wikipedia.org/wiki/Ubuntu_Budgie I see it was formerly called as Budgie Remix | 18:19 |
| arunpyasi | So, is that we need to work on it as Remix at the initial state and later to Flavors ? | 18:20 |
| cjwatson | ahasenack: no, requires some fairly awkward work that has never been done | 18:21 |
| ahasenack | cjwatson: ok, thanks | 18:21 |
| connor_k | arunpyasi, that's my understanding. There are more details on the Recognized Flavors link I posted above under this header: "Guidelines to become and remain a recognized flavor" | 18:21 |
| cjwatson | or at least not integrated | 18:21 |
| cjwatson | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690210 I think | 18:21 |
| ubottu | Debian bug 690210 in debootstrap "debootstrap: please support multiple suites" [Wishlist,Open] | 18:21 |
| arunpyasi | connor_k, Ahh OK. Thanks a lot for your help :) | 18:22 |
| connor_k | np :-) | 18:22 |
| connor_k | ddstreet, is this comment referring to an existing launchpad bug or should I file one: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1825946/comments/7 | 22:30 |
| ubottu | Launchpad bug 1825946 in network-manager (Ubuntu Xenial) "'nm' autopkgtest fails due to GI stderr output" [Low,New] | 22:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!