[09:22] <alkisg> Hi, I'm upstream and Debian maintainer for the "ltsp" package. A rewritten version of it has just landed in Debian testing, and it'd be best if focal got it too.
[09:22] <alkisg> Question, will this be done automatically or do I need to do some action? https://launchpad.net/ubuntu/+source/ltsp lists it in "proposed".
[09:35] <rbasak> alkisg: hi! Thank you for looking out for your package in Ubuntu!
[09:35] <rbasak> The reason something gets "stuck on proposed" is much the same as migration to testing in Debian
[09:35] <rbasak> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ltsp has the details
[09:36] <rbasak> Is there some kind of rearrangement in the binary packages produced?
[09:36] <alkisg> Thanks, reading.. :)
[09:37] <alkisg> Yes, many binary packages were removed
[09:37] <alkisg> There's only one "ltsp" binary package now
[09:37] <alkisg> And it's "arch: all", interpreted
[09:38] <rbasak> I'm somewhat puzzled why this hasn't happened automatically.
[09:38] <alkisg> The migration to debian testing only happened yesterday
[09:39] <alkisg> Maybe it just needs some time?
[09:39] <rbasak> No Ubuntu doesn't have a mandatory delay like testing
[09:40] <rbasak> And the excuses file is clear that it's blocked
[09:40] <rbasak> I think deletion of the binaries in the release pocket would work, but I'm not sure that's definitely the right thing to do.
[09:40] <rbasak> We need to ask an archive admin (equivalent of an ftpmaster) to take a look.
[09:40] <rbasak> Unless there's something I'm missing here
[09:40] <alkisg> We did have to ping ftp master for the debian migration to testing
[09:41] <alkisg> Maybe something similar is needed here
[09:41] <rbasak> What happens if a user has the old binary packages installed?
[09:41] <rbasak> I don't see an upgrade path?
[09:42] <alkisg> It should remain installed, and it should be possible to get autoremoved with apt
[09:42] <alkisg> It was possible to have the old and the new ltsp coexist for some time, that's why this was preferred
[09:42] <alkisg> Also the other debian developer said that way it would avoid the New queue for debian ;)
[09:43] <alkisg> (vagrantc is DD, I'm just DM, so I defer to him for such issues :))
[09:43] <rbasak> Could you file a bug against ltsp in Ubuntu please, and subscribe ~ubuntu-archive to it?
[09:43] <alkisg> Sure, thank you
[09:43] <rbasak> I don't want to go into the technical detail myself because I'm not confident I understand the nuances here and I don't want to take you down a path that's wrong.
[09:44] <rbasak> And I don't have the authority to resolve it in the archive anyway.
[09:48] <alkisg> Hopefully I got the correct list subscribed: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1855422
[09:52] <rbasak> akelling: thanks! Yes, that subscription is correct.
[09:52] <alkisg> Ty. alkisg :)
[09:52] <rbasak> The archive admins tend to process things in batches though so the bug may not get attention quickly.
[09:52] <rbasak> Ah, sorry!
[09:53] <alkisg> There's no hurry, just making sure it requires no other action from my part
[09:53] <rbasak> You were right to ask in here.
[09:53] <rbasak> And feel free to ask again if it doesn't get attention in a while.
[09:53] <alkisg> Great, thank you
[09:53] <rbasak> I don't see any European archive admins in here right now
[09:54] <rbasak> Ah, seb128 maybe? ^
[10:03] <seb128> rbasak, hey, sorry had to change wifi, I'm around now ... what's up?
[10:03] <rbasak> seb128: are you an active archive admin?
[10:03] <seb128> yes
[10:04] <rbasak> alkisg has an issue with ltsp migrating. I think it needs some binary deletions but am not sure. On my advice he just filed bug 1855422 but then I saw you were online :)
[10:05] <seb128> looking
[10:06] <alkisg> Ty, I'm here if feedback's needed
[10:20] <seb128> alkisg, rbasak, seems like the old binaries have no rdepends and just need to be deleted
[10:21] <alkisg> Nice
[10:27] <cjwatson> coreycb: those two pushes of yours should work now
[10:28] <cjwatson> teward: wasn't around then.  what do you need?
[11:15] <rbasak> seb128: thank you!
[11:21] <seb128> rbasak, np!
[11:52] <kanashiro> rbasak, did you see my message yesterday about the sphinxsearch issue? ruby-riddle regression is the only thing avoiding ruby-defaults migration atm
[12:20] <rbasak> kanashiro: yes. That research looks good. Did you have a question for me?
[12:31] <kanashiro> rbasak, there was no question, I thought I was handing it over to someone else :p but that's fine, I can try to find the fix by myself
[12:32] <kanashiro> if I have any question I'll ping you
[12:34] <rbasak> kanashiro: oh, sorry for the confusion!
[12:36] <kanashiro> np :)
[13:05] <coreycb> cjwatson: thanks
[13:08] <ahasenack> cpaelzer: how does one build manual test-retrigger urls again? I'm trying to do it for one package specifically before going the all-proposed=1 route (learning experience)
[13:08] <ahasenack> https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=amd64&package=samba&trigger=ldb%2F2.0.7-4 <-- failed with
[13:08] <ahasenack> You submitted an invalid request: ldb/2.0.7-4 is not published in focal
[13:08] <ahasenack> which is correct, as ldb 2.0.7-4 is in focal-proposed
[13:09] <ahasenack> I want to run the samba test under https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ldb
[13:09] <ahasenack> but with the samba package from focal-proposed
[13:09] <ahasenack> test is green as is
[13:11] <ahasenack> or, to use a real case that is read
[13:11] <ahasenack> samba under https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#talloc
[13:11] <ahasenack> I need it to run with samba from focal-proposed
[13:11] <ahasenack> and didn't want to pass all-proposed=1
[13:12]  * ahasenack reads https://wiki.ubuntu.com/ProposedMigration in the mean time
[13:14]  * ahasenack adds samba itself as a trigger
[13:15]  * ahasenack feels smart
[13:15]  * ahasenack waits for the outcome
[13:19] <ahasenack> Unpacking samba-libs:amd64 (2:4.11.1+dfsg-3ubuntu1) ...
[13:20] <ahasenack> yay, seems to have picked up the correct version
[13:20] <ahasenack> nice
[13:32] <seb128> ddstreet, hey, please commit your network-manager changes to the packaging vcs
[15:03] <seb128> alkisg, rbasak, the ltsp update is in focal now
[15:15] <rbasak> Thank you!
[15:19] <alkisg> Great seb128, thank you, thanks to rbasak too
[15:19] <seb128> yw!
[16:14] <Odd_Bloke> rbasak: Thanks!
[16:18] <rbasak> yw!
[17:50] <ddstreet> seb128 done, sorry
[17:50] <seb128> ddstreet, np, thanks!
[17:52] <ddstreet> vorlon will i386 autopkgtests on focal get properly tweaked somehow so they pull the right arch deps (I see you did some work for build-essential already), or will they all just get marked ignore?
[17:52] <ddstreet> i'm assuming for now, at least, i386 tests on focal can be ignored
[19:01] <doko> seb128: python-pceclib: please don't depend on python, use python2 instead
[19:01] <seb128> doko, ack
[20:15] <vorlon> ddstreet: many autopkgtests will need adjusted individually to have correct cross-capable definitions; I've started working on uploading a number of these and will be posting to ubuntu-devel with some guidance on how to do this.  In the meantime, it's correct to mark any that are failing "ignore" since they have regressed in the release pocket
[20:31] <santa_> so ... i386 packages started to "dissapear", correct?
[20:31] <santa_> from focal I mean
[20:34] <santa_> ah, indeed
[20:34]  * santa_ reads ubuntu-devel ML
[20:35] <santa_> yep, time to ditch my kde test rebuilds for i386 I guess
[20:35] <vorlon> for focal, very much so ;)
[21:38] <LocutusOfBorg> fossfreedom, is it ok to sync nautilus-dropbox?
[21:39] <LocutusOfBorg> the new release is fine with budgie or not?
[21:39] <LocutusOfBorg> speaking wrt https://bugs.launchpad.net/ubuntu/+source/nautilus-dropbox/+bug/1683051
[21:56] <LocutusOfBorg> merged it
[22:27] <LocutusOfBorg> kanashiro, hello, any idea for this failure? I tried to sync ruby-riddle but failed https://launchpad.net/ubuntu/+source/ruby-riddle/2.3.1-2ubuntu1
[22:27] <LocutusOfBorg> looks like the current version in focal is not even working with a no-change rebuild