[02:59] <cjwatson> mwhudson: What is the openssh behaviour change here?
[03:00] <mwhudson> cjwatson: previously openssh closed the connection on the presentation of an invalid terminal mode
[03:01] <mwhudson> with a log like thisL
[03:01] <mwhudson> 		debug1: session_pty_req: session 0 alloc /dev/pts/3
[03:01] <mwhudson> 		debug1: Ignoring unsupported tty mode opcode 255 (0xff)
[03:01] <mwhudson> 		parse_tty_modes: unknown opcode 255
[03:01] <mwhudson> 		parse_tty_modes: n_bytes_ptr != n_bytes: 1 1
[03:01] <mwhudson> 		Packet integrity error (5 bytes remaining) at ../../session.c:1899
[03:01] <mwhudson> 		Disconnecting user mwhudson UNKNOWN port 65535: Packet integrity error.
[03:02] <mwhudson> now the log looks like
[03:02] <mwhudson>         debug1: Ignoring unsupported tty mode opcode 255 (0xff)
[03:02] <mwhudson>         ssh_tty_parse_modes: unknown opcode 255
[03:02] <mwhudson>         ssh_tty_parse_modes: 5 bytes left
[03:02] <mwhudson> and the connection proceeds
[03:10] <cjwatson> mwhudson: Could be a consequence of the translation of ssh_tty_parse_modes to the sshbuf API
[03:10] <cjwatson> mwhudson: Not certain whether upstream would be interested, but it might be worth reporting it there if you can come up with a more upstream-friendly test case
[03:10] <mwhudson> cjwatson: yes, those were the sort of words i saw rummaging around in openssh-portable git
[03:11] <cjwatson> I think you're right that it's likely unintended
[03:11] <mwhudson> cjwatson: otoh it looks like the intended behaviour was always to ignore invalid modes
[03:11] <mwhudson> judging by the older log message
[03:11] <mwhudson> cjwatson: where do bugs get reported?
[03:12] <cjwatson> Ignore yes, but in the case of 160-255 sshd doesn't know how long the message is supposed to be
[03:12] <cjwatson> bugzilla.mindrot.org
[03:13] <mwhudson> should i be amused or not that openssh bugzilla does not redirect to https?
[03:13] <cjwatson> The current comment does still say "Opcodes 160 to 255 are undefined and cause parsing to stop"
[03:13] <mwhudson> ah ok
[03:13] <mwhudson> does sound like a bug then
[03:14] <cjwatson> I doubt I ever noticed that since I've had HTTPS Everywhere installed forever :)
[03:14] <mwhudson> yeah i should probably do that too
[03:14] <mwhudson> cjwatson: are you up very early, very late, or not at home?
[03:15] <cjwatson> I'd say it's not precisely a bug, but it would make more sense for the undefined opcode to return an error
[03:15] <cjwatson> Up in the middle of the night waiting for painkillers+antibiotics to kick in so I can go back to sleep
[03:16] <valorie> get well soon, cjwatson
[03:17] <cjwatson> Thanks.  I know what the problem is now so it's just frustrating waiting for treatment to be effective
[03:18] <mwhudson> cjwatson: i hope you manage to sleep soon then!
[03:41] <mwhudson> cjwatson: https://bugzilla.mindrot.org/show_bug.cgi?id=3061
[03:42] <cjwatson> thanks, LGTM
[08:43] <marcoagpinto> bugs
[08:43] <marcoagpinto> ops
[08:43] <mwhudson> marcoagpinto: we have lots of bugs, yes :)
[08:43] <marcoagpinto> sorry... wronte join text
[08:43] <marcoagpinto> I was trying to write: /j ubuntu-bugs
[08:43] <mwhudson> yes, just being silly
[08:44] <marcoagpinto> >:)
[08:44] <marcoagpinto> and I had "/j ubuntu-" on the clipboard
[08:44] <marcoagpinto> :)
[08:44] <marcoagpinto> I forgot to paste it
[08:48]  * mwhudson glares at http://autopkgtest.ubuntu.com/packages/g/golang-fsnotify/eoan/arm64
[09:01] <LocutusOfBorg> mwhudson, do you want to have a look also at golang-golang-x-tools ?
[09:01] <LocutusOfBorg> this might be the last blocker
[09:01] <LocutusOfBorg> with fsnotify
[09:01] <mwhudson> LocutusOfBorg: yea i guess so
[09:01] <mwhudson> fsnotify will pass if we bounce on retry enough i'm sure but that's also stupid
[09:02] <mwhudson> golang-gopkg-square-go-jose.v2 is gone from testing
[09:05] <LocutusOfBorg> syncthing should be probably patched to fail less frequently
[09:05] <LocutusOfBorg> syncing syncthing
[09:07] <LocutusOfBorg> I asked to kick it out on release channel
[09:24] <seb128> juliank, hey, any idea why in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/u/uim/20190824_150559_359b3@/log.gz we get
[09:24] <seb128> 'Broken uim-el:amd64 Depends on xemacs21-mule:amd64 < none | 21.4.24-8 @un uH >
[09:24] <seb128>   Considering xemacs21-mule:amd64 1 as a solution to uim-el:amd64 0
[09:24] <seb128>   Holding Back uim-el:amd64 rather than change xemacs21-mule:amd64'
[09:25] <juliank> that probably needs like half an hour of investigating
[09:25] <seb128> k
[09:27] <mwhudson> ooh fsnotify passed
[09:27] <LocutusOfBorg> LOVELY
[09:29] <mwhudson> LocutusOfBorg: so yeah, just tools really
[09:29] <seb128> juliank, uim-el depends on         emacs24 | xemacs21-mule | xemacs21-mule-canna-wnn | emacsen
[09:29] <LocutusOfBorg> seb128, I see lots of emacs stuff has been no change rebuilt in Debian, because of new dh-elpa
[09:30] <seb128> emacs24 doesn't exist anymore
[09:30] <LocutusOfBorg> ok but the others exist?
[09:30] <seb128> but in a chroot I can install the -mule just fine
[09:30] <seb128> yes
[09:30] <seb128> dunno why apt prefers to hold on
[09:30] <seb128> I might just try to change emacs24 for "emacs" which exists and see if that helps
[09:35] <juliank> seb128: that certainly sounds like a bug in the packaging that it depends on emacs24 first
[09:35] <seb128> juliank, well, still alternative depends should work...
[09:36] <juliank> seb128: And they did
[09:36] <juliank> seb128: The reason it failed is that the sat-dep package was removed before that
[09:36] <seb128> so something else is probably buggy :/
[09:36] <juliank> seb128: Like, it did in the autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt install on test deps directly for further data about failing dependencies in test logs part
[09:37] <seb128>   Removing autopkgtest-satdep:amd64 rather than change uim-el:amd64
[09:39] <juliank> yeah
[09:39] <juliank> that happens earlier
[09:39] <juliank> than it tries to get more info by passing all package names directly to apt install
[09:39] <juliank> which succeeds
[09:42] <juliank> We're unfortunately missing debugging output from the mark phase
[09:42] <seb128> I tried to change the emacs24 to emacs, let's see if that helps
[09:43] <juliank> It should
[09:43] <mwhudson> hm i wonder if the golang-golang-x-tools tests are just ooming
[09:43] <seb128> bah, calligra fails to build in eoan and a rebuild is needed for the poppler transition
[09:45] <seb128> https://bugs.launchpad.net/ubuntu/+source/calligra/+bug/1841910
[09:46] <seb128> RikMills, ^ is that something you could look at?
[09:47] <RikMills> seb128: yeah. will do
[09:49] <LocutusOfBorg> juliank, question: why this works: apt build-dep ./golang-golang-x-tools*.dsc
[09:49] <LocutusOfBorg> and this fails? apt build-dep golang-golang-x-tools*.dsc
[09:49] <LocutusOfBorg> E: You must put some 'source' URIs in your sources.list
[09:50] <juliank> LocutusOfBorg: because it's hard to differentiate the latter from a real package name, while the former is not a valid package name
[09:50] <seb128> RikMills, thx
[09:50] <juliank> LocutusOfBorg: APT only accepts filenames starting with / or ./; everything else is not considered a filename
[09:51] <LocutusOfBorg> juliank, like if it ends with ".dsc" it is probably a filename? or if (access(file))?
[09:51] <LocutusOfBorg> I got the problem, I was thinking about a possible solution
[09:51] <juliank> that makes the behavior context-sensitive
[09:51] <juliank> like foo.dsc is a valid package name
[09:52] <juliank> Then we end up with the same problem we have now with regex and fnmatch
[09:52] <LocutusOfBorg> yes, but if the file exists in that directory... meh
[09:52] <LocutusOfBorg> but I get the issue, thanks
[09:52] <LocutusOfBorg> there is always some hope to get an answer like "oh, this is a bug, lets fix it" :)
[09:53] <juliank> If the file exists in the directory means it will install the build-depends of package foo.dsc in another directory, and of your foo.dsc in its directory
[09:53] <juliank> which makes it suboptimal as you have to make sure you are in the right directory
[09:54] <juliank> I wonder if we can make autocompletions autocomplete foo.dsc to ./foo.dsc
[09:54] <juliank> What I want apt to do is say: "No such package found, but a file with that name. Prefix it with ./ if you did mean the file"
[09:55] <juliank> APT syntax post-20.04 will need 1 lookup character to decide argument type: ? => pattern, .|/ => filename, rest=>package name
[09:55] <juliank> oh, and I guess ^=>regex
[10:01] <RikMills> seb128: test building with upstream patch added
[10:08] <seb128> RikMills, woot, thx
[10:31] <LocutusOfBorg> seb128, how is poppler going? only calligra and gdcm left?
[10:34] <LocutusOfBorg> I have some work to do, but I don't want to delay your transition with my stuff :)
[10:35] <RikMills> LocutusOfBorg: I'm test building fix for calligra
[10:41] <seb128> LocutusOfBorg, yeah, I think so ... if you want to do gdcm please do, I got other things to handle and I'm on vac tonight :/
[10:42] <LocutusOfBorg> sure, with pleasure!
[10:43] <seb128> LocutusOfBorg, thx!
[10:58] <LocutusOfBorg> RikMills, can you also rebuild kitinerary?
[10:58] <LocutusOfBorg> and kdepim-addons?
[10:59] <RikMills> I will try
[10:59] <LocutusOfBorg> thanks! with your 4 packages we should be good to go
[11:03] <mwhudson> [  865.965695] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-998.slice/session-c2.scope,task=gcimporter.test,pid=8873,uid=998
[11:03] <mwhudson> [  865.965711] Out of memory: Killed process 8873 (gcimporter.test) total-vm:870044kB, anon-rss:779692kB, file-rss:0kB, shmem-rss:0kB
[11:03] <mwhudson> that'd be a yes then
[11:05] <mwhudson> should probably patch that test to skip in -short mode
[11:05] <mwhudson> tomorrow!
[11:12] <RikMills> LocutusOfBorg: kdepim-addons doesn't need a rebuild. poppler build dep is obsolete. the feature went into kitinerary in fact!
[11:12] <RikMills> I'll drop the bd in git
[11:12] <seb128> kitinerary might need one then? ;)
[11:13] <RikMills> seb128: it does. just checking it builds with new poppler
[11:14] <RikMills> it does :)
[11:16] <seb128> good! :-)
[11:48] <LocutusOfBorg> seb128, will you open a bug against debian/uim please?
[11:48] <LocutusOfBorg> looks like it migrated!
[11:48] <LocutusOfBorg> RikMills, and an upload without that dependency?
[11:49] <LocutusOfBorg> oh I see now, I checked the build log and I probably failed to parse the output
[11:49] <LocutusOfBorg> not needed, yes
[11:55] <LocutusOfBorg> RikMills, calligra is good
[11:55] <LocutusOfBorg> gogogo?
[11:55] <RikMills> LocutusOfBorg: just this second uploaded
[11:56] <LocutusOfBorg> 💖
[11:57] <LocutusOfBorg> now autopkgtests will take a while... queues are half full
[12:03] <seb128> LocutusOfBorg, yes, I plan to, I wanted to see if it worked first
[13:07] <LocutusOfBorg> seb128, thanks, it worked btw :D
[13:07] <LocutusOfBorg> do you have any news about duplicity on ppc64el?
[13:08] <LocutusOfBorg> I prod the bug...
[13:08] <seb128> no, I don't think we can/should could on upstreamm to fix it
[13:09] <seb128> I opened a RT to get eoan chroots on the builders over a month ago but got ignored
[13:09] <LocutusOfBorg> :/ remove the binary?
[13:09] <seb128> it probably needs someone who has access to a debug env to debug
[13:09] <seb128> that's a big hammer
[13:10] <LocutusOfBorg> I didn't mention it before because I know how big the hammer is, but meh
[13:10] <LocutusOfBorg> did you try to lower the optimization level already, right?
[13:10] <seb128> smaller hammer would be to ignore the test failure in the ppc64el build
[13:10] <seb128> no
[13:10] <seb128> I didn't have much time to get back to that
[13:11] <LocutusOfBorg> if it works with -O2 on ppc64el I upload in the archive
[13:11] <seb128> it's in my backlog but was not a ff blocker so got ranked lower than other work
[13:11] <seb128> LocutusOfBorg, thx
[13:11] <cjwatson> seb128: RT> have you escalated that with your manager?
[13:12] <cjwatson> it's #1033 in the BVG queue so is going nowhere unless you get it bumped
[13:12] <cjwatson> (also I'd suggest that saying "it's a low-priority request" in the ticket is not a recipe for getting immediate attention :) )
[13:12] <seb128> cjwatson, no, I was unsure if was important enough to go the escalation route
[13:13] <cjwatson> well, if it's blocking investigation ... although don't we have canonistack bos01 now?
[13:13] <seb128> we do, which is one of the reason I though it was not that important
[13:14] <seb128> it's probably just me holding to old habits
[13:14] <seb128> I need to have a look again how to access/use the canonistack instead
[13:14] <cjwatson> https://wiki.canonical.com/InformationInfrastructure/IS/CanoniStack-BOS01
[13:14] <seb128> thx
[13:15] <LocutusOfBorg> cjwatson, how do you feel today?
[13:15] <LocutusOfBorg> seb128, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/17483477
[13:17] <cjwatson> LocutusOfBorg: so-so; thanks for asking
[13:17] <LocutusOfBorg> if it works, I'll join the party of people telling to the person who decided to use -O3 on ppc64el that it was a BAD idea
[13:17] <cjwatson> antibiotics beginning to be useful
[13:17] <LocutusOfBorg> after some days...
[13:18] <LocutusOfBorg> have some rest, they will eventually do the trick :)
[13:18] <seb128> LocutusOfBorg, I don't think comments like 'Hello, ping? this bug is preventing some transition from landing in ubuntu eoan...' are useful on upstream trackers...
[13:18] <seb128> they probably do care about Ubuntu, but they stated that they have no access about ppc64el nor any clue about it
[13:19] <LocutusOfBorg> yes, but there was an unanswered question...
[13:19] <seb128> well, you can try, I doubt they are likely to do anything about it
[13:19] <LocutusOfBorg> ping is about "hey what do you need to trace it down"? do you have a way to show more logs?
[13:19] <seb128> out of responding 'we don't care about that arch, none of our users are on it'
[13:20] <LocutusOfBorg> when I had the src:firewalld issue, I got some debugging information from upstream that I was not aware of
[13:20] <seb128> ah, I forgot about that one
[13:20] <seb128> your comment didn't include much context on what the ping was about :)
[13:20] <LocutusOfBorg> it was just the message above, this is why I didn't add context
[13:20] <LocutusOfBorg> anyway I hope -O2 does the trick
[13:30] <cjwatson> seb128: FWIW, after getting bos01 access generally set up and creating a temporary model, "juju deploy --constraints 'arch=ppc64el instance-type=m1.small' --series bionic cs:ubuntu" will deploy a machine you can "juju ssh" to once it's built and then you can play with that at will
[13:30] <cjwatson> (Maybe different instance-type depending on size requirements)
[13:34] <seb128> cjwatson, k, thx for the tips, I'm going to try in a bit
[13:34] <seb128> LocutusOfBorg, build failed :-/
[13:35] <LocutusOfBorg> :(
[13:44] <LocutusOfBorg> seb128, I did a test adding some print message to that test and uploaded in my ppa
[13:45] <seb128> LocutusOfBorg, good luck!
[13:45] <LocutusOfBorg> I wish you a better luck with real hw, but I just want to print the numbers that are causing that assert
[13:45] <LocutusOfBorg> just to understand the values
[13:46] <seb128> it just needs debugging I think, but I've been too busy with feature freeze and travelling to GUADEC and on holidays tonight
[13:48] <LocutusOfBorg> lower bound: 334464: actual st_size value: 841656 upper bound: 465536
[14:15] <GunnarHj> Hi jdstrand, can you please take a look at https://github.com/ibus/ibus/issues/2116 . I upstreamed the patch we've carried for a while, but issues due to it have been reported. Your input on that issue would be appreciated.
[16:02] <RikMills> seb128 LocutusOfBorg: poppler migrated
[16:02] <seb128> I saw, nice
[16:08] <LocutusOfBorg> yep, good job seb128 RikMills !
[16:10] <seb128> thx RikMills LocutusOfBorg!
[16:12] <LocutusOfBorg> enjoy your vac!
[16:30] <seb128> LocutusOfBorg, thanks :-)
[16:34] <marcoceppi> I'm trying to amend some of the rpi images to work with our CM3+ images. I'd like to know how the base images are packed so I could potentially inject our changes in that process but I can't seem to find where. fginther How does CPC pack the rpi preinstalled images?
[16:53] <fginther> marcoceppi, the images are built by https://launchpad.net/livecd-rootfs. Of particular interest that might help are the helper functions under 'live-build/functions'
[16:54] <marcoceppi> fginther: is there any documentation on how the rpi steps are run? thanks for the pointer I'll take a look in a min
[16:57] <fginther> marcoceppi, no there isn't any documentation that I'm aware of
[17:02] <marcoceppi> fginther: mind if I ping you with questions? Or is there a better person wrt livecd-rootfs
[17:04] <fginther> marcoceppi, rpi isn't a build I'm particularly familiar with, so there are probably better experts around, but I don't mind trying to answer specific questions
[19:29] <sunweaver> Laney: hi! Do you think you could take a look at some fancy build result...
[19:29] <sunweaver> https://jenkins.arctica-project.org/job/libayatana-indicator.deb+nightly/target=eoan/4/console
[19:29] <sunweaver> it seems that latest GLib 2.0 in Ubuntu eoan is incompatible with its GTK-2. Is that so?
[19:30] <sunweaver> (I'll be afk now, but will pick up any answer by tomorrow...)
[19:34] <jdstrand> GunnarHj: done
[19:36] <GunnarHj> jdstrand: Thanks!
[21:11] <vorlon> rbasak: mysql-5.7 is now demotable to universe, I haven't looked if it's also removable now or if there are still revdeps
[21:19] <rbasak> Ah. I forgot all about the deletion. I'll add it to my list, thanks.
[21:21] <rbasak> Yes there are a bunch of reverse depends. I'll take care of them.
[23:57] <RAOF> tjaalton: I've got that Kaby Lake G bug for you: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1842009
[23:57] <RAOF> tjaalton: Or, rather, *not* for you, because it's probably a GNOME Shell bug.