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