[01:35] <lucas_ai> I'm trying to read an H264 video stream in python but it seems there are NO libraries for this... wtf? - how am I supposed to decode H264 frames?
[01:59] <mwhudson> # go4.org/reflectutil.test
[01:59] <mwhudson> go4.org/reflectutil.typedmemmove: relocation target runtime.typedmemmove not defined for ABI0 (but is defined for ABIInternal)
[01:59] <mwhudson> yikes
[02:00] <mwhudson> lucas_ai: this channel is for the development of ubuntu, not using ubuntu for development (if that makes sense)
[02:01] <mwhudson> https://github.com/go4org/go4/issues/43
[03:03] <lucas_ai> it seems ffmpeg cannot decode h264... only mp4
[05:29] <seb128> cyphermox, hey, did you get any success with ffmpeg?
[07:07] <lennyb> rbasak. Thanks.  Do you know how packages go to this repo http://mirror.iad.rax.openstack.org/ubuntu-cloud-archive/pool/main/n/networking-mlnx/   ?  As I see this mirror should have all version of the package
[07:11] <Locutusofborg> mwhudson, I think its over for now :D
[07:12] <Locutusofborg> rebuilding once bileto lands is something better to do, even if not required
[07:12] <Locutusofborg> and bootstrapping was really painful, the dependency chain was looooooooong
[07:29] <alkisg> cyphermox: hi, in 19.04, netplan generates this line in /etc/net-enp0s3.conf:
[07:29] <alkisg> IPV4DNS0=1.2.3.4 1.2.3.5 1.2.3.6
[07:29] <alkisg> I.e. unquoted, so the file is not longer a valid/sourceable shell script.
[07:29] <alkisg> In addition, I think it should be writing a single value to IPV4DNS0 and another one in IPV4DNS1, and omit the third one, as script may not be able to cope with multiple values in IPV4DNS0.
[07:29] <alkisg> My question is... where do I file issues that come from the netplan changes in the initramfs code? In initramfs-tools, or in netplan, or both?
[07:35] <alkisg> *sorry, I meant in /run/net-enp0s3.conf
[07:35] <alkisg> In Ubuntu 18.04 it didn't have this issue
[09:15] <doko> sforshee, apw: could you start using python3 for your kernel builds?
[09:15] <apw> doko, very likely ...
[09:16] <doko> ta
[09:17] <apw> doko, indeed our explicit dep is python3, so odd that we are using 2
[09:17] <apw> sforshee, lets put some actions somewhere to get that investigated
[09:19] <doko> apw: B-D: python-dev, python-sphinx <!stage1>, python-sphinx-rtd-theme
[09:19] <apw> doko, yeah, we'll find it and see if we can squash it
=== dwmw2 is now known as dwmw2_gone
[09:54] <rbasak> lennyb: I think that's probably https://wiki.ubuntu.com/OpenStack/CloudArchive. THe OpenStack team manage it and I'm not aware of their policies and procedures, sorry.
[10:12] <rbasak> openssl/libssl1.1 1.1.1-1ubuntu2.1~18.04.4 hit the security pocket last night, and that regressed ejabberd
[10:13] <rbasak> 2019-08-21 06:52:28.402 [warning] <0.539.0>@ejabberd_c2s:process_terminated:290 (tls|<0.539.0>) Failed to secure c2s connection: TLS failed: client renegotiations forbidden
[10:13] <rbasak> bionic-security that is
[10:13] <rbasak> Downgrading to 1.1.0g-2ubuntu4.3 (the previous package I had installed which I assume is what was in bionic-security previously) fixes it.
[10:13] <rbasak> Should I file this against openssl or ejabberd?
[10:14] <rbasak> mdeslaur: ^
[10:20]  * rbasak has filed bug 1840902
[10:20] <ubottu> bug 1840902 in openssl (Ubuntu Bionic) "ejabberd fails incoming connections with "Failed to secure c2s connection: TLS failed: client renegotiations forbidden"" [Critical,New] https://launchpad.net/bugs/1840902
[10:52] <lennyb> rbasak:thanks a lot.
[11:04] <mdeslaur> rbasak, xnox: I gather I should rebuild erlang-p1-tls in -security?
[11:05] <xnox> mdeslaur:  as requested in an email to you.... rbasak's bug marked as duplicate.
[11:06] <xnox> rbasak:  promoting demoting openssl is not nice =)
[11:07] <xnox> rbasak:  also, do you trust SRU process so much that you use -security only =) ?! I find that peculiar =) unless i'ts not your system, but someone elses =)
[11:08] <mdeslaur> xnox: sorry, let me catch up on my email
[11:08] <xnox> mdeslaur:  well it's only been minutes ago =) but i think we are all on the same page =)
[11:10] <mdeslaur> ok, cool, I'll rebuild and release today
[11:16] <Locutusofborg> rafaeldtinoco, hello, thanks for LP: #1840511
[11:16] <ubottu> Launchpad bug 1840511 in gcc-9 (Ubuntu Eoan) "Eoan FTBFS with gcc-9 and MySQL 8" [Medium,In progress] https://launchpad.net/bugs/1840511
[11:16] <Locutusofborg> next time please ping me directly on irc!
[11:16] <Locutusofborg> I lost the emails into the spam folder
[11:16] <Locutusofborg> looks like we did double work, I'm reading the bug right now
[11:23] <Locutusofborg> btw there is no hurry wrt feature freeze
[11:23] <Locutusofborg> packages in proposed are allowed to migrate
[11:27] <rbasak> xnox: well, it is the default. It's important to test the default ;)
[11:29] <xnox> rbasak:  har har sure. Also what do you use ejaberd for? actual jabber/xmpp or for voip?
[11:30] <rbasak> Actual XMPP
[11:32] <xnox> nice
[11:32] <xnox> so retro =)
[11:35] <xnox> jelmer:  feature freeze is tomorrow =/ so i guess we didn't get in bzr -> breezy transition
[11:38] <Locutusofborg> rafaeldtinoco, thanks for the big valuable patches, I think you should be a MOTU :D
[11:41] <rbasak> Locutusofborg: my team is handling the MySQL transition. If you're working on that without contacting us, you're doing the double work :-/
=== ricab is now known as ricab|lunch
[12:23] <seb128> MIR team, do you know what's the status of bug #1811824? webkit2gtk needs it now, unsure why it has not been picked since june after security team reviewed it?
[12:23] <ubottu> bug 1811824 in xdg-dbus-proxy (Ubuntu) "[MIR] xdg-dbus-proxy" [Undecided,New] https://launchpad.net/bugs/1811824
[12:23] <seb128> doko, cyphermox, cpaelzer, ^
[12:27] <cpaelzer> seb128: as I read it didrocks wanted to have it set back to new to re-review (which you did in may)
[12:28] <seb128> unsure why Ken assigned to himself, maybe that confused things?
[12:28] <cpaelzer> not sure what Ken wanted by assigning it to himself, but maybe that made it be lost in the overviews that we check every now and then
[12:28] <seb128> yeah, I guess so
[12:28] <seb128> well now webkit has been updated
[12:29] <seb128> so that problem shows on proposed migrations reports
[12:29] <cpaelzer> since we also have already a security review that should go fast
[12:29] <seb128> what's the process to flag that to the MIR team?
[12:30] <cpaelzer> I think you did
[12:31] <cpaelzer> we check the links that you find at http://people.ubuntu.com/~cyphermox/meetings/ubuntu-mir.html weekly
[12:31] <cpaelzer> now that Ken is unassigned it is visible there again
[12:31] <cpaelzer> due to that it was hidden to be open
[12:31] <cpaelzer> and I guess didrocks forgot about it as well
[12:32] <cpaelzer> I'm waiting for a build anyway, let me help you by starting the review
[12:32] <cpaelzer> if it looks smooth you'd be ready to go afterwards since security acked it already
[12:32] <seb128> cpaelzer, ok, thanks for the reply and poking at it!
[12:33] <seb128> cpaelzer, it's a bit confusing sometime that bugs need to be in a particular state to be considered and nothing is indicating they are not (like having an assignee in this case), but good to know about that report so I can check to make sure it's on there next time
[12:34] <seb128> cpaelzer, also I own you a reply for the zsys one, week is a bit busy with ff (and Didier is off and knows better about the go/vendor copies thing)
[12:34] <cpaelzer> seb128: https://wiki.ubuntu.com/MIRTeam#Process_states
[12:34] <cpaelzer> essnetially this assign prevented it to be visible in #1 and thereby never moved to #2
[12:34] <cpaelzer> this is my mental helper for the admittedly complex states of the MIR process
[12:35] <seb128> useful summary
[12:35] <cpaelzer> I wrote and extended it everytime I wondered about it
[12:36] <cpaelzer> and at some point it was ready to be up in the wiki :-)
[12:38] <seb128> :)
[12:42] <seb128> juliank, do you think you could merge wpa 2.9 from Debian? could be good to get in E
[12:46] <cpaelzer> seb128: you are a member of https://launchpad.net/~desktop-packages could you double check for me if this is already subscribed to xdg-dbus-proxy?
[12:47] <seb128> cpaelzer, '“Desktop Packages” team subscription: (unnamed)'
[12:48] <seb128> cpaelzer, yes, it is
[12:52] <cpaelzer> seb128: this was probably the most straight forward review that I had
[12:52] <cpaelzer> LGTM and +1
[12:52] <cpaelzer> now get an AA to do your promotion to main
[12:52] <seb128> cpaelzer, wooot, thx!
[12:52] <seb128> cpaelzer, I'm an AA so I can do it :)
[12:52] <cpaelzer> yay
[12:53] <juliank> seb128: ack
[12:53] <seb128> juliank, thx!
[13:07] <jelmer> xnox: I've got the changes committed, just not uploaded yet :/
[13:08] <seb128> juliank, thx :)
=== ricab|lunch is now known as ricab
[13:32] <Odd_Bloke> rbasak: re: dh_auto_test stuff from yesterday, thanks!
[13:37] <rbasak> Odd_Bloke: you're welcome. Another thought just occurred to me: you could also patch out what the Makefile does.
[13:37] <rbasak> I don't know which is better.
[13:37] <rbasak> An override in debian/rules is perhaps more obvious.
[13:44] <teward> ddstreet: wolsen: slashd: any of you three online?
[13:48] <slashd> o/ teward
[13:49] <teward> slashd: https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1835818 showed up on the radar for me because -sponsors was autosubbed.  Noticed STS Sponsors is on there, and it was filed by someone on the Canonical Support team.  My concern: "Regression Potential: TBD" makes it 'unsatisfiable' for sponsoring under the standard criterion, but STS Sponsors seems to be you paid canonical people for this, so I wanted to check with you guys
[13:49] <teward> first
[13:49] <ubottu> Launchpad bug 1835818 in net-snmp (Ubuntu Eoan) "snmpd causes autofs mount points to be mounted on service start/restart" [Medium,In progress]
[13:49] <teward> before I make any response
[13:50] <teward> it's listed for SRU it seems too
[13:50]  * slashd looking
[13:50] <teward> and I can just hear vorlon and others screaming "NEEDS A REGRESSION POTENTIAL" from fifty lightyears away
[13:53] <slashd> teward, joalif is in my team, I think the SRU tmpl as it is right now, is still a draft. dddstreet and I are part of STS Sponsor and we sponsor most patch inside our team, and we won't sponsor things without a good details potential regression if it recomfort you (as we always do)
[13:53] <teward> yep.  i'm more annoyed that the bot autosubbed it :P
[13:53] <teward> last time I saw a "Regression Potential TBD" it sent me down the rabbit hole :P
[13:54] <teward> slashd: just wanted to check with you guys since I know you guys sponsor internal on the team, the chrichton bot from bdmurray just subbed sponsors is all.  I'll take -sponsors off since you guys handle internal.
[13:54] <teward> if you have no objections :)
[13:54] <slashd> teward, yep because it has detected a debdiff attachement. yeah no worry. We won't upload anything before the template is completed and detailled.
[13:54] <teward> 👍
[13:55] <slashd> teward, sound good in this case sts-sponsor is the only needed.
[13:55] <teward> yep.  that bot is slightly annoying ;)
[13:55] <teward> but i always read through the stuff that lands on my email from the -sponsors list :)
[13:56] <teward> thanks
[13:56] <slashd> teward, sure anytime
[13:56] <teward> *drifts back into the shadows*
[14:06] <dwmw2_gone> Is there an easy way to autobuild a .deb package for each commit in a gitlab repo? I have a Fedora COPR set up with a trigger from gitlab; would quite like to do the same for Ubuntu.
[14:10] <slashd> teward: joalif is updating the potential regression as we speak fyi.
[14:10] <teward> ah, nice.  well it's off my radar since standard ubuntu-sponsors is off it, thank you though :)
[14:12] <slashd> teward, yeah was simply an fyi ;)
[14:16] <ddstreet> rbalint xnox what's the plan for systemd in eoan?  is it staying at 240?  i have a couple bugs already sru'ed that i need to add to eoan, if so
[14:30] <xnox> ddstreet:  plan is to upgrade to at least v241. And yes, it does mean we need to do a lot of cherrypicking of bugfixes and features we like/need/known-to-work-correctly
=== ubott2 is now known as ubottu
[15:21] <Locutusofborg> rbasak, thanks! and sorry for stealing your poco merge, I had to rebuild it, and then I have to rebuild ros-class-loader with new poco multiarch location (sigh!), to hopefully fix ros-rviz build (tested locally, it works), because the fix in ros-python-qt-binding was not enough (fixed one qt issue, but another one appeared)
[15:21] <rbasak> vorlon, rafaeldtinoco, Locutusofborg, cpaelzer: I just filed https://bugs.launchpad.net/ubuntu/+source/clickhouse/+bug/1840938.
[15:21] <ubottu> Launchpad bug 1840938 in clickhouse (Ubuntu) "Please remove clickhouse from the release pocket" [Undecided,New]
[15:22] <rbasak> Locutusofborg: I appreciate your work
[15:22] <Locutusofborg> but its fixed now :)
[15:22] <rbasak> Oh, you retried amd64?
[15:22] <rbasak> I was responding to its failure
[15:23] <rbasak> If it succeeds this time then sure.
[15:23] <Locutusofborg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/17449022
[15:23] <Locutusofborg> it worked on my ppa
[15:23] <Locutusofborg> my guess is flaky test
[15:23] <Locutusofborg> but I won't oppose to "removing it from eoan" :D
[15:23] <rbasak> Another one to add to the skip list? Looks like Rafael already added a bunch.
[15:24] <Locutusofborg> such issues will be handled by Debian maintainer... I already committed changes there
[15:24] <Locutusofborg> and tagged him
[15:24] <rbasak> Nice. Thanks!
[15:24] <Locutusofborg> so I'll make it build on amd64 and then hope to forget it
[15:24] <Locutusofborg> (this is why I like your bug about removing it :D)
[15:31] <rafaeldtinoco> rbasak: just replied, that build missed the gcc9 workaround
[15:32] <rafaeldtinoco> sorry, just woke up from last night adventures on unblocking stuff #)
[15:33] <Locutusofborg> rafaeldtinoco, why do you say that?
[15:33] <Locutusofborg> why did it work on my ppa?
[15:33] <Locutusofborg> same build?
[15:33] <rafaeldtinoco> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/clickhouse.html
[15:33] <rafaeldtinoco> check the G++ dumpo
[15:33] <Locutusofborg> oh you mean Debian :D
[15:33] <rafaeldtinoco> yep
[15:33] <Locutusofborg> I uploaded your package in Ubuntu
[15:33] <rafaeldtinoco> ahh great!
[15:33] <Locutusofborg> it failed on builders/amd64 and the very same identical build didn't fail in my ppa/amd64
[15:33] <Locutusofborg> so we suspect some flaky test
[15:33] <rafaeldtinoco> ...
[15:34] <Locutusofborg> I retried it https://launchpad.net/ubuntu/+source/clickhouse/18.16.1+ds-4ubuntu2
[15:34] <rbasak> Removing packages from eoan:...1 package successfully removed.
[15:34] <Locutusofborg> lovely thanks!
[15:34] <rafaeldtinoco> rbasak: nice
[15:34] <rafaeldtinoco> Locutusofborg: sorry =) I tried =)
[15:34] <rafaeldtinoco> lol
[15:34] <rafaeldtinoco> the huge amount of tests (flaky) arent too good
[15:35] <rafaeldtinoco> i would do the opposite and enable only the important ones
[15:35] <rafaeldtinoco> and maybe convert them to autopkgtests
[15:35] <rafaeldtinoco> (to run the ctest after the build time)
[15:35] <rafaeldtinoco> or something like it
[15:35] <rbasak> I'll do the no-change rebuilds for dependency level 3 now, shall I?
[15:35] <rbasak> Excluding bareos, since we know that one will FTBFS without a patch.
[15:35] <Locutusofborg> in any case rafaeldtinoco please forward patches to Debian...
[15:36] <rafaeldtinoco> Locutusofborg: definitely!
[15:36] <Locutusofborg> thanks!
[15:36] <rbasak> We're tracking all the patches that need upstreaming. There are rather a lot.
[15:36] <rafaeldtinoco> rbasak: alright
[15:37] <rafaeldtinoco> rbasak: should I do the -glusterfs lib patch to bareos ?
[15:38] <rbasak> Oh, hold on.
[15:38] <rbasak> bareos isn't in the release pocket.
[15:39] <rbasak> rafaeldtinoco: so not needed for the transition. Sorry I didn't notice that before.
[15:39] <rbasak> This case is a missing feature in the transition tracker I guess.
[15:39] <rafaeldtinoco> np at all
[15:40] <rbasak> You can still fix it though if you have the fix ready already - or just send to Debian for them to incorporate eventually.
[15:40] <rbasak> The work you did is useful.
[15:40] <rafaeldtinoco> sure!
[15:40] <rafaeldtinoco> maintainers will have to fix it for libglusterfs
[15:40] <rafaeldtinoco> i was basically removing the feature
[15:49] <rbasak> No change rebuilds uploaded.
[16:10] <rbasak> xnox: "Please create ubuntu-hints project" -> could the existing Ubuntu project be used instead? Eg. we already have package removal process bugs for ~ubuntu-archive.
[16:10] <rbasak> And you get your series tasks
[16:10] <rbasak> And can associate the existing relevant packages if you wish.
[16:11] <xnox> rbasak:  .... and per-series bzr branches? lp:ubuntu-hints/bionic ?
[16:12] <xnox> rbasak:  somehow ubuntu-hints feels arthogonal to me.... cause it's usually a combination of packages X blocks Y, which can be solved in X or Y or hinted over or Z fixed/hinted or package removed.
[16:13] <xnox> rbasak:  or do you mean like Ubuntu project without any source package?
[16:13] <xnox> rbasak:  also separate project helps with filtering.
[16:13] <xnox> rbasak:  cause currently hints are in the britney project
[16:13] <xnox> or rather our fork of it.
[16:13] <rbasak> My first thought was to do it without any source package.
[16:13] <rbasak> For filtering, use tags!
[16:14] <xnox> rbasak:  and keep the branches in the britney project?
[16:14] <rbasak> That's what I thought, yes. Unless that won't work?
[16:15]  * xnox is unsure if it's better to "git clone lp:ubuntu-hints" or like "brz branch lp:ubuntu-hints/bionic"
[16:16] <xnox> rbasak:  well ACLs issues / branches are only manageble by release (for devel) and sru (for stable) teams, and not by all of bugmasters.....
[16:16] <xnox> i should be able to make NEW issue, but not close it...... then again we seem to manage that fine with SRUs.
[16:17] <rbasak> I don't see that as a problem. Operating on trust mostly works fine.
[16:18] <rafaeldtinoco> rbasak: catching up
[16:18] <rafaeldtinoco> something needed for bareos or clickhouse on my side ?
[16:18] <rafaeldtinoco> (bareos = open a debian bug and share discoveries)
[16:19] <rafaeldtinoco> about dbconfig-mysql dependency needs and gluster new api
[16:19] <rbasak> Nothing needed for those packages for the transition now.
[16:19] <rafaeldtinoco> ok
[16:19] <rbasak> For general cleanup we need to upstream everything, eventually bring the packages back into sync, etc.
[16:19] <rbasak> If that applies to those packages
[16:19] <rafaeldtinoco> yep
[16:19] <rbasak> clickhouse is quite deltified now I think?
[16:19] <rafaeldtinoco> rbasak: i saw Locutusofborg did the patches in debian
[16:20] <rbasak> Great!
[16:20] <rafaeldtinoco> ill check with him
[16:21] <xnox> rbasak:  so here is an example then https://bugs.launchpad.net/ubuntu/+source/linux-oem-osp1/+bug/1840943
[16:21] <ubottu> Launchpad bug 1840943 in zlib (Ubuntu Eoan) "[hint] zlib through due to osp1 regression" [Undecided,New]
[16:21] <xnox> ubuntu-hints tag, [hint] title, affected packages / series, ~ubuntu-release subscribed
[16:22] <Laney> what problem are you two solving?
[16:24] <xnox> Laney:  that, yet again, "submit hint merge proposal" ended up questioning the life universe and everything, instead of resolving proposed migration issue between two packages.
[16:25] <xnox> Laney:  since proposing solution, is not an effective way of stating a proposed migration problem and requesting release team to decide on how to resolve it https://code.launchpad.net/~xnox/britney/oem-osp1/+merge/371570
[16:25]  * xnox doesn't like proposing solutions, when it's not up to me how something should be resolved
[16:25] <xnox> and most proposed-migration false regressions have many ways of being fixed.
[16:26] <Laney> OK, probably a mail to ubuntu-release setting out the problem that you see and how you think it could be fixed/improved would be best then.
[16:26] <Laney> (the general problem)
[16:26] <rbasak> xnox: I like what you did with that bug, and I prefer it over a new ubuntu-hints project
[16:27] <xnox> Laney:  ack. Plus it's like relese&sru team intersection... cause different teams do hinting for devel & stable series.
[16:35] <vorlon> xnox: I think it's appropriate to propose a specific solution, but always with complete rationale
[16:35] <Locutusofborg> rbasak, rafaeldtinoco yes, for the two packages I did yes
[16:35] <xnox> vorlon:  in debian, release hints are proposed as bug reports no? i.e. file a case in BTS with suggested hint / transition-tracker?
[16:35] <Locutusofborg> clickhouse and cpuinfo or whatever is called are upstreamed
[16:36] <rafaeldtinoco> Locutusofborg: nice! thx!
[16:36] <Locutusofborg> mitya57, hello, just FYI I'm uploading a python-pyqtgraph with python2 still, and then I'll remove python2 package once it migrates
[16:36] <Locutusofborg> ^^ it is already in deferred/5, so please don't reopen the bug :D
[16:37] <vorlon> xnox: I don't think there's anything about bug reports that makes them fundamentally better suited to presenting the rationale to the release team vs MPs
[16:38] <vorlon> and in Debian, you don't get MPs as a toplevel feature of random projects
[16:45] <xnox> vorlon:  is it only me who trips up non-trivial hints that seem to always require further actions and discussion, and are never merged as is?
[16:45] <xnox> or do i need to explain things from like a different point of view / trail of proof?
[16:45] <xnox> i can see that i might be looking at everything backwards.
[16:50] <vorlon> xnox: I think you tend to bring the more interesting cases. :P  broadly speaking, my experience with other MPs is that they wind up being straight rejects or accepts or merges with modifications and an explanation to the submitter after the fact why I changed it
[16:51] <vorlon> whereas you bring me the hints that don't make sense to me as-is but I assume you have a reason so I want to ask questions to understand that reason
[16:52] <xnox> ahhahahhaha
[16:52]  * xnox is a problem child
[17:39] <powersj> rbasak, looks like your uploads fixed the rest for mysql8?
[17:57] <rbasak> powersj: yes. Waiting for autopkgtests now.
[18:35] <alkisg> cyphermox: I ended up filing it against both packages, hope this is ok; LP bug #1840965
[18:35] <ubottu> Launchpad bug 1840965 in initramfs-tools (Ubuntu) "netplan initramfs code writes invalid net-eth0.conf" [Undecided,New] https://launchpad.net/bugs/1840965
[18:38] <cyphermox> yup
[18:40] <alkisg> ty
[18:42] <alkisg> ...where can I download xubuntu 18.10 from, to see if the problem started in 19.04 or in 18.10? I don't see it in cdimage, nor in old-releases...
[18:43] <alkisg> http://cdimage.ubuntu.com/cdimage/xubuntu/releases/ and http://old-releases.ubuntu.com/releases/xubuntu/releases/
[18:43] <alkisg> Some releases missing from either those directories...
[18:49] <alkisg> Seems like old flavor releases are being lost from the mirrors and archives; I had to download it from some indonesian forgotten mirror...
[18:59] <mitya57> Locutusofborg: thanks. Nothing urgent as removing Qt 4 will be a long process :)
[19:30] <seb128> cyphermox, hey, did you get any success with ffmpeg/armhf?
[19:35] <cyphermox> seb128: not yet
[19:36] <seb128> cyphermox, vorlon, can't we just ignore the ffmpeg/armhf issue for the migration and unblock things? ff is tomorrow and we have a full GNOME stack blocked on that to land as well as other transitions then
[19:51] <cyphermox> sure, I think this single failure with a less-important codec is ignorable
[19:52] <cyphermox> (well, still needs to be fixed, but maybe not a blocker)
[19:52] <cyphermox> I don't know if there'll be more issues though to complete the transition
[20:08] <vorlon> seb128, cyphermox: I agree that it's better to ignore the regression than to let things logjam, but ignoring confirmed regressions is my least favorite solution.  Did anyone who was looking into this consider asking for ffmpeg 4.1.4 to be dropped from -proposed, so we could get a reubild of 4.1.3 instead?
[20:08] <vorlon> is it too late to do that now?
[20:09] <vorlon> and, how much time was put into reproducing/fixing the actual armhf issue?  a sigsegv shouldn't be hard to reproduce
[20:11] <vorlon> seb128, cyphermox: the autopkgtests for ffmpeg are not steep. We could proably have an ffmpeg 4.1.3 rebuild built and tested in 3 hours.  I'd rather do that now than ignore the brokenness of ffmpeg 4.1.4 on armhf
[20:15] <seb128> vorlon, I didn't spent time on it since cyphermox is saying daily that he's looking at it for a week and I don't want to dup work
[20:15] <cyphermox> certainly not for a week.
[20:15] <seb128> cyphermox, you said on thursday at the foundation team meeting you would look at it, so ok 6 days :)
[20:16] <seb128> anway, I'm travelling tomorrow and at a conf until tuesday then
[20:16] <cyphermox> I said I'd help you out looking at the libvpx transition on Thursday, I only got to the point that it was ffmpeg on Monday, when I couldn't debug it
[20:16] <seb128> I can try to poke at it if I get some connectivity tomorrow while travelling though
[20:16] <cyphermox> I'm waiting for dd to finish copying an eoan image to an sd card right now
[20:16] <seb128> k
[20:17] <seb128> well no-one at blame, that's just not moving and meanwhile stack of other changes are pilling up
[20:17] <seb128> which is unfortunate :/
[20:17] <seb128> also holidays and ff rush also doesn't help to find free slots to poke at that I guess
[20:17] <cyphermox> that's why I thought sbc was a bug that shouldn't block 4.1.4, provided nothing else is an issue.
[20:18] <cyphermox> or going back to 4.1.3, doesn't really matter which way
[22:59] <cyphermox> fwiw, I am unable to reproduce the ffmpeg segfault here
[22:59] <vorlon> cyphermox: I'm able to reproduce it, but when I run it under gdb the program crashes under ld-linux instead of where it's supposed to :P
[23:00] <vorlon> reproducible in canonistack: ffmpeg -f lavfi -i sine=d=0.1 -strict -2 -c:a sbc -f sbc /tmp/sbc.sbc -y -hide_banner -nostdin
[23:01] <vorlon> I can give you ssh on my instance if you like
[23:04] <vorlon> cyphermox: ubuntu@10.48.131.150 if you want it
[23:11] <mwhudson> we all know what failing on a buildd but working on real hw means, right?
[23:12] <vorlon> that the universe is a simulation and we've found a bug?
[23:13] <mwhudson> vorlon: i wasn't aware the universe had rules about pointer alighnment, but sure, let's go with that
[23:13] <vorlon> heh
[23:13] <vorlon> mwhudson: it's segfault though, not sigbus
[23:13] <mwhudson> ah
[23:14] <mwhudson> vorlon: add my key to that instance too?
[23:14] <vorlon> mwhudson: done
[23:14] <vorlon> it's probably easy once we can get gdb to give an answer :P
[23:15] <vorlon> but gdb /bin/bash gives the same result, a crash in ld-linux
[23:15] <vorlon> who broke gdb on armhf
[23:15] <mwhudson> vorlon: where is ffmpeg hiding?
[23:15] <vorlon> mwhudson: in the armhf container
[23:15] <mwhudson> oh right, that was a silly question
[23:15] <vorlon> which is the one named, uh, 'helped-oyster'
[23:16] <mwhudson> heh yes that's not very helpful gdb
[23:17] <mwhudson> libc6-dbg is already the newest version (2.29-0ubuntu3).
[23:18] <mwhudson> does that not include symbols for ld-linux.2 ?
[23:18] <mwhudson> or well /lib/ld-linux-armhf.so.3 or whatever
[23:18] <vorlon> it includes the debug copy of ld-linux, at /usr/lib/debug/lib/arm-linux-gnueabihf/ld-2.29.so
[23:19] <vorlon> which gives different, but not better, results from gdb
[23:20] <vorlon> (perhaps the fact that the names of the files under debug don't match the sonames is an issue?)
[23:20] <mwhudson> errr
[23:20] <mwhudson> what is cmnvc
[23:20] <vorlon> or perhaps they're simply detached debug symbols and file is lying to me
[23:20] <vorlon> /usr/lib/debug/lib/arm-linux-gnueabihf/libc-2.29.so certainly has no soname
[23:21] <vorlon> infinity: ^^ do you know if the current libc6-dbg is usable on armhf for debugging?
[23:21] <mwhudson> it has a .text section
[23:22] <mwhudson> oh but so do the other detached symbol files?
[23:22] <mwhudson> i don't know how this works i guess
[23:22] <vorlon> yeah perhaps this all relies on the build-id magic
[23:24] <mwhudson> vorlon: have you tried analyzing a core dump?
[23:24] <vorlon> no
[23:26] <mwhudson> root@helped-oyster:~/ffmpeg-4.1.4# file core
[23:26] <mwhudson> core: empty
[23:26] <mwhudson> how does this work again? :)
[23:28] <vorlon> ulimits?
[23:28] <vorlon> oh also apport and containers and dry heaves
[23:29] <mwhudson> i removed apport
[23:29] <vorlon> ok
[23:30] <mwhudson> vorlon: er is there an unstripped ffmpeg around in this container somewhere
[23:32] <mwhudson> it's faulting on => 0x00aecb38:	ldr.w	r0, [r1], #44
[23:32] <mwhudson> where $r1is 0xff6a
[23:32] <vorlon> mwhudson: just downloaded you the ddeb
[23:32] <mwhudson> so it looks like aligment fun but without symbols it's a bit hard to find the source :)
[23:33] <mwhudson> #0  0x00aecb38 in output_packet (of=0xff6a, pkt=0xff9d1628, ost=0x1a98b10, eof=0) at src/fftools/ffmpeg.c:886
[23:34] <vorlon> so how did you manage to get a working gdb?
[23:34] <vorlon> by running against the core file?
[23:35] <mwhudson> yeah
[23:35] <mwhudson> gdb being this broken on armhf does seem kinda bad :(
[23:36] <cyphermox> this isn't going to help though, this is only failing for a single codec, you'd need to have a trace elsewhere that points to something in avcodec/sbc*
[23:36] <mwhudson> uh the line being pointed to is still not very helpful, i think there is inlining going on
[23:37] <vorlon> yeah
[23:37] <cyphermox> :/
[23:37] <cyphermox> I already inspected the code enough to figure out there weren't obvious changes between versions, except for some things in dB calculations which didn't look that crazy either
[23:37] <mwhudson> need a debug build i guess
[23:42] <cyphermox> vorlon: mwhudson: you're looking at ffmpeg 4.1.4, right? not the rebuilt 4.1.3?
[23:42] <vorlon> yes
[23:44] <cyphermox> ...
[23:44] <cyphermox> because ffmpeg 4.1.3-1build1 also segfaults
[23:49] <vorlon> ah, does it?
[23:49] <vorlon> that's rather rude of it
[23:51]  * mwhudson has gotten disctracted trying to debug gdb
[23:52] <mwhudson> same thing happens in a disco container
[23:53] <mwhudson> not bionic though
[23:54] <mwhudson> although it does say this
[23:54] <mwhudson> Cannot parse expression `.L1207 4@r4'.
[23:54] <mwhudson> warning: Probes-based dynamic linker interface failed.
[23:54] <mwhudson> Reverting to original interface.
[23:55] <cyphermox> I got as far as you did with the output_packet() trace, but no farther
[23:59] <mwhudson> apparently gdb does something with systemtap