[01:19] <mup> PR snapd#3964 opened: many: implement our own ANSI-escape-using progress indicator <Created by chipaca> <https://github.com/snapcore/snapd/pull/3964>
[07:15] <zyga-ubuntu> o/
[08:08] <mup> Bug #1717900 opened: Confined snap fail for user with homedir in /var/lib <Snappy:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1717900>
[12:12] <mup> PR snapd#3965 opened: interfaces/mount: add support for parsing x-snapd-{mode,user,group}= <Created by zyga> <https://github.com/snapcore/snapd/pull/3965>
[13:39] <kalikiana> \o
[13:52] <kyrofa> Hey ogra_, think you might have any free time today to sit down with Chris to talk about gadget snaps?
[13:53] <ogra_> sure
[13:53] <ogra_> kyrofa, any time you like
[13:53] <kyrofa> ogra_, wonderful, thank you, I'll ping you :)
[14:15] <kyrofa> lool, you around?
[14:16] <kyrofa> lool, question about your dnsmasq snap
[14:19] <zyga-ubuntu> hey kyrofa
[14:19] <zyga-ubuntu> how's the event?
[14:19] <kyrofa> zyga-ubuntu, going quite well. Nice to just sit down with these folks and get their stuff working
[14:21] <zyga-ubuntu> kyrofa: what are you working on there?
[14:22] <apol> https://pastebin.com/neAd9iPU
[14:26]  * zyga-ubuntu wonders why removing unused code makes tests fail
[14:26] <zyga-ubuntu> it must have been _slightly_ used :/
[14:28] <zyga-ubuntu> ah wait, master is broken!?
[14:28] <zyga-ubuntu> or artful is broken
[14:29] <Son_Goku> everything is broken, zyga-ubuntu
[14:35] <kyrofa> zyga-ubuntu, got a few roboticists here working on snapcraft updates and snapping their stuff
[14:37] <zyga-ubuntu> kyrofa: sounds great, tweet a few pics, that stuff is very interesting to people
[14:42] <mup> PR snapd#3966 opened: cmd/snap-seccomp,osutil: make user/group lookup functions public <Created by zyga> <https://github.com/snapcore/snapd/pull/3966>
[14:53] <morphis> davidcalle: is there any target date when docs.ubuntu.com will be refreshed?
[14:57] <davidcalle> morphis: afaict, there is a deployment outage since sep 21st, I'm running one now, will ping you when I know more
[15:09] <morphis> davidcalle: ok, thanks
[15:11] <__chip__> zyga-ubuntu: how's things?
[15:11] <zyga-ubuntu> __chip__: hey
[15:11] <zyga-ubuntu> __chip__: climbing out of the rm -rf hole but making progress
[15:12] <__chip__> zyga-ubuntu: sergiusens could use some pointers, i hear
[15:13] <zyga-ubuntu> __chip__: about?
[15:13] <__chip__> zyga-ubuntu: climbing out of the rm -rf hole
[15:13] <__chip__> zyga-ubuntu: although in his case i think it's a "do git clone in the wrong place" hole
[15:13] <__chip__> or git reset?
[15:14] <__chip__> i dunno
[15:14] <__chip__> it sounded nasty so i didn't listen, just in case he wanted me to fix it
[15:16] <cratliff> @ogra_   Hey,  would you be available to look at making a gadget snap with me?
[15:16] <nothal> cratliff: No such command!
[15:16] <zyga-ubuntu> __chip__: I killed my data last week
[15:16] <cratliff> ogra_
[15:23] <ogra_> cratliff, sure, where are you ?
[15:23] <cratliff> ogra_  I'm in the snapcraft room on the conference floor, but it is a little full in here if me coming to you works.
[15:24] <ogra_> ah, i'll come down in 20-0min then (need to finish a test )
[15:24] <ogra_> *20-30
[15:24] <ogra_> and i wanted to see the snapcraft room anyway
[15:24] <cratliff> ogra_ thanks, cya then.
[15:25] <nacc> sergiusens: i found another case of plugins on classic not dtrt -- the python pluginn invokes /usr/bin/env in the rewrite: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/python.py#L370
[15:25] <ogra_> (if it is to full we can go to the ballroom or some such ... )
[15:25] <nacc> sergiusens: the whole code needs to be audited for that, IMO
[15:25] <nacc> *if* one tries to modify LD_LIBRARY_PATH and that wrapper gets invoked, you get segfaults when mismatchinng host and classic snap distribution :)
[15:26] <nacc> and no built-in way to avoid it
[15:31] <nacc> for a classic app, does snapd setup LD_LIBRARY_PATH for the app? To refer to the core snap? Can I assume that in my own environment (so I can say prepend my snap's library paths)?
[15:32] <ogra_> bschaefer, i cant get the card to misbehave :/ so i guess i'll need the one where you are actually seeing the breakage ... were you using it on pi2 or pi3 ?
[15:32] <bschaefer> ogra_, raspi3
[15:32] <ogra_> yeah, thats what i'm trying it on
[15:33] <bschaefer> yeah i got the things installed i need so you can get this one if you want, ive not had the issue
[15:33] <bschaefer> since ive manually mounted the overlay.tar
[15:33] <bschaefer> or ... w/e it was
[15:33] <bschaefer> but yeah umm you can take this one as well and i can use that one
[15:33] <bschaefer> ogra_, what room are you in?
[15:34] <ogra_> bschaefer, at the end of the same corridor you are
[16:06] <mup> PR snapd#3967 opened: release: release snapd 2.28 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3967>
[16:07] <jamesh> nacc: IIRC, snapcraft will set flags to try and link using -rpath to point at the core snap
[16:08] <jamesh> rather than setting LD_LIBRARY_PATH for you
[16:08] <jamesh> depending on your app's build system, that might not take effect though
[16:09] <ogra_> cratliff, sorry, will still take a bit up here ... i'm in 1419 though in case you want to come upstairs
[16:14] <nacc> jamesh: ok, so in theory, do I need to specify LD_LIBRARY_PATH for *classic* snaps to force my app to use only my snap's libs and the core snap's libs?
[16:14] <cratliff> ogra_, no problem.  Does after lunch work well?
[16:17] <nacc> jamesh: specifically, since a 16.04-built classic snap with a 16 core could run on artful, it's *really* important not to use libs from the host.
[16:17] <jamesh> nacc: if your project's build system respects the LDFLAGS environment variable,  it should end up with an rpath that will search common paths in both itself and the core snap
[16:18] <nacc> jamesh: ok, let me try that
[16:18] <jdstrand> kyrofa: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/5
[16:18] <mup> Bug #1598309: The aplay command doesn't work <snapd-interface> <xenial> <snapd (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1598309>
[16:21] <jamesh> nacc: try running "objdump -x /path/to/my/exe | grep RPATH"
[16:22] <nacc> jamesh: i have had to do stuff in my own wrappers so far, because I will get thinngs like man in my snap not finding the custom-built /usr/lib/man-db in my snap
[16:22] <nacc> jamesh: will do
[16:22] <jamesh> nacc: that should show up paths that will be searched before the default library locations
[16:22] <jamesh> if it doesn't show anything, then you might need to alter your project build system to make use of LDFLAGS
[16:22] <nacc> jamesh: are you sure what you describe is true for classic snaps?
[16:23] <ogra_> cratliff, sure
[16:23] <ogra_> popey, moop moop
[16:23] <jamesh> nacc: yes.  You can see the logic in Snapcraft's build_env() function at /usr/lib/python3/dist-packages/snapcraft/internal/project_loader/_env.py
[16:24] <ogra_> popey, oh ... unmoop ...
[16:24] <popey> wat wat
[16:25] <nacc> jamesh: ok, man for instance is installed via stage-packages
[16:26] <nacc> in any case, i'll try it
[16:27] <nacc> jamesh: i'm really curious if this is tested with builds on xenial run on artful?
[16:28] <jamesh> nacc: if the executable isn't being built under control of snapcraft (as would be the case if you're pulling executables from the Ubuntu archive), then you wouldn't see the rpath
[16:28] <jamesh> nacc: it would be up to you to handle it
[16:29] <jamesh> either by trying to patch in an rpath, or use a wrapper shell script that configures LD_LIBRARY_PATH instead
[16:30] <jamesh> patchelf can add an rpath to an existing binary, but sometimes fails
[16:30] <nacc> jamesh: ok, so there are two cases, got it
[16:31] <jamesh> (it isn't always possible to modify an already linked executable)
[16:44] <nacc> well, fwiw, (jamesh is gone), the python3 generated in the classic snap by using the pythonn plugin also does nont have any RPATH set
[16:51] <nacc> core snap's ldd references a host path
[16:51] <nacc> (/bin/sh)
[16:52] <nacc> err, /bin/bash
[16:56] <davidcalle> morphis: it will be deployed at some point in the next hours (https://docs.staging.ubuntu.com/core/en/stacks/network/index) , IS is looking into it.
[17:23]  * nacc is super-confused, the bash in the core snap also has no rpath
[17:24] <nacc> so was jamesh wrong earlier?
[17:24] <nacc> and if i try to run binaries from the core snap restricting LD_LIBRARY_PATH i get segfaults (Probably implies I'm being too strict)
[17:25] <ogra_> nacc, snaps do a pivot_root when running ... how do you check ?
[17:26] <ogra_> nacc, http://paste.ubuntu.com/25621829/
[17:26] <nacc> ogra_: classic snaps too?
[17:26] <ogra_> nacc, thats a zyga-ubuntu question
[17:26] <nacc> ogra_: ok
[17:26] <nacc> zyga-ubuntu: --^ :)
[17:26] <nacc> i assume they *don't* otherwise they couldn't use the host at all
[17:27] <nacc> but if they don't, none of the core snap makes much sense
[17:27] <nacc> debugging all of this has really not been fun, and makes me thinks classic snaps on artful may just be sort of broken (even if they happen to work some of the time)
[17:28] <nacc> ogra_: your paste makes total sense on core and with confined snaps (to me)
[17:29] <ogra_> they could use the host if they pivot and then bind-mount half the host ;)
[17:29] <nacc> i hope that isn't how it's done :)
[17:29] <nacc> but it might be, true
[17:29] <nacc> and i guess snapd has privilege to do that before running the app
[17:30] <nacc> ogra_: but i still don't see any actual use of rpath in the core snap's binaries
[17:30] <ogra_> (which they do via /var/lib/snapd/hostfs/ i think)
[17:30] <ogra_> well, the core snap is built from debs ... iirc rpath isnt allowed in debs
[17:30] <nacc> ogra_: ok, so maybe there is snapd voodoo for that on classic, for core snap binaries
[17:31] <nacc> the problem is, I have almost no way of knowing if that is true :)
[17:31] <ogra_> https://wiki.debian.org/RpathIssue
[17:31] <ogra_> "While there's no policy dictating the accepted use of RPATH, it's been a general consensus that RPATH use is discouraged, given the interactions between the above reasons and Debian's way of dealing with libraries and package dependencies. "
[17:53] <pstolowski> jdstrand, hey, what conf room are you in?
[17:53] <zyga-ubuntu> pstolowski: hey
[17:53] <zyga-ubuntu> pstolowski: how's the event?
[17:53] <pstolowski> zyga-ubuntu, it's good!
[17:58] <ogra_> mvo, https://github.com/snapcore/snapd/pull/2105
[17:58] <mup> PR #2105: snapstate: only import defaults from gadget on install <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2105>
[17:59] <ogra_> mvo, https://github.com/CanonicalLtd/ubuntu-image/pull/72
[17:59] <mup> PR CanonicalLtd/ubuntu-image#72: Make sure <unpack>/image/etc gets into the system-data directory <Created by warsaw> <Merged by warsaw> <https://github.com/CanonicalLtd/ubuntu-image/pull/72>
[18:08] <nacc> is it possible that while building a snap, one part (e.g., mine that builds xz-utils) gets staged/built, and then a subsequent part that depends on it (dpkg), sees the xz binary in stage, but rpath hasn't been modified on it yet, so it, at runtime, tries to load core libs, instead of libs from my snap?
[18:08] <kyrofa> nacc, rpath hasn't been modified one... what? xz?
[18:09] <kyrofa> s/one/on/
[18:09] <nacc> kyrofa: yeah, on the staged xz
[18:09] <nacc> i'm wondering about the order here
[18:09] <nacc> http://paste.ubuntu.com/25622009/
[18:09] <nacc> is the error dpkg's autopoint is spitting out
[18:09] <kyrofa> nacc, the first bit makes total sense: if part A builds "after" part B, part B will be staged before A is built
[18:09] <nacc> which feels like a mismatch between the just built xz and the libs being loaded
[18:10] <kyrofa> Ah, this sounds like an LD_LIBRARY_PATH ordering issue
[18:10]  * __chip__ might be having too much fun right now
[18:10] <mup> PR snapd#3968 opened: daemon: use client.Snap instead of map[string]interface{} for snaps <Created by chipaca> <https://github.com/snapcore/snapd/pull/3968>
[18:10] <nacc> kyrofa: maybe? i'm not setting it at all
[18:11] <nacc> kyrofa: this is during the build
[18:11] <kyrofa> nacc, yeah but snapcraft does. Checking...
[18:11] <nacc> kyrofa: yeah :)
[18:11] <kyrofa> nacc, this is a classic snap, I assume?
[18:11] <nacc> kyrofa: so i can confirm the core snap's liblzma is XZ_5.0 while my built one is XZ_5.2
[18:11] <nacc> kyrofa: yep
[18:16] <davidcalle> morphis: It's live
[18:17] <nacc> kyrofa: would i need to write my own plugin in the short-term?
[18:18] <kyrofa> nacc, I suspect something odd is happening in snapcraft itself, particularly in snapcraft/internal/project_loader/_env.py
[18:18] <kyrofa> Could the LDFLAGS be going wrong there?
[18:19] <nacc> kyrofa: it could be (although i don't know how to debug that) -- but also, how is it finding my just built xz? I don't see PATH manipulation there
[18:21] <kyrofa> nacc, look at runtime_env there
[18:23] <nacc> kyrofa: but that's for runninng binaries, not building them?
[18:23] <nacc> or is the xz now a runtime
[18:23] <nacc> kyrofa: bbiab
[18:24] <kyrofa> nacc, yeah the name is perhaps a bit misleading: it still gets evaluated for the build env
[18:24] <kyrofa> sgclark, SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft
[18:25] <sgclark> thanks!
[18:30] <ogra_> pstolowski, https://docs.ubuntu.com/core/en/reference/interfaces/index
[18:33] <kyrofa> Hey ogra_ any idea why we're using /etc/profile to add /snap/bin to the path? Is there no way to do it without a login shell?
[18:44] <__chip__> kyrofa: hey, what's that about /etc/profile and login shells?
[18:45] <ogra_> kyrofa, the only other way is /etc/environment and that can only be changed for new installs ...
[18:46] <__chip__> well, there is environment.d
[18:46] <ogra_> kyrofa, we could surely talk to foundations (hey slangasek ) about adding /snap/bin to /etc/environment in new artful installs by default as we do since a while on ubuntu core images
[18:47] <ogra_> __chip__, is that finally landed ?
[18:47] <kyrofa> ogra_, yeah it's odd to have different behavior depending on how you're logging in, e.g. we have someone here trying to package mosh
[18:47] <ogra_> (i only know thats a lennart plan but havent heard anyone implemented it yet in a stable distro)
[18:48] <ogra_> kyrofa, if you're logging in it should always work
[18:48] <__chip__> ogra_: I don't think we've got it yet, no, definitely not in x
[18:48] <kyrofa> ogra_, over ssh
[18:48] <kyrofa> mosh doesn't run a login shell, so you have to give it an absolute path to the mosh server
[18:48] <__chip__> kyrofa: fun fact: fedora (and rhel?) load profile.d from non-login shells as well
[18:48] <ogra_> kyrofa, if you're logging in it should always work (and surely does with ssh ... ) if you do *not* log in ssh will strip your path
[18:49] <ogra_> kyrofa, but thats an ssh thing ...
[18:49] <ogra_> kyrofa, anyway ... what needs to happen to have it globally is to add it to /etc/environment ... and by poloicy we do not touch it on installed systems
[18:50] <__chip__> kyrofa: why doesn't mosh run a login shell?
[18:50] <ogra_> *policy
[18:51] <ogra_> kyrofa, the issue is that when using snapd on other distros we can not control /etc/environment (unless they have environment.d support as __chip__ pointed out) ... so there profile.d is the only way
[18:52] <kyrofa> ogra_, this is what needs to work in order for e.g. mosh to work: https://pastebin.ubuntu.com/25622245/
[18:52] <kyrofa> __chip__, no clue
[18:52] <kyrofa> __chip__, https://github.com/mobile-shell/mosh/issues/182
[18:53] <kyrofa> __chip__, not a mosh user myself
[18:53] <kyrofa> More of an SSH+screen guy
[18:58] <jdstrand> pstolowski: 1413
[19:01] <pstolowski> jdstrand, k, will be there in a few minutes
[19:03] <ogra_> kyrofa, well, the only way currently is to make mosh use 'ssh sh -l -c "<command>"' instead of 'ssh "<command>"'  ... there is also elopio's bug 1659719 that explains it
[19:03] <mup> Bug #1659719: ssh can't call a binary from a snap without the full path <isv> <Snappy:Fix Committed by ogra> <livecd-rootfs (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1659719>
[19:07] <kyrofa> ogra_, how is that fix-committed for snappy?
[19:08] <kyrofa> Or is that just ubuntu core, and it should also apply to snapd?
[19:50] <mup> PR snapcraft#1570 closed: Don't fail over empty or faulty lines <Created by aleixpol> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1570>
[19:50] <mup> PR snapcraft#1571 closed: Make sure we don't try to include an empty set <bug> <Created by aleixpol> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1571>
[19:50] <kyrofa> jdstrand, your alsa workaround got us further, but now we're getting a denial on /dev/snd/controlC0. snappy-debug suggests the alsa plug, but we're already using it
[20:08] <__chip__> niemeyer: https://forum.snapcraft.io/t/2268 <- let me know if that seems reasonable, you
[20:15] <mup> PR snapd#3969 opened: hooks: rename refresh hook to post-refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/3969>
[20:25] <pstolowski> mvo, ^
[20:25] <mvo> pstolowski: hm? could you please paste it again?
[20:26] <pstolowski> mvo, sorry, sure - https://github.com/snapcore/snapd/pull/3969
[20:26] <mup> PR #3969: hooks: rename refresh hook to post-refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/3969>
[20:26] <mvo> pstolowski: ta
[20:26] <pstolowski> i hope the branch name is accurate ;P
[20:27] <nacc> kyrofa: i'm here now
[20:32] <kyrofa> cratliff, https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives
[20:33] <nacc> kyrofa: did you have any furhter thoughts? this is a relatively big blocker for me right now
[20:38] <nacc> kyrofa: i'm going to try reordering my build
[20:38] <nacc> we don't really care about usinng the new xz in dpkg's build, I do't think
[20:40] <ogra_> compression is overrated anyway :P
[20:41] <nacc> heh
[20:41] <nacc> well, SOVERSION'd compression ;)
[20:49] <ogra_> kyrofa, the bugy is fix comitted for Ubuntu Core (Snappy) and livecd-rootfs, snapd had at a similar time the fix in profile.d (which was the only sane thing we could do from a cross distro perspective)
[20:50] <ogra_> (sorry, only just noticed you answered above)
[21:01] <kyrofa> cratliff, https://forum.snapcraft.io/t/service-ordering
[21:02] <nacc> kyrofa: cool, i think orderign (after adding some deps), is letting dpkg build
[21:02] <nacc> kyrofa: but it does imply a snapcraft bug if the ordering breaks the build inn a non-obvious way
[21:03] <kyrofa> nacc, yes I'd say so
[21:03] <nacc> kyrofa: i'll add it to my backlog of bugs to file :)
[21:50] <mup> PR snapcraft#1573 opened: WIP project_loader: parse YAML without processing it <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1573>
[21:57] <nacc> kyrofa: any ideas? http://paste.ubuntu.com/25623175/
[22:09] <nacc> kyrofa: that's pygit2 from a part using the python snap
[22:09] <kyrofa> nacc, are you using python from the archive?
[22:11] <nacc> kyrofa: yes
[22:13] <mup> Bug #1719747 opened: Fedora 26 LXD container: cannot load apparmor profile <Snappy:New> <https://launchpad.net/bugs/1719747>
[22:14] <kyrofa> nacc, sergiusens will know more, but I seem to remember an issue with that, e.g. it's hard-coded to the wrong libc or something. We had to build our own Python in snapcraft to get around it


[02:50] <lifeless> wgrant: hey
[02:51] <lifeless> wgrant: is there a good thing around for generating comprehensive per-project stats of bugs?
[02:51] <lifeless> wgrant: specifically # opened/day, # changed state/day # commented on by non-devs/day etc?
[02:52] <wgrant> lifeless: No existing API script that I know of.
[02:56] <lifeless> nuts
[02:56] <lifeless> thanks
[06:21] <stub> wgrant: So I think that @inlineCallbacks decorator is required because, despite having the result tossed away, the yields does let the reactor do its thing and all the processing completes before it returns and gets its result tossed
[06:22] <stub> I seem to be able to hold twisted in my head for about 3 days before I forget how it fits together :-/
[06:27] <wgrant> Hum, that shouldn't work :/
[06:29] <wgrant> stub: Where does the exception show up if you raise one after a yield in resumeProcessing?
[06:42] <stub> wgrant: https://pastebin.canonical.com/101029/
[06:46] <stub> Its all so lovely and magical ;)
[06:47] <stub> I thought I understood how it was working, but that might have just been me rationalising observed behaviour.
[06:59] <stub> The request invokes resumeProcessing for the producer to actually produce something. It doesn't care what it returns, as it is responsible for spitting out the data. It can do this asynchronously if it wants.
[07:00] <wgrant> Yeah, but normally in Twisted you have to return the deferred up to the reactor before it's executed.
[07:41] <lifeless> wgrant: huh? no
[07:41] <lifeless> wgrant: the reactor holds references to things it will fire like protocols and callLaters
[07:42] <lifeless> wgrant: you return defereds so that your caller can attach a callback
[07:43] <wgrant> lifeless: But a deferred won't fire until it has a callback attached, will it?
[07:43] <wgrant> Hm, though I guess that doesn't matter here.
[07:44] <lifeless> no
[07:44] <lifeless> defereds can fire before the callback is attached
[07:45] <wgrant> stub: Anyway, if resumeProducing is allowed to do nothing immediately I suppose that works.
[07:52] <stub> yes, resumeProducing is invoked and expected to eventually produce the result. Its actual return value is ignored.


[08:27] <laney> xnox: different dependency per arch, so the symlinks happened differently, so the trailer is different
[10:57] <cpaelzer> I should take a old-style paper-note about it as I think I ask this the third time but what exactly is the big_packages sizing in regard to memory
[10:58] <cpaelzer> I see it was broken out from the old repo and now is controlled via https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs
[10:58] <cpaelzer> but neither has revealed me the actual size and canonistack does not list the flavor that https://autopkgtest-cloud.readthedocs.io/en/latest/administration.html#give-a-package-more-time-or-more-resources refers to
[12:36] <bdmurray> cpaelzer: https://wiki.ubuntu.com/ProposedMigration#autopkgtests
[12:40] <cpaelzer> thank you bdmurray
[12:40] <cpaelzer> and gladly that confirms we get the 8G that match Debian with it
[13:16] <xnox> laney:  leh sigh
[16:29] <schopin> Could a kind soul with the proper accesses trigger autopkgtests on this PPA for all arch but s390x, on impish, for the openssl package ? ~schopin/openssl3
[16:34] <bdmurray> schopin: Could you craft the urls for those tests?
[17:17] <Tenkawa> Is there a way to manually call dpkg-deb to use xz or gz in Impish instead of zstd in Impish if needed for building backwards compatible archives?
[17:17] <Tenkawa> oops on the 2 Impish'es there
[17:18] <Tenkawa> or a configuration variable set would be fine too.
[17:35] <cjwatson> Tenkawa: -Zgzip or -Zxz
[17:35] <cjwatson> Tenkawa: if it's being called via dh_builddeb (which is usual), then "dh_builddeb -- -Zgzip" etc.
[17:37] <Tenkawa> cjwatson: ok… thanks.. I was looking at the script and thats what I thought.. I wasn't sure if that was all but thought so.. I'll give it a go shortly.. thanks
[17:37] <cjwatson> Tenkawa: but zstd support was added all the way back to xenial, so this is unlikely to be necessary just for backward-compatibility
[17:38] <Tenkawa> I am not 100% convinced the destinations are all going to be ubuntu and that might be what happened
[17:38] <cjwatson> (in bionic at release time; in xenial as a fairly recent stable update, in order to support Launchpad)
[17:39] <Tenkawa> just debian format
[17:39] <Tenkawa> I just got a bug report that my archive format changed
[17:39] <Tenkawa> in testing
[17:40] <Tenkawa> I just started upgrading to Impish to evaluate upgrading the porting
[17:41] <Tenkawa> thats been the only hiccup so far
[17:41] <Tenkawa> for arm64 on Raspberry PI 4 and Odroid N2+
[17:43] <Tenkawa> Thanks again for the help.. Going to go give it a try. Will sit around for a bit.. Have been very impressed by what I've seen in the last few days
[18:13] <ginggs> bdmurray: looks like schopin left, but I've triggered them https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=openssl&ppa=schopin/openssl3&trigger=openssl/3.0.0~~beta1-1ubuntu1~ppa6
[18:14] <bdmurray> ginggs: Great, thanks!
[18:14] <ginggs> np!
[20:17] <Eickmeyer> I have a versioning question. I'm wanting to update jackd2 in Impish, but it's currently a sync from Debian with a ~dfsg on it. I know that when Debian releases an update, it'll likely be the same version with the ~dfsg, but since it's a repack, if I attempt to resync it the tarball won't be the same.
[20:17] <Eickmeyer> How can I version this so that it can be resynced when the time comes?
[20:18] <Eickmeyer> I'm thinking jackd2_1.9.19~dfsg~0.orig.tar.gz (for the tarball, for instance.)
[22:15] <jbicha> Eickmeyer: I don't think we have a standard naming convention for that so IMO that's fine. You could also ask Debian if they'd be willing to upload the new version to experimental now
[22:17] <Eickmeyer> jbicha: The entire multimedia team is MIA right now. :/
[22:19] <GunnarHj> Eickmeyer: I'd replace ~0 with -0, i.e. hyphen instead of tilde.
[22:20] <Eickmeyer> GunnarHj: Unfortunately, that has the effect of overriding any future sync of the same package version.
[22:21] <GunnarHj> Eickmeyer: Wouldn't the Debian version be -1 ?
[22:21] <Eickmeyer> GunnarHj: Yes, but not the tarball.
[22:22] <GunnarHj> Eickmeyer: Ah, sorry, it's late here...
[22:22] <Eickmeyer> GunnarHj: No worries. :)
[22:28] <dbungert> May I interest someone in a retest click?  I'd like to unblock linux-meta for what I believe to be a flaky test in casper https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=casper&trigger=linux-meta/<IP_ADDRESS>.23&trigger=linux-signed/5.13.0-12.12&trigger=linux/5.13.0-12.12
[23:25] <rbasak> Eickmeyer: ideally, ask the Debian maintainer to kindly use the same repack. Failing that you can do things with versioning like you suggested, but I wouldn't worry about trying too hard - tarball mismatches can be annoying but so is annoying versioning, and you'll probably move on to a future upstream tarball eventually anyway.
[23:26] <rbasak> ~ubuntu maybe, rather than ~0, to make it clear?
[23:26] <rbasak> It doesn't need a number any more than we version our repacks for a particular upstream release.
[23:32] <bdmurray> I retried casper
[23:34] <dbungert> bdmurray: thanks!  I'm looking into the flakiness as this seems to be not a new problem.
[23:39] <Eickmeyer> rbasak: Ok, I'll go with ~ubuntu. Thanks!


[01:19] <StevenK> wgrant: Looks like there are 18 or so legitimate failures, most of them related to query counts.
[01:20] <StevenK> And one very strange one where the sharing service seems to generate a completly bong query.
[01:20] <StevenK> wallyworld: ^ Let me get you a traceback
[01:20] <wallyworld> ok
[01:23] <StevenK> wallyworld: http://pastebin.ubuntu.com/1077406/
[01:23]  * wallyworld looks
[01:26] <wallyworld> StevenK: so, you have code that i don't, but the callto getPeopleWithoutAccess in trantitionToInfoTyoe in branch is being done with people=[]
[01:27] <StevenK>             blind_subscribers = service.getPeopleWithoutAccess(
[01:27] <StevenK>                 self, self.subscribers)
[01:27] <wallyworld> so self.subscribers must be empty
[01:28] <wallyworld> or so it seems
[01:29] <StevenK>     + Subscribers: [<Person at 0x10071b50 eric (Eric the Viking)>]
[01:30] <wallyworld> from the sharing service code:
[01:30] <wallyworld>         # Find the people who can see the artifacts.
[01:30] <wallyworld>         person_ids = [person.id for person in people]
[01:30] <wallyworld> the onbly way person_ids can be [] is if people is empty
[01:31] <wallyworld> so i'm not sure what's happening
[01:31] <wallyworld> can you pastebin your code?
[01:31] <StevenK>     + Subscribers: [<Person at 0xeed1e90 eric (Eric the Viking)>]
[01:31] <StevenK>     + person_ids = [243652]
[01:32] <StevenK> (It's a doctest, so pdb debugging makes me want to kill people.)
[01:32] <wgrant> That's probably the wrong call.
[01:32] <StevenK> Bah, so it is.
[01:32] <wallyworld> ah, i may have found it
[01:32] <StevenK> wallyworld: https://code.launchpad.net/~stevenk/launchpad/new-branch-visibility/+merge/113484
[01:33] <wallyworld> there's also clauses in the result set In(TeamParticipation.teamID, policy_grantees)
[01:33] <wallyworld> maybe policy_grantees is empty
[01:33] <wallyworld> or artifact_grantees
[01:34] <wgrant> That should be a subselect, shouldn't it?
[01:34] <wgrant> So it won't appear as an empty sequence in the textual statement.
[01:34] <wallyworld> perhaps, but it doesn't appear to be coded that way
[01:35] <wgrant> It's a subselect
[01:35] <wgrant>             In(Person.id, person_ids))
[01:35] <wgrant> It has to be that line
[01:36] <wallyworld> why not this line In(TeamParticipation.teamID, policy_grantees)
[01:36] <StevenK> if not person_ids: return [] ?
[01:36] <wgrant> Yeah
[01:36] <wallyworld> or this one In(TeamParticipation.teamID, artifact_grantees)
[01:36] <wgrant> wallyworld: No.
[01:36] <wallyworld> they use the same construct
[01:36] <wgrant> That is on teamparticipation.team, and it uses a subselect
[01:36] <wgrant> Whereas the error is about person.id without a subselect
[01:37] <StevenK> wgrant, wallyworld: http://pastebin.ubuntu.com/1077416/ is the full statement
[01:37] <wgrant> launchpad_dev=# SELECT COUNT(*) FROM branchsubscription WHERE branch = (SELECT id FROM branch WHERE unique_name='~name12/firefox/main');
[01:37] <wallyworld> yes, i have read the code again and person ids doesn't use the sub select
[01:37] <wgrant>  count
[01:37] <wgrant> -------
[01:37] <wgrant>      0
[01:37] <wgrant> StevenK: There is the problem
[01:37] <wgrant> (1 row)
[01:38] <wgrant> StevenK: So you'll want to fix the sharing service to not crash when given no people, but you might also need to fix sampledata.
[01:38] <wallyworld> i don't think the service should be called with no people
[01:38] <wallyworld> if no people, don't call it
[01:39] <wallyworld> but StevenK said above there were people
     + Subscribers: [<Person at 0xeed1e90 eric (Eric the Viking)>]
     + person_ids = [243652]
[01:39] <StevenK> Different call, as wgrant surmised
[01:39] <wgrant> When a statement from a human is in conflict with a traceback, disregard the human statement :)
[01:40] <wallyworld> ok. i believed what i was told :-)
[01:40] <StevenK>         authorised_people = [self.branch.owner]
[01:40] <StevenK>     Unauthorized: (<Branch u'~name12/firefox/main' (1)>, 'owner', 'launchpad.View')
[01:40] <wallyworld> so, the design of getPeopleWithoutAccess was to be called with a non empty list
[01:40]  * StevenK stabs things
[01:41] <wallyworld> i guess i should have added an assert
[01:42] <StevenK> Right, it changes the information type, reconciles access, tries to render Branch:+index, and fails hard because no one has access to the branch.
[01:44] <wallyworld> that also happended at some point with bugs
[01:44] <wallyworld> i think reassigning a private bug
[01:44] <wallyworld> i can't recall the solution, perhaps redirect to the project page with a message i think it was
[01:46] <StevenK> wgrant: The branch in question is PUBLIC, I should create a branchsubscription for the owner anyway?
[01:46] <wgrant> StevenK: All new branches have a subscription created for the owner.
[01:46] <wgrant> They can remove it, of course.
[01:47] <wgrant> But the sample data is a little anomalous.
[01:47] <StevenK> Right, so let's create a subscription
[02:15]  * wallyworld -> buy coffee
[03:40]  * mwhudson stabs the branch vocabulary
[03:57] <lifeless> stub: hi
[03:57] <lifeless> stub: can we catch up soon ? [after morning cofee :)]
[03:57] <stub> lifeless: hi
[03:57] <stub> lifeless: Coffeed up already, been here a while; just offline on IRC
[03:58] <lifeless> cool, let me just change rooms
[04:00] <lifeless> stub: skype or g+; just sent you a g+ invite but skype is running too ... whatever you prefer
[04:11] <StevenK> wgrant: So, query counts?
[04:13] <wgrant> StevenK: Can you paste a failure?
[04:15]  * StevenK fixes another test by use of rSP
[04:16] <StevenK> wgrant: http://pastebin.ubuntu.com/1077548/
[04:18] <wgrant> StevenK: Oh, I guess we still need the shortcircuit for public branches
[04:18] <wgrant> To avoid tripping query tests like that :)
[04:21] <StevenK> wgrant: In IBranch.visibleByUser?
[04:22] <StevenK> Hm, I wonder if this evil hack fixes it
[04:22] <wgrant> StevenK: Yeah
[04:22] <StevenK> wgrant: http://pastebin.ubuntu.com/1077551/
[04:23] <wgrant> StevenK: Exactly.
[04:23] <StevenK> Wow, you approving of code I wrote in anger. :-P
[04:25] <StevenK> wgrant: I'm also getting a wierd failure in lib/lp/registry/browser/tests/poll-views_0.txt
[04:25] <wgrant> Oh?
[04:26] <StevenK> wgrant: http://pastebin.ubuntu.com/1077553/
[04:33] <wgrant> StevenK: Did that fail on ec2?
[04:33] <StevenK> And locally
[04:34] <wgrant> StevenK: I don't care about locally. ec2 is all that's interesting :)
[04:34] <StevenK> Oh, hah. It failed on ec2 with [<storm.databases.postgres.PostgresConnection object at 0x168662d0>]
[04:34] <wgrant> Yeah
[04:34]  * StevenK ignores it at spurious 2.7 garbage
[04:34] <StevenK> s/at/as/
[04:34] <wgrant> Nah
[04:35] <StevenK> wgrant: And thoughts on http://pastebin.ubuntu.com/1077556/ ?
[04:35] <wgrant> StevenK: It's because of the local timezone.
[04:35] <StevenK> Haha
[04:35] <StevenK> Polls fail
[04:35] <wgrant> Test fail
[04:36] <wgrant> It uses datetime.now() and assumes launchpad will interpret it the same way.
[04:36] <StevenK> Polls need to die horribly anyway
[04:39] <spm> StevenK: wgrant: I note you both always want features to die horribly. have you considered maybe having them be tastefully removed instead?
[04:40] <StevenK> spm: They don't deserve it.
[04:41] <spm> that wasn't my implication
[04:41] <spm> I might have been alluding to deep and disturbing psychological problems that are currently assailing two of my close colleagues. might.
[04:42] <spm> there's probably room for a "trolling" in that description too
[04:42] <StevenK> spm: Polls are special. They have been removed once, and then it turned out a few community teams required them to elect new members, so they were added back.
[04:42] <spm> lovely
[04:45] <StevenK> spm: You're not implying that wgrant and I are closet psychopaths? :-)
[04:45] <spm> sure I was
[04:45] <wgrant> Closet!?
[04:45] <spm> point
[04:45] <spm> it could be a very BIG closet
[04:51] <StevenK> wgrant: Can has look at pastebin?
[04:56] <wgrant> StevenK: Something may have been preloading subscriptions before.
[04:56] <wgrant> StevenK: Check the old query log to see what's different
[05:03] <StevenK> wgrant: bin/test -m test_pillar_sharing -t test_view_query_count still runs four tests, can I nail it down further?
[05:03] <wgrant> StevenK: -t specifies a regex
[05:03] <wgrant> Multiple regexes are ORed
[05:04] <wgrant> So -t test_pillar_sharing.*test_view_query_count might work
[05:04] <wgrant> Otherwise -t test_pillar_sharing.TestProductSharingDetailsView.test_view_query_count should be pretty specific
[05:09] <StevenK> wgrant: http://pastebin.ubuntu.com/1077582/ is the test on devel, all 2500 lines of output
[05:11] <wgrant> StevenK: I was more interested in just the interesting bit.
[05:11] <StevenK> Yeah, I'm just looking how to get the statement recorder to print out what it saw.
[05:13] <wgrant> StevenK: Reduce the limit to 1
[05:13] <StevenK> Haha, that would do it too, I suppose
[05:14] <StevenK> wgrant: Interesting bit: http://pastebin.ubuntu.com/1077587/
[05:19] <wgrant> StevenK: Ah, I was looking at the wrong test
[05:20] <wgrant> StevenK: Given that it's viewing +sharing, it's probably logged in as the product owner
[05:20] <wgrant> StevenK: And you'll never guess who owns the branches that it creates.
[05:20] <StevenK> Hahah
[05:20] <wgrant> So the test is buggy
[05:20] <wgrant> It verifies that the query count is constant, but only in a very exceptional case.
[05:21] <StevenK>     def makeArtifactGrantee(
[05:21] <StevenK>             self, grantee=None, with_bug=True,
[05:21] <StevenK>             with_branch=False, security=False):
[05:21]  * StevenK stabs wallyworld
[05:21] <wallyworld> why?
[05:21] <StevenK> For crimes against PEP8
[05:22] <wallyworld> could be worse
[05:30] <spm> yeah. could be stabbed for not providing cake to deserving webops staff
[05:31] <StevenK> spm: Hahaha
[05:32] <StevenK> wgrant: So what do you think the plan is?
[05:33] <wgrant> StevenK: Well, see what the query count is if the owner is someone else. I suspect it'll be the same with the new and old code.
[05:33] <wgrant> StevenK: That's an important bug, but not a regression.
[05:45] <StevenK> wgrant: Modulo being distracted by Sarah, http://pastebin.ubuntu.com/1077619/
[05:46] <wallyworld> spm: but i gave you some cake
[05:46] <spm> yeah. could be stabbed for not providing non-virtual cake to deserving webops staff
[05:46] <spm> fixed.
[05:47] <wallyworld> if i had one of those "beam me up scotty" things i could send you some
[05:49] <stub> 🎂
[05:51] <StevenK> wallyworld: Money can be exchanged for goods, such as cake, and services, such as cake delivery to Canberra.
[05:51] <wallyworld> StevenK: ssshhh
[05:52] <wgrant> StevenK: I wonder if the user might be an admin, then.
[05:52] <wgrant> StevenK: It doesn't explicitly log in, AFAICT
[05:52] <wgrant> So it might be running as some user tha happens to leak from the factory.
[05:53] <StevenK> Hahahaha
[05:53] <StevenK> TestProductSharingDetailsView.setUp calls login_person(self.owner)
[05:54] <wgrant> StevenK: Right, that's what I expected. But then I wonder why the test works even after you change the branch owner.
[05:54] <StevenK> Well, it's only a query count
[05:55] <StevenK> I've not looked deeply into what that view is doing
[06:00] <wgrant> StevenK: Well, it's somehow doing an access check in 0 queries.
[06:00] <StevenK> wgrant: Shall we just bump the test from 12 to 26 and move on for the time being?
[06:07] <wgrant> StevenK: No. You need to work out why there are 0 queries initially.
[06:07] <StevenK> There can't be zero. Is no understand
[06:08] <wgrant> StevenK: http://pastebin.ubuntu.com/1077619/ shows 0 access checking queries.
[06:10] <StevenK> wgrant: What about the last one that UNIONs against BranchSubscription?
[06:13] <wgrant> StevenK: Right, it only finds visible branches, same as with your changes, but then it doesn't do any subsequent checks.
[06:13] <wgrant> I can't see any code to prefill the authorization cache.
[06:14] <wgrant> So I don't know what's going on
[06:15] <StevenK> So where is there the actual view code? I've yet to find it
[06:18] <wgrant> StevenK: lp.registry.browser.pillar
[06:19] <StevenK> WTF? That code doesn't help at all
[06:20] <wgrant> Hm?
[06:20] <wgrant> PillarPersonSharingView is what you're looking for
[06:25] <StevenK> Indeed, how does this even work?
[06:28] <StevenK> wallyworld: Maybe you could help? How is PillarPersonSharingView managing to do its work in 0 queries?
[06:29] <wallyworld> context?
[06:29] <wallyworld> when did this start happening?
[06:30] <StevenK> wallyworld: http://pastebin.ubuntu.com/1077619/ and http://pastebin.ubuntu.com/1077587/ and http://pastebin.ubuntu.com/1077556/
[06:34] <wallyworld> StevenK: the one with 25 queries, what changes were done for that?
[06:34] <StevenK> wallyworld: That branch is my new-branch-visibility branch that uses APG and AAG to determine branch access rather than subscriptions
[06:34] <StevenK> wallyworld: The other two pastebins are against devel
[06:35] <wallyworld> ok
[06:37] <wallyworld> so the question you want to know i think is why changing the branch owner to some other person other than the pillar owner reduces the query count
[06:38] <wallyworld> StevenK: do all the other tests pass, other than the query count one?
[06:40] <StevenK> wallyworld: bin/test -vvt test_pillar_sharing == Ran 40 tests with 1 failures and 0 errors in 1 minutes 4.142 seconds.
[06:40] <wallyworld> StevenK: so looking at the devel branch with owner=someperson, the query count has just been reduced by 1, no?
[06:40] <wallyworld> ie down to 10
[06:41] <StevenK> Which makes no sense to both wgrant and I
[06:41] <wallyworld> what's your concern?
[06:42] <wallyworld> (save me trying to grok the sql)
[06:42] <wgrant> The issue is not that changing the owner reduces the query count.
[06:42] <wgrant> It's that it doesn't increase it.
[06:42] <wgrant> Somehow the old code is taking 0 queries to do security proxy access checks.
[06:42] <wgrant> The new code is doing one per branch.
[06:44] <wallyworld> i see that the old code has an extra person select
[06:44] <wallyworld> at the end
[06:45] <wallyworld> so where are the SP checks you are expecting?
[06:46] <wallyworld> the work to load the data is primarily done by accesspolicy stuff at the db level
[06:49] <StevenK> wallyworld: Where at the DB level?
[06:49] <wgrant> wallyworld: It's not the DB level that's the problem
[06:49] <wgrant> It fetches the branches from the DB, then the securityproxies need to verify launchpad.View
[06:49] <wgrant> In devel at present the launchpad.View checks take no queries
[06:49] <wallyworld> StevenK: in the queries performed by findArtifactsByGrantee
[06:50] <wallyworld> wgrant: but the current code return no branches
[06:50] <wallyworld> unless i am wrong
[06:51] <wallyworld> the initial tests were written only for bugs
[06:51] <wallyworld> since branches didn't support info type etc then
[06:52] <wgrant> wallyworld: That's actually not a crazy thought.
[06:52] <wgrant> Except that this should have broken last week when we started adding AAGs.
[06:53] <wallyworld> why?
[06:53] <wallyworld> if the tests didn't create any branches
[06:53] <wallyworld> then nothing would have broken
[06:53] <wgrant> Oh, did the test change?
[06:53] <wallyworld> not afaik.
[06:54] <wallyworld> the test never created any branches to check
[06:54] <wallyworld> i think
[06:54] <wgrant> Does so.
[06:54] <wallyworld> there's a bunch of test modules that need to have extra tests for branhces added
[06:54] <wgrant>     def makeArtifactGrantee(
[06:54] <wgrant>             self, grantee=None, with_bug=True,
[06:54] <wgrant>             with_branch=False, security=False):
[06:54] <wgrant>             for x in range(0, 15):
[06:54] <wgrant>                 self.makeArtifactGrantee(person, True, True, False)
[06:55] <StevenK> So it makes 15 bugs and branches
[06:55] <StevenK> And then dies when the query count increases by 15.
[06:55] <wallyworld> but are any of those branches included in the results
[06:55] <wgrant> Not until last week
[06:55] <wallyworld> right ok
[06:56] <wgrant> But I don't see how this branch could change the set of branches that is found.
[06:57] <StevenK> But it doesn't? The queries that are added are all access checks
[06:57] <StevenK> If Branch and BranchSubscription are cached by earlier queries which sounds likely, the query count would be low
[06:57] <wallyworld> i'm still not sure why we expect changing the owner will change the results returned
[06:57] <wgrant> StevenK: BranchSubscription doesn't appear to be cached.
[06:57] <wgrant> It's not even cachable.
[06:58] <wgrant> StevenK: It's used as part of the query's internal access check, but it's not returned.
[06:58] <wgrant> wallyworld: I was expecting that we were hitting the branch owner short-circuit.
[06:58] <wgrant> But StevenK reports that the query count remains low even when a non-owner is used.
[06:58] <wallyworld> well it dropped from 11 to 10
[06:59] <StevenK> Yes, defined as 'remains low'
[06:59] <StevenK> Rather than 26
[06:59] <wallyworld> so with bugs, they are bulk loaded
[06:59] <wallyworld> not sure about branches
[06:59] <wgrant> Right, bug searches generally automatically populate the access cache.
[06:59] <wallyworld> that's why this query count test was added
[07:00] <wallyworld> since initially the query count was linear
[07:00] <wallyworld> just like it appears to be now for branches
[07:01] <wgrant> Exactly. The question is how that happens, and why it stops working.
[07:02] <wgrant> I suspect there isn't actually any prepopulation of the access cache. We're just hitting another short-circuit somewhere.
[07:02] <wgrant> So the test is buggy.
[07:03] <wallyworld> why is the test buggy?
[07:03] <wallyworld> it verifies that the query count is independent of nr of bugs
[07:03] <wgrant> It's asserting query count linearity, but it looks like it's only linear in a special case that the test hits, rather than the general case.
[07:04] <wallyworld> it used to fail though before changes were made
[07:04] <wallyworld> to fix it
[07:04] <wallyworld> fix the code i mean
[07:04] <wallyworld> i can't recall what was done though
[07:05] <wallyworld> it's not asserting linearity, it's ensuring there is no linearity
[07:05] <wgrant> Er, yeah, that.
[07:05] <wgrant> Sub-linearity :)
[07:08] <wallyworld> well, the intent is that the query count doesn't increase as the number of artifacts increases
[07:08] <wallyworld> who is to say it can't decrease by 1 or 2
[07:08] <wallyworld> depending on what the exact data is
[07:08] <wgrant> wallyworld: That's not the issue
[07:08] <wgrant> That issue is that somehow the old code is not issuing extra queries
[07:08] <wgrant> The new code is
[07:08] <wgrant> The new code needs to not
[07:09] <wgrant> But we can't work out how the old code manages to not
[07:09] <wallyworld> so fix the new code :-)
[07:09] <wgrant> So we can't make the new code not.
[07:09] <wgrant> StevenK: Breaking on visibleByUser in the old code didn't reveal anything useful?
[07:09] <wallyworld> wgrant: i'm not sure how did old code did its thing, too long ag
[07:09] <wallyworld> ago
[07:10] <wgrant> Indeed, I didn't really expect you to remember :)
[07:10] <wallyworld> wgrant: bugtasks = list(getUtility(IBugTaskSet).search(param))
[07:10] <wallyworld> that's what the old code does to load the bugs
[07:11] <wallyworld> where param has the bug ids
[07:11] <wallyworld> param = BugTaskSearchParams(user=user, bug=any(*bug_ids))
[07:11] <wallyworld> iso it's whatever IBugTaskSet does
[07:11] <wgrant> Yes, bugtaskset precaches authorization
[07:11] <wgrant> But branchcollection appears not to
[07:12] <wallyworld> yes
[07:12] <wallyworld> so isn't that the answer?
[07:12] <wallyworld> the old code for branches
[07:12] <wallyworld>             all_branches = getUtility(IAllBranches)
[07:12] <wallyworld>             wanted_branches = all_branches.visibleByUser(user).withIds(
[07:12] <wallyworld>                 *branch_ids)
[07:12] <wallyworld>             branches = list(wanted_branches.getBranches())
[07:13] <wgrant> Hmmm?
[07:13] <wgrant> The answer to how it avoids queries is not "it's not precached"
[07:13] <wgrant> That's the anti-answer :)
[07:13] <wallyworld> no, i meran bugtaskset precahces, so eliminates queries
[07:13] <wallyworld> branch collection does not
[07:13] <wallyworld> so queries increase
[07:14] <StevenK> So, I think the 10th query in the devel test is IBranchCollection.visibleByUser()
[07:14] <wgrant> But *something* manages to avoid an access query for the 15 branches in the old code!
[07:14] <wgrant> The key thing is to identify what that is.
[07:14] <StevenK> I'm not certain why it is called 15 times, but only generates one query
[07:14] <StevenK> Well, I'm certain why it's called
[07:14] <wallyworld> so it must be in branchcollection
[07:14] <StevenK> branchcollection gives me a headache
[07:14] <StevenK> It's horrible
[07:14] <wallyworld> yep
[07:19] <wgrant> StevenK: So how many times is the visibleByUser called in the problematic context, in devel?
[07:19] <StevenK> wgrant: 15
[07:20] <wgrant> StevenK: And what does stepping through it show it doing?
[07:21] <StevenK> wgrant: Hold on a moment, visibleByUser returns a collection
[07:21] <StevenK> So it probably returns all fifteen in one query
[07:21] <wgrant> StevenK: I mean Branch.visibleByUser, not *BranchCollection.visibleByUser
[07:21] <StevenK> Branch.visibleByUser is not called
[07:26] <StevenK> wgrant: http://pastebin.ubuntu.com/1077708/
[07:28] <wgrant> StevenK: Hm
[07:28] <wgrant> StevenK: Of course, the alternate explanation is that the user can't actually see any of the branches in the devel test.
[07:28] <wgrant> StevenK: So there's nothing returned to check access on.
[07:28] <wgrant> StevenK: Can you check that hypothesis?
[07:29] <wgrant> The project owner will be able to see them in your branch, due to the APG
[07:32] <StevenK> wgrant: self.branches in PPSV is []
[07:32] <StevenK> (for devel)
[07:33] <wgrant> StevenK: Ha ha hahhah
[07:33] <wgrant> That explains it.
[07:33] <StevenK> [<Branch u'~person-name-100003/product-name-100004/branch-100010' (77)>, ...] for my branch
[07:34] <StevenK> So it caches nothing and was a useless test
[07:34] <wgrant> It's good for bugs.
[07:34] <wgrant> Just not branches.
[07:34] <wallyworld> it was designed primarily for bugs
[07:34] <wallyworld> branches weren't done yet
[07:34] <StevenK> So it's awesome that we've wasted a few hours bashing our head against it
[07:34] <wgrant> Which is unsurprising, given that branches didn't know about the access schema when it was written
[07:35] <StevenK> wgrant: So, 12 -> 26 and move on? Please?
[07:35] <wgrant> StevenK: Do file a critical bug about it, but yes.
[07:35] <adeuring> good morning
[07:38] <StevenK> wgrant: https://bugs.launchpad.net/launchpad/+bug/1021622
[07:38] <_mup_> Bug #1021622: PillarPersonSharingView uses O(n) queries for branch access <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1021622 >
[07:38] <wgrant> StevenK: Thanks.
[08:08] <czajkowski> morning
[08:42] <cjwatson> Err, I just got http://paste.ubuntu.com/1077762/ from an ec2 land run - should I be concerned?
[09:49] <cjwatson> Oh, well, it didn't do it again on a retry ...
[10:29] <danilos> cjwatson, then it does mean you should be worried :)
[11:34]  * cjwatson starts to understand the layout of .../browser/ and .../templates/ and feels something else leaking out of his ears as counterbalance
[13:32] <deryck> adeuring, https://plus.google.com/hangouts/_/977b4ffbaf4a8c42a0f41a913e0632048bf13e25?authuser=0&hl=en
[13:49] <jam> benji: you landed some stuff in the lazr code (and launchpadlib) that seem to be dealing with httplib2 0.7+ (which enables ssl validation by default).
[13:49] <jam> I'm trying to land some of that in launchpad itself (because I want a patch to launchpadlib's test suite to pass on py2.7)
[13:50] <jam> however, httplib 0.7 breaks launchpad's test suite because of the ssl validation.
[13:50] <jam> is it sane to just set the env var for the test suite/
[13:50] <jam> ?
[13:51] <benji> jam: I'm trying to remember that branch... oh, I think that is the one by jml; yeah, setting the env. variable for the test suite would work.
[13:58] <jam> benji: where/when would that get set in the lp test suite?
[13:59] <benji> jam: hmm, let me look
[13:59] <jam> maybe in a layer?
[13:59] <jam> LPFunctionalLayer is the one the specific test I'm looking at right now.
[14:01] <benji> jam: that might work; if you wanted to set it globally, doing it in buildout-templates/bin/test.in would make sense
[14:07] <cjwatson> What's a sensible way to write a test that attempts to open a URL on the appserver that traverses to one on the librarian?
[14:07] <cjwatson> I can use setupBrowserForUser to get something that knows how to open URLs on the appserver, and urlopen to open librarian files, but I can't seem to find something that works for both
[14:07] <cjwatson> (I'm in LaunchpadFunctionalLayer)
[14:16] <jam> benji, bac, jcsackett: I just committed and uploaded launchpadlib-0.10.2 (as approved). Can you upload it to pypi? I can do everything but that step.
[14:16] <jml> jam, benji: let me know if I can help.
[14:17] <benji> jam: if you're going to be making releases, then you should have pypi access; give me your pypi user name and I'll give you access
[14:19] <benji> jam: to clarify, we don't upload releases to pypi, we just register them (although, we should upload them in my opinion, but that's a seperate issue)
[14:20] <jam> benji: I did mean register, and my pypi name is jameinel, let me double check, though.
[14:20] <jam> benji: yeah, jameinel
[14:21] <benji> jam: you're all set
[14:21] <jam> jml: so the patch you requested ends up *requiring* httplib2 0.7+ because it is passing a parameter that doesn't exist in 0.6
[14:21] <jam> however, using 0.7 means that the test suite aborts all over the place because by default the ssl certificate is checked and fails
[14:22] <jam> I'm guessing we want to push forward, and fix that, rather than changing the patch to be backward compatible?
[14:22] <jml> jam: I think so. 0.6 isn't even the version in lucid.
[14:23] <jam> jml: it is the version in versions.cfg :)
[14:24] <jam> jml: the problem right now is that I set the env var in bin/test, and if I drop into pdb I see it set, but the test still fails
[14:25] <jml> jam: interesting. I had to make changes both to launchpadlib and to lazr.restfulclient. Perhaps only one is up-to-date?
[14:26] <mpt> jml, what's "LoC neutrality"? Is it removing as many LoC as you add?
[14:26] <jml> mpt: yes.
[14:27] <jam> jml: something is stripping the env variable in "launchpad_for()
[14:27] <jml> jam: remind me which code-base that function is in?
[14:27] <jam> as in, it is set, I break on _request and then it is no longer set
[14:27] <jam> lazr.restfulclient._browser.Browser._request is the chain that ends up failing
[14:27] <jam> which you updated to support the flag
[14:28] <jam> the test I'm running is: lp.bugs.browser.tests.test_bugattachment_file_access.TestWebserviceAccessToBugAttachmentFiles.test_user_access_to_private_bug_attachment
[14:32] <jam> I'm sure I'm running updated code, as I'm getting the error: SSLHandshakeError: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed: perhaps set LP_DISABLE_SSL_CERTIFICATE_VALIDATION if certificate validation failed and you genuinely trust the remote server.
[14:32] <jam> which means it asks me to set the variable I have set.
[14:33] <jml> jam: pulling latest stable
[14:34] <jml> jam: what's launchpad_for() ?
[14:35] <jml> oh launchpadlib_for
[14:36] <jam> jml: so... I can see that the value is being seen inside _browser
[14:37] <jam> self.disable_ssl_certificate_validation is True
[14:37] <jam> and I'm still getting an SSL handshake failure...
[14:37] <jml> jam: perhaps I missed a place in my patch? can you paste the full stack?
[14:38] <jml> jam: also, I thought you were reporting that the env var is unset at the time of error?
[14:39] <jam> jml: lp:///~jameinel/launchpad/py27-introduction-1020667
[14:39] <jam> jml: I thought that was the problem, as I was still getting the error.
[14:39] <jml> jam: ah right.
[14:40] <jam> But no, it is set, and tracking down I see RestfulHttp.__init__
[14:40] <jam> sees the disabled flag correctly
[14:40] <jam> and after super()
[14:40] <jam> super().__init__()
[14:40] <jam> self.disable_ssl_certificate_validation is True
[14:41] <jml> then my bet is that there's a request I missed
[14:41] <jml> in the absence of more information, like a stack trace. (which I'll get soon, once I up download-cache, make schema and run the test)
[14:41] <jam> jml: http://pastebin.ubuntu.com/1078135/
[14:42] <jam> jml: you'll need to update download-cache as well
[14:42] <jam> once I actually commit the new packages
[14:42] <jam> done
[14:42] <jam> rev 498 of download-cache
[14:43] <jam> anyway, I'm at my EOD here, so if you want to poke at it, that would be great.
[14:43] <jam> but it can wait until monday as well.
[14:44] <jam> jml: (this is all just fallout of trying to get a small 2-line patch to make introduction.txt not fail when run under python-2.7, so I'm trying to avoid fixing-the-world just to get that changed. But I want to do the 'right' thing as well)
[14:44] <jml> jam: I can see how this is annoying.
[14:45] <jam> anyway, enjoy your weekend
[14:45] <jml> jam: you too
[14:45] <cjwatson> Maybe the correct answer (to my question above) is to manually follow the first redirect to the librarian.
[14:48] <jml> forgot to switch to lxc
[15:36] <jml> mpt: what prompted that?
[15:36] <mpt> jml, just saw you mention it in a mailing list message, and I hadn't seen it mentioned before, that's all
[15:37] <jml> mpt: oh right. it's a short-hand for Launchpad's broader "no increased maintenance burden" policy
[15:37] <mpt> I see
[15:38] <mpt> If you want a list of features to remove to make up the numbers... ;-)
[15:38] <czajkowski> mpt: only if we can submit the same amount for you to remove elsewhere on design :)
[15:47] <sinzui> Speaking of LoC, I think I need to get the knives out and cut code to help my self-esteem.
[15:51] <jml> mpt: heh, there's actually plenty of code that can be removed without affecting functionality one whit.
[15:52] <mpt> czajkowski, there are almost certainly ways to make Launchpad prettier by reducing the amount of CSS. Would that count?
[15:52] <jml> yeah.
[15:53] <czajkowski> mpt: huw is working on that atm when he's not working on other areas, he's been fixing the layout of side bars and this week fixed links on the blog
[15:53] <mpt> grand
[15:57] <sinzui> mpt, huwshimi is landing such a branch now. I also pointed out out bug about the obsolete portletBody classes
[16:26] <jml> w t f.
[16:26] <jml> bzr just started thinking that my lp:divmod.org branch was a Launchpad branchh
[16:27] <jelmer> jml: how do you mean, aren't all lp:... branches Launchpad branches?
[16:27] <jml> jelmer: as in a branch of lp:launchpad
[16:27] <jml> jelmer: the .bzr/branch/location was a URL to the branch of jam's I just checked out.
[16:27] <jml> jelmer: I'm guess pebkac, but ... wow.
[16:28] <jelmer> jml: that is a bit scary..
[17:11] <cjwatson> I'd love a review of https://code.launchpad.net/~cjwatson/launchpad/queue-api-fix-urls/+merge/113776, if anyone's still around; nearing the end of this arc, and if I can land it today then I can QA it over the weekend and hopefully delete lots of code on Monday


[11:51] <ahasenack> good morning
[13:23] <sforshee> xnox, apw: I've got new wireless-regdb packages if one of you could sponser them when you get a chance: https://launchpad.net/~sforshee/+archive/ubuntu/wireless-regdb
[13:40] <utkarsh2102> rbasak: hey, I am going to take a look today and tomorrow and sort this out!
[13:40] <utkarsh2102> sorry for the delay, this is next in my list of things to do
[13:54] <rbasak> utkarsh2102: I've already been looking
[13:55] <rbasak> utkarsh2102: so leave it for now please. I think it's a regression in MySQL 8.0.28 and I'm mostly through writing a reproducer.
[13:57] <schopin> Anyone know of any documentation on how to package a new upstream version using git-ubuntu (if that's supported?)
[14:02] <rbasak> schopin: I don't think the git-ubuntu CLI has a specific tool to automated it for you, if that's what you're asking.
[14:02] <rbasak> The importer should accept the result in the normal way though.
[16:20] <schopin> ahasenack: thanks for keeping me in the loop for freeradius, much appreciated. Is the EAP-MD5 issue tracked anywhere?
[16:21] <ahasenack> schopin: plain eap-md5 works
[16:21] <ahasenack> it's when used inside ttls that the client I selected for testing refused to accept it
[16:21] <ahasenack> I was just in copy & paste mode by then
[16:22] <ahasenack> schopin: the freeradius PR is up, https://code.launchpad.net/~ahasenack/ubuntu/+source/freeradius/+git/freeradius/+merge/415870
[16:32] <ahasenack> schopin: eap-md5 through ttls was already like this with my 3.0.25+patches build, I just didn't check another ubuntu release to be sure it's a change in behavior
[16:32] <ahasenack> there is time for that after FF
[16:40] <schopin> ahasenack: BTW, are you expecting me to review the MP? Given the size of it, I'm not sure I'd be able to get to it before FF
[16:51] <ahasenack> if you want, but no, not expecting
[16:51] <ahasenack> you could take a glance, see if you spot anything obviously wrong, but really it's the upstream snapshot, no extra patches
[16:52] <ahasenack> in fact, I dropped the patches I had added to 3.0.25 to get it to work/build with openssl3
[17:04] <bluca> anybody from the kernel team around? it would be really great to have CONFIG_WATCHDOG_HRTIMER_PRETIMEOUT enabled for Jammy
[17:04] <bluca> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1961771
[17:05] <bluca> I'm looking to add a watchdog test for systemd upstream autopkgtest, and we'd use that feature when we rebase to jammy
[18:08] <ahasenack> what happens in terms of component mismatches when a package in main has a Depends with "a | b"? Are both "a" and "b" required to be in main?
[18:08] <ahasenack> in this example, "b" is in main
[18:08] <ahasenack> Depends:
[18:08] <ahasenack>  wireguard-dkms (>= 0.0.20200121-2) | wireguard-modules (>= 0.0.20191219),
[18:09] <ahasenack> I'm wondering about this in the wireguard MIR (https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1950317) if I should seed "wireguard" or "wireguard-tools"
[18:09] <ahasenack> (the depends paste above is missing a line which pulls in "wireguard-tools")
[18:09] <ahasenack>  wireguard-dkms (>= 0.0.20200121-2) | wireguard-modules (>= 0.0.20191219),
[18:09] <ahasenack>  wireguard-tools (>= ${source:Version}),
[18:09] <ahasenack> I'm wondering about the wireguard-dkms bit, I don't want that in main
[18:10] <ahasenack> rbasak: do you know? ^
[18:12] <rbasak> ahasenack: I think wireguard is just a contentless metapackage?
[18:12] <rbasak> So -tools only we need
[18:13] <ahasenack> yes, wireguard is a metapackage
[18:13] <ahasenack> but so if someone disabled universe, "apt install wireguard" won't work, that's the experience I wanted to avoid
[18:14] <rbasak> I don't think anyone actually disables universe nowadays
[18:14] <rbasak> So I'm not sure it's worth caring about that too much. The right thing to do would be to install the wireguard-tools package only.
[18:15] <ahasenack> ok, agreed
[18:20] <ahasenack> rbasak: https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/platform/+merge/415920 pretty please? :)
[18:25] <jpeisach_> hey, i'm ItzSwirlz on another account
[18:25] <jpeisach_> who maintains libsdl2-dev? it is broken on jammy
[18:25] <rbasak> ahasenack: done
[18:25] <jpeisach_> causes systemd issues, nearly broke my system trying to develop InfiniTime stuff
[18:25] <ahasenack> rbasak: \o/
[18:26] <ahasenack> that seems to be... server team (!)
[18:26] <ahasenack> https://launchpad.net/ubuntu/+source/libsdl2
[18:26] <jpeisach_> that  would explain why it tried going for my desktop components only
[18:26] <jpeisach_> im updating my system but if i confirm it i'll dm them
[18:27] <ahasenack> see if the issue is here, if not, report it: https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bugs?orderby=-id&start=0
[18:27] <ahasenack> although, keep in mind there are many transitions going on right now, it might be a temporary issue
[19:22] <rbasak> bryyce: did you know about shuf(1) from coreutils?
[19:29] <bryyce> rbasak, no, and not surprised I reinvented the wheel with shuffle ;-)
[19:29] <bryyce> I actually needed that code for shuffling m3u files which needs shuffling pairs of lines
[19:54] <sarnold> rbasak: re disabled universe, I think the 'live system' installer is main only, every now and then we have to instruct folks how to enable universe to install whatever it is they want installed
[19:56] <rbasak> sarnold: that's good to know, thanks.
[19:56] <rbasak> I don't think that changes my opinion though. Those users should `apt install wireguard-tools` if they want it, and `apt install wireguard` would be wrong (since they don't need the DKMS package).
[19:57] <rbasak> Unfortunately the name of deb packages conflate implementation with UX in users' eyes, so this isn't perfect, but that's how it is.
[19:58] <rbasak> Or, I suppose we could maintain a delta to drop the wireguard-dkms dependency in Ubuntu since Ubuntu-shipped kernels already include that functionality. But that's maybe not worth it.
[19:59] <sarnold> yeah, I'm not sure maintaining a delta just to handle this is worth it, but it'd probably be a low-effort delta..
[20:15] <seb128> sarnold, if the debian maintainer is friendly you can get a dynamic depends generation from debian/rules in Debian and stay in sync
[20:17] <ahasenack> that delta is easy
[20:17] <ahasenack> I'm just unsure we won't be reintroducing a bug
[20:17] <ahasenack> the history of that depends ordering is complicated, from what I could gather
[20:20] <ahasenack> I can ask apw again tomorrow (it's past his EOD)
[20:37] <mmikowski> Hey team, we at Kubuntu Focus are looking at ways to provide customers with better system rollback solutions.
[20:37] <mmikowski> We have a working prototype with luks+lvm+ext4 which is nice, but the snapshot sizes grow very quickly and it requires a good deal of additional disk space.
[20:38] <mmikowski> The other approach we were looking at is luks+btrfs (no luks). This appears to work well as POC, but I was curious what others felt about this setup.
[20:39] <mmikowski> fwiw, almost-FDE is completely a requirement here.  Also, if there is interest in adding an upstream option we can certainly contribute our work.
[20:41] <ahasenack> mmikowski: ubuntu has zsys, introduced in one of the previous releases, which uses zfs, and a very specific zfs dataset layout
[20:41] <ahasenack> it integrates with grub, and has the rollback functionality
[20:41] <ahasenack> I haven't tried it recently, though
[20:42] <ahasenack> mmikowski: https://github.com/ubuntu/zsys
[20:42] <ahasenack> and https://discourse.ubuntu.com/t/zfs-focus-on-ubuntu-20-04-lts-blog-posts/16355
[20:43] <mmikowski> I really like the idea of ZFS a lot, but a risk analysis looks rough :P
[20:44] <ahasenack> I think apt has a hook for btrfs, or had at least
[20:44] <ahasenack> have you looked at apt-btrfs-snapshot ?
[20:44] <mmikowski> Yes, apt-btfs-snapshot is there.
[20:44] <mmikowski> Already using it?
[20:45] <ahasenack> I don't, I'm in the zfs camp ;)
[20:45] <mmikowski> also snapper
[20:45] <ahasenack> but I don't use rollbacks in zfs either, I use it just so it's easy to send backups
[20:45] <ahasenack> regarding your size issue with lvm snapshots, are you doing pruning? Or else you will have the same problem in all solutions
[20:46] <mmikowski> The alure is to let users to update after a botched upgrade or ill-advised package install.
[20:46] <mmikowski> *update = rollback
[20:49] <ahasenack> in the zsys approach, there is a separation between user data and apps
[20:49] <ahasenack> so rolling back won't rollback changes done to your home, for example
[20:49] <ahasenack> iirc
[20:56] <mmikowski> ahasenack: with btrfs, there is also a separation between /home and / on subvolumes.
[20:56] <ahasenack> note I said zsys
[20:56] <mmikowski> Rollbacks are nice, and pretty performant on single disk system.
[20:56] <ahasenack> it's what makes the zsys layout so "complicated", it's not just /home
[20:57] <mmikowski> ahasenack: is zsys distinct from zfs?
[20:57] <ahasenack> it's a tool that manages the snapshots and rollback
[20:58] <ahasenack> using zfs primitives
[20:58] <ahasenack> and it integrates into the ubuntu desktop
[20:58] <ahasenack> so you get grub with support for it (you select in the grub menu what previous snapshot you want to boot into),
[20:58] <ahasenack> adduser creates a new zfs dataset for the user
[20:58] <ahasenack> and so on
[21:00] <mmikowski> Thanks. Yes, we see most of this with btrfs. So with a single or dual disk system it seems to provide similar benefits and stability.
[21:00] <ahasenack> yes
[21:00] <mmikowski> I do know that zfs is far superior with RAID and enterprise features like those previously available with netapp.
[21:00] <ahasenack> the debate goes on :)
[21:01] <mmikowski> But we didn't go down the zfs route too far.
[21:01] <ahasenack> I personally found it much easier to use, it's a nice cmdline interface
[21:01] <ahasenack> but there are some messy things
[23:26] <mmikowski> ahasenack: We are very interested in ZFS and sys. We would need to incorporate somehow into a custom installer. Thank you for the links, and please share if there is more we should do.
[23:26] <ahasenack> np
[23:26] <mmikowski> ahasenack: or any other links you recommend :)
[23:27] <ahasenack> one of those I think has a collection
[23:27] <ahasenack> of links, I mean


 In pcmanfm-qt 0.17.0, there is an option "Reopen last window tabs in a new window" which works as expected. The next time you open the manager, it opens with previously opened tabs. But if the PC shuts down unexpectedly, the history is not saved. My PC sometimes do that which leads to history loss. Isn't there a way to save the history as soon as a tab is opened instead of when the manager is closed? Or is there a way I can run a scri
[07:49] <guiverc> You could try telling the kernel (Linux) to flush buffers to disk (SysRq combination), but I can't recall what keys are enabled for what releases; newer releases have more disabled than older releases.
[07:49]  * guiverc has no idea if that would help, just something I'd likely try
[07:52]  * guiverc switched to terminal, used SysRq S & got a message that told me sync had occurred on my mantic; so that feature is possibly enabled for all releases (unless me on development have more enabled)
 I am not an advanced user so when I ran that I got this: SysRq: command not found
[07:58] <guiverc> SysRq is a key on an IBM compatible keyboard; though it was printed on the front of the key (modern keys are often too flat it's not there, so you need to guess based on older traditional keyboards).
[07:59] <guiverc> You can look up "magic sysrq" on a search engine & the wikipedia page maybe helpful.  Ctrl+Alt+SysRq to initiate command to linux kernel, keep holding ALT down and then hit S
[08:00] <guiverc> SysRq allow us to command the kernel, bypassing any stuck GUI/UI etc... (it won't work on a onscreen keyboard; thus no good for android phones/tables unless real keyboard is being used & features enabled there)
[08:01] <guiverc> if you're using a GUI at the time, you won't spot anything (unless you're able to detect disk activity)... but you'll get messages if using terminal; thus test it there.   Be aware you can kill apps, even reboot/turn off your machine via SysRq commands...
[08:01] <guiverc> (ie. save all data on your GUI session when trying it out)
 Thanks I will get back in a few mins to test it out
[08:03]  * guiverc may not be here, I've got to go out very soon
[08:10] <guiverc> fyi:  the newest dell keyboard I have here is from 2021; it has no sysrq printed; but despite the lack of printing, it still works as expected (on a full keyboard here the key that says "Print Screen" on its top, says SysRq in green on the key-front; just like Pause-key has Break written on key-front (in black)
[08:11] <guiverc> SysRq commands are Linux specific, not Lubuntu; but we use the Linux keyboard thus we can use them
 I got it working. Proof:
 kernel: [ 1039.211575] sysrq: Emergency Sync
 But it sadly didn't save the history.
[11:07] <guiverc> :(  it would only have worked if the program wrote the detail before exit, but it hadn't been 'flushed' to disk sitting in cache (that forces the write of cached data only)..  if the app (pcmanfm-qt) doesn't write until it closes; I'm not aware of how you can get around that, and don't know sorry
[11:07] <guiverc> @vanitas_77 ^
 Thanks for your time though @guiverc  . Maybe I will try switching to a different manager.
[22:17] <boyet> the context menu is garbled when i do a right click. https://paste.pics/670ad72692eafb5c33123b35f3129ebd
[22:22] <boyet> i have an acer swift 3 laptop AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx (8) @ 2.100GHz CPU  with  AMD ATI 03:00.0 Picasso GPU
 Just dropping by to say thanks - lubuntu is driving fine on my travel laptop


[03:05] <ypwong> http://ubuntuone.com/56Vt9O9AVKokluhrXkaPy0
[05:07] <JackYu> ypwong, hi
[05:08] <ypwong> JackYu, hi
[05:09] <JackYu> ypwong, 下午例会安排，3:00-3:30 讨论UK相关packages 的FFE和入库；3:30-4:00 PM，中文化；4:00-4:30 PM，输入法。如何？
[05:10] <JackYu> ypwong, 如果OK就麻烦发个会议邀请出来，抄送给sanbu
[05:10] <ypwong> JackYu,  ok
[05:10] <JackYu> ypwong, thanks:)
[09:04] <ypwong> www.oprilzeng.com/2048/
[22:31] <JackYu> happyaron, are you there?