[01:52] <bryce> sarnold, thanks for the suggestion to extract the cookies from firefox, while I couldn't do it via the sqlite database programmatically, it made me look from the FF gui itself, and I was able to manually copy each of them to a file, and pass that to wget.  There were a couple other openid-related tweaks specific to autopkgtest I figured out digging through autopkgtest's flask code, but I finally got it all working.
[01:55] <sarnold> bryce: dang, I wonder why it didn't work for you -- or why it works for us, I think it does anyway :)
[01:55] <sarnold> bryce: but now you've got a way to restart N autopkgtests at a go?
[02:34] <bryce> sarnold, I do
[02:35] <sarnold> yay :)
[02:35] <bryce> sarnold, do you guys run the scripts on a ubuntu version earlier than focal?  could be as simple as that
[02:37] <sarnold> bryce: I'm on focal for a few weeks now, and I'm pretty sure I used the responses/security/ scripts recently, which I think use that cookie
[02:42] <bryce> sarnold, can you run `python2 ./cookies-sql2txt.py ~/.mozilla/firefox/m2yx7v41.default/cookies.sqlite autopkgtest.ubuntu.com` ?
[02:43] <bryce> I get an error like "pysqlite2.dbapi2.OperationalError: near ".": syntax error"
[02:44] <sarnold> ImportError: No module named pysqlite2
[02:44] <sarnold> heh, I don't even get that far.
[02:45] <bryce> sudo apt-get install python-sqlite
[02:47] <bryce> anyway, it's an interesting angle on the problem, I may dig more into it later.  thanks again
[02:48] <sarnold> heh, required python-pysqlite2.
[02:48] <sarnold> pysqlite2.dbapi2.OperationalError: near ".": syntax error
[02:49] <bryce> ok, yep
[02:49] <bryce> I put the database table name in quotes but then it didn't recognize it as a valid table name.
[04:33] <bryce> wow, and autopkgtest.ubuntu.com has now finished processing all of that.  Looks like chake and ruby-session are still on the board
[04:38] <mwhudson> bryce: do you know about retry-autopkgtest-regressions from ubuntu-archive-tools?
[04:38] <mwhudson> looks like it requires you did the cookie out of your browser too though
[05:05] <bryce> mwhudson, yep that was one of the first things I looked at actually
[05:05] <mwhudson> bryce: ok good :)
[05:06] <techalchemy> sarnold, fyi whatever the rason is we're using pysqlite we should probably use the native bindings instead
[06:40] <cjwatson> Yeah, there's the perfectly good sqlite3 in the standard library
[06:40] <cjwatson> Since Python 2.5
[06:41] <cjwatson> Most things that use pysqlite2 were originally written for Python <= 2.4
[06:45] <mwhudson> i don't seem to be getting a plymouthy boot in focal currently
[06:46] <mwhudson> is that a known thing?
[08:19] <seb128> vorlon, a few people pinged me because of bug #1864586, any idea when you will get a fix out?
[08:19] <ubottu> bug 1864586 in plymouth (Ubuntu Focal) "plymouth does not ask for LUKS password and does not change tty properly" [High,Confirmed] https://launchpad.net/bugs/1864586
[08:24] <seb128> vorlon, plymouth includes a plymouth-populate-initrd script that can be used and would copy the right content
[08:32] <mwhudson> oh i'm seeing that
[08:39] <Laney> me too :'(
[08:40] <juliank> seb128: the fix is easy, it's just adding a word to the for loop that copies the theme in the initramfs hook
[08:41] <juliank> -currthemes="${THEME_NAME} ${TEXTTHEME_NAME}"
[08:41] <juliank> +currthemes="${THEME_NAME} ${TEXTTHEME_NAME} spinner"
[08:41] <seb128> juliank, I know, it's just that Steve said he would have a fix uploaded on friday and I don't want to dup work
[08:41] <seb128> but thanks
[10:34] <dannf> cjwatson: been a while since i tried to do git-dpm/grub work - is there something i need to do to the master to unapply patches? https://paste.ubuntu.com/p/kz4n5t4SXj/
[11:29] <cjwatson> dannf: don't use quilt!
[11:30] <cjwatson> dannf: git-dpm gives you patch-applied already.  If you want to edit the patch stack, use git-dpm checkout-patched and commit stuff directly, then git-dpm update-patches to serialise the commits back into debian/patches/
[11:36] <dannf> cjwatson: yeah, that's what i'm doing - but i'd assumed after update-patches i'd have a quilt-compatible tree.
[11:38] <dannf> if that's not the case, that's ok :) just trying to make sure i'm doing it correctly
[11:38] <dannf> bbiab
[12:02] <cjwatson> dannf: It would be quilt-compatible if you did something like https://people.canonical.com/~cjwatson/dpkg-quilt-setup to set up quilt metadata.  But it's not designed to be managed with quilt, and trying to do so will probably just cause confusion
[12:02] <cjwatson> dannf: It's just using quilt as an export format
[12:41] <ahasenack> does ubuntu or debian have this packaged? I couldn't find it: https://git.kernel.dk/cgit/liburing/
[12:42] <ahasenack> https://lwn.net/Articles/776703/
[12:52] <dannf> cjwatson: ack, thx
[14:00] <cpaelzer> rbasak: with the Origin added I guess you can re-reply to the mail
[14:00] <cpaelzer> rbasak: and then either upload youself now (allowing for bryce to pick up the results)
[14:00] <cpaelzer> or wait for him to ack and sponsor it
[14:01] <cpaelzer> kanashiro: the ctioga2 worked now, triggered on all architectures
[14:02] <seb128> vorlon, I'm having a look to the plymouth/initramfs issue now
[14:05] <cpaelzer> rbasak: I'm taking a look at the class III bugs
[14:06] <cpaelzer> rbasak: in case this is another phpunit patch we could do it in one upload
[14:06] <cpaelzer> Those are the likes of " Declaration of HTTP_Request2_Adapter_CommonNetworkTest::setUp() must be compatible with PHPUnit\Framework\TestCase::setUp(): void in /tmp/autopkgtest.Ih0Z0B/build.kMc/src/HTTP_Request2-2.3.0/tests/Request2/Adapter/CommonNetworkTest.php"
[14:09] <rbasak> Ah yes, I was about to ask if we wanted to bundle any more phpunit fixes before uploading
[14:12] <kanashiro> cpaelzer, good news, I should come up with another set of packages with similar issue
[14:21] <cpaelzer> kanashiro: so they all need triggers combined with ruby-defaults and their own version in -proposed then?
[14:33] <cpaelzer> rbasak: I have patches that will need your phpunit change
[14:34] <cpaelzer> rbasak: I'll upload all together to a PPA hoping they will test there together nciely
[14:37] <kanashiro> cpaelzer, I didn't check all the regressions but some of them yes
[14:38] <cpaelzer> kanashiro: ok once you have a list to restart that way let me know
[14:39] <rbasak> cpaelzer: sure. Feel free to upload, etc.
[14:42] <cpaelzer> rbasak: I replied to the thread with two debdiffs
[14:42] <cpaelzer> will later reply if the testing shows anything useful
[14:46] <kanashiro> rbasak, don't you want to comment on this MP https://code.launchpad.net/~lucaskanashiro/ubuntu/+source/ruby-dataobjects-mysql/+git/ruby-dataobjects-mysql/+merge/380125 ? I just kept the changes you added in the past to support mysql 8
[14:51] <rbasak> kanashiro: sorry, I don't read all the MP traffic. I'll comment now.
[14:54] <kanashiro> np
[15:31] <roaksoax> win 1
[18:08] <ahasenack> hi, can one of these two dep8 requests be killed?
[18:08] <ahasenack> cacti {"requester": "ahasenack", "submit-time": "2020-03-03 17:05:55", "triggers": ["cacti/1.2.9+ds1-1ubuntu2"]}
[18:08] <ahasenack> cacti {"requester": "ginggs", "submit-time": "2020-03-03 17:54:32", "triggers": ["cacti/1.2.9+ds1-1ubuntu2"]}
[18:28] <kanashiro> rbasak, could you sponsor ruby-dataobjects-mysql if you are happy with the changes I proposed on that MP?
[18:34] <rbasak> kanashiro: sure. I'm heading out now though, so it might be later today or tomorrow. Is that OK?
[18:34] <rbasak> (if not grab someone else maybe?)
[18:34] <kanashiro> rbasak, totally fine
[18:35] <rbasak> Though also, is rafaeldtinoco happy with my comment?
[18:35] <rbasak> I don't want to step on his question without checking he's happy with my response.
[18:35] <rafaeldtinoco> rbasak: sorry I should have +1ed your comment
[18:35] <rafaeldtinoco> I read it, agreed and moved on to something else
[18:35] <rafaeldtinoco> lol
[18:35] <rafaeldtinoco> kanashiro: ^
[18:35] <rbasak> OK, I'll sponsor when I get back.
[18:36] <rbasak> Thanks!
[18:36] <rafaeldtinoco> tku!
[18:37] <kanashiro> great :)
[18:43] <doko> kanashiro: are you working on https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ruby-defaults ?
[18:45] <kanashiro> doko, yes, I should request some re-runs latter today to fix some regressions and start to investigate some actual failures (now I am trying to rebuild some packages against ruby2.7 that are still missing)
[18:46] <kanashiro> however, help is welcome :)
[20:01] <kanashiro> doko, any idea about this python related src:subversion failure? https://launchpadlibrarian.net/467386393/buildlog_ubuntu-focal-amd64.subversion_1.13.0-2build1_BUILDING.txt.gz
[20:02] <kanashiro> I added a patch to drop the '-classic' option (not supported according to the logs) but then I got another error
[20:02] <kanashiro> subversion/bindings/swig/python/svn_client.c:7517:106: error: ‘svn_argnum_swig_obj’ undeclared (first use in this function); did you mean ‘svn_argnum_obj1’?
[20:08] <doko> kanashiro: not python related, but more likely swig 4.0. just drop that?
[20:11] <kanashiro> doko, yep, someone filed a bug upstream about it while ago and not fixed yet apparently: https://issues.apache.org/jira/browse/SVN-4818?jql=project%20%3D%20SVN%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22swig%22%20ORDER%20BY%20priority%20DESC
[20:12] <kanashiro> this link is better: https://issues.apache.org/jira/browse/SVN-4818
[20:13] <doko> great, no upstream support
[20:13] <doko> so maybe package a legacy swig-3.0 and use it?
[20:13] <doko> or drop the bindings
[20:14] <kanashiro> doko, I'd go for dropping the python binding
[20:14] <kanashiro> it is not functional anyway
[20:14] <doko> take care about the rdeps
[20:15] <kanashiro> ack
[21:26]  * rafaeldtinoco takes a break to get back to pacemaker
[22:36] <vorlon> seb128: yeah sorry, I'm off today so if you were to get the plymouth fix out that would be rgeat
[22:36] <vorlon> seb128: "great"