[00:33] <cyphermox> fossfreedom: did you inspect the filesystem to make sure the appropriate binary was included, if it needs feh or something like that?
[01:10] <mwhudson> Unit193, tsimonq2: thanks!
[01:10] <Unit193> Now I can harass you for uploads!  (Nah, just kidding.)
[01:14] <mwhudson> heh heh
[01:22] <RAOF> niedbalski: Bug 1708305 hasn't had its traditional 7-day aging in xenial-proposed; is there a particular reason to release it early?
[07:24] <fossfreedom> cyphermox, re ubiquity.  Yes budgie-wm is there and the process list indicates budgie-wm --sm-disable is running. For fun, I commented out gnome-settings-daemon & budgie-wm process start code, installed metacity and feh with a hard-coded background_image and the wallpaper was displayed.  Title bar looks odd though.
[07:26] <fossfreedom> I do note there is two gnome-settings-daemon binaries listed in ubiquity-dm that no longer exists with the recent gnome-settings-daemon upload but deleting those two from the array doesnt do anything.  more of a tiny code cleanup in that area
[07:44] <fossfreedom> cyphermox, brain-wave! Ubuntu Budgie has the new per-desktop override for the gsettings background schema so that we don't trample over other desktops overriding that key.  We need now to set the environment variable "XDG_CURRENT_DESKTOP=Budgie".  Would you be ok with a PR for that?
[08:30] <sil2100> @pilot in
[08:34] <tsimonq2> Patch pilot <3
[08:38] <sil2100> tsimonq2: you don't need patch pilots that much anymore though! Just for main packages ;)
[08:46] <tsimonq2> sil2100: I know, I just love the concept ;)
[08:47] <cpaelzer> I like it as a day to have a reason to ignore all else
[08:47] <cpaelzer> and actually focus on creating/reviewing/sponsoring fixes
[08:49] <tsimonq2> cpaelzer: <3
[08:50] <tsimonq2> I liked it as someone without upload access and I'm guessing I wasn't the only one
[11:03] <jbicha> fossfreedom: oh
[11:11] <xnox> cjwatson, thank you for env --chdir. It did occur to me for ages that make -C is amazing, but i never thought of porting it elsewhere.
[11:12] <cjwatson> yeah, been annoying me for a long time now!
[11:13] <jbicha> https://code.launchpad.net/~jbicha/ubiquity/adapt-to-gsd325/+merge/329902
[11:13] <doko> jbicha: libdazzle ftbfs on ppc64el, accepting anyway, new package
[11:13] <tsimonq2> bdmurray: Can I please be approved to ~ubuntu-reviewers? :)
[11:14] <jbicha> doko: thanks
[11:28] <sil2100> @pilot out
[11:28] <sil2100> (lunch time)
[11:46] <rbasak> tsimonq2: around? About bug 1327002. Your uploaded changes file is missing bug references even though the changelog entry has them. Did you use an Ubuntu system to build the changes file? The Ubuntu delta in dpkg-genchanges matters.
[11:47] <tsimonq2> rbasak: Hey :)
[11:47] <tsimonq2> rbasak: That's...weird
[11:47] <rbasak> It's pretty common when people upload SRUs from Debian.
[11:47] <tsimonq2> rbasak: I *am* on a Buster system at the moment
[11:47] <rbasak> (Ubuntu SRUs)
[11:47] <tsimonq2> So yeah
[11:48] <rbasak> tsimonq2: can you fix up? If not I can.
[11:48] <tsimonq2> Sorry, my mistake. I didn't know there was much of a difference and this is the first time I'm using a Buster system for this sort of thing...
[11:48] <tsimonq2> rbasak: How would I go about fixing it?
[11:49] <rbasak> tsimonq2: I'm not sure how to do it on Debian. But you can check before upload: the changes files should have a X-Launchpad-Bugs-Fixed (IIRC, similar at least) line if correct.
[11:49] <rbasak> tsimonq2: on Ubuntu, it happens by magic.
[11:49] <tsimonq2> rbasak: Alright.
[11:50] <tsimonq2> rbasak: So should I upload a new upload with that line in changes, or is it easier to do it on your end?
[11:50] <rbasak> tsimonq2: new upload please. One of us has to do it. You already have the source :-)
[11:50] <tsimonq2> Ok. :)
[11:50] <rbasak> I can fetch it from the reject queue and do it myself if it's awkward for you.
[11:50] <tsimonq2> No, I can try ;)
[11:51] <cjwatson> On Debian you should be able to make it work by setting DEB_VENDOR=ubuntu in the environment when running debuild.
[11:51] <tsimonq2> cjwatson: ack, thanks!
[11:52] <tsimonq2> I run Testing on my laptop (which I use less often but happen to be using today) and Artful on my desktop... weird little quirk you wouldn't expect :)
[11:54] <rbasak> I've been meaning to write a "so you're now an uploader!" page with a list of quirks for a while :-/
[11:55]  * rbasak JFDI
[11:57] <tsimonq2> rbasak: better?
[11:59] <tsimonq2> rbasak: I have a feeling doomsday and any other package that I uploaded to the SRU queue within the past few hours might have the same problem :(
[12:00] <rbasak> tsimonq2: do you mind checking for me please? If you click on the entry in the queue you'll see the changes file. If you can give me a list of uploads I need to reject, that's the easiest way.
[12:03] <tsimonq2> rbasak: libva/xenial libqapt/xenial doomsday/zesty
[12:03] <tsimonq2> rbasak: I've been busy :P
[12:03] <rbasak> OK, I'll reject those, thanks.
[12:03] <rbasak> I've just written an initial revision of https://wiki.ubuntu.com/DeveloperMembershipBoard/NewUploader
[12:04] <rbasak> Not linked to it from anywhere yet.
[12:04] <rbasak> Everyone: feel free to contribute and edit.
[12:04] <rbasak> The DMB could refer successful applicants to this page so they know what to do. I remember that I certainly didn't know how to upload when my application was approved :)
[12:05] <Laney> rbasak: Have you seen https://wiki.ubuntu.com/MOTU/New ?
[12:05] <tsimonq2> rbasak: The only reason I knew how to upload when I got approved is because when working with acheronuk on some Kubuntu stuff, he remote signed some packages and I got to dput ubuntu them from the VPS we were working on :P
[12:06] <tsimonq2> But yeah, I pretty much had to figure out everything on there :)
[12:06] <rbasak> Laney: ah. Thanks!
[12:07] <rbasak> Most of that isn't MOTU specific. We should have a single page and make sure the DMB points successful applicants to it.
[12:08] <tsimonq2> One thing that I had to learn once I got MOTU was how to use the autopkgtest infra from the point of view of someone who has upload permissions to the archive
[12:09] <tsimonq2> In this specific example, nodejs wouldn't migrate because node-something-or-other failed tests, I uploaded a new version fixing it and it didn't automatically retry... turns out my sponsors have always been smart enough to retry that stuff for me :)
[12:10] <sforshee> Unit193: tseliot looks after the nvidia drivers, I don't have upload rights for those packages
[12:13] <acheronuk> tsimonq2: there is: https://wiki.ubuntu.com/UbuntuDevelopment/Uploading
[12:14] <tsimonq2> Oh
[12:14] <tsimonq2> Ok
[12:14] <tsimonq2> Cool
[12:15] <rbasak> And then there were three :-/
[12:17]  * tsimonq2 scratches head:
[12:17] <tsimonq2> E: libqapt source: maintainer-address-causes-mail-loops-or-bounces Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[12:18] <tsimonq2> Hmmm, is that a bug in Lintian or a Won't Fix? O_o
[12:18] <rbasak> Does it do that on Ubuntu also?
[12:19] <rbasak> IIRC, Debian's policy is that maintainer addresses must not be behind a moderation wall.
[12:20] <tsimonq2> I'll check later on my Artful machine
[12:20] <tsimonq2> But there doesn't seem to be a relevant delta so my guess is Yes
[12:20] <rbasak> Perhaps we need to suppress that on Ubuntu as it's acceptable to us.
[12:21] <tsimonq2> Ok
[12:24] <tsimonq2> rbasak: All of those packages should be fixed now with a proper header, fwiw
[12:25] <rbasak> Thanks!
[12:25] <tsimonq2> Thanks for catching that ;)
[12:47] <tsimonq2> Wooo, sponsorship queue down to 34
[12:48] <mitya57> tsimonq2, \o/
[12:49] <tsimonq2> Oh hey mitya57 :D
[12:49] <tsimonq2> (a good chunk of the things in the sponsorship queue just needed triage
[12:49] <tsimonq2> )
[13:11] <sil2100> @pilot in
[13:11] <tsimonq2> o/ sil2100
[13:11] <sil2100> o/
[13:12] <tsimonq2> rbasak: Since it's your SRU day, could I please get this accepted into xenial-proposed? bug 1710993
[13:12] <cyphermox> fossfreedom: that doesn't sound like something that ubiquity should do?
[13:13] <tsimonq2> rbasak: With my Lubuntu Release Manager hat on, I think it's a fairly important update that should be rolled out... what's the process for shortening and/or bypassing the 7 day limit? i.e. do I just justify it to you or do I say something in the bug report?
[13:15] <rbasak> Looking
[13:17] <rbasak> tsimonq2: that's a pretty radical change given what Lubuntu is supposed to be.
[13:18] <rbasak> tsimonq2: I suppose I'd like an ack from the Lubuntu release managers :-P
[13:18] <tsimonq2> rbasak: I also agree that it's a pretty radical change from upstream Firefox
[13:18] <rbasak> tsimonq2: so ultimately I guess you can decide, but would it be worth getting some wider discussion first?
[13:19] <tsimonq2> rbasak: We did have this discussion back in February or March
[13:19] <rbasak> Oh, OK. Did that include stable release changes?
[13:19] <tsimonq2> rbasak: Upstream Firefox isn't going to budge, and we already ship with pulse in 16.10 and on
[13:19] <tsimonq2> Yep
[13:19] <rbasak> As I say I think it's not really for me to say if that's what you all want to do.
[13:20] <rbasak> I just want to make sure that you're sure :-)
[13:20] <tsimonq2> I'm sure :)
 :-)
[13:20] <tsimonq2> We're sure :P
[13:20] <rbasak> OK :)
[13:21] <rbasak> Technically, will this dtrt and pull in pulseaudio in all cases?
[13:22] <rbasak> Is there any case where apt will attempt to remove lubuntu-meta instead?
[13:22] <tsimonq2> Well, I'd also like a merge on my lubuntu.xenial MP :P
[13:22] <rbasak> Link?
[13:22] <tsimonq2> ...why would apt try to remove lubuntu-desktop? :P
[13:22] <tsimonq2> https://code.launchpad.net/~tsimonq2/ubuntu-seeds/add-pulseaudio-to-lubuntu-xenial/+merge/329783
[13:22] <rbasak> Well for example something could conflict with pulseaudio.
[13:23] <tsimonq2> Well like I said, this change is implemented in 16.10 and on
[13:23] <tsimonq2> While I know that's not 100% justification, the seed hasn't changed that much from 16.04 to 16.10
[13:23] <rbasak> Yeah but package disruption is expected during release upgrades.
[13:24] <tsimonq2> Well, it'll just install some new packages.
[13:24] <tsimonq2> I wouldn't describe it as "disruption"
[13:24] <rbasak> I'm not sure (technically) about a seed change after release. I suppose it'll affect only future point releases? I don't know, so I'd like to defer to someone who knows for the MP.
[13:24] <tsimonq2> Ok.
[13:24] <rbasak> If that's all it does, then I agree it's not disruption.
[13:24] <rbasak> The risk is that it doesn't do that for some unknown reason.
[13:24] <tsimonq2> rbasak: We have a daily ISO that runs germinate
[13:24] <tsimonq2> I see
[13:25] <rbasak> One reason might be that if I have lubuntu-desktop and something installed that conflicts with pulseaudio for example.
[13:25] <tsimonq2> ic
[13:25] <rbasak> I don't know if there are other cases that might cause a problem.
[13:25] <rbasak> I'm not saying there is a problem. I'm just trying to explore possibilities to try and discover any problems now rather than later.
[13:25] <tsimonq2> I understand :)
[13:26] <tsimonq2> Worst case scenario, not saying this *will* happen, but lubuntu-desktop gets removed. It's a metapackage, it shouldn't really matter.
[13:26] <rbasak> It impacts a future release upgrade.
[13:26] <tsimonq2> i.e. iirc it *shouldn't* autoremove the deps
[13:26] <tsimonq2> Oh
[13:26] <tsimonq2> Well true
[13:27] <rbasak> This might all be considered acceptable of course.
[13:27] <rbasak> Another thing is that "apt upgrade" may not want to install pulseaudio; only "apt full-upgrade". What will the GUI do?
[13:27] <rbasak> This may not be so bad; it's no worse.
[13:27] <rbasak> Actually kernel upgrades work that way.
[13:27] <rbasak> So it must be fine.
[13:27] <tsimonq2> Good point
[13:36] <tsimonq2> But yeah, we're pretty sure about doing this :)
[13:36] <rbasak> OK
[13:36] <rbasak> +1
[13:36] <rbasak> I'm just writing this up in the bug.
[13:37] <tsimonq2> Ok :)
[13:43] <tsimonq2> rbasak: My thoughts on Firefox not sticking to the ESR releases for stable releases because of the regression potential is another issue, but it could have made this easier to deal with
[13:43] <rbasak> It's difficult. I'm not sure general Ubuntu users want to stick to ESR for the lifetime of Xenial for example.
[13:43] <tsimonq2> (I'm not a Firefox expert (that's... the point with this...) but I think that's how Debian does it)
[13:44] <tsimonq2> No I get it
[13:44] <tsimonq2> But
[13:44] <rbasak> snaps better suit Firefox's model IMHO.
[13:44] <tsimonq2> rbasak: For once irt snaps I agree :P
[13:44] <rbasak> Another way might be to package ESR also (as firefox-esr or something). Then flavours could choose to use that.
[13:45] <tsimonq2> I wouldn't mind doing that
[13:45] <rbasak> But as always there's the question of who would provide the developer time.
[13:45] <tsimonq2> Exactly...
[13:46] <rbasak> I don't think Ubuntu would object to a firefox-esr being maintained in universe.
[13:46] <tsimonq2> But, hindsight is 20/20, some users have complained already that they have to install pulse (to Mozilla) and there will be more... but as Chris said in the changelog entry, if nobody will step up to fix it, it goes unfixed.
[13:46] <tsimonq2> And we have to adapt.
[13:47] <tsimonq2> Unfortunately...
[13:47] <tsimonq2> rbasak: Maybe at the start of b-cycle I'll consider bringing that up to the MOTU list
[13:47] <tsimonq2> But we'll have to see
[13:48] <rbasak> Any reason to delay the discussion? You can talk about B plans now :)
[13:49] <tsimonq2> I don't have a good answer :P
[13:50] <tsimonq2> Sometime between today and B Alpha 1 then :P
[13:50] <rbasak> Does lubuntu-meta autogenerate its dependencies like ubuntu-meta?
[13:50] <tsimonq2> Yep.
[13:50] <tsimonq2> Well, it does the thing with ./update
[13:50] <rbasak> So for this upload you did that manually against your local change to the seed for which the MP is still outstanding?
[13:50] <tsimonq2> Yep, then discarded the config change.
[13:51] <tsimonq2> That's why I think they should land closely timed :P
[13:52] <rbasak> OK. You have my +1 for both the upload and the MP, but I'd like someone who knows more to confirm that this approach is OK please.
[13:52] <tsimonq2> Sure.
[13:53] <tsimonq2> cyphermox: ping :) ^
[13:53] <rbasak> slangasek perhaps? ^ and https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1710993 and https://code.launchpad.net/~tsimonq2/ubuntu-seeds/add-pulseaudio-to-lubuntu-xenial/+merge/329783
[13:54] <tsimonq2> Fair ;)
[14:00] <zyga-ubuntu> hey, any network-manager modem-manager experts around? I updated my xenial x250 to zesty and my modem connection can no longer be established. I see the modem (modem-manager-gui) and network-manager sees the modem but any attempts to connect fail with ""No suitable device found for this connection." -- indeed any attempt to create a new 3G connection shows no devices on the "applicable to this
[14:00] <zyga-ubuntu> device" page
[14:11] <cyphermox> tsimonq2: rbasak: looks sane to me, but you'll want to test what the effect is of adding pulseaudio in general
[14:11] <cyphermox> ie is that going to pull in other things too?
[14:11] <cyphermox> does that work fine with volume controls or is there config to change as well? (I don't think so, but better be safe)
[14:12] <cyphermox> I think it would be best to further flesh out the test cases even if it looks liek a pretty straightforward change
[14:14] <cyphermox> zyga-ubuntu: you should check if your modem is listed by 'mmcli -L', and if not, you should check whether usb-modeswitch and usb-modeswitch-data were updated
[14:17] <sil2100> @pilot out
[14:17]  * sil2100 switches to his SRU hat
[14:19] <zyga-ubuntu> cyphermox: it is listed by mmcli -L
[14:19] <zyga-ubuntu> cyphermox: 	/org/freedesktop/ModemManager1/Modem/0 [Sierra] MBIM [1199:A001]
[14:20] <bjf> jbicha, any guess on when the hidpi scaling issue will get resolved in artful? is there a bug i can track the progress of?
[14:21] <jbicha> bjf: wait for gnome-shell 3.25.90, we're working on it this week
[14:21] <bjf> jbicha, ack, thanks
[14:21] <jbicha> I guess you could subscribe to LP: #1712800
[14:22] <cyphermox> zyga-ubuntu: do you have ofono installed?
[14:23] <cyphermox> I think there was a case where it might be pulled in or remain installed when it really shouldn't
[14:24] <Unit193> sforshee: I did see he uploaded, but for the past several changes you were the one submitting them so figured I'd poke you.
[14:25] <tsimonq2> cyphermox (cc rbasak): ack, I'll spin up a Lubuntu VM and test it out, report back soon
[14:27] <zyga-ubuntu> cyphermox: partially
[14:27] <zyga-ubuntu> libqofono-qt5-0:amd64				install
[14:27] <zyga-ubuntu> qml-module-ofono:amd64				install
[14:27] <zyga-ubuntu> cyphermox: ^ just those two
[14:27] <zyga-ubuntu> should I remove them?
[14:27] <cyphermox> I don't think that would be it
[14:27] <cyphermox> you shouldn't just remove random things if unsure ;)
[14:27] <zyga-ubuntu> ok
[14:27] <zyga-ubuntu> any more hints on what to try?
[14:28] <cyphermox> zyga-ubuntu: sorry, I do not know, the best I can offer is that you delete the connection in NM and re-create it after a reboot
[14:28] <zyga-ubuntu> cyphermox: tried that
[14:28] <cyphermox> ok
[14:28] <zyga-ubuntu> cyphermox: when I create the connection I don't see my modem listed as a choice
[14:28] <zyga-ubuntu> cyphermox: it's a roaming connection, not sure if that's a factor
[14:28] <cyphermox> if the modem is listed in ModemManager (mmcli), but not found in NM, I don't know what to do with that
[14:29] <cyphermox> ah, well you should check if the connection allows roaming
[14:29] <cyphermox> there's a checkbox when you edit it
[14:29] <sforshee> Unit193: I supplied patches yes, however it sounds like there's a patch already and I'm not able to upload that pacakge
[14:34] <Unit193> Somewhat, yes.  No idea how the internal Canonical stuff works though.  Thanks.
[14:35] <zyga-ubuntu> cyphermox: checked that as well, it does
[14:35]  * zyga-ubuntu moves out of range
[14:37] <Unit193> tseliot: Have you seen LP 1711758 by chance?
[14:38] <tseliot> Unit193: not yet, but I'll have a look at it, and I'll fix it. Thanks
[14:38] <Unit193> Thanks a lot!
[14:47] <rbasak> cpaelzer: looking at nut in Xenial unapproved. Is it intentional that it has no bug link?
[14:48] <cpaelzer> cpaelzer: yes and no
[14:48] <cpaelzer> grr
[14:48] <cpaelzer> rbasak: ^^
[14:48] <cpaelzer> rbasak: that is the lack of -v on that build
[14:48] <cpaelzer> on the bug we talked in regard to the importer
[14:49] <rbasak> I see. And the latest version bump is supposed to not have a bug link, right?
[14:49] <cpaelzer> rbasak: the former upload had both buglinks, and the new one is reverting one of them
[14:49] <cpaelzer> so with -v I'd close "both" which would be also wrong
[14:49] <rbasak> Could you re-upload with a -v please? Otherwise I think it'll cause issues in the pending-sru report.
[14:49] <rbasak> Oh.
[14:49] <rbasak> I see.
[14:49] <cpaelzer> rbasak: well I can, but then both which is wrong
[14:49] <cpaelzer> and changing old changelog history isn't good either
[14:49] <cpaelzer> which is why I uploaded the way it is now
[14:50] <rbasak> I think we need a bug link for the bug that is still being fixed. Otherwise pending-sru will be broken.
[14:50] <rbasak> I wonder if we need to hack the changes file to have one bug but not the other.
[14:50] <cpaelzer> rbasak: TL;DR tell me which way we need it for the process to work and I'll do so
[14:51] <rbasak> cpaelzer: unless someone says otherwise, I'd rebuild the source with -us -uc -v..., then modify the changes file manually, then debsign on the changes file. Ugly, but I can't think of anything better.
[14:51] <Unit193> tsimonq2: Also, in regards to your lintian warning.  Yes there isn't delta, but that's because lintian uses profiles.  That specific check is disabled in Ubuntu.
[14:52] <tsimonq2> Unit193: aha
[14:52] <Unit193> Try --profile ubuntu
[14:52] <cpaelzer> rbasak: https://code.launchpad.net/~paelzer/ubuntu/+source/nut/+git/nut/+ref/bug-1540008-1099947-xenial https://code.launchpad.net/~paelzer/ubuntu/+source/nut/+git/nut/+ref/bug-1540008-1099947-trusty
[14:52] <cpaelzer> rbasak: do you want to do that hacking to fix it up or shall I try and you reject from unapproved so I can re-upload?
[14:53] <rbasak> cpaelzer: I'd prefer if you could hack it please, then I can independently check. Less chance of a mistake slipping through - especially because it's a hack.
[14:53] <cpaelzer> rbasak: ok, then reject now and I'll send you something into -unapproved
[14:53] <cpaelzer> rbasak: will ping you then
[15:03] <cpaelzer> rbasak: you rejected the xenial one but the case is the same for xenial and trusty
[15:04] <cpaelzer> rbasak: I have the modified changes file ready
[15:04] <cpaelzer> rbasak: would you reject the nut in trusty as well so we can halde both at once?
[15:05] <rbasak> cpaelzer: sorry, done.
[15:06] <slangasek> rbasak: what part of this approach were you looking for confirmation on?  The mechanics of how to add a package to a seed post-release, or the idea of doing so?
[15:06] <cpaelzer> rbasak: bot nut uploads are in unapproved again, please take a look if you think the +v+changesmod worked the way
[15:11] <rbasak> cpaelzer: will do, thanks!
[15:11] <rbasak> slangasek: mainly the changing of the seed post-release.
[15:11] <rbasak> slangasek: well, both parts of your question I guess.
[15:11] <rbasak> slangasek: I don't know what I don't know, so I'm asking :)
[15:13] <rbasak> slangasek: I don't see what would go wrong with changing both the seed and accepting the upload. But as it's unusual, I'm asking.
[15:14] <rbasak> cpaelzer: https://launchpadlibrarian.net/335184706/nut_2.7.1-1ubuntu1.2_source.changes
[15:15] <rbasak> cpaelzer: that's not quite what I was expecting. But I don't particularly mind 99947 ending up auto-closing. That can easily be fixed.
[15:15] <slangasek> rbasak: yes, we've had to do this sort of thing before, and this is the right mechanism; update-manager will honor new dependencies on upgrade, so if Lubuntu is using that, we're ok
[15:16] <tsimonq2> rbasak: oh hey, another Lubuntu Release Manager who has access approved my MP ;)
[15:17] <cpaelzer> rbasak: I tohught the regex is on LP: #<HERE>
[15:17] <cpaelzer> rbasak: odd
[15:17] <cpaelzer> rbasak: do you want another new changes file?
[15:17] <cpaelzer> rbasak: or do you handle the remaining mistake in that?
[15:24] <zyga> cyphermox: http://paste.ubuntu.com/25432469/
[15:24] <zyga> cyphermox: n-m crashes, I'm trying to fetch sources to see what's going on there
[15:24] <zyga> specifically on sie 30 16:59:44 fyke NetworkManager[1442]: ((nm-manager.c:2863)): assertion '<dropped>' failed sie 30 16:59:44 fyke NetworkManager[1442]: ((devices/nm-device.c:8235)): assertion '<dropped>' failed
[15:27] <tsimonq2> rbasak: Well, he approved it, just didn't actually merge it.
[15:28] <zyga>     g_return_if_fail (nm_device_get_managed (device, FALSE));                                                                                                                                                                       |>
[15:28] <zyga> also on     g_return_val_if_fail (nm_device_get_managed (self, FALSE), FALSE);
[15:29] <zyga> cyphermox: so nmcli gives me this: cdc-wdm0: unmanaged 	gsm (cdc_mbim, cdc_acm), hw
[15:30] <tsimonq2> cyphermox, rbasak: Ok, to report back, it installs 9 additional dependencies with 7,528 KB taken up. It installs correctly and Firefox can now play audio.
[15:30] <tsimonq2> Not too many extra things
[15:30] <tsimonq2> I think it'll be fine.
[15:31] <rbasak> tsimonq2, slangasek, cyphermox: thanks. I'll process this today. Just otp right now.
[15:31] <tsimonq2> Ok
[15:40] <tsimonq2> Sponsorship queue down to 30 \o/
[15:42]  * zyga updates to artful
[15:42] <zyga> mvo: fingers crossed :)
[15:44] <zyga> hmm
[15:44] <zyga> freenode's web irc is pretty neat
[15:44] <zyga> if it only did offline / background I'd never look back
[15:45] <slangasek> tsimonq2: hopefully not as a result of freeze-violating uploads? :)
[15:47] <tsimonq2> slangasek: Nope
[15:47] <tsimonq2> slangasek: Most are triaging things, asking for updates on packages, ~ubuntu-sponsors falsely subscribed, etc.
[15:47] <tsimonq2> slangasek: If anything I've done a lot of SRUs :P
[15:47] <cjwatson> Mm, not convinced most of lgw01 is going to wake back up trivially ...
[15:48] <tsimonq2> slangasek: One thing I want to know is how to get things like the top entry (a Bazaar branch) which I already left a comment on out of the queue :P
[15:49] <slangasek> hmm, good question
[15:51] <andyrock> bdmurray: hey
[15:52] <andyrock> seems like that the pep8 tests were failing before too
[15:52] <andyrock> do you want me to fix them all or just the parts that I edited?
[15:54] <tsimonq2> slangasek: In general I'm wondering how some of these Bazaar branches are getting on here, take that MP against lp:ubuntu-cve-tracker for example, that's on the MOTU page, not the security one, which is inaccurate because the MOTU page should be things the MOTUs can sponsor, no? :)
[15:55] <andyrock> bdmurray: nevermind
[15:55] <andyrock> they're not failing on trunk
[15:56] <slangasek> tsimonq2: I don't have the url in front of me, can you point me the page you're seeing this on/
[15:56] <slangasek> tsimonq2: http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html ?
[15:57] <tsimonq2> slangasek: General overview: http://reqorts.qa.ubuntu.com/reports/sponsoring/ - MOTU page: http://reqorts.qa.ubuntu.com/reports/sponsoring/motu.html - Security page: http://reqorts.qa.ubuntu.com/reports/sponsoring/security.html
[15:57] <nacc> jbicha: do you have a recommendation of who would be appropriate to help review a SRU for vim? specifically related to gvim on unity and segfaults in xenial? it was done via the git workflow and I can review the code content, but I don't know what is considered 'correct' for desktop
[15:58] <slangasek> tsimonq2: ok, completely unclear to me as well; UTSL https://launchpad.net/ubuntu-sponsoring
[16:00] <tsimonq2> Someone needs to indent their CSS ;)
[16:00] <tsimonq2> (not pointing fingers at anyone :P)
[16:01] <nacc> heh
[16:02] <jbicha> nacc: IMO gvim isn't "desktop" so any Ubuntu developer should be fine
[16:02] <nacc> jbicha: well the question in particular is what to do about some desktop-related hook/variable
[16:02] <nacc> jbicha: specifically the last comment from the submitter in https://code.launchpad.net/~jbenden/ubuntu/+source/vim/+git/vim/+merge/329613
[16:02] <jbicha> vim is Foundations
[16:02] <tsimonq2> slangasek: So is ~ubuntu-branches still relevant?
[16:02] <nacc> slangasek: --^ :)
[16:03] <nacc> tsimonq2: we're going to reuse it for git, i think (or something similar, at least). but the bzr branches are generally dead.
[16:03] <tsimonq2> Ok
[16:04] <tsimonq2> I'll whip up an MP working with that...
[16:04] <nacc> tsimonq2: that's my understanding at least. I'd wait to be sure from slangasek :)
[16:04] <slangasek> yeah the remaining ~ubuntu-branches bzr branches are a bucket of fail
[16:05] <tsimonq2> Ok
[16:05] <slangasek> (the fail was left out in the sun too long and melted)
[16:06] <nacc> heh
[16:07] <jbicha> nacc: I left a couple drive-by comments, you can ask in #ubuntu-desktop
[16:07] <nacc> jbicha: thank you
[16:39] <Unit193> zyga-ubuntu: If you like webchat, perhaps check out 'thelounge'
[16:46] <zyga-ubuntu> Unit193: thanks, I'll check that out
[16:47] <Unit193> Can be configured to have scrollback.
[17:16] <tsimonq2> rbasak: Is git ubuntu something I can install yet?
[17:18] <tsimonq2> Mhhh, it would be great to have it as just a regular deb package, I don't like having snapd installed as it hogs my disk space :/
[17:18] <nacc> tsimonq2: it's only a snap
[17:19] <nacc> tsimonq2: making it a deb is not in our plans
[17:19] <nacc> tsimonq2: because we depend on functionality from debs only available in artful (or potentially outside of debs, in the case of somethjing i'm hitting now)
[17:19] <nacc> tsimonq2: and i'm not willing to sign up to backport git, gbp, etc. to older releases :)
[17:20] <tsimonq2> I guess I'm installing from source :P
[17:20] <nacc> tsimonq2: what release are you on?
[17:20] <tsimonq2> Artful :P
[17:20] <nacc> tsimonq2: ok, that should be fine :)
[17:20] <nacc> tsimonq2: and 'installing' from source, is just clone and add repo/bin to PATH
[17:20] <nacc> (for now)
[17:20] <tsimonq2> Fair ok
[17:21] <nacc> as it's a degenerate case currently (only used by developers)
[17:21] <nacc> tsimonq2: if that doesn't work, let me know
[17:21] <tsimonq2> Ok
[17:24] <tsimonq2> nacc: Let's just say that I might be hacking on the packaging guide, if I was, is git ubuntu something production ready enough to put there? ;)
[17:25] <tsimonq2> (probably not, right?)
[17:25] <tsimonq2> I mean, it can always be edited in the future, but I'd like a working packaging guide...
[17:27] <nacc> tsimonq2: we're not yet importing the world, so i'd wait
[17:28] <nacc> tsimonq2: it's on our roadmap for 1.0 to hit that switch
[17:28] <nacc> but we need to coordinate with LP team, etc.
[17:28] <tsimonq2> Ok
[17:28] <nacc> tsimonq2: so yeah, i'd not mention it in the hacking guide (yet). I don't think. But I woudl drop any mention of UDD or bzr :)
[17:28] <tsimonq2> I'm working on that right now ;)
[17:29] <nacc> tsimonq2: nice, can check that off my list then :)
[17:29] <tsimonq2> nacc: That was a major part of my MOTU application, I would have been around and probably had MOTU a year before I did had that thing been up-to-date.
[17:29] <tsimonq2> I know I'm not the only one who is discouraged by that.
[17:30] <tsimonq2> So since the sponsorship queue doesn't hurt my eyes as much, this is my next step ;)
[17:30] <nacc> tsimonq2: nice!
[17:31] <nacc> tsimonq2: yeah, tbh, the tooling is probably stable enough for most people to use it, but the first thing many will try to do is clone some srcpkg which we haven't imported yet and complain (we have a clear error message to request the import). So rather than throw up that roadblock, my plan was to transition the guide at the same time as we hit the switch to import the world (which is going to take a
[17:31] <nacc> while anyways)
[17:32] <tsimonq2> nacc: Ok
[17:32] <tsimonq2> nacc: Do you generally have an ETA on that?
[17:32] <tsimonq2> (i.e. days, weeks, months, years?)
[17:34] <nacc> tsimonq2: heh
[17:35] <tsimonq2> I guess I'm sort of asking because if it's a matter of a month or two, I might not want to pour my heart and soul into that part of it
[17:35] <nacc> tsimonq2: we are hopefully going to have a trello board up soon which has the plan laid out (and public)
[17:35] <tsimonq2> ooooooh ok
[17:35] <nacc> tsimonq2: we're hopefully going to be at alpha in the next month or two, but that's not a hard requirement
[17:35] <tsimonq2> Ok
[17:35] <tsimonq2> Fair
[17:35] <nacc> tsimonq2: major feature wise, we're mostly done. but we have a bunch of refactoring going on now and a huge testing spike that rbasak is working on
[17:36] <tsimonq2> nacc: Ok.
[17:37] <tsimonq2> nacc: Btw, I've been meaning to ask... how will that deal with packages that are already imported in Git?
[17:37] <tsimonq2> nacc: i.e. the Kubuntu packages use a totally separate Git workflow
[17:37] <nacc> tsimonq2: i'll make sure to loop you in when we get all that documented out (our plan is to sit down and do that by eow next week, but again, no guarantees :)
[17:37] <tsimonq2> Will git merge be expected or how will that work?
[17:37] <tsimonq2> nacc: Ok :)
[17:37] <nacc> tsimonq2: the importer doesn't really care (currently)
[17:38] <tsimonq2> Alright
[17:38] <nacc> tsimonq2: we have discussed telling the importer about some upstream sources of information (where upstream is up to the developer)
[17:38] <tsimonq2> Ok
[17:38] <nacc> tsimonq2: the distinction is that the importer only trusts launchpad publishing data
[17:38] <nacc> tsimonq2: and we want it to always be 'correct' relative to the archive
[17:38] <tsimonq2> I see
[17:38] <tsimonq2> Publishing data in respect to what?
[17:39] <nacc> e.g.: https://launchpad.net/ubuntu/+source/freeradius/+publishinghistory
[17:39] <nacc> what was published when, and to where and with what contents
[17:39] <nacc> basically, the git import is a git view of that page for every srcpkg
[17:39] <tsimonq2> oic
[17:40] <tsimonq2> nacc: Let's say someone really really hates Git and doesn't want to do their changes in Git, it'll automatically import the changes, right?
[17:40] <nacc> the other issue we'll run into with adding 'other' sources (if we do it automatically) is that we have to translate version strings correctly (as each git project could do versioning however they want, with namespaces etc.)
[17:40] <nacc> tsimonq2: yep
[17:40] <nacc> tsimonq2: as long as they are published
[17:40] <tsimonq2> And what if there's (unfortunately) build conflicts?
[17:40] <nacc> tsimonq2: build where?
[17:40] <tsimonq2> s/build/merge/
[17:40] <nacc> tsimonq2: algorithmically, there won't be :)
[17:41] <tsimonq2> Oh, so you'll have an algorithm that'll sort all that out (or try to)?
[17:41] <nacc> http://www.justgohome.co.uk/blog/2017/08/more-on-the-imported-repositories.html
[17:41] <nacc> i think talks about it a bit
[17:41] <nacc> i'm not sure it goes into the detail of how we do parenting yet
[17:42] <tsimonq2> Ohhhhhhh I get it
[17:42] <nacc> but a future post will, i think :)
[17:42] <tsimonq2> So work in Git will be done in $release-devel
[17:42] <nacc> tsimonq2: we're trying to avoid being too clever, as that's what broke UDD (aiui)
[17:42] <tsimonq2> And then archive copies will be in the pockets
[17:42] <nacc> tsimonq2: yeah
[17:42] <tsimonq2> ic
[17:42] <nacc> and developer input is provided by these upload tags
[17:42] <tsimonq2> nacc: SRUs?
[17:42] <nacc> which is just rich history
[17:42] <nacc> tsimonq2: there's a devel branch for all active releases
[17:42] <tsimonq2> How will SRUs and security updates work then?
[17:43] <tsimonq2> nacc: Ok
[17:43] <nacc> tsimonq2: in generaly, you start off $release-devel, make some changes, `git ubuntu submit` them for review (in LP) and then a sponsor/reviewer agrees and uploads
[17:43] <nacc> tsimonq2: in the case that you can upload, we are working on refining that
[17:43] <tsimonq2> Ah ok
[17:43] <nacc> so that your MP gets integrated into the history of the import
[17:44] <nacc> we have an idea of how to do it, just need to implement it and make sure it does what we want :)
[17:44] <tsimonq2> I see :)
[17:44] <nacc> tsimonq2: for now, you can always still just dput
[17:44] <nacc> tsimonq2: the importer will just carry on importing what has been dputted
[17:44] <tsimonq2> nacc: So I really like Git's hard reset, can I do something like that with the Git repo and will it be smart and correct the changelog for me? That would be awesome :P
[17:45] <tsimonq2> I can see another case where that function would be use
[17:45] <tsimonq2> *used
[17:45] <tsimonq2> Someone forgets an epoch in a Debian merge or something
[17:45] <tsimonq2> Would it be smart and bump the changelog or just flat out reject it?
[17:45] <tsimonq2> nacc: I plan on using dput still, yeah ;)
[17:45] <nacc> so, in principle, `git ubuntu` is only used to get the source code. Once you have it, you can do any git-ish thing with it. We are providing some helpers for ubuntu-merges.
[17:46] <nacc> (only = currently)
[17:46] <nacc> git-ubuntu itself doesn't know about dput (yet)
[17:46] <nacc> so it relies on the archive to still reject bad uploads
[17:46] <nacc> we have a linter, that tries its best (but is a WIP)
[17:46] <tsimonq2> Ok
[17:46] <nacc> we are trying to avoid too much auto-correction
[17:47] <nacc> as it tends to be hard to get right, and complicated :)
[17:47] <nacc> (at least for 1.0)
[17:47] <tsimonq2> I see
[17:47] <nacc> we want to get the tool out there and usable by most first, then we can improve the UX, add new workflows, etc.
[17:47] <tsimonq2> Makes sense
[17:47] <tsimonq2> nacc: Well thanks for letting me pick your brain on it :)
[17:48] <tsimonq2> I hope this works out :D
[17:48] <nacc> tsimonq2: thanks -- we did have a studio person do a merge with it, and it worked ok, that was the first real usage outside of the server team
[17:48] <nacc> tsimonq2: but if there are packages you'd like us to import, so you can play around, just let me know
[17:49] <tsimonq2> Ok :)
[18:27] <Unit193> nacc: Waaaait, git-ubuntu isn't going to be packaged?  Is this the expected workflow or optional "You can do this"?
[18:27] <Unit193> Can one just use gbp with it?
[18:29] <Unit193> Sounds optional, hrm.  Also sounds like the majority of it will be server side, so I can just ignore it and gbp instead.
[18:40] <nacc> Unit193: it's not trivial to package it in a way that makes sense -- we are dependent on new upstream functionality from, e.g., gbp itself
[18:40] <nacc> Unit193: afaict, without owning backporting (and thus maintaining) all the deps we need, it's not possible to pacakge it for older releases
[18:40] <nacc> Unit193: if one can use gbp with an arbitrary git repository, then use, one can use gbp with our repository :)
[18:41] <nacc> Unit193: tbh, i've not used gbp, so I don't know what the value-add is (yet)
[18:41] <Unit193> Is it in the standard format of upstream/master/pristine-tar? (Where master = upstream+debian)
[18:41] <Unit193> gbp is pretty handy stuff, fwiw.
[18:41] <nacc> Unit193: we don't track upstream directly
[18:41] <Unit193> Specifically gbp dch -a is nice.
[18:42] <nacc> Unit193: we don't have a master branch
[18:42] <nacc> Unit193: and we have per-distro pristine-tar branches (as debian and ubuntu can differ on tarball contents)
[18:42] <Unit193> Sounds...Fun.
[18:43] <nacc> Unit193: in principle, yes, you should be able to use gbp -- it probably needs flags and/or a conf file
[18:47] <Unit193> nacc: I guess time will tell, thanks for elaborating at least.
[18:49] <nacc> Unit193: so there are probably two sides to this, which is part of the confusion
[18:49] <nacc> Unit193: the importer and the developer tools are in the same code
[18:49] <nacc> Unit193: the importer is what you referred to earlier as server-side
[18:49] <nacc> Unit193: our 'master' is 'ubuntu/devel' (we could make an actual master, we just intentionally did not yet)
[18:50] <nacc> Unit193: so for developer side, i think it would be pretty easy (IME gbp has flags for everything :)
[18:52] <Unit193> Hmm, wondering how imports would work.  Not really messed with single branch git repos, that don't only have debian/ that is.
[18:52] <nacc> Unit193: see the above blog post -- and future ones that will explain more how the importer algorithm works
[18:52] <nacc> and/or the source :)
[18:53] <nacc> imports are imports of Launchpad publishing information (with potentially additional rich history provided by developers)
[18:53] <Unit193> Right, was just thinking about without 'git ubuntu'.
[18:54] <nacc> so, e.g, in thinking about tsimonq2's question earlier -- if a developer was to provide the hash of a commit from the kde repo as the upload tag to the importer (process to be clarified/explained later), then the entire history of that commit will get integrated into the import history at that point
[18:54] <nacc> Unit193: yeah, good luck :)
[18:54] <nacc> Unit193: dgit is the only other importer-like model I'm aware of
[18:54] <nacc> Unit193: and we do pretty similar things (intentionally)
[18:54] <Unit193> So, ignore and use dput for new upstreams, this for other changes. :D
[18:55] <nacc> Unit193: new upstream versions you mean (where upstream is unrelated to debian/) ?
[18:56] <Unit193> nacc: Right, new tarball, eg 2.3 → 2.4
[18:56] <nacc> Unit193: yeah, effectively, we need to provide tooling to wrap that particular workflow (uupdate/uscan) in a clean way -- there is i believe a bug for that already
[18:57] <Unit193> nacc: As I said, I should just wait and see how you guys do it (well, how you provide ways to do it rather), hopefully will be quite nice. :)
[18:58] <nacc> yeah, I've done upstream updates for php7.0 in the tooling, just by hand. Then the importer handles the pristine-tar'ing of it all (as it gets the orig tarball from the archive)
[18:58] <nacc> Unit193: agreed, wait and see :)
[18:59] <Unit193> Huh, OK.
[18:59] <nacc> Unit193: we have a slightly different model than UDD did, I think. We don't want developers messing with the branches
[19:00] <nacc> Unit193: it's too easy to get wrong, parenting, etc.
[19:00] <nacc> Unit193: so instead, you just give us the upload itself, we figure out where it goes into the imported history
[19:01] <nacc> Unit193: and that includes, for new upstreams, the pristine-tar branches themselves
[19:03] <Unit193> In regards to upstream, not...Oh I'll just go look for a repo...
[19:03] <nacc> Unit193: :)
[19:03] <nacc> hopefuly I didn't make it more confusing
[19:07] <Unit193> That's a lot of branches and tags..
[19:09] <nacc> Unit193: yep :)
[19:10] <Unit193> nacc: So I make some changes, commit them, push them to the repo.  Did I just do an upload?
[19:10] <nacc> Unit193: nope :)
[19:10] <Unit193> \o/
[19:10] <nacc> Unit193: that's the bit that's currently disconnected
[19:11] <nacc> Unit193: current: use `git ubuntu submit` to create a MP
[19:11] <nacc> Unit193: that will get reviewed by one of us that can do upload tagging and we will sponsor it (if appropriate)
[19:11] <Unit193> Well, staging things is nice too though.  Pushing a tag might be a nice way to indicate it should be an upload (though there's a lot of tags.)
[19:11] <Unit193> Hrm, so that's the part that's a bit disconnected, I see.
[19:11] <nacc> Unit193: short-term future: MPs that are in the approved state (thus dependent on approving teams) will get upload-tagged automatically by the importer
[19:12] <nacc> Unit193: long-term future: `git ubuntu push` replaces `dput`
[19:12] <Unit193> Right, I'm still thinking of when someone doesn't have 'git ubuntu'
[19:12] <nacc> Unit193: right, if they don't have git ubuntu, nothing changes for them
[19:12] <nacc> for now
[19:13] <nacc> Unit193: the importer proceeds regardless of how the upload occurred
[19:13] <nacc> Unit193: the only differnce between the above and doing a normal dput is the rich history
[19:14] <Unit193> Indeed.  I like git managed packaging (clearly: https://git.launchpad.net/~xubuntu-dev/+git/xfdashboard), just figuring out how without git-ubuntu.  Again, thanks for discussing it, I can tell you're excited about it. :)
[19:15] <nacc> Yeah, I'm not sure how I'd do packaging without git anymore (I can do it by hand, I just tend to make more mistakes that way)
[19:15] <nacc> in general, one should be able to do `git ubuntu clone <srcpkg>` and then do whatever they want with git
[19:15] <nacc> everything after that point is workflow(s)
[19:34] <nacc> Unit193: tsimonq2: thank you both for the discussions. It helps me clarify to myself assumptions we are making.
[19:35] <Unit193> Eg, "grumpy people not installing snaps".  Sure thing!  Thanks for listening.
[20:51] <nacc> Unit193: :) I get it. For us, right now, snaps make a ton of sense for getting someone to go from nothing to a fully configured development environment
[21:02] <rbasak> Unit193, tsimonq2: I think you're both thinking of this from a perspective of using git to maintain packaging for a particular package. You can already do that without our work like some flavor teams do already for example.
[21:03] <nacc> rbasak: a good point
[21:03] <rbasak> Just use gbp, etc.
[21:03] <rbasak> But this of course clashes when someone outside a team uploads to Ubuntu without also pushing to git.
[21:03] <rbasak> Same as a Debian NMU.
[21:04] <rbasak> What we're achieving with our work is presenting a git view of the archive regardless of whether uploaders pushed to Ubuntu's git repos or not.
[21:04] <rbasak> For example most uploads will some as syncs from Debian.
[21:05] <nacc> rbasak: you're explaining it better than me :)
[21:05] <rbasak> Then you have a choice. You can base further work on our general git view, or continue using your specific git repositories with your own layout and branching and tagging scheme
[21:06] <rbasak> You cannot push to our git views directly. Only the importer can do that. This ensures that the git view accurately reflects uploads that actually happened.
[21:07] <rbasak> If you wish, you can provide (work in progress - manually done by us currently) the importer with your commits before you perform an upload. When the importer imports your upload from Launchpad, if it agrees that your commits match what it sees in the archive, then it'll adopt those commits as history in the appropriate branch.
[21:09] <rbasak> If you don't provide the commits, then the importer will import anyway - but it'll be as if all your commits have been squashed together. The importer will only present one commit per upload in that case. But that's still very useful.
[21:25] <Unit193> rbasak: To some extent, except a nmu is supposed to be minimal and generally discouraged, whereas Ubuntu is more like a QA upload.  So one can maintain it in git, but certainly not ideal.  And is it really like a view?  In that case, I'd expect not to interact with it, and it'd not be a replacement for the old bzr interface (which is what I thought the goal was.)
[21:25] <Unit193> And, somewhat useful as one commit, it's like the diffs now.
[21:25] <rbasak> It's a view if you don't interact with it.
[21:25] <Unit193> And I see, it's really not meant to be a replacement for the old bzr interface.
[21:25] <rbasak> If you do provide rich history, it'll adopt that history and be more than a view.
[21:26] <nacc> Unit193: what was the old bzr interface that you refer to? UDD?
[21:26] <rbasak> But it'll still be authoritative in that developers can trust that it represents the archive exactly. The archive remains the single source of truth, as uploaded, rather than what a developer pushed to git.
[21:27] <rbasak> One day, we could switch over the single source of truth to git. But we'd need to collectively agree to do that, and dput would have to become secondary for everyone.
[21:27] <rbasak> If this switchover were to happen, then at that point developers would be able to push directly, and the importer would no longer be needed.
[21:29] <Unit193> Sounds less useful how you explain it, more like a version of sources.debian.net with diffs too.
[21:29] <rbasak> What do you want instead?
[21:30] <Unit193> No, just going on what it is.
[21:31] <rbasak> I mean: you're saying it's less useful; what's the more useful thing you were expecting?
[21:32] <Unit193> Something part way between dgit (which I've never used), and the older bzr interface.
[21:32] <Unit193> nacc: I'm not entirely sure the name, could be.
[21:32] <Unit193> nacc: udd to me is https://udd.debian.org though.:P
[21:32] <rbasak> Can you be more specific?
[21:37] <nacc> Unit193: heh
[21:37] <Unit193> I mean, I don't think there's reason for me to be?  TBH.  Was just thinking the idea was to create another way to upload, like dgit, with pull requests and the like, not a way to view sources and how it changes over time.  I just misunderstood the goal, it seems.
[21:37] <nacc> Unit193: jumping from A to C isn't possible :)
[21:37] <Unit193> OK...
[21:37] <nacc> Unit193: we are going A -> B -> C (I think what you describe is what both rbasak and I described, as a future possibility)
[21:38] <nacc> Unit193: it won't be 'another way', though, it would have to be "the" way. Because otherwise you get inconsistencies and there isn't a single 'source of truth' to rely on
[21:38] <Unit193> nacc: Now, don't misunderstand me.  Viewing certainly has advantages, not having to `pull-lp-source` just to look at a patch will be nice.  Right, and that doesn't sound ideal.
[21:39] <rbasak> It would be trivial to have a git push -> dput wrapper. Though it would need Launchpad to be changed to trust a git signed commit, etc.
[21:39] <rbasak> But that wrapper might as well be in the client.
[21:39] <rbasak> You can do that pretty trivially today.
[21:40] <rbasak> So you can do that if you want. But it's entirely a client thing. And it doesn't solve the use cases we're trying to fix.
[21:40] <Unit193> (I keep saying dgit as I know *somehow* it interacts with uploads, not in the standard way.  That being said, I have never used that, I only do git/svn/bzr packaging then either request sponsorship or dput and tag.)
[21:41] <Unit193> rbasak: Exactly, you're seeing what I'm talking about as a request.  While I think certain things would be nice, I'm just figuring it out (and it's already taken up enough time, I'd think. :/ )
[21:42] <rbasak> Sure, it's tricky to figure out. We've spent months thinking about this area.
[21:42] <Unit193> Well, perhaps a little less "what it is", and more "what it is and how would I work with it"
[21:42] <rbasak> I'm confident that if you agree with our use cases, then you won't come to any other solution.
[21:43] <rbasak> But feel free to prove me wrong :)
[21:43] <tsimonq2> Side note, am I the only one who thinks it's a bit ironic to, when this gets rolled out for wide usage, have to install a Snap to develop a deb package? :P
[21:43] <tsimonq2> C'mon, I'll happily help maintain the deb package :P
[21:43] <rbasak> You'd have to maintain it in backports.
[21:43] <rbasak> I have no objection if you want to take that on.
[21:43] <Unit193> rbasak: TBH, I think having a specific branch that LP/etc basically monitor, but you can have changes staged and it'd only treat as an upload when you have a signed tag would be amazing.  But that's something else.
[21:44] <rbasak> Yeah - what we're doing is orthogonal to that.
[21:45] <Unit193> (This seems like a bit of extra work as it is.  "Stage your changes in git, push, make a pull request, then upload, and the importer will accept your PR when it sees the upload and merge.")
[21:45] <rbasak> The wrapper will deal with all that in the end.
[21:45] <rbasak> "Here's a commit; make it be my upload. Go."
[21:46] <Unit193> rbasak, nacc: I don't mean to bash what you're doing, as stated having something like sources.debian.net is nice.
[21:46] <tsimonq2> Oh I didn't even think of that
[21:46] <tsimonq2> sources.debian.net but with Git
[21:46] <rbasak> Once we're there, we could look into turning signed git tags into uploads automatically.
[21:46] <tsimonq2> That would be *nice*
[21:47] <rbasak> tsimonq2: we're pretty much there now; only it's not searchable and isn't live for all packages yet.
[21:47] <rbasak> https://code.launchpad.net/~usd-import-team/+git
[21:47] <Unit193> tsimonq2: "more like a version of sources.debian.net with diffs too." is what I said earlier.
[21:47] <tsimonq2> Unit193: then the credit goes to you :P :D
[21:47] <tsimonq2> rbasak: oooooh
[21:47] <Unit193> Not looking for credit, just how I'd explain it.
[21:48] <tsimonq2> Unit193: however you want to say it :)
[21:48] <tsimonq2> But we're on the same page
[21:48] <tsimonq2> rbasak: Oh, here's a use case for ya... NEW packages
[21:48] <Unit193> (They're different things.)  Now stupid question: Rather than filing a bug, will this enable me to make a PR to upload?
[21:49] <tsimonq2> Can I have a package have the initial upload with this, rbasak?
[21:49] <tsimonq2> Or only existing packages?
[21:49] <Unit193> tsimonq2: Perhaps we should wait until it's fully baked, then just take a look. :)
[21:49] <tsimonq2> "existing" meaning "in the archive"
[21:49] <Unit193> Speaking of, I still have something stuck in NEW. :/
[21:49] <rbasak> Unit193: I appreciate the conversation now. Happy to influence our plans based on developer opinion!
[21:50] <rbasak> tsimonq2: I'm not sure I follow your question
[21:50] <tsimonq2> Unit193: That's fair, just giving a brain dump as to my thoughts :)
[21:50] <rbasak> tsimonq2: new packages will end up imported once accepted.
[21:50] <tsimonq2> rbasak: Ok, is there any way to have the Git repo created *before* it's accepted and have *that* do the initial upload?
[21:50] <tsimonq2> rbasak: Or do they have to already be accepted in the archive?
[21:51] <tsimonq2> Sure it may be an edge case but I can see it
[21:51] <rbasak> Uploads must go through dput as usual.
[21:51] <tsimonq2> Oh, ok.
[21:51] <rbasak> However, if you want the importer to pick up your existing git tree as history, it can do that.
[21:51] <rbasak> There's also "git ubuntu queue" which can be used for NEW and Unapproved queue reviews.
[21:51] <rbasak> So archive admins and SRU team members (or anyone) can get a preview of something before it's accepted.
[21:52] <rbasak> I use this to diff proposed SRUs against different things, which is really handy.
[21:52] <rbasak> If it helps, we aren't yet doing anything to Launchpad or any other infrastructure.
[21:53] <tsimonq2> Ah ok
[21:53] <rbasak> The importer is a separate tool that has no special privilege over any normal user.
[21:53] <rbasak> The one thing we have in the immediate roadmap is to make lp:ubuntu/<package> be aliased to the importer's repositories, rather than any other team's repositories.
[21:53] <rbasak> That's the only privilege we intend to give to this project in the short term.
[21:56] <tsimonq2> Side note... Creative Commons Attribution 4.0 International License looks to be DFSG-compatible, I'm just wondering what the best way to put it in debian/copyright would be...
[21:58] <tsimonq2> Ah ok, found an example...
[22:13] <Unit193> rbasak: Regarding backports, there's really nobody manning that now so even if one does do backports, you won't get anywhere.
[22:24] <Unit193> rbasak, nacc: FWIW, I think I may have also sounded more harsh than I was.  If so, sorry about that.
[22:26] <nacc> Unit193: no offense taken here. With (currently) two of us working on it, there's just only so much scope we can really commit to at a time. I think we all agree, at a first pass, having the history/src of every src package in git is a good start. That's our primary 1.0 goal.
[22:27] <Unit193> I'm not going to disagree with you there!  And cgit is fast enough that it wouldn't be faster to just grab the source.
[22:30] <nacc> Unit193: i think for teams that already use git (or individual developers) then there is a lot of work to be done just to understand workflows. Tbh, I don't think it's in my interest to try and replace every tool out there. So if gbp is your friend, use it til the end of time. I want to provide a easier path for people that aren't experienced developers to get fixes to Ubuntu.
[22:30] <nacc> *experienced Ubuntu developers (specifically packaging)
[22:31] <Unit193> I'm not sure if I count as "experienced", but yeah gbp floats my boat pretty well.  I just don't use it in Ubuntu too much due to the free-for-all nature of the archive.  I understand your point, though.  Makes sense (Still think PRs would be nicer than bugs.)
[22:32] <Unit193> (It's what I use in Debian, but Debian != Ubuntu.)
[22:34] <nacc> Unit193: and to be clear, yes, at some point, PRs (well, MPs, as it's Launchpad) will be (are already for our team, e.g.) a way to request sponsorship and uploading
[22:34] <Unit193> \o/
[22:34] <Unit193> MP == bzr. :P
[22:34] <Unit193> nacc: I should really stop bugging you though.
[22:37] <nacc> Unit193: yeah, it's overloaded in LP
[22:39] <mwhudson> Laney: the artful autopkgtest base images still seem to have python3.5 installed even though it's been removed from artful
[22:39] <mwhudson> Laney: how does that get fixed, do you move to a new base image at some point?
[23:22] <mwhudson> Laney: nm :)