=== mgedmin_ is now known as mgedmin
[05:26] <didrocks> good morning
[05:30] <duflu> Morning didrocks
[05:30] <duflu> And nothing personal, but bbl
[05:34] <didrocks> hey duflu
[05:34] <didrocks> ;)
[05:47] <oSoMoN> good morning desktoppers
[06:20] <didrocks> and a 3rd reboot due to this extension crashing the Shell!
[06:20]  * didrocks does reboot on reboot since 7am :/
[06:27] <duflu> Morning oSoMoN
[06:44] <jibel> duflu, hi, about bug 1691921 you theory looks right. Yesterday I couldn't open system settings because of "too many open files" so it might be related.
[06:44] <ubot5> bug 1691921 in gnome-shell (Ubuntu) "gnome-shell crashed with SIGTRAP in g_wakeup_new() from g_main_context_new() from g_dbus_connection_send_message_with_reply_sync() from g_dbus_connection_call_sync_internal() from g_dbus_connection_call_sync() ["Creating pipes for GWakeup: Too many open files\n"]" [High,Confirmed] https://launchpad.net/bugs/1691921
[06:48] <duflu> jibel, yeah it's less likely that you'd ever hit "Too many open files" without a leak. Although that can happen
[06:49] <duflu> The default limit is still 1024
[06:49] <duflu> per process
[06:49] <duflu> jibel, hopefully you can identify it by name in /proc/PID/fd/* ?
[06:52] <jibel> duflu, it's set to 2034595 on my system, I'll have a look
[06:52] <duflu> ulimit -n ?
[06:53] <jibel> ah true, 1024
[06:57] <jibel> duflu, 1017 gnome-shell
[06:57] <jibel> 1017 = files in fd/
[06:57] <duflu> jibel, right so something transient released some but it clearly bounced off the limit
[06:57] <duflu> jibel, are they mostly the same name? any name?
[06:57] <duflu> or type?
[06:59] <jibel> duflu, they are all like  980 -> 'pipe:[8531231]
[06:59] <duflu> Hmm, tricky
[07:01] <duflu> jibel, I can only think of spawning external programs (in a buggy way) could cause that. Maybe an extension is running some command periodically?
[07:02] <jibel> duflu, https://paste.ubuntu.com/p/WFMNPZ6Bk8/ is the output of lsof for one of the pipe id
[07:02] <duflu> Or maybe it's a shell and it's meant to spawn programs ;)
[07:03] <duflu> jibel, "JS\x20Hel" sounds like "JS Helper" or something?
[07:05] <duflu> jibel, sounds like an extension is using https://community.algolia.com/algoliasearch-helper-js/ or such in a buggy way
[07:05] <duflu> gnome-shell doesn't seem to use it
[07:06] <duflu> jibel, try grepping the extensions *.js for "JS Help"
[07:07] <duflu> grep -r "JS Help" /usr/share/gnome-shell/extensions/
[07:11] <jibel> duflu, yes it's JS Helper https://paste.ubuntu.com/p/rrbQpW5tqk/
[07:11] <duflu> jibel, yeah I think it must be an extension using that. Just grep the extensions for it
[07:12]  * duflu assumes most of the other 1017 are the same
[07:12] <jibel> duflu, nothing
[07:13] <jibel> and nothing in locally installed extensions
[07:13] <duflu> jibel, grep -ri help.js ?
[07:13] <duflu> or helper.js
[07:14] <jibel> duflu, still nothing
[07:16] <duflu> jibel, OK then time to grep everything on disk, including binaries :)
[07:17] <duflu> Damn. libmozjs-52
[07:18] <duflu> jibel, I found one: package mozjs52
[07:18] <duflu> which I think is used indirectly by gnome-shell
[07:20] <jibel> duflu, http://paste.ubuntu.com/p/yKTgtRtJzB/ all the references to JS Helper from lsof
[07:20] <jibel> definitely not specific to gnome-shell
[07:21] <duflu> jibel, no that's a reverse lookup you did. That's all files in use by process "JS Helper"
[07:23] <duflu> So maybe not the issue after all
[07:23] <duflu> jibel, try:  lsof -c gnome-shell
[07:23] <duflu> and see what most of the 1017 entries are
[07:24]  * duflu is seeing too many references to a deleted file "/i915"
[07:24] <duflu> so that would be mesa-related
[07:28] <jibel> duflu, http://paste.ubuntu.com/p/Fqjf2Y8Tbg/
[07:29] <jibel> most of the entries are pipes
[07:31] <duflu> jibel, I wonder - can you match any of those NODE values to pipes in other processes?
[07:31] <duflu> gnome-shell 7476 j-lallement  153w     FIFO               0,12      0t0 7855742 pipe
[07:31] <duflu> gnome-shell 7476 j-lallement  154r     FIFO               0,12      0t0 7855299 pipe
[07:31] <duflu> gnome-shell 7476 j-lallement  155w     FIFO               0,12      0t0 7855912 pipe
[07:31] <duflu> gnome-shell 7476 j-lallement  156r     FIFO               0,12      0t0 7853797 pipe
[07:31] <duflu> (the second last column)
[07:32] <duflu> Possibly not. More likely they are leaked descriptors to dead pipes
[07:32] <duflu> I think some basic system-monitor type shell exensions might do stuff like that. So try excluding those
[07:33] <jibel> duflu, no, they only exist for process 7476 (gnome-shell)
[07:35] <duflu> jibel, basically it looks like something in gnome-shell has been spawning external commands and not cleaning up. Could be a system monitor extension
[07:36] <jibel> duflu, I had a system-monitor extension enabled. It's removed now and I'll monitor the number of open files to see if it fixes the situation
[07:36] <duflu> Cool
[07:47] <seb128> good morning desktopers
[07:49] <duflu> Morning seb128
[07:49] <seb128> hey duflu, how are you?
[07:50] <jibel> salut seb128
[07:51] <duflu> seb128, going well. How are you?
[07:52] <willcooke> hi gang
[07:52] <willcooke> chrisccoulson, the thunderstorms have failed to arrive. again
[07:53] <didrocks> hey seb128, willcooke
[07:53] <chrisccoulson> willcooke, we got a some lightning at 4am, and I got up to cover the garden furniture
[07:53] <chrisccoulson> but the actual storm passed a few miles to our west and it didn't rain in the end
[07:55] <duflu> Hi willcooke
[07:59] <seb128> hey jibel willcooke didrocks
[07:59] <seb128> we had like 3 drops yesterday evening
[08:00] <seb128> didn't help to lower the temperature at all, still 27°C inside and 37°C forecasted today
[08:00] <willcooke> :(
[08:00] <willcooke> 24 outside here, 28 in the house!!
[08:00] <seb128> lucky you!
[08:00] <didrocks> 28.3°C inside already :(
[08:01] <seb128> go work in the garden :)
[08:01] <didrocks> it's already 28°C outside here
[08:01] <Laney> yo
[08:01] <seb128> hey Laney, how are you?
[08:01] <didrocks> hey Laney
[08:03] <Laney> hey seb128 didrocks
[08:03] <Laney> good thx, travelling to debconf later today
[08:03] <Laney> you?
[08:05] <seb128> oh right, debconf
[08:05] <seb128> safe travel!
[08:05] <seb128> I'm good, waiting for the rain that should arrive tonight/tomorrow and drop the temperature
[08:06] <seb128> Laney, you made version unhappy :/
[08:06] <Laney> oh how?
[08:07] <Laney> I ran it on my system and it worked
[08:07] <seb128>   File "versions.py", line 35, in <module>
[08:07] <seb128>     from ssl import CertificateError
[08:07] <seb128> ImportError: cannot import name CertificateError
[08:07] <Laney> meh must be some version problem on that box
[08:07] <seb128> could have to do with the version on lillypilly
[08:07] <Laney> precise
[08:07] <Laney> WTFFFFFFFFFFFFFFF
[08:08] <seb128> sorry :/
[08:08] <didrocks> containers containers containers containers containers :)
[08:08] <seb128> troll day right?
[08:09] <duflu> Every day is troll day
[08:09]  * seb128 not falling into that one today, trying to get some work done while it's not too hot to think :p
[08:09] <duflu> (for trolls)
[08:10] <didrocks> not a troll, just a why they exist :)
[08:10] <duflu> or channeling Steve Balmer
[08:10] <didrocks> ok, that part for the troll one ;)
[08:11] <seb128> containers are not a justification to not update machines to a modern OS version though
[08:12] <didrocks> well, as long as it's supported, from an IS standpoint, I can understand… (and it's not rare)
[08:12] <seb128> yeah, well it's easy enough to
[08:12] <seb128> yeah, well it's easy enough to make that script work on precise
[08:12] <didrocks> yep
[08:12] <seb128> containers are a big hammer for that small nail
[08:12] <didrocks> right, but for a while, production was broken (which was OK for our use case)
[08:13] <seb128> because we don't have a "pull, try, revert if fail" machinery
[08:13] <seb128> containers don't protect you either from buggy commits
[08:14] <seb128> I mean they have use but are not a megical solution
[08:14] <seb128> anyway, I said no trolling :p
[08:14] <Laney> 'buggy'
[08:14] <didrocks> sounds like you want to troll ;) but at least testing on Laney's machine == what you deploy in production, that was my point
[08:14] <seb128> I'm not saying that one was buggy
[08:14] <Laney> I guess ESM changes that precise is not properly supported
[08:14] <seb128> just that containers don't protect you from everything automagically
[08:15] <seb128> I was not speaking about that particular commit!
[08:15] <didrocks> did I say that it was magic? ;)
[08:15] <Laney> haha
[08:15] <seb128> tendency of the modern world
[08:15] <didrocks> just highlighting that in that case, it would have prevented that issue
[08:15] <didrocks> nothing more :)
[08:15] <Laney> yeah then I could have run the docker script to check the actual environment it was going to be deployed in
[08:16] <Laney> ;-)))))))))))))))))))))))))))))))))))
[08:16] <seb128> yeah, it's fine if that 100 lines script requires a 1GB of disk for the container and 3G of ram to have a webengine and a datacenter to run
[08:16] <didrocks> Laney: you are not even sure that -updates are installed on the machine
[08:16] <seb128> energy is infinite and why would you want to be efficient
[08:16] <seb128> waste for the win!
[08:16] <didrocks> seb128: most of containers, if properly done aren't that big :p
[08:17] <didrocks> but it requires effort to streamline it, agreed
[08:17] <seb128> still more cpu and resources used that being native code on the host
[08:17] <didrocks> true
[08:17] <seb128> but yeah modern world is not about optmization
[08:17] <Laney> CPU used by me fixing this up now
[08:17] <seb128> it's about doing the less work and putting the cost on the infra
[08:18] <Laney> and us talking about it
[08:18] <Laney> !!!!!!
[08:18] <seb128> haha
[08:18] <Laney> keeping this light hearted troll friday
[08:18] <seb128> :)
[08:19] <Laney> seems the version on this machine isn't validating SSL certificates then
[08:39] <andyrock> seb128: https://code.launchpad.net/~azzar1/ubuntu/+source/file-roller/+git/file-roller/+merge/351407
[08:39] <andyrock> seb128: I'm not sure it makes sense doing this in salsa
[08:40] <andyrock> debian does not ship unstable gnome releaes
[08:40] <andyrock> and doing this in experimental for a non-DD takes too long
[08:44] <seb128> andyrock, thx
[08:44] <seb128> sorry channel for the stupid question
[08:45] <seb128> but do we really need 3 mps in those cases for the 3 branches (ubuntu / pristine-tar /  upstream)?
[08:45] <andyrock> i wanted to ask the same
[08:45] <andyrock> Laney: Trevinho ^^^
[08:45] <didrocks> I don't think there is any other way for a new release with the pristine-tar workflow
[08:46] <Laney> You don't need the merge proposal itself to be able to merge something from one place to another
[08:46] <didrocks> (at least, needing a way to pull/push pristine-tar & upstream)
[08:46] <Laney> But you need to do it of course
[08:47] <Laney> Maybe merge requests help with reminding people to do that and maybe they don't, I don't know
[08:47] <seb128> well, our contributor workflow needs to be standard
[08:47] <Laney> I'm not arguing with that at all
[08:47] <Laney> I'm replying to your question about whether we need it
[08:47] <andyrock> it would be nice if we could have multi-branches MR in launchpad
[08:47] <seb128> do we have that in salsa?
[08:47] <andyrock> seb128: nope
[08:47] <Laney> no
[08:48] <seb128> k
[08:48] <seb128> so we could define that contributors mp the ubuntu (or debian) branch
[08:48] <seb128> and that the reviewer needs to pull/merge pristine-tar and upstream as well
[08:48] <seb128> ?
[08:48] <Laney> that would work
[08:49] <Laney> by the way "takes too long" I don't agree with, and certainly not in this case
[08:49] <didrocks> we still need to check the content of upstream/ though? If it's an external contributor
[08:50] <seb128> Laney, you can't really "disagree" with how people feel though... better to try to figure out what is making them feel like that
[08:50] <seb128> andyrock, what is your main issue there?
[08:50] <seb128> the fact that you can't branch to experimental in a mp?
[08:50] <Laney> :/
[08:50] <seb128> didrocks, I guess yes
[08:50] <andyrock> didrocks: even if it's not an external contributor
[08:50] <andyrock> seb128: Laney the fact that I cannot use gitlab to propse things
[08:50] <didrocks> andyrock: you mean we have to double check on you? :p
[08:50] <Laney> thanks for the nitpicking pickup
[08:50] <didrocks> we know where you live
[08:51] <Laney> but OK
[08:51] <didrocks> "Italy"
[08:51] <didrocks> should be easy to find you :p
[08:51] <andyrock> didrocks: of course you need to check on me
[08:51] <Laney> can you propose on launchpad for non-existing branches?
[08:51] <Trevinho> Morning...
[08:51] <andyrock> Laney: I don't think so
[08:52] <didrocks> hey Trevinho
[08:52] <Laney> I find it strange since I offered to sponsor this stuff
[08:52] <Trevinho> didrocks: hi
[08:52] <Laney> but whatever, getting updates in Debian is a battle I've been fighting for a long time
[08:52] <Laney> just do it in cosmic, that's fine
[08:52] <seb128> Laney, was that comment for me? sorry, I didn't mean to be negative
[08:52] <seb128> hey Trevinho
[08:53] <andyrock> Laney: my point is that debian never did .x[13579] releases
[08:53] <Trevinho> Ciao seb128
[08:53] <andyrock> ciao Trevinho
[08:53] <Laney> andyrock: you can do those in experimental, that's what I've been doing this week
[08:53] <seb128> andyrock, that's a non issue, Laney said he's wanting to sponsor those to experimental
[08:53] <andyrock> Laney: and the other point is that doing this in experimental without being a DD is a pain
[08:54] <duflu> Happy Friday Trevinho
[08:54] <seb128> andyrock, well, until we branched
[08:54] <duflu>  and andyrock
[08:54] <duflu> and Laney
[08:54] <duflu> and people I missed
[08:54] <seb128> once the branch exists then it 's ok
[08:54] <andyrock> hey duflu
[08:54] <andyrock> seb128: indeed
[08:54] <andyrock> being not able to use gitlab MR feels :/ to me
[08:54] <seb128> I'm a bit lost as a reviewer there on what needs to be reviewed
[08:55] <andyrock> seb128: that's another thing
[08:55] <seb128> is there an easy way to check that the upstream branch that has been mp matches real upstream?
[08:55] <seb128> like a command/tool to use?
[08:55] <Trevinho> you too duflu
[08:55] <andyrock> seb128: it's not easy to review this kind of stuff :D
[08:55] <seb128> right
[08:55] <duflu> Or not. It's 5pm on a Friday and two fixes I thought were finished need reworking
[08:56] <Trevinho> anyway I was saying the same to Andrea, last night... Using only ubuntu and in case Laney can pull to debian experimental
[08:56] <seb128> I start thinking it's more work to review/sponsor an update with this workflow that to do it themselve for the sponsors
[08:56] <Trevinho> And we merge back once both on 3.30
[08:56] <seb128> like I don't even know how I would go to verify that the upstream branch hasn't been tricked
[08:56] <andyrock> seb128: I guess you can check the SHA https://gitlab.gnome.org/GNOME/file-roller/commits/3.29.1
[08:56] <seb128> it's less effort to just do the gbp import-orig myself
[08:57] <andyrock> at least for upstream/latest
[08:57] <Trevinho> seb128: git diff gnome/master
[08:58] <Laney> Trevinho: why would you though if a DD (me) has said they wanted that in experimental?
[08:59] <Laney> anyway I need to pack my bag, if it's easier for everyone to do it this way then feel free
[08:59] <Laney> brb
[09:03] <Trevinho> Laney: I meant what you can't propose (new branches), you can pull them if want
[09:04] <Laney> I mean it's only easier in Launchpad because we happen to have an ubuntu/master branch, if this package was in sync it would be the same problem
[09:04] <andyrock> seb128: btw to check upstream/latest just do: git checkout upstream/latest; git diff 3.29.1
[09:05] <andyrock> or git diff upstream/latest 3.29.1
[09:05] <seb128> does that diff the disk content?
[09:05] <seb128> or would it tell you if a commit message was amended between the branches?
[09:05] <Trevinho> Andyrock with .. I think
[09:06] <Trevinho> seb128: you can also diff the history
[09:06] <andyrock> Trevinho: works the same here
[09:06] <andyrock> seb128: it would tell if I modified a file
[09:06] <seb128> Trevinho, that doesn't answer my question
[09:06] <Trevinho> In the mean time...
[09:06] <Trevinho> https://csorianognome.wordpress.com/2018/07/27/nautilus-3-30/
[09:06] <seb128> so diff is on disk content
[09:06] <seb128> not logs?
[09:06] <andyrock> seb128: to check if the history was properly imported just check the sha
[09:06] <seb128> k
[09:07] <Trevinho> seb128: git diff yes... Checks rey content. Also the unstated one though
[09:07] <Trevinho> Unstaged
[09:07] <andyrock> e.g. https://git.launchpad.net/~azzar1/ubuntu/+source/file-roller/commit/?id=12384cf98b64ef7a9f6970c454181fd34afedfa7 and https://gitlab.gnome.org/GNOME/file-roller/commit/12384cf98b64ef7a9f6970c454181fd34afedfa7
[09:07] <seb128> I miss the good old bzr times where reviewing was only checking the debian dir was correctly changed :p
[09:07] <seb128> oh well, let's not start with those comments it's not helpful
[09:08] <andyrock> seb128: as you can see the sha is the same
[09:08] <seb128> andyrock, thx
[09:08] <seb128> I wonder if it would be easier to ask packaging debdiffs in that context
[09:08] <seb128> and let the sponsor do the gbp orig-import
[09:08] <seb128> and then copy the updated debian content over
[09:08] <Laney> not in any way would that be easier for me
[09:09] <seb128> it's probably less work for everyone than having to deal with reviewing and merging 3 branches
[09:09] <Laney> you have to check you didn't mess up your own work anyway
[09:10] <seb128> well, if I do gbp import-orig myself I know I didn't meddle with the upstream content or history
[09:10] <seb128> so it's less intensive work than having to check a contributor upstream line
[09:11] <seb128> the one "interesting" part in the new version is the debian/ dir work, that's what is not automatically handled by the tools
[09:11] <seb128> e.g patches refreshes and maybe (build-)depends
[09:11] <Laney> if you import a debdiff you get no proper commits
[09:12] <Laney> you get problems with transmitting data that diffs can't handle
[09:12] <Laney> the contributor *and* the reviewer have to transport a patch out of git and back into it
[09:13] <seb128> k, either way it's work I guess :/
[09:14] <andyrock> it would be good btw do define standard ways to review this kind of stuff
[09:14] <seb128> yeah
[09:14] <andyrock> when I had to review Trevinho's work for nautilus I had to spend hours to understand that Marco was wrong :D
[09:14] <seb128> at this point I'm also unsure it makes sense to ask contributors to help on easy updates, it feels like it's more work for the sponsor to review/merge the stuff than to do the update (that's not true if there are patches to rebase though)
[09:15] <seb128> Trevinho, well done on getting mentioned on the nautilus .30 blog post :)
[09:17] <Laney> I'm feeling a bit burned out by this whole exercise to be honest
[09:18] <Laney> It's really draining for me to have to advocate / fight for it all the time
[09:19] <seb128> yeah, sorry, I think we all feel burned in some way at this point
[09:20] <seb128> I'm not sure how to fix the situation though
[09:20] <seb128> the new workflow is powerful but that has a cost
[09:20] <Laney> It feels like you are fighting against it constantly, and I have to counter that
[09:20] <seb128> the cost is not that high for people who know the workflow/have commit access/see the advantage and are wanting to pay the cost
[09:21] <seb128> but it's high for others
[09:21] <Laney> Like in this case, checking the branch is not high cost really, but we're jumping around questioning the whole thing
[09:21] <Laney> If the question stayed on "what is the best way to do this?"
[09:21] <Laney> I could have showed you a screenshot of gitg
[09:22] <seb128> k, point taken
[09:24] <seb128> I'm going to step out of those discussions for the rest of the cycle
[09:24] <seb128> and see how the team goes with it, taking notes on the way
[09:24] <seb128> and we can do de-brief in Brussels
[09:26] <seb128> one fact is that doing an update is an higher number of commands and more error prone that the old workflow at this point (need to set the origns, don't forget to push 3 branches, tags, etc), maybe it's worth it though
[09:26] <seb128> maybe getting used to the system and building wrapper is going to help though
[09:26] <seb128> so let's people try to get used to it
[09:29] <seb128> k, on that note stepping out for early lunch, bbl
[09:31] <Laney> There's some learning / skill acquisition, yes. I'm not sure it's possible to avoid that but we should and have been trying to document it and make it as smooth as we can.
[09:32] <seb128> right, it's still a complex system and it shows
[09:32] <seb128> e.g see andyrock's feedback as a "new contributor"
[09:32] <Laney> what is the path out of this?
[09:32] <seb128> maybe the solution is to write some tooling/scripts to help with part of the repetitive work though
[09:33] <seb128> well, ether ^
[09:33] <Laney> It's a new thing for the team. We can't avoid people having to learn how to do some new things.
[09:33] <Laney> Hmm.
[09:33] <seb128> or maybe the conclusion is that the workflow with the 3 branches to maintain is too complex and not worth it, at least for "easy packages" and that ubuntu-git might be a better solution
[09:33] <Laney> This is getting me a bit irritated, I'm sorry, it's best I step out
[09:34] <seb128> k, sorry it's irritating to you
[09:35] <seb128> you see more the benefits from the system, where other see the complexity, we have probably work to do to see things from the others' perspective
[09:36] <seb128> and yes we can learn, but it's still error prone and a step learning curve for new contributors which mean be fine but we should still ask ourself the question if it's not overengineered
[09:36] <seb128> anyway, I'm stepping out of the discussion at this point
[09:36] <seb128> sorry it's frustating to you
[09:37] <Laney> No worries, maybe I really am blind to how crap it is.
[09:37] <Laney> If that's the case then it should definitely *not* be me arguing.
[09:40] <andyrock> my point was not to irritate or to blame anyone. From a developer point of view the all process it's easy, but not from a reviewer
[09:40] <andyrock> *reviewer point of view
[09:41] <andyrock> gitg helps but I still feel we can have something better
[09:46] <Trevinho> Yes... And agree.
[09:47] <Trevinho> However the tool itself from my side is waaaaay better. And doing things like all the backports from nautilus 3.28 to 3.26 without all the git tooling would have been just impossible (not easy anyway, but still possible and you've real tooling).
[09:49] <Trevinho> I don't see why any request related how to do things or how to improve the work flow has to bring to irritation.
[09:49] <Trevinho> It's normal to discuss how to do things or what would en the best behavior. Without having to stop after 2 minutes saying that this is just too hard or too bad.
[09:50] <Trevinho> The time might invest now, might look like is lost, but I'm sure it will pay back in the future.
[09:51] <Trevinho> So.... Let's discuss, strongly on tech aspects if the case, but no need to complaining because a new system brings to that. It's quite normal.
[13:06] <juliank> Hmm, in case we have two apps with the same name, one a snap and one a deb, would it make sense to show some badge or something on the icon to differentiate those?
[13:09] <ogra> hmm, i suppose apt hasnt been tested much on single-core single-thread CPUs, has it ?
[13:09] <ogra> $ sudo apt update && sudo apt upgrade
[13:09] <ogra> ...
[13:09] <ogra> All packages are up to date.
[13:09] <ogra> E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
[13:09] <ogra> E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
[13:09] <ogra> ...
[13:10] <ogra> $
[13:10] <ogra> i'm seeign this from time to time on an imx6ull (extremely low end ARM CPU)
[13:10] <didrocks> ogra: I guess a question for mvo?
[13:10] <jibel> ogra, it's usually the setup in test VMs
[13:10] <ogra> if i call both commands separately it doesnt happen
[13:11] <ogra> (it also happens rarely (like 1 out of 100 calls or so) ... but i never see it anywhere else)
[13:12] <didrocks> maybe apt doesn't call flush() when terminating?
[13:12] <didrocks> and so removal of the lock file isn't proceeded when the second command starts?
[13:12] <didrocks> (pure theory)
[13:12] <ogra> jibel, well, thats x86 multi-threaded ... still like 100x faster than that ARM thing :)
[13:12] <ogra> (even when in single core mode)
[13:14] <ogra> didrocks, my theory was that apt simply operates async now ... the CPU easily blocks on IO so the second command might kick in while the backend is still busy with the first part
[13:15] <didrocks> ogra: yeah, that's also plausible
[13:16] <ogra> err
[13:16] <ogra> geez ...
[13:16] <ogra> why am i in -desktop !
[13:17]  * ogra thought he was in -devel ... damned heat !!!
[13:23] <willcooke> juliank, it's on the backlog for consideration in future cycles
[13:23] <willcooke> juliank, i.e. yes, I think it would make a lot of sense
[13:23] <juliank> Nice, thanks willcooke
[13:23] <willcooke> yw!
[16:27] <jbicha> ogra: that issue also happens if you try to use apt shortly after booting because of a systemd timer checking for apt updates. If you wait several minutes, the background process finishes and the apt/dpkg locks are removed
[16:28] <ogra> aha !
[16:28] <ogra> jibel, thans for clearifying ... that makes sense
[16:28] <ogra> *thanks even
[16:30] <jbicha> it looks like the timer also runs twice per day, but I notice it mostly when I boot an Ubuntu instance I had turned off
[16:38] <jbicha> seb128: hi, I saw LP: #1775329 on the sponsor queue. Do you think it's a good idea?
[16:38] <ubot5> Launchpad bug 1775329 in gnome-terminal (Ubuntu) "Feature request: Add a handler for CVE URLs" [Undecided,New] https://launchpad.net/bugs/1775329
[17:01] <willcooke> gnight all
[18:10] <seb128> jbicha, hey, no opinion on that, seems a wishlist/nice to have but maybe not worth a SRU
[18:10] <seb128> would be fine to include in a stable update with other changes though