[06:34] <dholbach> good morning
[13:34] <mensahbenjamin> hi
[13:34] <mensahbenjamin> anybody around?


[10:59] -SwissBot:#ubuntu-news- ::Planet:: Full Circle Magazine: Full Circle Magazine #169 @ https://fullcirclemagazine.org/2021/05/28/full-circle-magazine-169/
[18:23] <Bashing-om> UWN: Issue 685 up for review and edits - proof-read carefully as I have had numerious distractions in making it up this issue.
[18:29] <krytarik> Bashing-om: The Lubuntu IRC summary says "LibreChat", but also I think it should be listed among the others at the top.
[18:30] <krytarik> "https://discourse.ubuntu.com/t/desktop-team-updates-monday-31st-may-2021/22460" - should lose the "/22460" tail.
[18:31] <krytarik> Oh, nevermind, the context was just confusing there..
[19:39] <Bashing-om> krytarik: ack - will get to it when I can - women folk got me busy for a spell. redecorating :(
[19:40] <krytarik> "At your command!" XD
[20:03] <Bashing-om> UWN: edited out the 22460 tail :)
[20:16] <krytarik> Eh, only that I corrected myself on it right after, and you probably broke the link now.. >_>
[20:18] <Bashing-om> kry I did test before editing - lemme verify :D
[20:27] <krytarik> Yeah, because it apparently gets redirected then to the one with the number tail.. >_<
[20:29] <krytarik> And what about the Lubuntu IRC one?
[20:29] <Bashing-om> krytarik: Yup ^ doing a re-do as we speak :(
[20:34] <Bashing-om> krytarik: Sorry about the Lubuntu IRC summary. I took "Oh, nevermind, the context was just confusing there.." to refer to the summary. Ya want that this be moved up as a bulletted item ?
[20:35] <krytarik> Yeah.
[20:35] <Bashing-om> krytarik: Ack moving :)
[20:36] <krytarik> Maybe higher up than the blogs though.
[20:37] <krytarik> So as the second item of those.
[20:51] <Bashing-om> krytarik: Yup - so done ^ :)
[21:10] <krytarik> Great, thanks!
[21:23] <Bashing-om> guiverc: :D poof-read the issue with attention to detail as I have worked under adverse conditions - errors are possible even after krytarik's sharp eyes.
[21:57] <guiverc> ack, won't be till later


 http://qa.kubuntu.co.uk/ppa-status/plasma/build_status_5.11.5_artful.html
 oh, wrong chat. never mind. backports of 5.11.5 in progress, anyway
 Kool.


[00:08] <wgrant> lifeless: Is security.py going to end up in lazr-postresql too?
[00:11] <lifeless> no
[00:12] <wgrant> :(
[00:12] <lifeless> or at least, not in this arc
[00:12] <wgrant> How're you going to manage security?
[00:14] <lifeless> wgrant: for scriptactivity ? in the db patches themselves probably.
[00:14] <wgrant> Ah
[00:14] <lifeless> we have three types of patches in the new system
[00:15] <lifeless> std (goes via slonik)
[00:15] <lifeless> direct (applies to each node separately in a xact)
[00:15] <lifeless> concurrent (applies to each node separately outside of a transaction)
[00:22] <wgrant> lifeless: Right.
[00:31] <lifeless> thus doing create role & grant on all the nodes is straight forward
[00:34] <wgrant> Yeah, which security.py can do :)
[00:34] <wgrant> Just needs to be made fully nodowntime, which I didn't quite get around to last week.
[00:34] <lifeless> I eagerly await this shiny.
[00:35] <lifeless> for now, minimal is good.
[00:35] <wgrant> True, true.
[00:35] <wgrant> But minimal LP is better :)
[00:35] <lifeless> we could just ditch security.py
[02:18] <lifeless> and success - https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-c63bba67bbc99ffb6e41ba383cd87c88
[02:18] <lifeless> tomorrows oops report should indeed have bazaar soft timeouts
[02:18] <wgrant> I fear it.;
[02:18] <lifeless> they will be soft timeouts
[02:18] <wgrant> I still fear it.
[02:19] <lifeless> and as you can see, w/no timeline, its pretty opaque data at the moment
[02:21] <wallyworld_> wgrant: i think there's a bad rev on qas but i'd like a 2nd opinion to ensure i've set things up correctly
[02:21] <wallyworld_> do you have a moment?
[02:25] <wgrant> wallyworld_: The person limitedview thing?
[02:25] <wallyworld_> wgrant: yes
[02:25] <wgrant> What's the issue?
[02:25] <wgrant> Hmm
[02:26] <wgrant> Interesting.
[02:26] <wallyworld_> i have a private team with a ppa. i have subscribed someone to the ppa. but theu can'
[02:26] <wgrant> Something is broken, yeah.
[02:26] <wallyworld_> t get to it
[02:26] <wallyworld_> team is ~private-foobarx
[02:26] <wallyworld_> i have subscribed xgy-ian to the ppa
[02:27] <wallyworld_> but when i login as xgy-ian, i get Unauthorized on https://qastaging.launchpad.net/~private-foobarx/+archive/ppa
[02:27] <wallyworld_> that's wrong, right?
[02:27] <wgrant> Should be, yes.
[02:27] <wgrant> Let me just fetch my testing account.
[02:27] <wallyworld_> ok
[02:27] <wallyworld_> there's 2 bugs
[02:28] <wallyworld_> one is not any worse, so is technically qa-ok
[02:28] <wallyworld_> but i hate marking a bug that doesn;t fix the issue as qa-ok :-(
[02:28] <wgrant> Hmm
[02:29] <wgrant> I think traversal may be failing.
[02:29]  * wgrant checks.
[02:29] <wallyworld_> yes
[02:29] <wallyworld_> that's my suspicion
[02:29] <wgrant> eg. if you go to https://qastaging.launchpad.net/api/devel/~private-foobarx?ws.accept=application/json you get an Unauthorized for account_status
[02:29] <wgrant> Which is checked during traversal.
[02:29] <wallyworld_> when i went on leave, the 2 branches i had were wip but curtis landed them with some fixes
[02:31] <wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-40786f88f5a5251bc6910b6f6b1ad083
[02:31] <wgrant> Traversal is indeed failing.
[02:31] <wgrant> qa-bad
[02:31] <StevenK> Hm, it looks like Curtis fixed my branch but didn't land it.
[02:32] <wallyworld_> wgrant: should i mark both bugs as qa-bad
[02:32] <wallyworld_> even though one of them is just as borken as before
[02:32] <StevenK> wallyworld_: qa-bad and bad-commit-<rev>
[02:32] <wallyworld_> ok
[02:32] <wgrant> "just as borken" == "people who are subscribed to branches owned by other private teams still can't see them"?
[02:32] <StevenK> I need to smack people for not adding bad-commit-<>
[02:32] <wallyworld_> wgrant: yes
[02:33] <wgrant> wallyworld_: Doesn't really matter.
[02:33] <wgrant> If they're the same rev.
[02:33] <wallyworld_> i marked it as qa-ok by mistake
[02:33] <wallyworld_> StevenK: how was your week off?
[02:33] <StevenK> It was excellent.
[02:33] <wallyworld_> stayed home?
[02:34] <StevenK> Yeah, I stayed home and played games all week.
[02:34] <wallyworld_> excellent. i went to the beach. limited internet so very relaxing :-)
[02:35]  * wallyworld_ goes to rollback the bad rev
[02:35]  * StevenK goes for lunch, with a plan to look carefully at the ec2 failure mail from this branch.
[02:47] <lifeless> wgrant: I know you are not here, but are you doing to land your config changes?
[02:48] <wgrant> lifeless: Two are in PQM now.
[02:48] <wgrant> One conflicts with mthaddon.
[02:49] <wgrant> And the last conflicts with the two that are landing now, so I'll merge and submit once they've landed.
[02:49] <lifeless> cool, thanks
[02:49] <lifeless> I was going to do the production datedir2amqp consolidation
[02:49] <lifeless> give spm something to do
[02:49] <lifeless> but I'll wait for your things to percolate through
[02:49] <wgrant> Do you want to switch (qa)staging to one-config-per-user first?
[02:50] <wgrant> Rather than migrating prod twice?
[02:50] <lifeless> no
[02:50] <lifeless> we have have debt here atm with the rsync copy backup dirs
[02:50] <lifeless> I want that solved before I go on leave
[02:50] <lifeless> or it will be hanging over our heads through EOY
[02:50] <wgrant> Ah, true, forgot you were running off.
[02:50] <lifeless> one config per is nice, but refactoring vs fixing issue
[02:50] <wgrant> Yeah.
[02:51] <wgrant> Forgot we only had a couple of days.
[02:51] <lifeless> says he that has already run off :P
[02:51] <wgrant> Silence, fool.
[02:53] <wgrant> One landed.
[03:07] <spm> lifeless: just about at the point where only cocobananas is left to do.
[03:17] <lifeless> wgrant: btw the initial lazr-postgresql code is on LP if you are interested
[03:17] <wgrant> lifeless: So I saw.
[03:18] <wgrant> lifeless: How will this integrate will full-update.py? We'll just use lazr-postgresql's upgrade.py?
[03:19] <lifeless> wgrant: we'll either call upgrade.upgrade directly
[03:19] <lifeless> wgrant: from a new buildout console_script; which will let us use the lazr config enabled connect() in the LP tree
[03:19] <wgrant> Right.
[03:20] <lifeless> wgrant: or we will have an extension point to call local hooks
[03:20] <lifeless> for now, for simplicity, I'm expecting to add an upgrade (devmode) and full_upgrade(prod) buildout script.
[03:32] <lifeless> wsyt
[03:32] <lifeless> bah
[03:32] <lifeless> wdyt
[03:32] <wgrant> Sounds reasonable.
[03:33] <wgrant> wallyworld_: Did you intend to submit the rollback twice?
[03:34] <wallyworld_> wgrant: no. i hadn't gotten any merge email so thought it didn't go through as happens when bb is broken and it just disappears into the ether
[03:35] <wgrant> wallyworld_: Ah, no, PQM was just spending a while chewing on my config branches.
[03:35] <wgrant> You can see the queue at pqm.launchpad.net.
[03:35] <wallyworld_> ah ok
[03:35] <wallyworld_> so do i need to correct anything?
[03:35] <wgrant> The second one will hopefully fail.
[03:35] <wgrant> Should be fine.
[03:36] <wallyworld_> just got the email just now
[03:36] <wallyworld_> and a failure for the 2nd one
[03:36] <wgrant> Great.
[03:39] <StevenK> wallyworld_: Check the queue, if someone submits a prod-config branch it will take 45 minutes.
[03:40] <wallyworld_> StevenK: rightio. i was used to it taking a minute or two
[03:40] <StevenK> Sure, which it does for devel branches :-)
[03:40] <wgrant> I optimised (db-)devel landings from 45 minutes to 45 seconds. But configs are harder and rarer, so I didn't fix them.
[03:45] <wgrant> lifeless: lp:~wgrant/lp-production-configs/cleanup will be landed in 30ish minutes, or you can start working off it now.
[03:45] <wgrant> That's only #3, but #4 is reasonably uninvasive.
[04:02] <lifeless> I have to wonder if we should slony-I all the dev environments
[04:02] <StevenK> You must really hate developer CPUs, then
[04:03] <lifeless> no
[04:03] <wgrant> Single-node slony with no slons?
[04:03] <lifeless> two-node local cluster
[04:03] <StevenK> To what end?
[04:04]  * StevenK is confused.
[04:04] <lifeless> same reason local dev environment is postgresql, so its close to prod
[04:04] <StevenK> sinzui didn't land my branch, but fixed the test failures and then set the bug to fix released.
[04:07] <StevenK> wgrant: ^ Can you explain that?
[04:08] <wgrant> Test fixes go in, bug status changes go out. Can't explain that.
[04:08] <wgrant> But no.
[04:08] <wgrant> No clue what's going on there :/
[04:10] <StevenK> From what I can see, the bug isn't fixed, so I'm tempted to set it back and toss my branch at ec2.
[04:10] <wgrant> Probably a good plan.
[04:12] <StevenK> Bah, conflict
[04:12]  * StevenK fixes first
[04:58] <wgrant> lifeless: The configs are all yours.
[04:58] <lifeless> thanks
[06:11] <lifeless> anyone around up for a tiny review?
[06:27] <wallyworld_> lifeless: can i help?
[06:29] <lifeless> I ended up self reviewing :)
[06:29] <lifeless> it was lp:~lifeless/oops-tools/own-oopses, if you wanted to do a post landing review
[06:29] <lifeless> its horribly uninteresting though
[06:31] <wallyworld_> lifeless: np. just thought i'd ask since i glanced at irc between tasks and saw your reuqest
[06:31] <lifeless> thanks!
[08:17] <lifeless> jtv: /winm 58
[08:17] <lifeless> bah
[08:40] <adeuring> good morning
[08:45] <lifeless> night all
[09:02] <mrevell> Que pasa?
[09:06] <bigjools> morning
[09:07] <danhg> Morning all
[09:07] <jtv> morning
[09:13] <Guest52098> hai, I'm from indonesia
[11:33] <rick_h_> morning party people
[11:33] <StevenK> Can haz someone from maintaince look at why db-devel went bang on buildbot?
[11:34] <rick_h_> heh, wouldn't expect to see a .jar error on there
[11:36] <bigjools> StevenK: maintenance is gary this week, so wait now() + 2.5 hours
[11:36] <wgrant> Hmmm?
[11:36] <wgrant> buildbot breakage is a $everybody event.
[11:45] <bigjools> it is not a "drop what I am doing right now event"
[11:56] <nigelb> rick_h_: I've been having "fun" with SqlAlchemy today :)
[11:56] <nigelb> Its not so bad after a while :P
[12:04] <rick_h_> nigelb: heh, let me know if you need a hand with anything
[12:27] <cjwatson> I've done (among other things) http://paste.ubuntu.com/767818/; can anyone explain why I get this ForbiddenAttribute exception? http://paste.ubuntu.com/767819/
[12:28] <cjwatson> Given that IndexStanzaFields isn't a database-backed class, this is surprising
[12:33] <StevenK> That's probably zope in your way, then
[12:36] <cjwatson> StevenK: no doubt, but I don't understand how it's getting there or how to fix it
[12:38] <StevenK> Can you pastebin a traceback?
[12:38] <StevenK> cjwatson: If you 'type()' is it a proxy or a real object?
[12:38] <bigjools> cjwatson: probably because it's being returned from a method on a proxied object
[12:39] <bigjools> if you give it an interface it'll work
[12:39] <bigjools> having said that, you are running non-zopeless tests again? :)
[12:41] <cjwatson> No, this is in LaunchpadZopelessLayer
[12:42] <cjwatson> StevenK: http://paste.ubuntu.com/767819/ (above) is the traceback I have
[12:43] <StevenK> LaunchpadZopelessLayer is not really zope-less sadly.
[12:44] <cjwatson> yeah, it's a proxy
[12:44] <bigjools> indeed
[12:44] <bigjools> ZopelessDatabaseLayer is what you need
[12:45] <bigjools> for publisher stuff
[12:45] <bigjools> I hate layers
[12:45] <cjwatson> But I need a librarian, unfortunately
[12:46] <cjwatson> In any case the actual site of the problem is not in a test so I need to deal with the proxy thing regardless
[12:47] <bigjools> we need a LibrarianZopelessDatabaseLayer :)
[12:47] <bigjools> (you see why I hate layers)
[12:47] <cjwatson> or a non-borked fakelibrarian
[12:48] <cjwatson> I think I'll shove in an interface
[14:32] <nigelb> rick_h_: Its mostly been okay so far. I took some time to get used to handling relationships. I have the manual open for the most part (which is excellent btw), so that's helping :)
[14:33] <rick_h_> nigelb: yea, docs are A+ imo, at least once you get past terminology
[15:20] <bac> sinzui:  i have about ten vouchers -- are there any projects that really need them?
[15:21] <bac> sinzui:  also, do you have access to niobium?
[15:22] <sinzui> bac: search project review for proprietary projects without a commercial subscriptions. There are some pmteam projects that need vouchers
[15:22] <sinzui> bac: I do not have access to niobium
[15:24] <sinzui> bac /sarasa also needs a license
[15:25] <sinzui> We do not need to worry about ezncrypt until February
[15:28] <lifeless> morning everyone
[15:29] <jcsackett> lifeless: it throws me when you say morning and it's actually my morning. but good morning. :-)
[15:31] <lifeless> trust me, it throws me too :)
[15:31] <lifeless> EBABY
[15:32] <nigelb> jcsackett: lifeless says morning in my morning and night.
[15:32] <nigelb> Confuses the heck out of me.
[15:35] <bac> thanks sinzui
[15:35] <abentley> deryck: It really throws me that we default to ascending order when clicking the losenges. If we default to descending order, we'll see most-important-first, recently-updated-first, most-bug-heat-first.  Can and should we change this?
[15:36] <jcsackett> abentley: that sounds entirely logical to me. i always want sort to work that way.
[15:36] <rick_h_> abentley: +1 on that
[15:37] <deryck> abentley, I think we should make it losenge-specific actually.  title makes more sense ascending, for example. I think each on should have it's own starting default...
[15:37] <deryck> abentley, but if not that, then yes, ascending probably works better for most then descending.
[15:38] <deryck> sorry, descending probably works better.
[15:38] <abentley> deryck: cool.
[15:38] <deryck> my head hurts trying to track ascending vs. descending for some reason. :)
[15:40] <abentley> deryck: Does YUI provide a way to test that something is logged?  I'm changing a Y.error to a Y.log, but it only seems right to test the log.
[15:41] <deryck> hmmm, I don't know.  Thinking....
[15:41]  * deryck is looking at how YUI tests logging
[15:42] <rick_h_> If the 'debug' config is true, a 'yui:log' event will be dispatched
[15:42] <rick_h_> can you watch that event to verify via test?
[15:42] <rick_h_> or do tests not run with debug? I don't recall
[15:44] <deryck> ah, that's a good idea.  And easy enough to change to debug config if not.
[15:45] <abentley> rick_h_: Okay, I can do that.
[15:46] <rick_h_> my turn, abentley deryck if I wanted to install a package for dev purposes (ipdb in this case) what's the *right* way to get it available?
[15:46] <deryck> abentley, rick_h_ and debug is true by default, so that event hook should work.
[15:46] <rick_h_> I've tried installing into the eggs dir, adding to versions.cfg
[15:47] <abentley> rick_h_: You put the tarball in download-cache/dist, add it to setup.py, and update versions.cfg, IIRC.
[15:47] <deryck> rick_h_, this is only something you want to use yourself?  or trying to add it for all lp devs to have access?
[15:47] <rick_h_> which I don't want to do since it's a bzr tracked file anyway
[15:47] <rick_h_> deryck: just me for prettier pdb
[15:47] <rick_h_> abentley: ah, ok. I'll try that route, thanks
[15:47] <abentley> rick_h_: bzr branches can be put in sourcecode/
[15:48] <abentley> rick_h_: They are configured using utilities/sourcedeps.conf and updated with utilities/update-sourcecode
[15:49] <rick_h_> abentley: cool, thanks for the heads up
[15:49] <deryck> rick_h_, can you not install it normally via apt-get and use it as you wish?  I didn't think we did any sort of virtualenv stuff that prevent importing from system python.
[15:49] <rick_h_> deryck: well this is a pip install'd package
[15:49] <rick_h_> and isn't in the path from the buildout stuff it appears
[15:50] <rick_h_> deryck: so I was trying to cheat it in, but it's still not picking it up and not sure if I'm doing it wrong or buildout/make is being overly helpful
[15:50] <deryck> rick_h_, where does pip want to put it?  And could you just not manually much about with PYTHONPATH exports?
[15:50] <rick_h_> deryck: so figured I'd see if there was a standard practice for this kind of personal tool thing.
[15:51] <deryck> rick_h_, there is, what abentley said.  but you'll have to be more careful to not commit that. So just thinking how to do it without going through lp.
[15:51] <rick_h_> deryck: yea, I installed it system wife /usr/local.. dist-packages
[15:51] <rick_h_> deryck: and yea, I tried just to manually symlink it into the egg directory with no success
[15:51] <rick_h_> deryck: definitely, don't want to muck with the official files, but figured I need to start with getting it to work, and then work on backing it out of bzr tracking
[15:51] <abentley> rick_h_: well, we don't really have a practise for stuff we're not intending for other devs to use.  Aside from the standard ways of administering your system.
[15:52] <rick_h_> abentley: ok, just checking
[15:52] <deryck> rick_h_, try export PYTHONPATH=$PYTHONPATH:/path/to/other/stuff then do your make run.
[15:53] <deryck> rick_h_, I'm not a pip user, though, which I know may be blasphemy to some. ;) So maybe others here have better ideas for how they manage their system with pip and running launchpad.
[15:53] <rick_h_> deryck: ok, thanks
[16:16] <lifeless> gary_poster: thanks for updating the lxc page; btw feel free to edit the main page as you go - probably easier than merging concurrent changes later
[16:23] <abentley> deryck or bac: There's no OCR, could one of you review https://code.launchpad.net/~abentley/launchpad/distro-structural-subscription/+merge/85356 ?
[16:23] <deryck> abentley, I can.
[16:24] <abentley> deryck: thanks.
[16:25] <deryck> np!
[16:26] <deryck> abentley, nice test, btw. That's a good way to do that.  glad rick_h_ suggested that.
[16:28] <deryck> abentley, in terms of code, I have no complaints.  Looks good!  I do wonder why we even need the logging, if we don't need the error.  I guess it doesn't hurt, though….
[16:29] <deryck> abentley, but why dirty up the console for would could be a normal operation?  i.e. why not just do nothing and move on?
[16:30] <abentley> deryck: It's hard to say.  What's Y.log for, if we only use the console for errors?
[16:31] <deryck> abentley, it's usually a debugging tool, right?  so it implies, we're logging something unexpected or unusual. in this case, we'll log on every juju page, which maybe is unneeded.
[16:32] <deryck> log for unusual or debugging corner cases, error for when we want the page to blow up because the tool is being used wrong.
[16:32] <deryck> (and I more asking here, than that I think this is wrong to do.  I'm not sure myself and wanted to discuss it.)
[16:32] <abentley> deryck: This is an unusual case.  On Friday, bac actually thought the link should never be missing.
[16:33] <deryck> right
[16:33] <lifeless> I want us to grab oopses from failed js
[16:33] <abentley> deryck: And the code assumed that too, of course.
[16:33] <lifeless> in that scenario a log of things that went odd in the page could be helpful
[16:33] <deryck> I'd like that too, lifeless
[16:33] <abentley> lifeless: me three.
[16:34] <deryck> lifeless, in that case Y.error makes sense, I think.  This is a case were we changed to Y.log since it's not an exceptional situation.
[16:34] <deryck> abentley, right.  and sense we can have cases where the link isn't present, I wonder if we shouldn't do nothing and move on.  That's our normal approach… sniff for something in the dom, nothing there?, them do nothing…..
[16:34] <abentley> deryck: but it would be great if Y.error was reporting an oops, and we'd fixed the problem months ago.
[16:35] <deryck> abentley, so I don't really mind the log, I just wonder what it buys us?
[16:35] <deryck> abentley, indeed!  agreed there.
[16:36] <abentley> deryck: I guess it would make things clearer for someone debugging a structural subscription issue.
[16:37] <abentley> deryck: But I'm fine with killing it entirely.
[16:37] <deryck> abentley, fair point.  I'm arguing with myself right now and trying to form a consistent opinion here. :)
[16:38] <abentley> deryck: there's also the option of logging it with a low priority, e.g. debug.
[16:39] <deryck> abentley, let's do it lower priority, so we can turn it on if we need, but we're not logging on every request for these pages.  I like that.  That work for you?
[16:39] <abentley> deryck: Okay.
[16:40] <deryck> abentley, thanks!  Sorry to make more work for you.  I'll note our discussion in the MP.
[16:50] <adeuring> deryck: got some time to talk about the sort issues?
[16:51] <deryck> adeuring, I'm about to get on a call.  Can I ping you after that?
[16:51] <adeuring> deryck: sure
[16:59] <abentley> adeuring: I believe you've addressed bug #894745
[16:59] <_mup_> Bug #894745: No sort on bug listing for most recently changed <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894745 >
[17:00] <adeuring> abentley: right, thanks for the nocitce :)
[18:23] <jelmer> I'm getting OOPSes during "make sync_branches", but none of those OOPses actually seem to end up anywhere
[18:30] <lifeless> jelmer: /var/tmp/lperr/
[18:31] <jelmer> lifeless: other OOPSes end up there, but not the ones generated by the branch scanner
[18:31] <lifeless> it may be firing up rabbit
[18:32] <lifeless> if so, follow my notes to setup a local exchange, and you can suck them out using amqp2datedir (either the main one or the oops-tools one, if you have oops-tools setup as well
[18:33] <jelmer> lifeless: I'll have a look - thanks
[19:05] <james_w> launchpad records timestamps for bug reports and bug last changed right?
[19:05] <james_w> bug reported I mean
[19:29] <rick_h_> james_w: looking at the db I see a date_last_updated
[19:33] <deryck> james_w, yeah, we do.  but bug last changed doesn't include comments.  so you have to do the more recent of date_last_updated and date_last_message.
[19:42] <lifeless> deryck: erm, i seem to recall it does. IMBW
[19:43] <deryck> lifeless, maybe it does now.  Or maybe I'm completely remembering wrong. :)
[19:43]  * deryck will look here in a sec
[19:45] <lifeless> deryck: I am a little concerned at wontfix ing the sort-by-date-of-task bug
[19:46] <lifeless> deryck: because date of task is the record of 'bug in context'
[19:48] <deryck> lifeless, ok.  we'll need to either break our basic design premise and stick a sort option on the bar that can never be removed, or add some display info that represents "bug in context age" (or some such)
[19:49] <lifeless> a quick diversion if you will
[19:49] <lifeless> let me grab a couple bug numbers
[19:49] <lifeless> deryck: actually, might be simpler to switch to voice, if you have a few minutes
[19:50] <lifeless> (ETIRED)
[19:50] <deryck> lifeless, I don't actually.  About to jump on another call.  And I've been on calls quite a bit today already.
[19:50] <lifeless> fair enough
[19:50] <lifeless> I'll blather on here a bit, give you as much context as I can
[19:50] <lifeless> and you can decide after your calls ;)
[19:52] <deryck> ok, cool
[19:53] <lifeless> I can't find the darn bug
[19:53] <lifeless> so I'll describe it
[19:53] <lifeless> when a bug has 2 tasks
[19:53] <lifeless> and you have a search that returns both
[19:53] <lifeless> we show both
[19:53] <lifeless> so our collections show tasks, not bugs.
[19:53] <lifeless> There is a bug about that
[19:54] <lifeless> for sorts on task columns, the two rows can be widely separated.
[19:54] <lifeless> for sorts on bug columns they will be adjacent
[19:55] <lifeless> related to this is our heuristic logic for when-to-show-context (e.g. we show 'project' when searching bugs in a project group, or on a users person +bugs page
[19:55] <lifeless> so -> seems to me that showing task-created as an optional column should be easy and preserve the design premise (which is pretty nice!)
[19:57] <deryck> yeah, I guess I have no issues with task-created as an extra piece of visible info.  It's creating it as a sort option in isolation that I don't support.
[19:57] <deryck> I think it's a bit hard to sum up simply in UI, but maybe just "Task age" as the label.
[19:57] <lifeless> I think the argument of 'cannot sort on it if you cannot see it' makes a great deal of sense
[19:57] <lifeless> at least for this data
[19:58] <lifeless> there is of course one exception - 'relevance', which is a bit hard to show as a column with any meaning
[19:58] <deryck> right
[19:58] <deryck> but if we had that, it makes more sense as a sort option that never goes away.
[19:59] <lifeless> separately, you know what would be sexy. Having closed bugs disappear out of the list in real time
[19:59] <lifeless> long poll subscribe to all the bugs shown on the batch.
[19:59] <deryck> lifeless, do you mind re-opening that bug and repurposing it to say "add display info and sort option for bug task age"?  if not, I can grab it later.
[19:59] <lifeless> re-evaluate their inclusion on the client when they are touched
[19:59] <deryck> lifeless, and indeed!  I'd love that.
[20:00] <lifeless> deryck: not at all, I will do that for you
[20:00] <deryck> lifeless, thanks, man!  And thanks for the discussion.
[20:00] <lifeless> np!
[20:00] <lifeless> btw today is my last day for the year
[20:00] <lifeless> so if you have stuff you want my input on... today is the day :)
[20:01] <deryck> ok, I have nothing today.  But I'm sure I will tomorrow or the next day. ;)
[20:01] <lifeless> of course :)
[20:02] <lifeless> I will probably still be around, things with long tails getting tweaked.
[20:02] <lifeless> but I won't 'be here' here, if that scans
[20:02] <deryck> yup, I follow.
[20:03] <lifeless> https://bugs.launchpad.net/launchpad/+bug/896539
[20:03] <_mup_> Bug #896539: bug task creation date is not selectable for display and thus can no longer be sorted by <bug-columns> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/896539 >
[20:03] <lifeless> hows that for a new title
[20:04] <deryck> perfect! :)
[20:04] <lifeless> I've added a note about the reopening too. Catch you later.
[20:13] <james_w> rick_h_, deryck: thanks
[20:14] <james_w> very useful attributes if exposed over the API
[20:53] <deryck> rick_h_, are you still around, or EOD'ed?
[20:53] <rick_h_> deryck: I'm here
[20:53] <rick_h_> in/out for a few min
[20:54] <deryck> rick_h_, I'll get those queries now.
[20:54] <rick_h_> deryck: ty much
[20:57] <deryck> rick_h_, https://pastebin.canonical.com/57002/
[21:01] <rick_h_> deryck: sorry had a typo in the id s/1007773/1007731 https://pastebin.canonical.com/57003/
[21:03] <deryck> rick_h_, better?  https://pastebin.canonical.com/57004/
[21:04] <rick_h_> deryck: awesome, thanks. That looks more like what I was looking for
[21:04] <deryck> rick_h_, cool
[21:14] <bac> hi sinzui
[21:15] <bac> sinzui: gary and i were talking about bug 480123 and whether the relaxing of the db constraint regarding milestone uniqueness should apply to distros too.  thoughts?
[21:15] <_mup_> Bug #480123: Milestone names/version should be unique to series <escalated> <linaro> <lp-registry> <Launchpad itself:In Progress by bac> < https://launchpad.net/bugs/480123 >
[21:17] <sinzui> bac, yes. the rules for distros are the same for projects...there can be only one release version in the history to prevent confusion and security vulnerabilities
[21:18] <bac> sinzui: right but is relaxing those rules for distros something that bug addresses?
[21:18] <bac> sinzui: so your previous 'yes' was to that question?
[21:19] <sinzui> bac I do not think that is what the bug is about. We are not in the business of making it easy to exploit a release.
[21:20] <sinzui> I think the issue is about making it possible to create an aggregate report of milestones in a project group's sub projects
[21:22] <sinzui> We do not need to change the constraints if we introduce a group_version that might make pg milestones faster and accurate since there will not no guessing.
[21:23] <sinzui> bac: but too you question, distros and product must have the same behavior
[21:32] <gary_poster> sinzui, could we have a call with you anytime soon?
[21:32] <lifeless> sinzui: whats the exploit ??
[21:32] <lifeless> s/??/?
[21:33] <sinzui> lifeless, If there is a defect in one of two version of the same name, how can I be certain I have the fixed version
[21:33] <lifeless> sinzui: if we show the full name consistently
[21:33] <lifeless> sinzui: precise/beta1 is not the same as oneiric/beta1
[21:33] <sinzui> lifeless, correct
[21:35] <sinzui> lifeless, consider the case of releasing from trunk!
[21:35] <lifeless> sinzui: so is the issue 'if we make milestone names only unique for a series, we have to audit the UI to be sure we always show the series' ?
[21:36] <lifeless> sinzui: indeed, and on trunk I can't imagine multiple 'beta' unqualified names being anything other than confusing
[21:36] <lifeless> sinzui: but someone releasing from trunk could do 0.1-beta1 and we'd be ok with that AIUI
[21:37] <sinzui> Most project do release from trunk and create series for backporting, so users creating a release want foo-5.beta
[21:37] <gary_poster> sinzui, but we would still have a constraint that milestones must be unique within a series.  Does that affect your argument?
[21:38] <sinzui> no, but the UI gets harder.
[21:38] <lifeless> hmm,also we can't permit whatever our join character is in the milestone name
[21:38] <sinzui> consider that I can move milestones between series and we support the feature because projects need a mechanism to reorganise themselves when hey grow, or advance
[21:39] <lifeless> otherwise the milestone 'foo-5.beta' on trunk and 'beta' on 'foo-5' might be hard to tell apart
[21:39] <sinzui> Moving a released milestone does not change the release version
[21:39] <sinzui> Users do move released milestones from trunk to a supported series for example
[21:40] <sinzui> I believe the current proposal support project that use leading series and milestones, which is not the norm. Most work on trunk/master, and use series for supported version
[21:41] <sinzui> Since the underlying issue is about a project group report, I think we need to be certain we are really solving that issue, and if we solve the timeouts too, instead of exacerbating the,, great
[21:44] <sinzui> gary_poster, bac, lifeless: project group milestones are the most prone to timeout because the listing grows too long. A good solution will reduce timeouts be making it easier to know which milestones compose the virtual project group milestone
[21:49] <bac> sinzui: it sounds like you are suggesting a different solution than the one originally discussed in the bug.  a new way to model linaro's grouping using something different from a milestone.  is that right?
[21:49] <sinzui> yes
[21:49] <sinzui> The chose to escalate a bug that "sounded" like the solution to their problem
[21:50] <sinzui> When I looked at the issue and the performance concerns, I seriously considered dropping support for project group milestones...which make matters worse for them
[21:52] <sinzui> Bac: the non-unique milestone bug is not about reporting, it is about normalising the milestone/release version from the series
[21:52] <bac> sinzui: but it does allow their report to be generated...
[21:54] <sinzui> yes. but at the cost that you must move the guard of duplicate releases from the early act of milestone creation to the late act of creating a release. An early mistake is easy to fix, a late mistake is not.
[21:58] <bac> sinzui: curtis do you have time to for a call with gary and me nowish?
[21:59] <sinzui> As I said before, no, I am meeting with my team
[21:59] <bac> sinzui: sorry, i missed your reply.  maybe early tomorrow?
[22:00] <sinzui> sure. I am free in the morning and isn the late afternoon
[22:00] <bac> sinzui: ok, great.  we're sprinting and cannot start until 9 am.  10am good for you?
[22:01] <sinzui> perfect
[22:01] <bac> thanks.
[22:07] <cjwatson> wgrant: Hmm.  Was bug 669404 perhaps fixed by your fix for bug 680889?
[22:07] <_mup_> Bug #669404: support linux-any and similar expansions in Packages-arch-specific <lp-soyuz> <soyuz-build> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/669404 >
[22:07] <_mup_> Bug #680889: Needs to handle "all linux-any" like "linux-any" <lp-soyuz> <qa-ok> <soyuz-build> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/680889 >
[22:14] <cjwatson> Could somebody with appropriate privileges mark bug 51763 as Won't Fix?  I left a comment explaining why.
[22:14] <_mup_> Bug #51763: Add effective tests for archive-cruft-check-ng.py <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/51763 >
[22:19] <lifeless> cjwatson: marked it invalid for you
[22:19] <lifeless> (there is no actual defect..)
[22:19] <cjwatson> fair enough
[22:33] <StevenK> sinzui, wallyworld_, jcsackett: http://pastebin.ubuntu.com/768422/
[22:40] <lifeless> incoming
[23:01] <mwhudson> jelmer: hey, does the "Always load foreign plugins" change mean we can switch to putting lp:bzr-git in sourcecode?
[23:02] <lifeless> mwhudson: where is it now ?
[23:19] <wgrant> cjwatson: I don't think so, but possibly...
[23:20] <wgrant> cjwatson: Doesn't look like it. P-a-s interpretation is pretty separate.
[23:20] <wgrant> It's in the same file, but it's handled very different.
[23:20] <wgrant> differently
[23:47] <jelmer> mwhudson: it's already in sourcecode, isn't it?
[23:47] <mwhudson> jelmer: we have some hack to support deregistering don't we?
[23:48] <jelmer> mwhudson: ah, right. that's no longer necessary
[23:58] <wgrant> wallyworld_: buildbot is about to fail, with account_status inaccessible.
[23:59] <wallyworld_> wgrant: ok. i'll deal with it. curtis landed the branch last night so i'll try and figure out why it got past ec2


[11:57] <kraut> moin
[02:00] <ogra> BenC, hey, could it be that linuc-ubuntu-modules is a bit out of sync ? seems people using ltsp with unionfs/squashfs/nbd setup are seeing a lot of unionfs noise in the dmesg outputs since the swithc from 2.6.22-10 to -11
[02:05] <mjg59> ogra: unionfs is currently broken
[02:05] <ogra> yeah, ltsp users are moaning :)
[02:05] <ogra> mjg59, thanks for the info
[02:20] <soren> AFAIUI the netconsole stuff in the kernel is only one-way. It's only good for spewing kernel output and such to a remote host.. Is there a more full featured mechanism for setting up a "real" networked console (if the hardware doesn't have it built in, obviously)?
[02:24] <BenC> ogra: everyone is moaning :)
[02:26] <ogra> heh
[02:26] <ogra> well, it seems to do any harm on thin clients at least apart from filling the logs with oopses :)
[02:26] <ogra> s/seems/seems not/
[02:27] <ogra> but then a thin client doesnt do any more with it but booting :)
[02:40] <\sh> BenC, btw...are you enabled hugetbl fs by default as module in the next kernel release?
[02:40] <\sh> s/enabled/enabling/
[02:41] <BenC> \sh: it's not modular
[02:43] <\sh> BenC, right ;) so it's enabled by default?
[02:44] <BenC> no, not on i386
[02:44] <\sh> BenC, but on amd64...that's whats more important ;)
[02:44] <BenC> only on sparc and powerpc
[02:45] <\sh> BenC, I filed a but about it on amd64...this is important for java devs on x86_64 ...
[02:45] <\sh> BenC, it enabled ibm java etc. to use largepages support
[02:45] <\sh> s/enabled/enables/
[02:46] <\sh> BenC, bug 122800 :)
[02:46] <ubotu> Launchpad bug 122800 in linux-source-2.6.22 "Please consider enabling HugeTBLFS for Gutsy " [Wishlist,Triaged]  https://launchpad.net/bugs/122800
[02:47] <BenC> \sh: we'll do our best
[02:47] <\sh> BenC, it was reported 2007-06-28 :)
[02:48] <\sh> when I tested feisty with our java backend on amd64
[02:48] <BenC> \sh: point taken, but it's still 3 days till beta :)
[02:48] <BenC> beta freeze I mean
[02:50] <\sh> BenC, using my self made <IP_ADDRESS> it's working perfectly...and when it's enabled via kernel paramenters (sysctl.conf) it works more perfectly..but it's not needed by default, only when you use this feature
[03:20] <BenC> rtg: rebooting in a sec to test the new iwlwifi
[03:21] <rtg> Big fire yesterday afternoon, my mirror isn't up to date. No power until this morning.
[03:21] <BenC> rtg: fire at your place?
[03:22] <rtg> No, downwind a few hundred yards.
[03:22] <rtg> Burnt up some power lines.
[03:22] <rtg> (and a bunch of houses)
[03:22] <BenC> rtg: nasty
[03:23] <ogra> rtg, hey, mn works fine with WEP and the rt73 driver in gutsy (have no WPA networks here so i only can test WEP and unencrypted)
[03:23] <ogra> s/mn/nm/
[03:23] <rtg> So, lum and kernel et al are in the archive?
[03:23] <BenC> rtg: kernel is, I'm giving pkl some time to fix unionfs before we do lum
[03:24] <rtg> ogra: rt73 works? I'm amazed.
[03:24] <BenC> so am I
[03:24] <BenC> ogra: works with n-m too?
[03:24] <ogra> yep
[03:25] <mjg59> acx100 seems to have broken again for some reason
[03:25] <mjg59> I managed to lose my hardware for that, which is a pain
[03:25] <ogra> on a minimally local install on the classmate ... tested on the weekend
[03:26] <rtg> ogra: I have a CMPC. Do you have directions and/or an image somewhere? I can test WPA.
[03:26] <JanC> aren't all those rt* bugs concurrency issues, so not always reproducable ?   ;)
[03:27] <ogra> rtg, i dont have any gutsy image yet ... mdz moaned about my decision to take a squashfs image for that thing, i'm waiting on a meeting for a proper decision
[03:28] <rtg> ogra: np.
[03:31] <BenC> rtg: iwlwifi seems to be working ok for me
[03:32] <BenC> $ lsmod | grep mac
[03:32] <BenC> iwlwifi_mac80211      174856  1 iwl4965
[03:32] <BenC> cfg80211                7304  1 iwlwifi_mac80211
[03:32] <rtg> BenC: have you tried WPA, suspend/resime hibernate, etc.
[03:32] <BenC> only thing I've done is connect via WEP
[03:32] <rtg> If it compiles, ship it :)
[03:36] <rtg> BenC: you won't forget debian/control-scripts/* will you?
[03:37] <rtg> Seeing activity on the DKMS bug reminded me.
[03:37] <BenC> rtg: err, I did forget
[03:37] <BenC> I'll work on that today and get an upload out tomorrow for it
[03:37] <rtg> Its important.
[03:37] <BenC> yeah, critical in fact
[03:38] <zul> how is the dkms revu coming in universe coming?
[03:38] <rtg> zul: https://bugs.edge.launchpad.net/ubuntu/+bug/121676. He is banging away at it.
[03:38] <ubotu> Launchpad bug 121676 in ubuntu "add DKMS to Ubuntu" [Wishlist,Incomplete]
[03:39] <zul> well if it needs a uvf for universe let me know since im on the uvf team i can get it rammed through
[03:40] <BenC> rtg: interestingly enough, I seem to be getting 85% signal now instead of ~75% like I was before
[03:41] <rtg> BenC: The real indicator is 'at what bit rate does it run?' and  'with how many retries?'. Ultimately throughput is the goal. Signal level can be quite misleading.
[03:42] <BenC> rtg: 2.2M/sec transfer over scp
[03:42] <rtg> Mbit/sec?
[03:43] <BenC> Megabytes
[03:43] <BenC> scp doesn't report mbits :)
[03:44] <rtg> BenC: Thats not too bad. Is it better then before?
[03:44] <BenC> connected at 54g
[03:44] <BenC> rtg: before was about 1.8M/sec
[03:45] <BenC> rtg: so far, no invalid packets reported in iwconfig
[03:45] <rtg> BenC: You should set up a loop and run some sustained bulk transfers. Maybe we can close the hiccup bug.
[03:45] <rtg> BenC: I'll do the same.
[03:45] <BenC> rtg: and more importantly, my dmesg isn't being flooded with operational messages :)
[03:46] <rtg> BenC: sounds like 2 steps forward.
[03:47] <BenC> rtg: only problem so far is the lack of wifi led
[03:47] <BenC> I need to see what I can do to make ieee80211_led.c compile in this new mac80211
[03:48] <BenC> it was expecting some new led interfaces in the kernel I think
[03:48] <rtg> I think it was a config option. I might not have turned it on.
[03:48] <BenC> I tried enabling it, but the compile failed
[03:49] <rtg> BenC: The iwlwifi pile is  backport from 2.6.23-rc*, so it might not compile.
[04:33] <zul> anyone got an opinon on bug 139881
[04:33] <ubotu> Launchpad bug 139881 in linux-source-2.6.22 "hdaps_protect patch to enable disk head parking on thinkpads" [Undecided,New]  https://launchpad.net/bugs/139881
[04:34] <mjg59> It would be nice if someone would actually get it into a state where it'll be accepted upstream
[04:35] <BenC> zul: Yeah, the patch is useless without userspace to support it
[04:36] <mjg59> BenC: There's userspace in the archive
[04:36] <BenC> mjg59: ah, last I heard it wasn't there
[04:36] <BenC> mjg59: but I also remember that the patch is pretty intrusive
[04:37] <mjg59> Yes, it's pretty nasty looking
[05:18] <zul> Ill just leave it then
[05:19] <afs> hi! I'm trying to compile qemu but it can't find /usr/include/linux/compiler.h. This include file belongs to package linux-headers-2.6.20-16-generic, but ends up in /usr/src/linux-headers-2.6.20-16-generic/include/linux/compiler.h. Is this normal behaviour?
[05:21] <soren> afs: It's an empty file, IIRC? Could you check that?
[05:22] <BenC> afs: add -I/usr/src/linux-headers-`uname -r` to your CFLAGS in qemu
[05:22] <afs> tried that, didn't work (suspect that's a qemu bug)
[05:24] <afs> /usr/include/linuxcompiler.h is not an empty file on debian
[05:28] <rtg> BenC: have a look at the changelog for iwlwifi 0.1.16. I'm testing his updates. It might fix an iwl3945 RF kill issue.
[05:33] <soren> do any of our kernel flavours have HZ=1000?
[05:35] <abogani> soren: Rt kernel have it
[05:35] <soren> abogani: Sure? It's not at 250?
[05:36] <abogani> soren: yes i'm sure.
[05:40] <soren> abogani: Ok. Thanks.
[05:40] <abogani> soren: :-)
[06:07] <BenC> soren: HZ= doesn't make sens with our stock kernel, because it has dynticks
[06:08] <JanC> hm, on all architectures?
[06:08] <mjg59> BenC: My understanding is that it still affects the base timer granularity
[06:09] <mjg59> HZ=1000 on i386 would make sense
[06:09] <BenC> we got too many complaints about battery usage when we did that
[06:09] <BenC> and we have quite a few laptop models that fall into the AMD broken ioapic timer category
[06:09] <mjg59> Yes, but dynticks avoids that being an issue
[06:10] <mjg59> When the system is idle, you still get the power savings
[06:10] <Nafallo> mjg59: my acer died ;-)
[06:10] <mjg59> And when it's active, it's no worse
[06:10] <Nafallo> mjg59: just thought you might want to know ;-)
[06:10] <mjg59> Nafallo: I'm shocked
[06:10] <Nafallo> hehe
[06:11] <BenC> mjg59: but the broken ioapic timer's don't get nohz, so they'll suffer
[06:11] <Nafallo> I've ordered a Dell D630 again :-P
[06:11] <mjg59> BenC: Uh. That shouldn't be the case.
[06:11] <mjg59> BenC: Lacking the apic timer isn't a blocker to nohz
[06:12] <BenC> mjg59: on the amd laptop I have, I had to add nolapic_timer nohz=on to get it to boot
[06:12] <BenC> I meant lapic timer
[06:12] <mjg59> Then there's a bug somewhere
[06:12] <BenC> nohz doesn't like not having lapic timer
[06:14] <mjg59> BenC: I think limiting functionality in the name of providing a small increase in battery life on broken hardware is less than ideal
[06:15] <mjg59> But I was also under the impression that the turion issue had been fixed without the need to disable the lapic timer (the issue was that the code was incorrectly thinking that the timer continued in C2, which it didn't)
[06:16] <BenC> maybe I misunderstood the patch then
[06:16] <BenC> I can't tell if dynticks is enabled or not...is there a file in sysfs that will show that?
[06:17] <mjg59> Not sure
[06:17] <mjg59> You can work it out from /proc/timer_list, I think
[06:18] <BenC> there's a nohz_mode...guess I can check the expected values for that
[06:19] <BenC> running on intel now
[07:04] <verwilst> hi!
[07:08] <verwilst> oh, they're in universe!
[07:08] <verwilst> carry on people ;)
[09:48] <rtg> mjg59: Do you only need the first 2 bytes of a hotkey to map it? For example, the windows media key on an XPS M1330 emits e0 5b e0 db.
[09:51] <superm1_> is this commit toward unionfs supposed to be resolving the issue on the currently daily builds, or is that coming in a later build? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy-lum.git;a=commit;h=2289191572cbb20dc4db387cc079e79f003a3bf2
[09:52] <rtg> superm1_:  Phillip is still working on it.
[09:53] <superm1_> rtg, okay cool thanks :)
[10:08] <mjg59> rtg: e0 means it's an extended scancode, 5b is the mapping, db is the release
[10:08] <mjg59> We need e05b for the mapping
[10:09] <rtg> mjg59: thanks.
[10:09] <mjg59> Does it not already generate a keycode under X?
[10:09] <rtg> mjg59: It does, I was juts trying to figure out the mapping using 'showkey -s'
[10:10] <mjg59> Ah, ok


[02:32] <copxer> hello
[09:24] <Smurphy> Hmmm. KMail Sieve filter stuff is broken/not working.
[09:24] <Smurphy> Any one has a workaround or is it known ? Latest available plasma and kde stuff from ppa.
[10:10] <tuor> Hi, I moved from Ubuntu to Kubuntu. I have a private SSH-key encrpted with a password. Every time I connect to a server with this key, I need to enter my password. I did ssh-add and for this terminal I did not need to enter the password again. What I want: I want that my Kubuntu "unlocks" the ssh key when I log in. On Ubuntu I had stored the password in the keyring and did not need to enter it again. Is
[10:10] <tuor> there a keyring or somthing similar in Kubuntu?
[10:12] <Smurphy> If you do that, you don't need ssh security.
[10:13] <Smurphy> justr re-create a new ssh key without password.
[10:15] <acheronuk> !info keychain
[10:17] <tuor> Smurphy, I need a key, so an other user, which has root rights, on the computer, can not use my key with out my user password. My keyring is secured with my user password. When I log in to my account I type in my password. This password should be the only one I enter. ;)
[10:18] <acheronuk> ^^ that starts ssh-agent for me so I only have to enter the key's PW once per login session
[10:24] <Smurphy> tuor: In that case don't use password manager or key stores. That is against what you do wityh the securiyt
[10:29] <tuor> I have one password to enter, the login password. This should unlock all what I need to work. That is my goal. After that (lower priority) my keys should be secure (ssh, gpg, what so ever).
[10:31] <tuor> I know the security aspect of using key stores. I'm fine with that.
[10:31] <tuor> Back to my question: Is there a keystore, which get unlocked when I login (using my login password to secure it self)?
[10:32] <Smurphy> Nope. Because the login password can be intercepted, and if the admin of that server has not enforced secure passwords, can be brute-force attacked pretty easily using jack the ripper
[10:36] <tuor> Ok. How can I get the ssh-agent working then? I have multiple ssh-keys, with different passwords. One for each customer. At the moment I have stored all ssh-passwords (which are realy long) in my keepass.
[10:37] <tuor> I want to get a simpler workflow. At the moment I work like this: login-PW, keepass-PW, copy/paste each time I need to use SSH in a new terminal. I want to get this simpler, it's to much typing, copy/paste.
[10:39] <tuor> So what would be good: login-PW, keystore-PW. So I need to know and enter 2 PW which have to be strong. The other passwords can be generated and as long as I want and I don't need to know or type them.
[10:42] <tuor> A good key-store should be good anough.
[10:43] <tuor> Is there a key-store which can run the ssh-agent?
[11:32] <kustodian> I'm trying to install Kubuntu 16.04.1 and I can't configure encrypted LVM with manual partition
[11:32] <kustodian> I have a few windows partitons already which I want to keep
[11:33] <kustodian> but when I go Manual, create a boot partition
[11:34] <kustodian> after which I create a Pysical volume for encryption" I can't do anything else
[11:34] <kustodian> the volume says Crypto, but nothing more
[11:43] <BluesKaj> 'Morning folks
[12:12] <Smurphy> tuor: Disable login-password, make sure people can only log-in using SSH keys, and assign a key to the ssh-key.
[13:09] <encolpe> Any idea to fix missing subjects in kmail? http://pasteboard.co/CTdsSljR.png
[13:21] <MadMage999> Anyone try using steam client on kubuntu 16.04 and have problems?
[13:23] <MadMage999> I'm trying to do that now and having issues.
[13:25] <MadMage999> Output of error.log from ~/.steam folder follows
[13:25] <MadMage999> rm: cannot remove '/home/mark/.steam/steam': Is a directory
[13:25] <MadMage999> rm: cannot remove '/home/mark/.steam/bin': Is a directory
[13:25] <MadMage999> grep: symbol lookup error: grep: undefined symbol: pcre_jit_stack_alloc
[13:25] <MadMage999> grep: symbol lookup error: grep: undefined symbol: pcre_jit_stack_alloc
[13:26] <MadMage999> Sorry for the flood
[13:27] <konrados> Morning :)
[13:28] <MadMage999> morning
[13:28] <BluesKaj> MadMage999, are yout rying to remove steam or.... ?
[13:28] <MadMage999> No, trying to get it to work, I just installed it with apt-get
[13:29] <konrados> In the task manager, once upon a time, I found a solution, which allowed be to drag&drop those tiles so I could rearrange them, now I can't find it, where is it?
[13:31] <MadMage999> Sorry I pasted the file into chat btw, I realize now I should have used kde paste
[13:31] <MadMage999> https://goo.gl/Sa1H0L <-- paste of ~/.steam/error.log
[13:32] <BluesKaj> MadMage999, https://userbase.kde.org/Kubuntu/Software/Games/Steam#Steam_on_Kubuntu
[13:33] <MadMage999> BluesKaj -- you're not supposed ot install with apt-get, eh?
[13:35] <MadMage999> Okay, another quick question... Does anyone else have the issue that typing in the search of 'Discover' seems to do nothing?
[13:35] <BluesKaj> no MadMage999 there is a debfile which you download tht contains an installer apt-get steam won't bring in all the required packages afaik
[13:36] <MadMage999> BluesKaj -- thanks for the info
[13:36] <BluesKaj> check the url above for the  manual install method
[13:36] <konrados> OK, nevermind, right click on the task manager panel -> settings -> sort: manually
[13:55] <MadMage999> When attempting to install steam via ubuntu software center I get "There isn’t a software package called “steam” in your current software sources"
[14:00] <MadMage999> Which doesn't make much sense to me since I was clicking on steam after finding it in a search in ubuntu software center, lol
[14:04] <MadMage999> I've tried all three methods on this page: https://userbase.kde.org/Kubuntu/Software/Games/Steam#Steam_on_Kubuntu and all three have failed for me, not usre if that's because I already tried to install it with apt-get or not, I'm going to try apt-get purge steam
[14:07] <MadMage999> Nope, no joy, any ideas?
[14:11] <BluesKaj> MadMage999, sudo apt purge steam* ...try that with the asterisk
[14:12] <MadMage999> k will do
[14:14] <MadMage999> https://goo.gl/jwzQV0 <-- results of sudo apt purge steam*
[14:17] <MadMage999> Hehe helps if you're not already root apparently
[14:18] <MadMage999> Okay that worked as user running sudo instead of root running sudo or just running the command minus the sudo
[14:19] <BluesKaj> well, one way or the other you need to get rid of the old steam config files , otherwise you're right back to where you started if you install it again
[14:19] <BluesKaj> reboot helps too
[14:20] <MadMage999> Okay, after sudo apt purge steam* resinstalled stem_latest.deb from http://store.steampowered.com using qapt and still  no joy
[14:20] <MadMage999> okay roger, rebooting now, brb
[14:23] <MadMage999> I re-ran sudo apt purge steam*, but I still see tons of stuff in ~/.steam
[14:28] <MadMage999> ran "rm -rf *" in folder ~/.steam
[14:29] <MadMage999> BluesKaj -- is there anything else I need to delete that you can think of?
[14:30] <BluesKaj> no
[14:30] <MadMage999> okay, I guess I'll reboot then
[14:39] <BluesKaj> madmouser1, run it from the terminal or the run command (allt+F2)
[14:39] <BluesKaj> MadMage999,^'
[14:41] <MadMage999> mmm more messages abot the driver, I'l paste in asec
[14:42] <MadMage999> https://goo.gl/clJh5S <-- output of steam command on cli
[14:49] <MadMage999> http://askubuntu.com/questions/771032/steam-not-opening-in-ubuntu-16-04-lts <-- found this on google
[14:50] <MadMage999> Steam started, updated itslef ,and the bit it on same messages, "libGL error: unable to load driver: radeonsi_dri.so" etc etc
[14:55] <MadMage999> Hmm, I guess steam is just broken, lol. Not sure what else to do
[14:58] <genii> MadMage999: I did find an article about that particular error, but the solution they offer is to delete quite a few files, which I'm not sure is very good
[14:59] <genii> MadMage999: If you want to check it out, at your own risk... https://bbs.archlinux.org/viewtopic.php?id=193802
[15:00] <MadMage999> Thanks Genii
[15:01] <MadMage999> LD_PRELOAD='/usr/$LIB/libstdc++.so.6' DISPLAY=:0 steam <-- this worked
[15:03] <MadMage999> So whats the best place to post a solution like this for kubuntu?
[15:06] <genii> MadMage999: Likely somewhere on the forums
[15:09] <MadMage999> right, thanks again genii, and BluesKaj
[16:27] <R13ose> In KDE on Ubuntu, the browsers (Chrome and FF) freeze on and off and don't see updates for the graphic driver.  Meaning I can still move around but I need to scroll or click link or switch tabs then move off of window and come back to see results.  How do I fix this?
[16:36] <faisal> tes
[16:45] <alesan> hello
[16:45] <faisal> hello
[16:45] <alesan> is there a way to tell kubuntu to only always use a DNS I specify and not an internet dns thing like <IP_ADDRESS> ??
[16:46] <faisal> ngomong apa?
[19:22] <dellhem> Has someone successfully installed ModemManager 1.6 yet? Can't get it to work.
[19:27] <dellhem> I fail because of dependencies, so if there's an apt repo I guess it will work, but I can't find it.
[21:49] <IVgoodapp> Hello, Does an Pacli (a Terminal based package manager for Arch Linux) alternative for Ubuntu exist?
[21:50] <Dragnslcr> IVgoodapp- Ubuntu (and Debian) uses apt
[21:53] <IVgoodapp> Dragnslcr I know that but does it work like Pacli? where you can search list of installed apps etc...?
[21:55] <ahoneybun> mm Steam is installable
[21:55] <ahoneybun> from apt
[22:30] <user|66108> can i get ubuntu software center in kubuntu and how
[22:31] <Dragnslcr> IVgoodapp- yes, you can search for packages with apt-cache
[22:33] <genii> !info software-center
[22:34] <genii> enable universe, install it


[16:06] <teolemon> who would be interested in a hangout about generating automated suggestions for the ddtp ?


[05:16] -queuebot:#ubuntu-release- New binary: freeradius [amd64] (focal-proposed/main) [3.0.20+dfsg-3] (ubuntu-desktop, ubuntu-server)
[05:16] -queuebot:#ubuntu-release- New binary: freeradius [s390x] (focal-proposed/main) [3.0.20+dfsg-3] (ubuntu-desktop, ubuntu-server)
[05:17] -queuebot:#ubuntu-release- New binary: freeradius [ppc64el] (focal-proposed/main) [3.0.20+dfsg-3] (ubuntu-desktop, ubuntu-server)
[05:19] -queuebot:#ubuntu-release- New binary: freeradius [armhf] (focal-proposed/main) [3.0.20+dfsg-3] (ubuntu-desktop, ubuntu-server)
[05:20] -queuebot:#ubuntu-release- New binary: freeradius [arm64] (focal-proposed/main) [3.0.20+dfsg-3] (ubuntu-desktop, ubuntu-server)
[09:46] -queuebot:#ubuntu-release- New binary: ntirpc [amd64] (focal-proposed/universe) [3.0-0ubuntu1] (no packageset)
[09:46] -queuebot:#ubuntu-release- New binary: ntirpc [s390x] (focal-proposed/universe) [3.0-0ubuntu1] (no packageset)
[09:46] -queuebot:#ubuntu-release- New binary: ntirpc [ppc64el] (focal-proposed/universe) [3.0-0ubuntu1] (no packageset)
[09:49] -queuebot:#ubuntu-release- New binary: ntirpc [arm64] (focal-proposed/universe) [3.0-0ubuntu1] (no packageset)
[09:49] -queuebot:#ubuntu-release- New binary: ntirpc [armhf] (focal-proposed/universe) [3.0-0ubuntu1] (no packageset)
[09:49] -queuebot:#ubuntu-release- Unapproved: stress-ng (eoan-proposed/universe) [0.10.07-1ubuntu2 => 0.10.07-1ubuntu3] (no packageset)
[10:00] -queuebot:#ubuntu-release- Unapproved: stress-ng (disco-proposed/universe) [0.09.57-0ubuntu4 => 0.09.57-0ubuntu5] (no packageset)
[10:05] -queuebot:#ubuntu-release- Unapproved: gcc-7 (eoan-proposed/universe) [7.4.0-14ubuntu2 => 7.5.0-3ubuntu1~19.10] (core) (sync)
[10:06] -queuebot:#ubuntu-release- Unapproved: gcc-8 (eoan-proposed/universe) [8.3.0-23ubuntu2 => 8.3.0-26ubuntu1~19.10] (core) (sync)
[10:06] -queuebot:#ubuntu-release- Unapproved: rejected gcc-7 [source] (eoan-proposed) [7.5.0-3ubuntu1~19.10]
[10:06] -queuebot:#ubuntu-release- Unapproved: rejected gcc-8 [source] (eoan-proposed) [8.3.0-26ubuntu1~19.10]
[10:11] -queuebot:#ubuntu-release- New: accepted freeradius [amd64] (focal-proposed) [3.0.20+dfsg-3]
[10:11] -queuebot:#ubuntu-release- New: accepted freeradius [armhf] (focal-proposed) [3.0.20+dfsg-3]
[10:12] -queuebot:#ubuntu-release- New: accepted freeradius [s390x] (focal-proposed) [3.0.20+dfsg-3]
[10:12] -queuebot:#ubuntu-release- New: accepted ntirpc [arm64] (focal-proposed) [3.0-0ubuntu1]
[10:12] -queuebot:#ubuntu-release- New: accepted ntirpc [ppc64el] (focal-proposed) [3.0-0ubuntu1]
[10:12] -queuebot:#ubuntu-release- New: accepted php-httpful [amd64] (focal-proposed) [0.2.20-1]
[10:12] -queuebot:#ubuntu-release- New: accepted php-mikey179-vfsstream [amd64] (focal-proposed) [1.6.7-1]
[10:12] -queuebot:#ubuntu-release- New: accepted php-php-mongodb [amd64] (focal-proposed) [1.4.3-1]
[10:12] -queuebot:#ubuntu-release- New: accepted php-tijsverkoyen-css-to-inline-styles [amd64] (focal-proposed) [2.2.2-1]
[10:12] -queuebot:#ubuntu-release- New: accepted starpu-contrib [amd64] (focal-proposed) [1.3.3+dfsg-1]
[10:12] -queuebot:#ubuntu-release- New: accepted freeradius [arm64] (focal-proposed) [3.0.20+dfsg-3]
[10:12] -queuebot:#ubuntu-release- New: accepted ntirpc [amd64] (focal-proposed) [3.0-0ubuntu1]
[10:12] -queuebot:#ubuntu-release- New: accepted ntirpc [s390x] (focal-proposed) [3.0-0ubuntu1]
[10:12] -queuebot:#ubuntu-release- New: accepted php-parsedown [amd64] (focal-proposed) [1.7.3-1]
[10:12] -queuebot:#ubuntu-release- New: accepted python-dlt [amd64] (focal-proposed) [2.0-1]
[10:12] -queuebot:#ubuntu-release- New: accepted starpu [amd64] (focal-proposed) [1.3.3+dfsg-2]
[10:12] -queuebot:#ubuntu-release- New: accepted starpu [armhf] (focal-proposed) [1.3.3+dfsg-2]
[10:12] -queuebot:#ubuntu-release- New: accepted starpu [s390x] (focal-proposed) [1.3.3+dfsg-2]
[10:12] -queuebot:#ubuntu-release- New: accepted freeradius [ppc64el] (focal-proposed) [3.0.20+dfsg-3]
[10:12] -queuebot:#ubuntu-release- New: accepted php-lorenzo-pinky [amd64] (focal-proposed) [1.0.5-1]
[10:12] -queuebot:#ubuntu-release- New: accepted starpu-contrib [ppc64el] (focal-proposed) [1.3.3+dfsg-1]
[10:12] -queuebot:#ubuntu-release- New: accepted starpu [ppc64el] (focal-proposed) [1.3.3+dfsg-2]
[10:12] -queuebot:#ubuntu-release- New: accepted ntirpc [armhf] (focal-proposed) [3.0-0ubuntu1]
[10:12] -queuebot:#ubuntu-release- New: accepted starpu [arm64] (focal-proposed) [1.3.3+dfsg-2]
[10:12] -queuebot:#ubuntu-release- New: accepted php-psr-event-dispatcher [amd64] (focal-proposed) [1.0.0-1]
[10:15] -queuebot:#ubuntu-release- Unapproved: stress-ng (bionic-proposed/universe) [0.09.25-1ubuntu5 => 0.09.25-1ubuntu6] (no packageset)
[10:29] -queuebot:#ubuntu-release- Unapproved: stress-ng (xenial-proposed/universe) [0.05.23-1ubuntu2 => 0.05.23-1ubuntu3] (no packageset)
[11:17] -queuebot:#ubuntu-release- Unapproved: gcc-8 (eoan-proposed/universe) [8.3.0-23ubuntu2 => 8.3.0-26ubuntu1~19.10] (core) (sync)
[11:17] -queuebot:#ubuntu-release- Unapproved: rejected gcc-8 [sync] (eoan-proposed) [8.3.0-26ubuntu1~19.10]
[11:20] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [sync] (eoan-proposed) [8.3.0-26ubuntu1~19.10]
[11:22] -queuebot:#ubuntu-release- Unapproved: rejected gcc-7 [sync] (eoan-proposed) [7.5.0-3ubuntu1~19.10]
[11:40] <seb128> vorlon, umockdev/i386 makes sense to badtest?
[12:15] -queuebot:#ubuntu-release- New binary: nfs-ganesha [amd64] (focal-proposed/universe) [3.0.3-0ubuntu1] (no packageset)
[12:46] -queuebot:#ubuntu-release- Unapproved: gcc-7 (eoan-proposed/universe) [7.4.0-14ubuntu2 => 7.5.0-3ubuntu1~19.10] (core) (sync)
[12:49] -queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8.3.0-6ubuntu1~18.04.1 => 8.3.0-26ubuntu1~18.04] (core) (sync)
[12:49] -queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.4.0-1ubuntu1~18.04.1 => 7.5.0-3ubuntu1~18.04] (core) (sync)
[12:53] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [sync] (eoan-proposed) [7.5.0-3ubuntu1~19.10]
[13:40] -queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.5-1]
[14:00] -queuebot:#ubuntu-release- Unapproved: rejected gcc-7 [source] (bionic-proposed) [7.5.0-3ubuntu1~18.04]
[14:00] -queuebot:#ubuntu-release- Unapproved: rejected gcc-8 [source] (bionic-proposed) [8.3.0-26ubuntu1~18.04]
[14:01] -queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [sync] (bionic-proposed) [8.3.0-26ubuntu1~18.04]
[14:03] -queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [sync] (bionic-proposed) [7.5.0-3ubuntu1~18.04]
[15:03] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20191113.1-0ubuntu<IP_ADDRESS> => 1:20191210.1-0ubuntu<IP_ADDRESS>] (no packageset)
[15:03] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20191113.1-0ubuntu<IP_ADDRESS> => 1:20191210.1-0ubuntu<IP_ADDRESS>] (no packageset)
[15:03] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (disco-proposed/partner) [1:20191113.1-0ubuntu<IP_ADDRESS> => 1:20191210.1-0ubuntu<IP_ADDRESS>] (no packageset)
[15:03] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20191113.1-0ubuntu<IP_ADDRESS> => 1:20191210.1-0ubuntu<IP_ADDRESS>] (no packageset)
[15:44] -queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1008.9] (core, kernel)
[15:56] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (disco-proposed) [1:20191210.1-0ubuntu<IP_ADDRESS>]
[15:56] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20191210.1-0ubuntu<IP_ADDRESS>]
[15:57] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20191210.1-0ubuntu<IP_ADDRESS>]
[16:23] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (eoan-proposed) [1:20191210.1-0ubuntu<IP_ADDRESS>]
[16:30] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.3.0-25.27~18.04.1] (kernel)
[16:30] -queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.3 [amd64] (bionic-proposed/main) [5.3.0-1008.9~18.04.1] (no packageset)
[16:31] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.3.0-25.27~18.04.1] (kernel)
[16:34] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.3.0-25.27~18.04.1] (kernel)
[17:15] -queuebot:#ubuntu-release- New binary: libbio-db-hts-perl [amd64] (focal-proposed/universe) [3.01-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: dltlyse [amd64] (focal-proposed/universe) [1.1-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: liblist-someutils-xs-perl [amd64] (focal-proposed/universe) [0.58-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: feed2toot [amd64] (focal-proposed/universe) [0.12-1] (no packageset)
[17:15] -queuebot:#ubuntu-release- New binary: mdevctl [amd64] (focal-proposed/universe) [0.50-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: libbio-db-swissprot-perl [amd64] (focal-proposed/universe) [1.7.3-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: jep [amd64] (focal-proposed/universe) [2.4.1+ds-3] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: libxstring-perl [amd64] (focal-proposed/universe) [0.002-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: libbio-cluster-perl [amd64] (focal-proposed/universe) [1.7.3-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: ckb-next [amd64] (focal-proposed/universe) [0.4.2+dfsg.1-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: libeuclid-java [amd64] (focal-proposed/universe) [1.0.1-2] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: haskell-text-conversions [amd64] (focal-proposed/universe) [0.3.0-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: ckb-next [ppc64el] (focal-proposed/universe) [0.4.2+dfsg.1-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: haskell-hindent [amd64] (focal-proposed/universe) [5.3.1-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: libbio-db-hts-perl [ppc64el] (focal-proposed/universe) [3.01-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: haskell-text-conversions [ppc64el] (focal-proposed/universe) [0.3.0-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: liblist-someutils-xs-perl [ppc64el] (focal-proposed/universe) [0.58-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: ckb-next [s390x] (focal-proposed/universe) [0.4.2+dfsg.1-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: libxstring-perl [ppc64el] (focal-proposed/universe) [0.002-1] (no packageset)
[17:21] -queuebot:#ubuntu-release- New: accepted feed2toot [amd64] (focal-proposed) [0.12-1]
[17:21] -queuebot:#ubuntu-release- New: accepted libeuclid-java [amd64] (focal-proposed) [1.0.1-2]
[17:21] -queuebot:#ubuntu-release- New: accepted nfs-ganesha [amd64] (focal-proposed) [3.0.3-0ubuntu1]
[17:21] -queuebot:#ubuntu-release- New binary: libsignatures-java [amd64] (focal-proposed/universe) [0.0~git20141229.14f3045+ds-2] (no packageset)
[17:21] -queuebot:#ubuntu-release- New: accepted jep [amd64] (focal-proposed) [2.4.1+ds-3]
[17:21] -queuebot:#ubuntu-release- New binary: liblist-someutils-xs-perl [s390x] (focal-proposed/universe) [0.58-1] (no packageset)
[17:21] -queuebot:#ubuntu-release- New: accepted mdevctl [amd64] (focal-proposed) [0.50-1]
[17:21] -queuebot:#ubuntu-release- New binary: libxstring-perl [s390x] (focal-proposed/universe) [0.002-1] (no packageset)
[17:21] -queuebot:#ubuntu-release- New: accepted dltlyse [amd64] (focal-proposed) [1.1-1]
[17:21] -queuebot:#ubuntu-release- New: accepted libsignatures-java [amd64] (focal-proposed) [0.0~git20141229.14f3045+ds-2]
[17:22] -queuebot:#ubuntu-release- New: accepted libbio-cluster-perl [amd64] (focal-proposed) [1.7.3-1]
[17:22] -queuebot:#ubuntu-release- New: accepted libbio-db-swissprot-perl [amd64] (focal-proposed) [1.7.3-1]
[17:22] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20191210.1-0ubuntu<IP_ADDRESS> => 1:20191210.1-0ubuntu<IP_ADDRESS>] (no packageset)
[17:22] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (eoan-proposed/partner) [1:20191210.1-0ubuntu<IP_ADDRESS> => 1:20191210.1-0ubuntu<IP_ADDRESS>] (no packageset)
[17:23] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (disco-proposed/partner) [1:20191210.1-0ubuntu<IP_ADDRESS> => 1:20191210.1-0ubuntu<IP_ADDRESS>] (no packageset)
[17:23] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20191210.1-0ubuntu<IP_ADDRESS> => 1:20191210.1-0ubuntu<IP_ADDRESS>] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: ginkgocadx [amd64] (focal-proposed/universe) [3.8.8-3] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: libbio-db-hts-perl [armhf] (focal-proposed/universe) [3.01-1] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: libbio-db-hts-perl [arm64] (focal-proposed/universe) [3.01-1] (no packageset)
[17:26] -queuebot:#ubuntu-release- New binary: haskell-dhall [amd64] (focal-proposed/universe) [1.19.1-1] (no packageset)
[17:26] -queuebot:#ubuntu-release- New binary: haskell-hindent [ppc64el] (focal-proposed/universe) [5.3.1-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: haskell-hindent [s390x] (focal-proposed/universe) [5.3.1-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: haskell-text-conversions [armhf] (focal-proposed/universe) [0.3.0-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: liblist-someutils-xs-perl [armhf] (focal-proposed/universe) [0.58-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: libxstring-perl [armhf] (focal-proposed/universe) [0.002-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: haskell-text-conversions [arm64] (focal-proposed/universe) [0.3.0-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: libxstring-perl [arm64] (focal-proposed/universe) [0.002-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: liblist-someutils-xs-perl [arm64] (focal-proposed/universe) [0.58-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: ckb-next [arm64] (focal-proposed/universe) [0.4.2+dfsg.1-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: ckb-next [armhf] (focal-proposed/universe) [0.4.2+dfsg.1-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: haskell-dhall [ppc64el] (focal-proposed/universe) [1.19.1-1] (no packageset)
[17:33] -queuebot:#ubuntu-release- New binary: haskell-hindent [arm64] (focal-proposed/universe) [5.3.1-1] (no packageset)
[17:35] -queuebot:#ubuntu-release- New binary: itksnap [amd64] (focal-proposed/universe) [3.6.0-5] (no packageset)
[17:42] -queuebot:#ubuntu-release- New binary: haskell-hindent [armhf] (focal-proposed/universe) [5.3.1-1] (no packageset)
[17:55] <vorlon> seb128: umockdev> agreed
[17:58] -queuebot:#ubuntu-release- New binary: haskell-dhall [arm64] (focal-proposed/universe) [1.19.1-1] (no packageset)
[18:11] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20191210.1-0ubuntu<IP_ADDRESS>]
[18:11] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (disco-proposed) [1:20191210.1-0ubuntu<IP_ADDRESS>]
[18:11] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (eoan-proposed) [1:20191210.1-0ubuntu<IP_ADDRESS>]
[18:11] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20191210.1-0ubuntu<IP_ADDRESS>]
[19:16] <vorlon> Laney: huh what updates the current_version table in autopkgtest.db?  I just noticed that it has the wrong version for json-glib, and maybe some others, invalidating the stats I just posted to ubuntu-devel
[19:29] <vorlon> apw: what would you like to do with autopkgtests of linux on i386?  we certainly shouldn't be doing anything involving a boot test anymore, nor is a build test particularly interesting if the only artifact we're outputting is linux-libc-dev.  Should I just perma-badtest this?
[19:35] -queuebot:#ubuntu-release- New binary: cmlxom [amd64] (focal-proposed/universe) [3.1-2] (no packageset)
[20:24] <rbalint> RAOF, bdmurray, the previous wslu sru caused regression on wsl2: LP: #1855520
[20:26] <rbalint> RAOF, bdmurray i have a proper fix linked to the bug but it is not a trivial change and it may be better to quickly revert the change and release that to -updates, and and only then start the aging for the proper fix's sru
[20:27] <apw> vorlon: likely yes
[20:27] <rbalint> RAOF, bdmurray: what do you think?
[20:27] <vorlon> apw: only "likely"?  Did you want to have a think about it before I add the hint?
[20:28] <apw> vorlon: no do it, it needs fixing in New kernels no doubt too
[20:28] <apw> is all I am thinking
[20:29] <vorlon> apw: other source packages that generate no artifacts on i386, or only ship arch: all binaries on i386, are more cut and dried
[21:02] <apw> vorlon, indeed
[21:15] -queuebot:#ubuntu-release- Unapproved: update-motd (eoan-proposed/main) [3.6-0ubuntu<IP_ADDRESS> => 3.6-0ubuntu<IP_ADDRESS>] (core)
[21:26] <rbalint> RAOF, bdmurray: also please take a look at update-motd ^
[21:27] -queuebot:#ubuntu-release- New: accepted ckb-next [amd64] (focal-proposed) [0.4.2+dfsg.1-1]
[21:27] -queuebot:#ubuntu-release- New: accepted ckb-next [armhf] (focal-proposed) [0.4.2+dfsg.1-1]
[21:27] -queuebot:#ubuntu-release- New: accepted ckb-next [s390x] (focal-proposed) [0.4.2+dfsg.1-1]
[21:27] -queuebot:#ubuntu-release- New: accepted ginkgocadx [amd64] (focal-proposed) [3.8.8-3]
[21:27] -queuebot:#ubuntu-release- New: accepted haskell-dhall [arm64] (focal-proposed) [1.19.1-1]
[21:27] -queuebot:#ubuntu-release- New: accepted haskell-hindent [armhf] (focal-proposed) [5.3.1-1]
[21:27] -queuebot:#ubuntu-release- New: accepted ckb-next [arm64] (focal-proposed) [0.4.2+dfsg.1-1]
[21:27] -queuebot:#ubuntu-release- New: accepted cmlxom [amd64] (focal-proposed) [3.1-2]
[21:27] -queuebot:#ubuntu-release- New: accepted haskell-dhall [ppc64el] (focal-proposed) [1.19.1-1]
[21:27] -queuebot:#ubuntu-release- New: accepted ckb-next [ppc64el] (focal-proposed) [0.4.2+dfsg.1-1]
[21:27] -queuebot:#ubuntu-release- New: accepted haskell-dhall [amd64] (focal-proposed) [1.19.1-1]
[21:27] -queuebot:#ubuntu-release- New: accepted haskell-hindent [amd64] (focal-proposed) [5.3.1-1]
[21:27] -queuebot:#ubuntu-release- New: accepted haskell-hindent [ppc64el] (focal-proposed) [5.3.1-1]
[21:27] -queuebot:#ubuntu-release- New: accepted haskell-text-conversions [amd64] (focal-proposed) [0.3.0-1]
[21:28] -queuebot:#ubuntu-release- New: accepted haskell-text-conversions [armhf] (focal-proposed) [0.3.0-1]
[21:28] -queuebot:#ubuntu-release- New: accepted itksnap [amd64] (focal-proposed) [3.6.0-5]
[21:28] -queuebot:#ubuntu-release- New: accepted libbio-db-hts-perl [arm64] (focal-proposed) [3.01-1]
[21:28] -queuebot:#ubuntu-release- New: accepted libbio-db-hts-perl [ppc64el] (focal-proposed) [3.01-1]
[21:28] -queuebot:#ubuntu-release- New: accepted liblist-someutils-xs-perl [arm64] (focal-proposed) [0.58-1]
[21:28] -queuebot:#ubuntu-release- New: accepted liblist-someutils-xs-perl [ppc64el] (focal-proposed) [0.58-1]
[21:28] -queuebot:#ubuntu-release- New: accepted libxstring-perl [amd64] (focal-proposed) [0.002-1]
[21:28] -queuebot:#ubuntu-release- New: accepted haskell-hindent [arm64] (focal-proposed) [5.3.1-1]
[21:28] -queuebot:#ubuntu-release- New: accepted haskell-text-conversions [arm64] (focal-proposed) [0.3.0-1]
[21:28] -queuebot:#ubuntu-release- New: accepted libbio-db-hts-perl [amd64] (focal-proposed) [3.01-1]
[21:28] -queuebot:#ubuntu-release- New: accepted liblist-someutils-xs-perl [amd64] (focal-proposed) [0.58-1]
[21:28] -queuebot:#ubuntu-release- New: accepted liblist-someutils-xs-perl [s390x] (focal-proposed) [0.58-1]
[21:28] -queuebot:#ubuntu-release- New: accepted libxstring-perl [armhf] (focal-proposed) [0.002-1]
[21:28] -queuebot:#ubuntu-release- New: accepted libxstring-perl [s390x] (focal-proposed) [0.002-1]
[21:28] -queuebot:#ubuntu-release- New: accepted haskell-hindent [s390x] (focal-proposed) [5.3.1-1]
[21:28] -queuebot:#ubuntu-release- New: accepted libbio-db-hts-perl [armhf] (focal-proposed) [3.01-1]
[21:28] -queuebot:#ubuntu-release- New: accepted libxstring-perl [arm64] (focal-proposed) [0.002-1]
[21:28] -queuebot:#ubuntu-release- New: accepted haskell-text-conversions [ppc64el] (focal-proposed) [0.3.0-1]
[21:28] -queuebot:#ubuntu-release- New: accepted libxstring-perl [ppc64el] (focal-proposed) [0.002-1]
[21:28] -queuebot:#ubuntu-release- New: accepted liblist-someutils-xs-perl [armhf] (focal-proposed) [0.58-1]
[21:39] <RAOF> rbalint: a revert and then testing the proper fix fully seems sensible.
[21:40] <RAOF> The update that triggered the bug seems like a pretty borderline SRU anyway 😬
[23:18] -queuebot:#ubuntu-release- New binary: prospector [amd64] (focal-proposed/none) [1.1.7-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: php-mongo-php-adapter [amd64] (focal-proposed/universe) [1.1.11-1] (no packageset)
[23:25] <RAOF> rbalint: Are you planning to do the revert?
[23:41] -queuebot:#ubuntu-release- Unapproved: accepted update-motd [source] (eoan-proposed) [3.6-0ubuntu<IP_ADDRESS>]
[23:43] -queuebot:#ubuntu-release- New binary: update-motd [amd64] (eoan-proposed/main) [3.6-0ubuntu<IP_ADDRESS>] (core)