=== pizzaiolo is now known as pizza
[00:50] <teward> guiverc: oh hello.  I'm testing the tor-browser launcher in my new Impish VM.  I'm going to spin tor browser via the CLI to pull stderr in :P
[00:51] <guiverc> :) thanks teward
[00:53] <teward> guiverc: E:NOREPO
[00:53] <teward> E:NOREPRO *
[00:54] <teward> fresh IMpish VM, fresh torbrowser-launcher run/install
[00:54] <teward> execution seemed to work fine
[00:54] <teward> how'd you execute after torbrowser-launcher installed it?
[00:54] <teward> (FYI torbrowser-launcher only handles the download and extraction of Tor Browser, it does NOT actually contain the tor-browser code)
[00:54] <guiverc> maybe i filed on wrong package - its the execution of the browser I have issues with
[00:54] <teward> (so any issues actually in Tor Browser *itself* (i.e. a crash in the tor browser binaries) is actually an upstream Tor issue and not a torbrowser-launcher issue - I know 'cause i've dug deep.)
[00:55] <teward> guiverc: then that's an Upstream Tor Problem
[00:55] <teward> guiverc: load up your terminal, run `find $HOME -iname '*start-tor-browser*'
[00:55] <teward> find the binary (NOT the desktop files!)
[00:56] <teward> execute the full binary path on the command line, pull any stdout
[00:56] <teward> or stderr
[00:56] <teward> see what *actually* happens behind the scenes
[00:56] <teward> (and again, I'm fairly fluent now in how the torbrowser-launcher scripts work 'cause I had SRU'd some major patches for it)
[00:57]  * guiverc will look in a few mins, after I complete a askubu comment
[01:01] <teward> guiverc: also run torbrowser-launcher on your command line if you want to, get that stderror as well
[01:01] <teward> that way we can actually see any useful error output
[01:01] <teward> though I think it's all Python o.O
[01:03] <teward> yeah to start Tor Browser, it calls a subprocess.call in Python so if it's not starting it's a Tor Upstream problem, but it might be localized to your environment because E:NOREPRO on a fresh Impish VM of Ubuntu (NOT lubuntu, but actual Ubuntu)
[01:03] <guiverc> my primary box has multiple DEs so I'd expect it to work here (GNOME/Ubuntu being one of them)
[01:04] <teward> guiverc: still why i asked :P
[01:06] <guiverc> comment made teward https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/1933886/comments/4
[01:06] <ubottu> Launchpad bug 1933886 in torbrowser-launcher (Ubuntu) "tor browser not launching in impish" [Undecided, Incomplete]
[01:10] <teward> guiverc: `$HOME/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/firefox --class "Tor Browser" -profile $HOME/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser'profile.default "http://cnn.com" 2>*1 </dev/null`
[01:10] <teward> i know that's long
[01:10] <teward> but that's what the start-tor-browser stuff does except disowns by default
[01:10] <teward> so it won't include the stderr and stuff
[01:10] <teward> foo i mistyped
[01:11] <teward> guiverc: `$HOME/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/firefox --class "Tor Browser" -profile $HOME/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser'profile.default "http://cnn.com"`
[01:11] <teward> there
[01:11] <teward> sorry to keep debugging :P
[01:11] <teward> but yeah I can't reproduce this on a fresh Impish
[01:12] <teward> so if this issue exists, unless someone else can reproduce it, I'm going to say "Something on your end is fubar"
[01:12] <teward> :)
[01:13] <guiverc> I'll zsync my ubuntu (impish) ISO & test there.. if it works there, but fails still on lubuntu - the issue maybe related to something in lubuntu & thus not upstream, but a lubuntu config issue maybe
[01:13] <teward> and then something i'll hunt
[01:13] <teward> but if it works fine in an Lubuntu environment then, then I have to start saying "It's a you problem"  ;P
[01:14] <guiverc> I think I see that as a "we" problem... you're lubuntu too :)
[01:14] <guiverc> when you change hats that is :)
[01:14] <teward> guiverc: true. but i don't have an lubuntu test env up yet
[01:14] <teward> ERR: ZSync Asploded
[01:15] <guiverc> thanks teward , appreciated
[01:16] <teward> ywp
[01:31] <teward> guiverc: prodded in #lubuntu-devel because Lubuntu confirmed failed
[01:31] <teward> but it's a segfault
[01:31] <teward> at the browser level so
[01:33]  * guiverc doesn't understand much of what you're saying.. I'm not at your level - but away in askubu as is common
[01:34] <teward> guiverc: basically: software crashes hard
[01:34] <guiverc> the package itself does install & runs correctly.. it even downloads & installs the later version then abends when it tries to run as I see it
[01:34] <teward> guiverc: it's not a problem at the torbrowser-launcher package
[01:34] <teward> it downloads the software
[01:34] <guiverc> (abend - abnormal end; I'm an ex-s390 coder)
[01:34] <teward> and runs it
[01:35] <teward> but the underlying Firefox executable it run segfaults
[01:35] <teward> and hard crashes
[01:35] <teward> i'm going to send to the tor browser UPSTREAM team at Tor to see if they've seen this
[01:36] <guiverc> thanks teward ... I have no issues with it in debian-testing
[01:36] <teward> fyi that Debian is under freeze
[01:36] <teward> so it's technically a bit behind impish
[01:37] <guiverc> yeah I know... I'm in debian publicity, but the few upgrades lets users know anyway
[01:38] <guiverc> i could test in opensuse tumbleweed; have to test something else there for lubuntu anyway when I can
[02:06] <guiverc> yeah teward ; ubuntu impish is good on same box; tor works as expected  (issue appears in lubuntu... since I've yesterday's kubuntu daily I'll try that next .. will add to bug report shortly)
[02:07] <teward> guiverc: check.  i have narrowed down the issue to SOMETHING torbrowser-launcher is doing.  Will probably run the crash logs by Tor upstream to see if they have any ideas, because the hash sums match upstream's stable release exactly for the actual binaries and such executed by the version downloaded by torbrowser-launcher
[02:07] <teward> ... tomorrow.
[02:07] <teward> I'm tired :)
[02:07] <teward> good night.
[02:08] <guiverc> Thanks heaps teward & sleep well !
=== not_phunyguy is now known as phunyguy
=== genii is now known as genii-core
=== not_phunyguy is now known as phunyguy
[09:45] <seb128> xnox, hey, any idea when you will be able to do the initramfs-tools / zstd / bionic SRU?
[09:51] <mwhudson> seb128: hey so you tested my livecd-rootfs branch locally -- how did you run it? i've not been having much luck running it localy lately
[09:51] <mwhudson> and when i run it on launchpad it does this https://launchpadlibrarian.net/545981409/buildlog_ubuntu_impish_amd64_test_BUILDING.txt.gz which makes no sense at all
[09:52] <mwhudson> (the error is "config//lb_chroot_layered: 77: printf: %402.t: invalid directive")
[09:53] <seb128> weird one indeed
[09:55] <mwhudson> it's like the file is being rewritten under the shell or something
[09:55] <mwhudson> (there's no printf on line 77 of that file)
[10:33] <mwhudson> oh wait
[10:33] <mwhudson> seb128: suspect this will fix it https://git.launchpad.net/~mwhudson/livecd-rootfs/+git/livecd-rootfs/commit/?id=f67b58fce8bcd02c343bc952ac6c840f31a1d85e
[10:33] <ubottu> Commit f67b58f in ~mwhudson/livecd-rootfs/+git/livecd-rootfs "attempt to fix obscure failure layer-fixes"
[10:35] <seb128> mwhudson, what's the difference between echo "$var" and echo "%s" "$var"?
[10:35] <mwhudson> seb128: Echo_message uses printf under the hood
[10:35] <mwhudson> so if you have a filename that has a printf directive in it...
[10:36] <mwhudson> anyway i've kicked off a build and will see in the morning if it helped :)
[10:36] <seb128> mwhudson, I see, thanks
[10:37] <mwhudson> and then i can get into why it changes the contents of the layers
[11:34] <seb128> rbasak, the GNOME SRU discussion has been inactive again for a week, anything we can do to help things moving?
[11:40] <rbasak> seb128: how about a realtime sync in a hangout and we'll try to sync on getting it to a conclusion?
[11:41] <seb128> rbasak, wfm
[11:41] <rbasak> I stuck something in the calendar for tomorrow
[11:42] <seb128> rbasak, did you want to get more people in the discussion or just us is enough?
[11:46] <rbasak> seb128: I think just us for now. Let's try to define exactly what is remaining so it isn't open ended, and then if those individual tasks need other people we can get more people involved then.
[11:47] <seb128> rbasak, ack
[11:49] <seb128> rbasak, I don't know when you lunch break but in fact it would work better for me an hour or half an hour earlier if you can, I've an appointement outside after that slot and I will probably need to step out a bit earlier
[11:51] <rbasak> seb128: moved forward an hour.
[11:51] <seb128> rbasak, perfect, thanks
[11:51] <rbasak> seb128: to 1100 UTC, to confirm
[11:51] <seb128> rbasak, yes
[11:51] <seb128> 👍
[11:52] <rbasak> Just because I moved it twice by mistake :)
[11:52] <rbasak> Where it is now is good
[11:54] <seb128> yes, confirmed it works for me and accepted, thanks!
[13:37] <apteryx> hello!  I'm trying to understand why the icons in a custom-made .deb fail to be registered with the system (gtk-update-icon-cache needs to be called manually).  Comparing with other debs, they don't manually have gtk-update-icon-cache in a postinst script, so it seems my deb is lacking something.
[13:39] <apteryx> This page hints at the importance of the md5sums file in the .deb control archive: "Since the AppStream Generator relies on packages' md5sums file to determine the contents of a package, symbolic links are not recognized.", but that's for the Appstream Generator.  Does this thing run at .deb installation time?  Or is it a process running on the Ubuntu build farm side?
[13:50] <seb128> apteryx, in which dir is your deb installing the icons?
[13:50] <seb128> apteryx, the refresh is done by /var/lib/dpkg/info/hicolor-icon-theme.triggers (or similar to the gnome directory)
[14:04] <sil2100> laney: yaaay, some more progress - so one thing that I was debugging with the private-tests on the staging instance was that the private-results app wasn't able to authenticate properly via swiftclient, even though the creds seemed good
[14:04] <sil2100> laney: then finally I noticed that the creds file is malformed! It has additional "" double quotes around all the values
[14:04] <sil2100> Which for conffiles is not valid
[14:05] <sil2100> laney: guess this is something IS needs to fix on their side, so that future deployments with these 'staging private test reader' user are properly formatted without any quotes?
[14:06] <sil2100> It had things like 'username = "the-user"' while it should be just 'username = the-user' etc.
[14:06] <sil2100> With this, the private-result fetcher works like a charm (needed a few smaller fixes but oh well)
[14:10] <laney> sil2100: that's me
[14:11] <laney> look in the /srv/ whatever it is location (check shell history) and fix it in there, then mojo run
[14:11] <laney> the documentation should cover that ;-)
[14:12] <laney> I mean, we should have documentation about how to set this up when we merge the private stuff
[14:16] <sil2100> Aaa, ok! Didn't look for it in the docs even, will do o/
[14:16] <sil2100> I'll fix it uppp
[14:17] <sil2100> Just now experimenting with the britney parts
[14:17] <laney> well this isn't explicitly but config in general is and this comes in via config
[14:17] <laney> but the private stuff should get a bit of documentation too, like the bit about having a separate user and all that, how to get the right information to put in the file
[14:18] <laney> the pieces of the architecture you know
[14:18] <laney> :-)
[14:18] <laney> good you're making progress though
[15:20] <apteryx> seb128: it installs two icons; one at /usr/share/icons/hicolor/48x48/apps/jami.png and another one at /usr/share/icons/hicolor/scalable/apps/jami.svg
[15:21] <seb128> apteryx, then the cache should be updated through the triggers when the deb is installed
[15:21] <seb128> the png one
[15:21] <seb128> svg icons are not cached iirc
[15:21] <apteryx> it also has /usr/share/jami-qt/jami-qt.desktop and /usr/share/metainfo/jami-qt.appdata.xml files
[15:21] <apteryx> the .desktop refers to the icon as 'jami'
[15:22] <apteryx> seb128: is the optional md5sums control file (in the control.tar archive inside the ar'd .deb) used by hicolor-icon-theme.triggers?
[15:23] <seb128> I don't think so
[15:44] <apteryx> OK, thanks.  It's mysterious :-)
[15:45] <apteryx> can you think of a way to debug this?
[15:48] <seb128> apteryx, could you share the deb in a ppa maybe?
[15:49] <jawn-smith> Is any core dev available to restart https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=ubuntu-image&trigger=mtools/4.0.31-1
[15:49] <bryceh> jawn-smith, done
[15:50] <jawn-smith> thanks!
[15:50] <apteryx> I'm not well versed with PPAs but I can share it via an upload to gdrive, if that's workable for you?
[15:50] <apteryx> (the .deb)
[15:50] <apteryx> I'm testing directly via dpkg -i
[15:50] <jawn-smith> This one as well please!
[15:50] <jawn-smith> https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=ppc64el&package=ubuntu-image&trigger=mtools/4.0.31-1
[16:09] <apteryx> seb128: here's the file https://drive.google.com/file/d/16xAtuh0Yri7WAERDjsUBc-GkRtDAfIRL/view?usp=sharing; beware, it's large at 453M.  It carries the whole Guix-provided Qt 5.15.2 + run-time required to run Jami, so can be installed on any GNU/Linux, deb-based distribution (I'm testing on Ubuntu 20.04).
[16:11] <apteryx> it won't install anything outside of /gnu/store except a couple copies (it could be symlinks too) provided for easy integration such as /usr/bin/jami-qt, the icons and the metadata
[16:12] <apteryx> so what I'd expect following installing this .deb is to see the Jami icon in the Dash or elsewhere, but instead I get the generic one (the gears icon).
[16:26] <apteryx> if I then manually run 'for d in /usr/share/icons/*; do sudo gtk-update-icon-cache -f $d; done', the icon is correctly resolved
[17:05] <bdmurray> jawn-smith: I did the mtools ubuntu-image one
[17:05] <jawn-smith> thanks bdmurray
[17:19] <bdmurray> dannf: comment #30 in bug 1908452 says its on focal but the apt-get install command shows groovy...
[17:19] <ubottu> Bug 1908452 in MAAS "MAAS stops working and deployment fails after `Loading ephemeral` step" [High, In Progress] https://launchpad.net/bugs/1908452
[17:21] <dannf> bdmurray: nice catch, my mistake. i was using different machines for each release, and i see that both groovy and focal were on the same one. let me (re?)do the focal verification now
[17:25] <bdmurray> dannf: thanks
=== genii-core is now known as genii
[18:04] <dannf> bdmurray: done
[20:17] <jawn-smith> Any core dev mind giving this another bump? It failed again but in a different place than the first time, so I'm pretty sure it's just flakey.
[20:17] <jawn-smith> https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=ppc64el&package=ubuntu-image&trigger=mtools/4.0.31-1
[20:31] <bdmurray> jawn-smith: done
[20:31] <jawn-smith> thanks again bdmurray
=== genii is now known as genii-core
=== JanC_ is now known as JanC