/srv/irclogs.ubuntu.com/2017/08/30/#ubuntu-devel.txt

cyphermoxfossfreedom: did you inspect the filesystem to make sure the appropriate binary was included, if it needs feh or something like that?00:33
mwhudsonUnit193, tsimonq2: thanks!01:10
Unit193Now I can harass you for uploads!  (Nah, just kidding.)01:10
mwhudsonheh heh01:14
RAOFniedbalski: Bug 1708305 hasn't had its traditional 7-day aging in xenial-proposed; is there a particular reason to release it early?01:22
ubottubug 1708305 in Ubuntu Cloud Archive ocata "Realtime feature mlockall: Cannot allocate memory" [Medium,In progress] https://launchpad.net/bugs/170830501:22
=== JanC is now known as Guest61806
=== JanC_ is now known as JanC
fossfreedomcyphermox, 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:24
fossfreedomI 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 area07:26
fossfreedomcyphermox, 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?07:44
=== maclin1 is now known as maclin
sil2100@pilot in08:30
=== udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: sil2100
tsimonq2Patch pilot <308:34
sil2100tsimonq2: you don't need patch pilots that much anymore though! Just for main packages ;)08:38
tsimonq2sil2100: I know, I just love the concept ;)08:46
cpaelzerI like it as a day to have a reason to ignore all else08:47
cpaelzerand actually focus on creating/reviewing/sponsoring fixes08:47
tsimonq2cpaelzer: <308:49
tsimonq2I liked it as someone without upload access and I'm guessing I wasn't the only one08:50
=== led2 is now known as led1
jbichafossfreedom: oh11:03
xnoxcjwatson, 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:11
cjwatsonyeah, been annoying me for a long time now!11:12
jbichahttps://code.launchpad.net/~jbicha/ubiquity/adapt-to-gsd325/+merge/32990211:13
dokojbicha: libdazzle ftbfs on ppc64el, accepting anyway, new package11:13
tsimonq2bdmurray: Can I please be approved to ~ubuntu-reviewers? :)11:13
jbichadoko: thanks11:14
sil2100@pilot out11:28
=== udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
sil2100(lunch time)11:28
rbasaktsimonq2: 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:46
ubottubug 1327002 in gthumb (Ubuntu Trusty) "Mint 17/Ubuntu 14.04 - can only launch one instance of gthumb" [Low,Triaged] https://launchpad.net/bugs/132700211:46
tsimonq2rbasak: Hey :)11:47
tsimonq2rbasak: That's...weird11:47
rbasakIt's pretty common when people upload SRUs from Debian.11:47
tsimonq2rbasak: I *am* on a Buster system at the moment11:47
rbasak(Ubuntu SRUs)11:47
tsimonq2So yeah11:47
rbasaktsimonq2: can you fix up? If not I can.11:48
tsimonq2Sorry, 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
tsimonq2rbasak: How would I go about fixing it?11:48
rbasaktsimonq2: 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
rbasaktsimonq2: on Ubuntu, it happens by magic.11:49
tsimonq2rbasak: Alright.11:49
tsimonq2rbasak: So should I upload a new upload with that line in changes, or is it easier to do it on your end?11:50
rbasaktsimonq2: new upload please. One of us has to do it. You already have the source :-)11:50
tsimonq2Ok. :)11:50
rbasakI can fetch it from the reject queue and do it myself if it's awkward for you.11:50
tsimonq2No, I can try ;)11:50
cjwatsonOn Debian you should be able to make it work by setting DEB_VENDOR=ubuntu in the environment when running debuild.11:51
tsimonq2cjwatson: ack, thanks!11:51
tsimonq2I 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:52
rbasakI've been meaning to write a "so you're now an uploader!" page with a list of quirks for a while :-/11:54
* rbasak JFDI11:55
tsimonq2rbasak: better?11:57
tsimonq2rbasak: 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 :(11:59
rbasaktsimonq2: 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:00
tsimonq2rbasak: libva/xenial libqapt/xenial doomsday/zesty12:03
tsimonq2rbasak: I've been busy :P12:03
rbasakOK, I'll reject those, thanks.12:03
rbasakI've just written an initial revision of https://wiki.ubuntu.com/DeveloperMembershipBoard/NewUploader12:03
rbasakNot linked to it from anywhere yet.12:04
rbasakEveryone: feel free to contribute and edit.12:04
rbasakThe 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:04
Laneyrbasak: Have you seen https://wiki.ubuntu.com/MOTU/New ?12:05
tsimonq2rbasak: 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 :P12:05
tsimonq2But yeah, I pretty much had to figure out everything on there :)12:06
rbasakLaney: ah. Thanks!12:06
rbasakMost of that isn't MOTU specific. We should have a single page and make sure the DMB points successful applicants to it.12:07
tsimonq2One 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 archive12:08
tsimonq2In 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:09
sforsheeUnit193: tseliot looks after the nvidia drivers, I don't have upload rights for those packages12:10
acheronuktsimonq2: there is: https://wiki.ubuntu.com/UbuntuDevelopment/Uploading12:13
tsimonq2Oh12:14
tsimonq2Ok12:14
tsimonq2Cool12:14
rbasakAnd then there were three :-/12:15
* tsimonq2 scratches head:12:17
tsimonq2E: libqapt source: maintainer-address-causes-mail-loops-or-bounces Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>12:17
tsimonq2Hmmm, is that a bug in Lintian or a Won't Fix? O_o12:18
rbasakDoes it do that on Ubuntu also?12:18
rbasakIIRC, Debian's policy is that maintainer addresses must not be behind a moderation wall.12:19
tsimonq2I'll check later on my Artful machine12:20
tsimonq2But there doesn't seem to be a relevant delta so my guess is Yes12:20
rbasakPerhaps we need to suppress that on Ubuntu as it's acceptable to us.12:20
tsimonq2Ok12:21
tsimonq2rbasak: All of those packages should be fixed now with a proper header, fwiw12:24
rbasakThanks!12:25
tsimonq2Thanks for catching that ;)12:25
tsimonq2Wooo, sponsorship queue down to 3412:47
mitya57tsimonq2, \o/12:48
tsimonq2Oh hey mitya57 :D12:49
tsimonq2(a good chunk of the things in the sponsorship queue just needed triage12:49
tsimonq2)12:49
sil2100@pilot in13:11
=== udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: sil2100
tsimonq2o/ sil210013:11
sil2100o/13:11
tsimonq2rbasak: Since it's your SRU day, could I please get this accepted into xenial-proposed? bug 171099313:12
ubottubug 1710993 in lubuntu-meta (Ubuntu Xenial) "PulseAudio requirement breaks Firefox on ALSA-only systems after 55.0.1 update" [Critical,In progress] https://launchpad.net/bugs/171099313:12
cyphermoxfossfreedom: that doesn't sound like something that ubiquity should do?13:12
tsimonq2rbasak: 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:13
rbasakLooking13:15
rbasaktsimonq2: that's a pretty radical change given what Lubuntu is supposed to be.13:17
rbasaktsimonq2: I suppose I'd like an ack from the Lubuntu release managers :-P13:18
tsimonq2rbasak: I also agree that it's a pretty radical change from upstream Firefox13:18
rbasaktsimonq2: so ultimately I guess you can decide, but would it be worth getting some wider discussion first?13:18
tsimonq2rbasak: We did have this discussion back in February or March13:19
rbasakOh, OK. Did that include stable release changes?13:19
tsimonq2rbasak: Upstream Firefox isn't going to budge, and we already ship with pulse in 16.10 and on13:19
tsimonq2Yep13:19
rbasakAs I say I think it's not really for me to say if that's what you all want to do.13:19
rbasakI just want to make sure that you're sure :-)13:20
tsimonq2I'm sure :)13:20
rbasak<plural>you</plural> :-)13:20
tsimonq2We're sure :P13:20
rbasakOK :)13:20
rbasakTechnically, will this dtrt and pull in pulseaudio in all cases?13:21
rbasakIs there any case where apt will attempt to remove lubuntu-meta instead?13:22
tsimonq2Well, I'd also like a merge on my lubuntu.xenial MP :P13:22
rbasakLink?13:22
tsimonq2...why would apt try to remove lubuntu-desktop? :P13:22
tsimonq2https://code.launchpad.net/~tsimonq2/ubuntu-seeds/add-pulseaudio-to-lubuntu-xenial/+merge/32978313:22
rbasakWell for example something could conflict with pulseaudio.13:22
tsimonq2Well like I said, this change is implemented in 16.10 and on13:23
tsimonq2While I know that's not 100% justification, the seed hasn't changed that much from 16.04 to 16.1013:23
rbasakYeah but package disruption is expected during release upgrades.13:23
tsimonq2Well, it'll just install some new packages.13:24
tsimonq2I wouldn't describe it as "disruption"13:24
rbasakI'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
tsimonq2Ok.13:24
rbasakIf that's all it does, then I agree it's not disruption.13:24
rbasakThe risk is that it doesn't do that for some unknown reason.13:24
tsimonq2rbasak: We have a daily ISO that runs germinate13:24
tsimonq2I see13:24
rbasakOne reason might be that if I have lubuntu-desktop and something installed that conflicts with pulseaudio for example.13:25
tsimonq2ic13:25
rbasakI don't know if there are other cases that might cause a problem.13:25
rbasakI'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
tsimonq2I understand :)13:25
tsimonq2Worst case scenario, not saying this *will* happen, but lubuntu-desktop gets removed. It's a metapackage, it shouldn't really matter.13:26
rbasakIt impacts a future release upgrade.13:26
tsimonq2i.e. iirc it *shouldn't* autoremove the deps13:26
tsimonq2Oh13:26
tsimonq2Well true13:26
rbasakThis might all be considered acceptable of course.13:27
rbasakAnother thing is that "apt upgrade" may not want to install pulseaudio; only "apt full-upgrade". What will the GUI do?13:27
rbasakThis may not be so bad; it's no worse.13:27
rbasakActually kernel upgrades work that way.13:27
rbasakSo it must be fine.13:27
tsimonq2Good point13:27
tsimonq2But yeah, we're pretty sure about doing this :)13:36
rbasakOK13:36
rbasak+113:36
rbasakI'm just writing this up in the bug.13:36
tsimonq2Ok :)13:37
tsimonq2rbasak: 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 with13:43
rbasakIt'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:43
tsimonq2No I get it13:44
tsimonq2But13:44
rbasaksnaps better suit Firefox's model IMHO.13:44
tsimonq2rbasak: For once irt snaps I agree :P13:44
rbasakAnother way might be to package ESR also (as firefox-esr or something). Then flavours could choose to use that.13:44
tsimonq2I wouldn't mind doing that13:45
rbasakBut as always there's the question of who would provide the developer time.13:45
tsimonq2Exactly...13:45
rbasakI don't think Ubuntu would object to a firefox-esr being maintained in universe.13:46
tsimonq2But, 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
tsimonq2And we have to adapt.13:46
tsimonq2Unfortunately...13:47
tsimonq2rbasak: Maybe at the start of b-cycle I'll consider bringing that up to the MOTU list13:47
tsimonq2But we'll have to see13:47
rbasakAny reason to delay the discussion? You can talk about B plans now :)13:48
tsimonq2I don't have a good answer :P13:49
tsimonq2Sometime between today and B Alpha 1 then :P13:50
rbasakDoes lubuntu-meta autogenerate its dependencies like ubuntu-meta?13:50
tsimonq2Yep.13:50
tsimonq2Well, it does the thing with ./update13:50
rbasakSo for this upload you did that manually against your local change to the seed for which the MP is still outstanding?13:50
tsimonq2Yep, then discarded the config change.13:50
tsimonq2That's why I think they should land closely timed :P13:51
rbasakOK. 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
tsimonq2Sure.13:52
tsimonq2cyphermox: ping :) ^13:53
rbasakslangasek 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/32978313:53
ubottuLaunchpad bug 1710993 in lubuntu-meta (Ubuntu Xenial) "PulseAudio requirement breaks Firefox on ALSA-only systems after 55.0.1 update" [Critical,In progress]13:53
tsimonq2Fair ;)13:54
zyga-ubuntuhey, 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 this14:00
zyga-ubuntudevice" page14:00
cyphermoxtsimonq2: rbasak: looks sane to me, but you'll want to test what the effect is of adding pulseaudio in general14:11
cyphermoxie is that going to pull in other things too?14:11
cyphermoxdoes that work fine with volume controls or is there config to change as well? (I don't think so, but better be safe)14:11
cyphermoxI think it would be best to further flesh out the test cases even if it looks liek a pretty straightforward change14:12
cyphermoxzyga-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 updated14:14
sil2100@pilot out14:17
=== udevbot changed the topic of #ubuntu-devel to: Zesty Released | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-zesty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
* sil2100 switches to his SRU hat14:17
=== jeblair_ is now known as jeblair
zyga-ubuntucyphermox: it is listed by mmcli -L14:19
zyga-ubuntucyphermox: /org/freedesktop/ModemManager1/Modem/0 [Sierra] MBIM [1199:A001]14:19
bjfjbicha, any guess on when the hidpi scaling issue will get resolved in artful? is there a bug i can track the progress of?14:20
jbichabjf: wait for gnome-shell 3.25.90, we're working on it this week14:21
bjfjbicha, ack, thanks14:21
jbichaI guess you could subscribe to LP: #171280014:21
ubottuLaunchpad bug 1712800 in mutter (Ubuntu) "FFe: gnome-shell 3.26" [Undecided,Confirmed] https://launchpad.net/bugs/171280014:21
cyphermoxzyga-ubuntu: do you have ofono installed?14:22
cyphermoxI think there was a case where it might be pulled in or remain installed when it really shouldn't14:23
Unit193sforshee: I did see he uploaded, but for the past several changes you were the one submitting them so figured I'd poke you.14:24
tsimonq2cyphermox (cc rbasak): ack, I'll spin up a Lubuntu VM and test it out, report back soon14:25
zyga-ubuntucyphermox: partially14:27
zyga-ubuntulibqofono-qt5-0:amd64install14:27
zyga-ubuntuqml-module-ofono:amd64install14:27
zyga-ubuntucyphermox: ^ just those two14:27
zyga-ubuntushould I remove them?14:27
cyphermoxI don't think that would be it14:27
cyphermoxyou shouldn't just remove random things if unsure ;)14:27
zyga-ubuntuok14:27
zyga-ubuntuany more hints on what to try?14:27
cyphermoxzyga-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 reboot14:28
zyga-ubuntucyphermox: tried that14:28
cyphermoxok14:28
zyga-ubuntucyphermox: when I create the connection I don't see my modem listed as a choice14:28
zyga-ubuntucyphermox: it's a roaming connection, not sure if that's a factor14:28
cyphermoxif the modem is listed in ModemManager (mmcli), but not found in NM, I don't know what to do with that14:28
cyphermoxah, well you should check if the connection allows roaming14:29
cyphermoxthere's a checkbox when you edit it14:29
sforsheeUnit193: I supplied patches yes, however it sounds like there's a patch already and I'm not able to upload that pacakge14:29
Unit193Somewhat, yes.  No idea how the internal Canonical stuff works though.  Thanks.14:34
zyga-ubuntucyphermox: checked that as well, it does14:35
* zyga-ubuntu moves out of range14:35
Unit193tseliot: Have you seen LP 1711758 by chance?14:37
ubottuLaunchpad bug 1711758 in nvidia-graphics-drivers-304 (Ubuntu) "artful: nvidia-304 unknown symbol init_mm" [Undecided,Confirmed] https://launchpad.net/bugs/171175814:37
tseliotUnit193: not yet, but I'll have a look at it, and I'll fix it. Thanks14:38
Unit193Thanks a lot!14:38
rbasakcpaelzer: looking at nut in Xenial unapproved. Is it intentional that it has no bug link?14:47
cpaelzercpaelzer: yes and no14:48
cpaelzergrr14:48
cpaelzerrbasak: ^^14:48
cpaelzerrbasak: that is the lack of -v on that build14:48
cpaelzeron the bug we talked in regard to the importer14:48
rbasakI see. And the latest version bump is supposed to not have a bug link, right?14:49
cpaelzerrbasak: the former upload had both buglinks, and the new one is reverting one of them14:49
cpaelzerso with -v I'd close "both" which would be also wrong14:49
rbasakCould you re-upload with a -v please? Otherwise I think it'll cause issues in the pending-sru report.14:49
rbasakOh.14:49
rbasakI see.14:49
cpaelzerrbasak: well I can, but then both which is wrong14:49
cpaelzerand changing old changelog history isn't good either14:49
cpaelzerwhich is why I uploaded the way it is now14:49
rbasakI think we need a bug link for the bug that is still being fixed. Otherwise pending-sru will be broken.14:50
rbasakI wonder if we need to hack the changes file to have one bug but not the other.14:50
cpaelzerrbasak: TL;DR tell me which way we need it for the process to work and I'll do so14:50
rbasakcpaelzer: 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
Unit193tsimonq2: 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:51
tsimonq2Unit193: aha14:52
Unit193Try --profile ubuntu14:52
cpaelzerrbasak: 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-trusty14:52
cpaelzerrbasak: 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:52
rbasakcpaelzer: 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
cpaelzerrbasak: ok, then reject now and I'll send you something into -unapproved14:53
cpaelzerrbasak: will ping you then14:53
=== led2 is now known as led1
=== led2 is now known as led1
cpaelzerrbasak: you rejected the xenial one but the case is the same for xenial and trusty15:03
cpaelzerrbasak: I have the modified changes file ready15:04
cpaelzerrbasak: would you reject the nut in trusty as well so we can halde both at once?15:04
rbasakcpaelzer: sorry, done.15:05
slangasekrbasak: 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
cpaelzerrbasak: bot nut uploads are in unapproved again, please take a look if you think the +v+changesmod worked the way15:06
rbasakcpaelzer: will do, thanks!15:11
rbasakslangasek: mainly the changing of the seed post-release.15:11
rbasakslangasek: well, both parts of your question I guess.15:11
rbasakslangasek: I don't know what I don't know, so I'm asking :)15:11
rbasakslangasek: 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:13
rbasakcpaelzer: https://launchpadlibrarian.net/335184706/nut_2.7.1-1ubuntu1.2_source.changes15:14
rbasakcpaelzer: 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
slangasekrbasak: 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 ok15:15
tsimonq2rbasak: oh hey, another Lubuntu Release Manager who has access approved my MP ;)15:16
cpaelzerrbasak: I tohught the regex is on LP: #<HERE>15:17
cpaelzerrbasak: odd15:17
cpaelzerrbasak: do you want another new changes file?15:17
cpaelzerrbasak: or do you handle the remaining mistake in that?15:17
zygacyphermox: http://paste.ubuntu.com/25432469/15:24
zygacyphermox: n-m crashes, I'm trying to fetch sources to see what's going on there15:24
zygaspecifically 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>' failed15:24
tsimonq2rbasak: Well, he approved it, just didn't actually merge it.15:27
zyga    g_return_if_fail (nm_device_get_managed (device, FALSE));                                                                                                                                                                       |>15:28
zygaalso on     g_return_val_if_fail (nm_device_get_managed (self, FALSE), FALSE);15:28
zygacyphermox: so nmcli gives me this: cdc-wdm0: unmanaged gsm (cdc_mbim, cdc_acm), hw15:29
tsimonq2cyphermox, 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
tsimonq2Not too many extra things15:30
tsimonq2I think it'll be fine.15:30
rbasaktsimonq2, slangasek, cyphermox: thanks. I'll process this today. Just otp right now.15:31
tsimonq2Ok15:31
tsimonq2Sponsorship queue down to 30 \o/15:40
* zyga updates to artful15:42
zygamvo: fingers crossed :)15:42
zygahmm15:44
zygafreenode's web irc is pretty neat15:44
zygaif it only did offline / background I'd never look back15:44
slangasektsimonq2: hopefully not as a result of freeze-violating uploads? :)15:45
tsimonq2slangasek: Nope15:47
tsimonq2slangasek: Most are triaging things, asking for updates on packages, ~ubuntu-sponsors falsely subscribed, etc.15:47
tsimonq2slangasek: If anything I've done a lot of SRUs :P15:47
cjwatsonMm, not convinced most of lgw01 is going to wake back up trivially ...15:47
tsimonq2slangasek: 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 :P15:48
slangasekhmm, good question15:49
andyrockbdmurray: hey15:51
andyrockseems like that the pep8 tests were failing before too15:52
andyrockdo you want me to fix them all or just the parts that I edited?15:52
tsimonq2slangasek: 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:54
andyrockbdmurray: nevermind15:55
andyrockthey're not failing on trunk15:55
slangasektsimonq2: I don't have the url in front of me, can you point me the page you're seeing this on/15:56
slangasektsimonq2: http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html ?15:56
tsimonq2slangasek: 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.html15:57
naccjbicha: 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 desktop15:57
slangasektsimonq2: ok, completely unclear to me as well; UTSL https://launchpad.net/ubuntu-sponsoring15:58
tsimonq2Someone needs to indent their CSS ;)16:00
tsimonq2(not pointing fingers at anyone :P)16:00
naccheh16:01
jbichanacc: IMO gvim isn't "desktop" so any Ubuntu developer should be fine16:02
naccjbicha: well the question in particular is what to do about some desktop-related hook/variable16:02
naccjbicha: specifically the last comment from the submitter in https://code.launchpad.net/~jbenden/ubuntu/+source/vim/+git/vim/+merge/32961316:02
jbichavim is Foundations16:02
tsimonq2slangasek: So is ~ubuntu-branches still relevant?16:02
naccslangasek: --^ :)16:02
nacctsimonq2: we're going to reuse it for git, i think (or something similar, at least). but the bzr branches are generally dead.16:03
tsimonq2Ok16:03
tsimonq2I'll whip up an MP working with that...16:04
nacctsimonq2: that's my understanding at least. I'd wait to be sure from slangasek :)16:04
slangasekyeah the remaining ~ubuntu-branches bzr branches are a bucket of fail16:04
tsimonq2Ok16:05
slangasek(the fail was left out in the sun too long and melted)16:05
naccheh16:06
jbichanacc: I left a couple drive-by comments, you can ask in #ubuntu-desktop16:07
naccjbicha: thank you16:07
Unit193zyga-ubuntu: If you like webchat, perhaps check out 'thelounge'16:39
zyga-ubuntuUnit193: thanks, I'll check that out16:46
Unit193Can be configured to have scrollback.16:47
tsimonq2rbasak: Is git ubuntu something I can install yet?17:16
tsimonq2Mhhh, 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
nacctsimonq2: it's only a snap17:18
nacctsimonq2: making it a deb is not in our plans17:19
nacctsimonq2: 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
nacctsimonq2: and i'm not willing to sign up to backport git, gbp, etc. to older releases :)17:19
tsimonq2I guess I'm installing from source :P17:20
nacctsimonq2: what release are you on?17:20
tsimonq2Artful :P17:20
nacctsimonq2: ok, that should be fine :)17:20
nacctsimonq2: and 'installing' from source, is just clone and add repo/bin to PATH17:20
nacc(for now)17:20
tsimonq2Fair ok17:20
naccas it's a degenerate case currently (only used by developers)17:21
nacctsimonq2: if that doesn't work, let me know17:21
tsimonq2Ok17:21
tsimonq2nacc: 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:24
tsimonq2(probably not, right?)17:25
tsimonq2I mean, it can always be edited in the future, but I'd like a working packaging guide...17:25
nacctsimonq2: we're not yet importing the world, so i'd wait17:27
nacctsimonq2: it's on our roadmap for 1.0 to hit that switch17:28
naccbut we need to coordinate with LP team, etc.17:28
tsimonq2Ok17:28
nacctsimonq2: 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
tsimonq2I'm working on that right now ;)17:28
nacctsimonq2: nice, can check that off my list then :)17:29
tsimonq2nacc: 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
tsimonq2I know I'm not the only one who is discouraged by that.17:29
tsimonq2So since the sponsorship queue doesn't hurt my eyes as much, this is my next step ;)17:30
nacctsimonq2: nice!17:30
nacctsimonq2: 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 a17:31
naccwhile anyways)17:31
tsimonq2nacc: Ok17:32
tsimonq2nacc: Do you generally have an ETA on that?17:32
tsimonq2(i.e. days, weeks, months, years?)17:32
nacctsimonq2: heh17:34
tsimonq2I 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 it17:35
nacctsimonq2: we are hopefully going to have a trello board up soon which has the plan laid out (and public)17:35
tsimonq2ooooooh ok17:35
nacctsimonq2: we're hopefully going to be at alpha in the next month or two, but that's not a hard requirement17:35
tsimonq2Ok17:35
tsimonq2Fair17:35
nacctsimonq2: 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 on17:35
tsimonq2nacc: Ok.17:36
tsimonq2nacc: Btw, I've been meaning to ask... how will that deal with packages that are already imported in Git?17:37
tsimonq2nacc: i.e. the Kubuntu packages use a totally separate Git workflow17:37
nacctsimonq2: 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
tsimonq2Will git merge be expected or how will that work?17:37
tsimonq2nacc: Ok :)17:37
nacctsimonq2: the importer doesn't really care (currently)17:37
tsimonq2Alright17:38
nacctsimonq2: we have discussed telling the importer about some upstream sources of information (where upstream is up to the developer)17:38
tsimonq2Ok17:38
nacctsimonq2: the distinction is that the importer only trusts launchpad publishing data17:38
nacctsimonq2: and we want it to always be 'correct' relative to the archive17:38
tsimonq2I see17:38
tsimonq2Publishing data in respect to what?17:38
nacce.g.: https://launchpad.net/ubuntu/+source/freeradius/+publishinghistory17:39
naccwhat was published when, and to where and with what contents17:39
naccbasically, the git import is a git view of that page for every srcpkg17:39
tsimonq2oic17:39
tsimonq2nacc: 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
naccthe 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
nacctsimonq2: yep17:40
nacctsimonq2: as long as they are published17:40
tsimonq2And what if there's (unfortunately) build conflicts?17:40
nacctsimonq2: build where?17:40
tsimonq2s/build/merge/17:40
nacctsimonq2: algorithmically, there won't be :)17:40
tsimonq2Oh, so you'll have an algorithm that'll sort all that out (or try to)?17:41
nacchttp://www.justgohome.co.uk/blog/2017/08/more-on-the-imported-repositories.html17:41
nacci think talks about it a bit17:41
nacci'm not sure it goes into the detail of how we do parenting yet17:41
tsimonq2Ohhhhhhh I get it17:42
naccbut a future post will, i think :)17:42
tsimonq2So work in Git will be done in $release-devel17:42
nacctsimonq2: we're trying to avoid being too clever, as that's what broke UDD (aiui)17:42
tsimonq2And then archive copies will be in the pockets17:42
nacctsimonq2: yeah17:42
tsimonq2ic17:42
naccand developer input is provided by these upload tags17:42
tsimonq2nacc: SRUs?17:42
naccwhich is just rich history17:42
nacctsimonq2: there's a devel branch for all active releases17:42
tsimonq2How will SRUs and security updates work then?17:42
tsimonq2nacc: Ok17:43
nacctsimonq2: 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 uploads17:43
nacctsimonq2: in the case that you can upload, we are working on refining that17:43
tsimonq2Ah ok17:43
naccso that your MP gets integrated into the history of the import17:43
naccwe have an idea of how to do it, just need to implement it and make sure it does what we want :)17:44
tsimonq2I see :)17:44
nacctsimonq2: for now, you can always still just dput17:44
nacctsimonq2: the importer will just carry on importing what has been dputted17:44
tsimonq2nacc: 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 :P17:44
tsimonq2I can see another case where that function would be use17:45
tsimonq2*used17:45
tsimonq2Someone forgets an epoch in a Debian merge or something17:45
tsimonq2Would it be smart and bump the changelog or just flat out reject it?17:45
tsimonq2nacc: I plan on using dput still, yeah ;)17:45
naccso, 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:45
nacc(only = currently)17:46
naccgit-ubuntu itself doesn't know about dput (yet)17:46
naccso it relies on the archive to still reject bad uploads17:46
naccwe have a linter, that tries its best (but is a WIP)17:46
tsimonq2Ok17:46
naccwe are trying to avoid too much auto-correction17:46
naccas it tends to be hard to get right, and complicated :)17:47
nacc(at least for 1.0)17:47
tsimonq2I see17:47
naccwe want to get the tool out there and usable by most first, then we can improve the UX, add new workflows, etc.17:47
tsimonq2Makes sense17:47
tsimonq2nacc: Well thanks for letting me pick your brain on it :)17:47
tsimonq2I hope this works out :D17:48
nacctsimonq2: 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 team17:48
nacctsimonq2: but if there are packages you'd like us to import, so you can play around, just let me know17:48
tsimonq2Ok :)17:49
Unit193nacc: Waaaait, git-ubuntu isn't going to be packaged?  Is this the expected workflow or optional "You can do this"?18:27
Unit193Can one just use gbp with it?18:27
Unit193Sounds optional, hrm.  Also sounds like the majority of it will be server side, so I can just ignore it and gbp instead.18:29
naccUnit193: it's not trivial to package it in a way that makes sense -- we are dependent on new upstream functionality from, e.g., gbp itself18:40
naccUnit193: afaict, without owning backporting (and thus maintaining) all the deps we need, it's not possible to pacakge it for older releases18:40
naccUnit193: if one can use gbp with an arbitrary git repository, then use, one can use gbp with our repository :)18:40
naccUnit193: tbh, i've not used gbp, so I don't know what the value-add is (yet)18:41
Unit193Is it in the standard format of upstream/master/pristine-tar? (Where master = upstream+debian)18:41
Unit193gbp is pretty handy stuff, fwiw.18:41
naccUnit193: we don't track upstream directly18:41
Unit193Specifically gbp dch -a is nice.18:41
naccUnit193: we don't have a master branch18:42
naccUnit193: and we have per-distro pristine-tar branches (as debian and ubuntu can differ on tarball contents)18:42
Unit193Sounds...Fun.18:42
naccUnit193: in principle, yes, you should be able to use gbp -- it probably needs flags and/or a conf file18:43
Unit193nacc: I guess time will tell, thanks for elaborating at least.18:47
naccUnit193: so there are probably two sides to this, which is part of the confusion18:49
naccUnit193: the importer and the developer tools are in the same code18:49
naccUnit193: the importer is what you referred to earlier as server-side18:49
naccUnit193: our 'master' is 'ubuntu/devel' (we could make an actual master, we just intentionally did not yet)18:49
naccUnit193: so for developer side, i think it would be pretty easy (IME gbp has flags for everything :)18:50
Unit193Hmm, wondering how imports would work.  Not really messed with single branch git repos, that don't only have debian/ that is.18:52
naccUnit193: see the above blog post -- and future ones that will explain more how the importer algorithm works18:52
naccand/or the source :)18:52
naccimports are imports of Launchpad publishing information (with potentially additional rich history provided by developers)18:53
Unit193Right, was just thinking about without 'git ubuntu'.18:53
naccso, 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 point18:54
naccUnit193: yeah, good luck :)18:54
naccUnit193: dgit is the only other importer-like model I'm aware of18:54
naccUnit193: and we do pretty similar things (intentionally)18:54
Unit193So, ignore and use dput for new upstreams, this for other changes. :D18:54
naccUnit193: new upstream versions you mean (where upstream is unrelated to debian/) ?18:55
Unit193nacc: Right, new tarball, eg 2.3 → 2.418:56
naccUnit193: 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 already18:56
Unit193nacc: 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:57
naccyeah, 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
naccUnit193: agreed, wait and see :)18:58
Unit193Huh, OK.18:59
naccUnit193: we have a slightly different model than UDD did, I think. We don't want developers messing with the branches18:59
naccUnit193: it's too easy to get wrong, parenting, etc.19:00
naccUnit193: so instead, you just give us the upload itself, we figure out where it goes into the imported history19:00
naccUnit193: and that includes, for new upstreams, the pristine-tar branches themselves19:01
Unit193In regards to upstream, not...Oh I'll just go look for a repo...19:03
naccUnit193: :)19:03
nacchopefuly I didn't make it more confusing19:03
Unit193That's a lot of branches and tags..19:07
naccUnit193: yep :)19:09
Unit193nacc: So I make some changes, commit them, push them to the repo.  Did I just do an upload?19:10
naccUnit193: nope :)19:10
Unit193\o/19:10
naccUnit193: that's the bit that's currently disconnected19:10
naccUnit193: current: use `git ubuntu submit` to create a MP19:11
naccUnit193: that will get reviewed by one of us that can do upload tagging and we will sponsor it (if appropriate)19:11
Unit193Well, 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
Unit193Hrm, so that's the part that's a bit disconnected, I see.19:11
naccUnit193: short-term future: MPs that are in the approved state (thus dependent on approving teams) will get upload-tagged automatically by the importer19:11
naccUnit193: long-term future: `git ubuntu push` replaces `dput`19:12
Unit193Right, I'm still thinking of when someone doesn't have 'git ubuntu'19:12
naccUnit193: right, if they don't have git ubuntu, nothing changes for them19:12
naccfor now19:12
naccUnit193: the importer proceeds regardless of how the upload occurred19:13
naccUnit193: the only differnce between the above and doing a normal dput is the rich history19:13
Unit193Indeed.  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:14
naccYeah, 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
naccin general, one should be able to do `git ubuntu clone <srcpkg>` and then do whatever they want with git19:15
nacceverything after that point is workflow(s)19:15
naccUnit193: tsimonq2: thank you both for the discussions. It helps me clarify to myself assumptions we are making.19:34
Unit193Eg, "grumpy people not installing snaps".  Sure thing!  Thanks for listening.19:35
naccUnit193: :) 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 environment20:51
rbasakUnit193, 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:02
naccrbasak: a good point21:03
rbasakJust use gbp, etc.21:03
rbasakBut this of course clashes when someone outside a team uploads to Ubuntu without also pushing to git.21:03
rbasakSame as a Debian NMU.21:03
rbasakWhat 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
rbasakFor example most uploads will some as syncs from Debian.21:04
naccrbasak: you're explaining it better than me :)21:05
rbasakThen 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 scheme21:05
rbasakYou 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:06
rbasakIf 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:07
rbasakIf 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:09
Unit193rbasak: 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
Unit193And, somewhat useful as one commit, it's like the diffs now.21:25
rbasakIt's a view if you don't interact with it.21:25
Unit193And I see, it's really not meant to be a replacement for the old bzr interface.21:25
rbasakIf you do provide rich history, it'll adopt that history and be more than a view.21:25
naccUnit193: what was the old bzr interface that you refer to? UDD?21:26
rbasakBut 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:26
rbasakOne 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
rbasakIf 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:27
Unit193Sounds less useful how you explain it, more like a version of sources.debian.net with diffs too.21:29
rbasakWhat do you want instead?21:29
Unit193No, just going on what it is.21:30
rbasakI mean: you're saying it's less useful; what's the more useful thing you were expecting?21:31
Unit193Something part way between dgit (which I've never used), and the older bzr interface.21:32
Unit193nacc: I'm not entirely sure the name, could be.21:32
Unit193nacc: udd to me is https://udd.debian.org though.:P21:32
rbasakCan you be more specific?21:32
naccUnit193: heh21:37
Unit193I 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
naccUnit193: jumping from A to C isn't possible :)21:37
Unit193OK...21:37
naccUnit193: we are going A -> B -> C (I think what you describe is what both rbasak and I described, as a future possibility)21:37
naccUnit193: 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 on21:38
Unit193nacc: 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:38
rbasakIt 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
rbasakBut that wrapper might as well be in the client.21:39
rbasakYou can do that pretty trivially today.21:39
rbasakSo 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:40
=== flexiondotorg_ is now known as flexiondotorg
Unit193rbasak: 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:41
rbasakSure, it's tricky to figure out. We've spent months thinking about this area.21:42
Unit193Well, perhaps a little less "what it is", and more "what it is and how would I work with it"21:42
rbasakI'm confident that if you agree with our use cases, then you won't come to any other solution.21:42
rbasakBut feel free to prove me wrong :)21:43
tsimonq2Side 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? :P21:43
tsimonq2C'mon, I'll happily help maintain the deb package :P21:43
rbasakYou'd have to maintain it in backports.21:43
rbasakI have no objection if you want to take that on.21:43
Unit193rbasak: 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:43
rbasakYeah - what we're doing is orthogonal to that.21:44
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
rbasakThe wrapper will deal with all that in the end.21:45
rbasak"Here's a commit; make it be my upload. Go."21:45
Unit193rbasak, nacc: I don't mean to bash what you're doing, as stated having something like sources.debian.net is nice.21:46
tsimonq2Oh I didn't even think of that21:46
tsimonq2sources.debian.net but with Git21:46
rbasakOnce we're there, we could look into turning signed git tags into uploads automatically.21:46
tsimonq2That would be *nice*21:46
rbasaktsimonq2: we're pretty much there now; only it's not searchable and isn't live for all packages yet.21:47
rbasakhttps://code.launchpad.net/~usd-import-team/+git21:47
Unit193tsimonq2: "more like a version of sources.debian.net with diffs too." is what I said earlier.21:47
tsimonq2Unit193: then the credit goes to you :P :D21:47
tsimonq2rbasak: oooooh21:47
Unit193Not looking for credit, just how I'd explain it.21:47
tsimonq2Unit193: however you want to say it :)21:48
tsimonq2But we're on the same page21:48
tsimonq2rbasak: Oh, here's a use case for ya... NEW packages21: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:48
tsimonq2Can I have a package have the initial upload with this, rbasak?21:49
tsimonq2Or only existing packages?21:49
Unit193tsimonq2: Perhaps we should wait until it's fully baked, then just take a look. :)21:49
tsimonq2"existing" meaning "in the archive"21:49
Unit193Speaking of, I still have something stuck in NEW. :/21:49
rbasakUnit193: I appreciate the conversation now. Happy to influence our plans based on developer opinion!21:49
rbasaktsimonq2: I'm not sure I follow your question21:50
tsimonq2Unit193: That's fair, just giving a brain dump as to my thoughts :)21:50
rbasaktsimonq2: new packages will end up imported once accepted.21:50
tsimonq2rbasak: Ok, is there any way to have the Git repo created *before* it's accepted and have *that* do the initial upload?21:50
tsimonq2rbasak: Or do they have to already be accepted in the archive?21:50
tsimonq2Sure it may be an edge case but I can see it21:51
rbasakUploads must go through dput as usual.21:51
tsimonq2Oh, ok.21:51
rbasakHowever, if you want the importer to pick up your existing git tree as history, it can do that.21:51
rbasakThere's also "git ubuntu queue" which can be used for NEW and Unapproved queue reviews.21:51
rbasakSo archive admins and SRU team members (or anyone) can get a preview of something before it's accepted.21:51
rbasakI use this to diff proposed SRUs against different things, which is really handy.21:52
rbasakIf it helps, we aren't yet doing anything to Launchpad or any other infrastructure.21:52
tsimonq2Ah ok21:53
rbasakThe importer is a separate tool that has no special privilege over any normal user.21:53
rbasakThe 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
rbasakThat's the only privilege we intend to give to this project in the short term.21:53
tsimonq2Side 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:56
tsimonq2Ah ok, found an example...21:58
Unit193rbasak: Regarding backports, there's really nobody manning that now so even if one does do backports, you won't get anywhere.22:13
Unit193rbasak, nacc: FWIW, I think I may have also sounded more harsh than I was.  If so, sorry about that.22:24
naccUnit193: 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:26
Unit193I'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:27
naccUnit193: 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:30
Unit193I'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:31
Unit193(It's what I use in Debian, but Debian != Ubuntu.)22:32
naccUnit193: 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 uploading22:34
Unit193\o/22:34
Unit193MP == bzr. :P22:34
Unit193nacc: I should really stop bugging you though.22:34
naccUnit193: yeah, it's overloaded in LP22:37
mwhudsonLaney: the artful autopkgtest base images still seem to have python3.5 installed even though it's been removed from artful22:39
mwhudsonLaney: how does that get fixed, do you move to a new base image at some point?22:39
mwhudsonLaney: nm :)23:22
=== NCommander is now known as mcasadevall

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!