| jibel | vorlon, thanks for your reviews and merging ubuntu-cdimage and debian-cd :) | 07:12 |
|---|---|---|
| kstenerud | Question regarding modifying a patchfile in debian/patches: If it's our patch (and not debian's), is it better to squash the commit into the older ubuntu commit, or to leave it as 2 commits? | 10:56 |
| doko | RAOF: please could you subscribe the mir team, or another team to yaml-cpp? still needed for the MIR | 11:30 |
| cjwatson | kstenerud: I'd normally squash it in that case | 11:38 |
| cjwatson | Assuming it's actually part of the same logical change | 11:38 |
| tjaalton | hum, https://wiki.ubuntu.com/ReleaseSchedule is out of date | 11:47 |
| tjaalton | I'll fix it | 11:47 |
| juliank | ddstreet: So, the thing that comes to my mind when add-apt-repository private ppa, is that I want it to look like a normal ppa with a sources.list.d file, but an additional auth.conf.d file with the username and password. | 12:11 |
| ddstreet | that would be great | 12:11 |
| juliank | Optimally, it would like talk to launchpad so you can do add-apt-repository ppa:<blah> and it fetches the auth data itself, but that might be a bit involved | 12:12 |
| ddstreet | yeah, it of course will need to switch from anon lp access to logged in, and actually getting the private ppa key and pw i haven't looked at how to do yet | 12:13 |
| ddstreet | but *should* be possible | 12:13 |
| juliank | ddstreet: The easier alternative is to go with apt-add-repository 'https://<authorized launchpad url> <components>' and then extract the data from the url, and generate the filename based on it | 12:14 |
| juliank | since they follow the form private-ppa.launchpad.net/USER/PPA | 12:15 |
| ddstreet | yeah, that will still require the user to go into their lp private repo area and get the info tho, which is a pain | 12:15 |
| juliank | Right | 12:16 |
| juliank | but at least it avoids people having the auth data in sources.list :) | 12:16 |
| juliank | (and getting warnings for that stuff) | 12:17 |
| ddstreet | exactly, that is annoying since it's what users are told to do | 12:17 |
| juliank | In general, add-apt-repository should ask for a repository name | 12:17 |
| juliank | so if you add another repository where we cannot detect a name with auth data | 12:17 |
| juliank | it should ask you to give it a name | 12:17 |
| juliank | and then create sources.list.d/<name>.list and auth.conf.d/<name>.conf | 12:17 |
| ddstreet | well if we keep the format of 'user/repo' we can just use that for the name, same as a public ppa | 12:18 |
| juliank | yes | 12:18 |
| ddstreet | just more work on the back-end to authenticate and gather the pw and ppa key | 12:18 |
| juliank | I meant, outside of launchpad, where we don't have a name schema, we can ask users | 12:18 |
| ddstreet | ah right | 12:19 |
| juliank | I'd like add-apt-repository to show you a URL to launchpad.net | 12:19 |
| juliank | it connects to another url | 12:19 |
| juliank | then you click the first one | 12:19 |
| juliank | and then launchpad authorizes the add-apt-repository process / sends it the auth data | 12:20 |
| juliank | that'd avoid any logging in on the client side, which might be a good idea or a bad one, depending on the use case :) | 12:20 |
| ddstreet | so you want to avoid using the normal non-anon lp login from python? | 12:21 |
| juliank | I think if you use the non-anon login, it basically works in a similar way? | 12:21 |
| juliank | But I'm not sure | 12:21 |
| ddstreet | right it gives you a url to create oauth to lp | 12:22 |
| juliank | It would be nice to have a page though that tells you "you requested access to this ppa, grant it?" | 12:22 |
| ddstreet | once you authorize the oauth for some time period, then the lp login succeeds | 12:22 |
| cjwatson | There doesn't seem like much point trying to avoid logging in if your proposal is to construct a special-case thing that requires you to go to the browser anyway | 12:22 |
| ddstreet | hmm that probably would require changes to lp itself i think | 12:23 |
| ddstreet | i think if we just make the user do the normal lp oauth login, then we dont need additional approval to add a ppa - i mean that's what they are doing with the add-apt-repo cmd anyway | 12:24 |
| cjwatson | And if you just use the normal oauth token login process, then add-apt-repository on multiple private PPAs in succession would cache the token and just work | 12:24 |
| ddstreet | we should leave the existing 'here's the repo description, press enter to keep adding it' prompt | 12:24 |
| juliank | cjwatson: I think there are two use cases: End-user machines, where you want to cache the token; and shared cloud servers, where you don't | 12:24 |
| ddstreet | i think the minimum oauth time is 1 hr, is that right? | 12:25 |
| juliank | I think in the latter case, you'd like to have something like one login per repository, with the token scoped to the ppa you are adding | 12:25 |
| cjwatson | I'd like to have more narrowly-scoped tokens for LP, but it's a big project | 12:25 |
| cjwatson | (I made a start on that in early 2016, but it was hugely complicated and we put it on indefinite hold) | 12:26 |
| cjwatson | https://code.launchpad.net/~cjwatson/lazr.restful/caveats/+merge/286796 was the start of it | 12:27 |
| ddstreet | for the cloud server use case and/or lots of machines use case, there should be a param/option to add-apt-repo like you said before, to just pass the ppa and pw without needing to authorize to lp | 12:27 |
| cjwatson | Or have a way to run add-apt-repository on a client system and push the authorisation to a remote system | 12:28 |
| ddstreet | and probably a param to do the oauth to get the pw, but not actually install on the local system - then they can take that ppa and pw and deploy in cloud servers without needing oauth on those servers | 12:28 |
| cjwatson | That way you don't have to worry about giving your credentials to a remote cloud machine, and you can benefit from local cred caching | 12:28 |
| ddstreet | well, that gets into add-ap-repo starting to do cloud management stuff | 12:29 |
| cjwatson | A bit like debsign -r | 12:29 |
| ddstreet | hmm yeah | 12:29 |
| cjwatson | It does, but it might still be overall simpler | 12:29 |
| juliank | that's a good idea | 12:29 |
| ddstreet | yep | 12:29 |
| ddstreet | is there an existing bug to track adding this? | 12:29 |
| juliank | We can combine that so that add-apt-repository -r remote ppa:something | 12:30 |
| cjwatson | I don't know how it fits with existing cloud automation, but I guess if you're looking at prompting anyway then automation isn't so much of a thing | 12:30 |
| juliank | basically resolves to ssh remote add-apt-repository 'https://foo:bar@private... blah blah' | 12:30 |
| cjwatson | Passing secrets on stdin rather than on the ps-visible command line, I hope | 12:30 |
| juliank | oh that's true | 12:31 |
| ddstreet | i suspect anyone with large numbers of instances would want to get the ppa/pw once, then drop that into whatever orchestration tool they are using, chef, puppet, juju, etc | 12:31 |
| juliank | add-apt-repository --stdin | 12:31 |
| === ricab is now known as ricab|lunch | ||
| juliank | and then you can even have support for multiple repositories being passed on stdin | 12:31 |
| cjwatson | person.getArchiveSubscriptionURL is probably the webservice method you want, BTW | 12:32 |
| ddstreet | let's use this existing old bug to track adding this https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/645404 | 12:32 |
| ubottu | Launchpad bug 645404 in software-properties (Ubuntu) "Support Private PPAs" [Wishlist,Confirmed] | 12:32 |
| juliank | I increased importance to low, as that's actually causing apt warnings with the auth data in sources.list, so it's more a bug than a feature these days :) | 12:33 |
| ddstreet | juliank cjwatson thnx and i'll make sure to update the bug if i find time to start working on it (and will check first to make sure you haven't already started on it) | 12:36 |
| juliank | ddstreet: I'm adding a comment with the summary of what we discussed | 12:36 |
| ddstreet | awesome | 12:36 |
| cyphermox | morning | 13:27 |
| === ricab|lunch is now known as ricab | ||
| seb128 | SRU team question, if a package got MIR approved and promoted in disco, can it be used for cosmic/bionic SRUs? is there a special process/consideration in that case? (we want to use libnfs to enable the gvfs/nautilus backend) | 14:32 |
| rbasak | seb128: what do you mean be "can it be used" exactly? | 14:46 |
| rbasak | Do you want to promote it in bionic/cosmic? Add it as a dependency of something else? | 14:46 |
| rbasak | AIUI (though this is more AA territory) we can move something to main as an new publication in the updates pocket. | 14:46 |
| rbasak | The rest is SRU exceptional with no policy, but I don't see any fundamental technical problem - as long as it's reasonable from an SRU perspective, which depends on the specifics. | 14:47 |
| rbasak | So many typos. Sorry. | 14:48 |
| seb128 | rbasak, yeah, basically it's bug #1637988 and gvfs is in the queue | 14:48 |
| ubottu | bug 1637988 in gvfs (Ubuntu) "Enable the nfs backend" [Wishlist,Fix released] https://launchpad.net/bugs/1637988 | 14:48 |
| seb128 | but libnfs is still in universe in bionic/cosmic | 14:49 |
| seb128 | so basically it means I also need a no change upload for libnfs to have it promoted? | 14:49 |
| rbasak | I'm not confident enough in the specifics - please check with an AA. | 14:51 |
| rbasak | But yeah, that sounds about right to me. | 14:52 |
| rbasak | I was going to ask if it would be easier to make it a Recommends instead for the SRUs, and keep libnfs in universe for users to opt-in perhaps. But it looks like it's compiled in so perhaps that's non-trivial (even if we did want it). | 14:53 |
| seb128 | rbasak, yeah, it's a lib the backend is using | 14:54 |
| seb128 | we can't make it optional | 14:54 |
| ahasenack | doko: hi, does this ring a bell: | 15:26 |
| ahasenack | x86_64-linux-gnu-gcc: error trying to exec 'go1': execvp: No such file or directory | 15:26 |
| doko | ahasenack: apt install gccgo? | 15:27 |
| ahasenack | I have it | 15:28 |
| ahasenack | it pulled in gccgo-9 | 15:28 |
| ahasenack | a previous build log in lp pulled in gccgo-8 | 15:29 |
| doko | ahh, wait, I made 9 the default for gccgo, so yes, then you have to pull in gccgo-8 explicitly | 15:29 |
| doko | gccgo-9 and golang-1.12 are both 1.12 | 15:30 |
| ahasenack | $ dpkg -L gccgo-8|grep go1 | 15:30 |
| ahasenack | /usr/lib/gcc/x86_64-linux-gnu/8/go1 | 15:30 |
| ahasenack | ok | 15:31 |
| rbasak | Oh, a Recommends would be insufficient, it'd have to be a Suggests, or a reverse Enhances. Anyway, not possible. | 15:31 |
| doko | ahasenack: which package is this? just wondering why gccgo is used explicitly | 15:51 |
| juliank | rbasak: the log for the u-u test case with the error messages has python3-apt 1.4.0~something, which is the stable versuin | 15:55 |
| juliank | um | 15:55 |
| juliank | rbalint: ^ | 15:55 |
| rbalint | juliank, rbasak it is upgrading to snapshot.debian.org/archive/debian/20171210T000000Z sid | 15:58 |
| juliank | don't highlight him just because I accidentally did :) | 15:59 |
| juliank | rbalint: ah ok | 15:59 |
| juliank | rbalint: that explains a lot | 15:59 |
| juliank | :) | 15:59 |
| rbalint | juliank, i'll move to a later snapshot upgrade delta | 15:59 |
| vorlon | jibel: sure thing - thanks for seeing this through! | 16:10 |
| alkisg | Hi, (lib)parted in bionic has a serious issue that corrupts fat file systems (debian #840710). It's been fixed in cosmic+. The newer parted versions only contain bug fixes. | 16:13 |
| alkisg | Should I ask for an SRU just for the one serious issue, or it can be considered a "microrelease" and backported as is, after proper testing of course? | 16:13 |
| ubottu | Debian bug 840710 in parted "parted: Fix recognition of FAT file system after resizing" [Wishlist,Fixed] http://bugs.debian.org/840710 | 16:13 |
| teward | alkisg: I'd ask for an SRU for that specific fix | 16:14 |
| alkisg | Thank you teward | 16:14 |
| teward | since that's a nitpicked upstream commit to solve the issue, SRU team can review it once it's submitted for consideration | 16:14 |
| teward | (this is also how I got the LVM2 resizing fix into Bionic before the last ISO point release) | 16:14 |
| teward | (because gparted coldn't resize LVM2 PVs) | 16:15 |
| alkisg | Gotcha | 16:15 |
| teward | alkisg: but we'll still need an Ubuntu bug touching upon the issue | 16:15 |
| teward | LO | 16:15 |
| teward | :P * | 16:15 |
| cjwatson | Agreed; that patch should be trivially cherry-pickable onto older series. The microrelease path would be inappropriate here. | 16:20 |
| rbalint | juliank, u-u test fails in cosmic, which is really bad, it seems it needs a fix | 16:22 |
| juliank | rbalint: they do? | 16:23 |
| juliank | You mean, the disco one is failing to upgrade cosmic? | 16:24 |
| rbalint | juliank, yes, failing to upgrade systemd when there is a higher version in -updates | 16:25 |
| ahasenack | doko: uwsgi | 16:31 |
| alkisg | Do I need to prepare a debdiff or something, or can the patch file from cosmic be used? https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1820090 | 16:37 |
| ubottu | Launchpad bug 1820090 in parted (Ubuntu) "SRU: fix FAT recognition after resizing" [Undecided,New] | 16:37 |
| teward | alkisg: if you'd like I can prep the debdiff. | 16:59 |
| teward | i'm not busy :p | 16:59 |
| teward | alkisg: this is for Bionic? | 17:00 |
| teward | and is this already 'fixed' in Cosmic+? (wasn't clear on the bug) | 17:00 |
| alkisg | teward: I'd very much appreciate it | 17:03 |
| alkisg | Yes, and yes | 17:03 |
| teward | alkisg: confirm for me, it's *any* FAT system yes? FAT16, FAT32, etc.? | 17:10 |
| teward | s/system/filesystem/ | 17:10 |
| alkisg | teward: I only tested with fat32, but afaik it's for any file system | 17:10 |
| alkisg | *fat | 17:10 |
| bdmurray | Did the output of 'date -u' switch from 24hr to AM/PM or is my desktop crazy? | 17:13 |
| sarnold | o_O | 17:14 |
| teward | alkisg: bug confirmed, i've picked up the bug and assigned it to myself, building a patched version in a PPA now, will test BEFORE I provide the debdiff to sponsors (I don't have coredev or Main upload rights but I'll at least generate the diff and get it to the point for sponsoring ASSUMING everything works as we expect) | 17:14 |
| ahasenack | is there a draft for the disco release notes somewhere? https://wiki.ubuntu.com/DiscoDingo/ReleaseNotes is not created yet | 17:18 |
| vorlon | jibel: No such live filesystem with this owner/distroseries: 'ubuntu-canary'. | 17:20 |
| vorlon | jibel: were you wanting us to set that up? :) | 17:20 |
| jibel | vorlon, Yes please, that was our next request. | 17:36 |
| alkisg | teward: I used "copy packages from primary archive to ubuntu" to copy/recompile the cosmic version for bionic, in my ppa, and I verified that it works. Not the same thing of course, just an indicator. | 17:42 |
| teward | alkisg: right, but part of my 'testing' process for any SRU debdiffs I have is to PPA build-test (right now my local builders are busted :| ) and then use that in a test environment to make sure it works | 17:42 |
| teward | at the MOMENT, apparently, there's some keyserver problems behind the scenes affecting my upload to the PPA at the moment | 17:43 |
| teward | (and they're looking into it) | 17:43 |
| Eickmeyer | Okay, question: Is there any place I can monitor the progress of an ISO build? Our last 8 builds for Ubuntu Studio have failed, but the ISO tracker at iso.qa.ubuntu.com says it's re-building, but I'm not sure if that's the one that I triggered yesterday or not. | 18:03 |
| * Eickmeyer feels like a noob | 18:03 | |
| vorlon | jibel: done and rebuilding | 18:06 |
| vorlon | Eickmeyer: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/disco/ubuntustudio/ | 18:06 |
| Eickmeyer | vorlon: That's what I thought, so that doesn't show any current image buillding. Should I mauallly trigger one? | 18:07 |
| vorlon | Eickmeyer: why? | 18:07 |
| Eickmeyer | vorlon: I think the last build attempt had the version of ubuntustudio-look before I uploaded the fix removing update-grub from the plymouth theme install. | 18:08 |
| vorlon | Eickmeyer: ok - sure, you can manually trigger | 18:09 |
| Eickmeyer | vorlon: Thanks. | 18:09 |
| vorlon | jibel: Subject: LiveFS ubuntu-canary/disco/amd64 failed to build on 20190314 | 18:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!