[00:02] <Pici> maco: done.
[00:02] <maco> Pici: thanks
[08:03] <ikonia> @mark #ubuntu poutine ban evading with new host
[08:08] <ikonia> hello Balsaq
[08:09] <Balsaq> hello ikonia
[08:10] <ikonia> how can we help you today Balsaq ?
[08:10] <Balsaq> i was just informed by a memebr of my channel, that i am banned in a room where i did not speak. could you possibly provide with the test that got me banned?
[08:10] <Balsaq> i would really like to see the text that got me banned.
[08:10] <Balsaq> becasue there is NONE. Iw il stake my life on it.
[08:11] <Balsaq> who is in charge at freenode?
[08:11] <bazhang> what channel
[08:12] <Balsaq> ubuntu-women
[08:12] <bazhang> try #ubuntu-irc
[08:12] <Balsaq> ok?
[08:12] <bazhang> this is not the channel to deal with bans in -women
[08:12] <Balsaq> what is that
[08:12] <bazhang> where you should go
[08:12] <Balsaq> ok what do i do
[08:13] <Balsaq> i want someone who is in charge to pull the text that got me banned and paste it so we can see it.
[08:14] <bazhang>  /join #ubuntu-irc
[08:14] <KB1JWQ> Balsaq: Please give it a rest.
[08:14] <Balsaq> i will try this ubuntu-irc
[08:15] <ikonia> Balsaq: then please leave this channel
[08:15] <Balsaq> no problem
[08:15] <ikonia> thank you
[08:23] <bazhang> from the bt log he seems to have a long time issue there. no point in us getting any further involved with it
[08:24] <ikonia> no, I agree
[08:24] <ikonia> for some reason I'm only showing a few bans for him in BT, yet I know there are a ton
[08:25] <ikonia> I wonder if it's something to do with most of his bans on IP, and not nick/cloak
[08:25] <ikonia> I only see 4 bans
[08:26] <ikonia> or entries I should say
[08:26] <Tm_T> ikonia: most likely
[08:26] <bazhang> one entry in the bt log is entirely bt sync :)
[08:26] <ikonia> yes
[08:27] <topyli> he was hardly banned for the "." we see in the bt :)
[08:27] <ikonia> I wonder when he was cloaked ?
[08:27] <ikonia> topyli: we ALL know that, but I don't know why (beyond IP bans) why BT's not showing more info
[08:27] <Tm_T> should I go thru my records?
[08:28] <Tm_T> is he using other nicks?
[08:28] <bazhang> tons
[08:28] <Tm_T> righto
[08:28] <bazhang> ubuxubu is a prominent one of late
[08:29] <Tm_T> I'll check what I got, one moment
[08:33] <ikonia> a lot of his other nicks where commented in BT, but I can't get them to show ??
[08:43] <Tm_T> quick grepping (which isn't so quick due disk I/O) there isn't much, but I only checked this year
[08:44] <Hobbsee> @btlogin
[08:45] <ikonia> Tm_T: probably because he was on a long term ban (or should have been)
[08:46] <Tm_T> ye
[08:46] <Tm_T> I found several removes, and discussions about him
[08:46] <Tm_T> he hasn't changed a bit
[08:46] <ikonia> the fact that he's in #freenode now asking how to get to the corperate office, shows he's just time wasting to be a problem
[08:48] <jussi>  and staff know him well I see: [10:33:48] <KB1JWQ> Balsaq: Oh here we go again.  What can I help you with?
[08:48] <Tm_T> <3
[08:48] <KB1JWQ> In fairness that was my mistake.
[08:48] <jussi> KB1JWQ: ahh, ok.
[08:48] <KB1JWQ> I got his nick confused with that of a very similar user.
[08:48] <Tm_T> bacta?
[08:48] <KB1JWQ> balsaq seems reasonable.
[08:48] <KB1JWQ> Nah, I'm not that far gone.
[08:48] <Tm_T> (:)
[08:49] <Tm_T> KB1JWQ: he seems
[08:49] <ikonia> could be anyone, bacta, jungli, panarchy, asuestek - take your pick, plenty to get mixed up with
[08:49] <KB1JWQ> What did balsaq do this evening that caused an upset?
[08:49] <KB1JWQ> I haven't been paying attention, lot of demands on my time.
[08:49] <knome> no, he's not any of those.
[08:50] <jpds> Do not assume anything.
[08:50] <KB1JWQ> Assume I'm stupid; what did he actually *do*? :-)
[08:50] <jussi> I suspect that his name may have something to do with the ban in -women - it sounds rather similar to something they would be sensitive to.
[08:50] <jussi> KB1JWQ: we arent sure atm
[08:50] <knome> jpds, well i've "known" him for months
[08:51] <KB1JWQ> I was confusing him with ballsac.
[08:51] <ikonia> KB1JWQ: ahhhhh
[08:51] <ikonia> I wonder if thats what #ubuntu-women have done ?
[08:51] <KB1JWQ> Makes a lot of sense.
[08:51] <ikonia> (and myself)
[08:51] <knome> his nick used to be something else, just can't remember what
[08:52] <KB1JWQ> I think that that may be what a lot of us have done.
[08:52] <knome> he also uses the nick ubuXubu, btw
[08:52] <knome> tostitos was the prev. nick, iirc
[08:52] <ikonia> I suppose we could ask if he's used any other nicks
[08:52] <KB1JWQ> So we may be unintentionally calling down grief upon a poor user who's done nothing more than chosing an unfortunate nick.
[08:52] <ikonia> KB1JWQ: very possible
[08:52] <KB1JWQ> No need, ikonia.
[08:52] <KB1JWQ> I have a script that tracks that.  That's not his.
[08:52] <knome> ikonia, see my comments;)
[08:53] <KB1JWQ> I see a list of users, but nothing objectionable.
[08:53] <ikonia> KB1JWQ: however he did join #ubuntu-offtopic and post a video about farts, not suggests he's not exactly the angel of maturity
[08:53] <ikonia> not that, it warrents the assumption I've made
[08:53] <knome> lol
[08:53] <KB1JWQ> So can we give him the benefit of the doubt and let him roam freely until he crosses a clearly defined line?
[08:53] <ikonia> he's only banned from #ubuntu-women
[08:53] <ikonia> he's never spoke in there,
[08:53] <ikonia> and the fuss he's making over it doesn't suggest good intentions for me personally
[08:54] <Hobbsee> one could always let him free, then reban after a few lines of rubbish.  *shrug*
[08:54] <ikonia> (personal opinion)
[08:54] <Hobbsee> then document it better
[08:54] <ikonia> let the #ubuntu-women ops deal with it
[08:54] <ikonia> Hobbsee: it's only 1 channel,
[08:54] <ikonia> it's not like he's banned from the name space
[08:54] <knome> ikonia, mmaybe he's also non-mature, but also sometimes very playful (not to be interpreted in a negative wa though - he's basically a nice guy)
[08:54] <Hobbsee> ikonia: exactly
[08:54] <KB1JWQ> Probably best that way.  Consider it a personal favor to me.
[08:55] <ikonia> knome: not doubting that, it appears (myself included) he may be mixed up with ballsaq
[08:55] <KB1JWQ> ballsac. :-)
[08:55] <ikonia> that too
[08:55] <KB1JWQ> "Balsaq" is actually a legitimate last name in some parts of the world.
[08:56] <knome> ikonia, mmh, just my 2 cents. he's been around a lot @#xubuntu
[08:56] <ikonia> I guess the #ubuntu-women ops can sort it, I'll message the banner though to make sure she's not done the same thing as us
[08:56] <ikonia> if it is a case of mistaken identity, I'll apologise to him myself too
[08:57] <Tm_T> well, he's been asked nicely to change his nick earlier, only to give attitude and excuses
[08:57] <ikonia> oh? I didn't see that
[08:58] <knome> really?
[08:58] <ikonia> ok, well I guess he was banned for that then, judging by elky's comments
[08:59] <KB1JWQ> Yeah-- i"m not trying to interfere in channel politics.
[08:59] <ikonia> apparantly, he's been told to change his nick, he knows what the ban is about and is just playing dumb now
[08:59] <KB1JWQ> He was upset and came to staff in a manner that's unlike most trolls, so I figured I'd dig a bit deeper.
[08:59] <ikonia> KB1JWQ: it would appear so
[08:59] <jussi> but surely, if he is creepy/a problem, then he will get banned soon enough...
[09:00]  * Hobbsee defers to elky
[09:00] <ikonia> jussi: he's already banned for refusing to change his nick
[09:00] <ikonia> jussi: there isn't a problem
[09:00] <KB1JWQ> jussi: That's my take.  Let him incriminate himself, then ban him with a pile of evidence as opposed to a bunch of hearsay.
[09:00] <ikonia> why
[09:00] <ikonia> an operator asked him to change his nick, he's refused, he got banned
[09:01] <ikonia> from what I'm now reading its a simple case of if you really want to be in #ubuntu-women, change your nick
[09:01] <ikonia> from what I'm reading he's more keen about making a fuss than getting back into the channel
[09:01] <KB1JWQ> Okay.  I'll accept that.
[09:02] <ikonia> maybe knome could have a chat to him as he has a bit of a relationship with him
[09:02] <ikonia> explain it to hiim ?
[09:02] <knome> ikonia, sure.
[09:02] <jussi> good idea.
[09:02] <KB1JWQ> Thanks. :-)
[09:02] <knome> maybe still invite him here?
[09:03] <ikonia> according to elky he knows why he was banned (which is probably why he's kicking up a stink)
[09:03] <ikonia> knome: maybe better in #ubuntu-irc
[09:03] <ikonia> where it "should" be resolved ?
[09:03] <knome> so you can all follow
[09:03] <ikonia> most of us are in #ubuntu-irc
[09:03] <jussi> he has been around a bit, I reconise the nick, but still,  I havent seen any behavioural issues apart from the misfortune of a marginally bad nick.
[09:04] <ikonia> jussi: I think it's the nick comfusion thats painted a worse picture,
[09:04] <knome> ikonia, oki, i can invite him there and join myself as well :)
[09:04] <ikonia> knome: he's already in there
[09:04] <jussi> knome: he is there last time I looked
[09:04] <knome> ah, okay
[09:05] <jussi> ikonia: yes, i think so also - it leads to the old rule about assuming someone is bad often makes them act worse than normal.
[09:05] <ikonia> very true
[09:05] <ikonia> I know I wouldn't be too happy to be assumed to be jewkonia
[09:06] <knome> yeah
[09:06] <elky> http://privatepaste.com/fb9275af16 is the logs I have of his banning from that channel.
[09:07] <elky> When considering his excuse, http://en.wikipedia.org/wiki/List_of_airlines_of_India may be a useful reference, as may the first hit on google for the string: http://www.urbandictionary.com/define.php?term=BALSAQ'
[09:12] <jpds> Righto.
[09:13] <elky> Just about any civil response that didn't involve UD would probably have been better.
[09:17] <bazhang> othello is poutine?
[09:20] <ikonia> don't think so, but we'll find out
[09:20] <ikonia> hello othello
[09:20] <othello> now im gonna hack u
[09:20] <Madpilot> can the scriptkiddy routine, you're not going to impress
[09:20] <ikonia> he impressed me
[09:21] <topyli> :)
[09:21] <elky> was poutine on an aussie internet?
[09:21] <ikonia> he probably ran his script on localhost
[09:21] <ikonia> killed himself off
[09:21] <ikonia> elky: I don't think so
[09:21] <Madpilot> ikonia, we can hope :)
[09:22] <ikonia> must dash, off to an office
[09:22] <ikonia> knome: thank you
[09:22] <knome> ikonia, np
[09:22] <jpds> Nice.
[09:25] <elky> knome, wth?
[09:25] <elky> only?!
[09:25] <knome> i mean :P
[09:26] <knome> *!*@unaffiliatednick ?
[09:26] <knome> not something!something@cloak
[09:27] <elky> I still don't understand how that's an "only"
[09:27] <knome> nvm the only then
[09:27] <knome> what's the reaon for the ban for balsaq then?
[09:27] <knome> the nick?
[09:28] <elky> the attitude after being asked about the nick
[09:28] <knome> does ballsac use the same cloak?
[09:28] <knome> right
[09:28] <elky> knome, this isn't about ballsac
[09:28] <elky> this has nothing to do with ballsac
[09:28] <knome> yeah
[09:29] <knome> that's what i thought as well
[09:42] <elky> I really don't like his attitude of thinking he can force his way in to other people's spaces.
[09:42] <elky> can someone turn the + operator off ubottu?
[09:43] <bazhang> ubot4
[09:43] <knome> could somebody just fix my typing?
[09:44] <bazhang> +knome
[09:44] <elky> whose is ubot4?
[09:45] <bazhang> j pds
[09:45] <Madpilot> willful cluelessness about his damn nick...
[09:46] <elky> Madpilot, yes, and I have no idea why he wants to be in the channel either. Other than because it contains women to talk at judging by his entrance in the log I posted.
[09:47] <Madpilot> seems like it. charming.
[09:49] <Madpilot> FFS. willfully thick.
[09:49] <popey> Isn't Balsaq this guys family name?
[09:49] <knome> no idea
[09:49] <Mamarok_> this is going in circles
[09:49] <elky> popey, he'd have said it by now if so
[09:49] <popey> Fabrizio Balsaq
[09:49] <elky> popey, he's never even indicated as much
[09:49] <knome> popey, does ircname prove anythig?
[09:49] <Madpilot> he spun some BS story about Indian airlines initially
[09:50] <popey> knome: a simple google search for launchpad and balsaq turns up mails to the xubuntu lists
[09:50] <elky> popey, the dishonesty is the issue more than the name.
[09:50] <popey> dishonesty?
[09:50] <Mamarok_> and I don't see what he would contribute to the u-w project anyway, if he doesn't see the problem
[09:50] <elky> popey, he quoted UD when we asked what his name meant.
[09:51] <elky> Mamarok, yeah, exactly
[09:51] <popey> yeah, I can see why someone might do that
[09:51] <knome> popey, i could think it is his family name, but till that doesn't prove anything
[09:51] <popey> what does it need to prove?
[09:51] <knome> well...
[09:51] <knome> it being hi family nme
[09:51] <knome> *name
[09:51] <Mamarok_> he never said it was in the first place, but talked abut some non-existing Indian airline
[09:51] <popey> well it seems nobody has actually _asked_ him about that
[09:51] <knome> *his
[09:51] <knome> GAAAH
[09:52] <Mamarok_> popey: he could have said that, no? Why did he try making it up?
[09:52] <popey> I dont believe he made anything up
[09:52] <Mamarok_> I see no reason to let this person in u-w
[09:52] <elky> popey, actually, we did ask what it meant.
[09:52] <Mamarok_> and he didn't say it was his famil name
[09:52] <popey> the question "what does popey mean" makes no sense
[09:52] <Mamarok_> but quoted UD with some non-existing Indian airline
[09:53] <popey> but "where does the nick popey come from" does
[09:53] <elky> Jan 18 16:59:58 *	Balsaq (n=Sausage@unaffiliated/balsaq) has joined #ubuntu-women <-- doesn't help either, to be honest.
[09:53] <Mamarok_> definitely
[09:53] <knome> i will have to leave soon for lunch
[09:54] <knome> to be exact, now
[09:54] <knome> bbl
[09:54] <Madpilot> "Balsaq'n'Sausage"... nice.
[09:54] <jpds> Go go paranoia.
[09:54] <Mamarok_> right...
[09:55] <knome> btw can somebody monitor #xubuntu?
[09:55] <elky> Madpilot, yeah.
[09:55] <Mamarok_> if he refuses to answer that simple question...
[09:55] <knome> ->
[09:56] <popey> well, I'd probably refuse to answer in his shoes
[09:56] <popey> if it was the _first_ question I might do
[09:57] <Tm_T> I fail to see insults he claim being given
[09:57] <Mamarok_> oh come one
[09:57] <Mamarok_> he was not insulted AFAICS
[09:57] <Tm_T> that's what I tried to say
[09:58] <Tm_T> he was repeating "I'm insulted" when he was asked simple questions
[09:58] <popey> cooks?
[10:00] <Tm_T> that
[10:00] <jussi> If jussi meant something nasty in indian Id likely not change it - and I could understand someone getting grumpy about it. However, he is being rather short.
[10:00] <Tm_T> jussi: but you could discuss about it without any trouble, I'm sure
[10:01] <elky> jussi, you'd probably at some point in the history of ever state that it's actually your name. He hasn't even done that.
[10:01] <jpds> jussi: Now you're attacking his height.
[10:01] <jussi> jpds: rofl
[10:01] <elky> Which makes me wonder if he's taken it as a pseudonym for the sake of the shock value
[10:02] <jpds> → http://www.youtube.com/watch?v=cycXuYzmzNg
[10:02] <Tm_T> he has nothing but avoided the subject, even in previous discussions
[10:02] <jussi> basically regardless of what the name is, he is saying it doesnt matter, dont judge me by my name.
[10:02] <popey> Am I the _only_ one who would pronounce that as "bal" not "ball"?
[10:03] <popey> as in a short A in Balloon.
[10:03] <popey> the same way I pronouce "Balsamic"
[10:03] <jussi> popey: thats how I would have said it
[10:03] <topyli> whatever the case, if i need a channel for something, i usually try to figure out the norms there so that i'm welcome. i also don't usually start arguing with the ops right away
[10:03] <popey> not Ballsamic
[10:03] <topyli> but that's just me
[10:03] <Tm_T> popey: you're not (:
[10:05] <popey> Right, so someone arrives in a channel, is told by someone who potentually mispronounces his family name that his choice of nick is inappropriate. In a nutshell.
[10:07] <elky> And then proceeds to outright tell us we're imagining it. Yep.
[10:07] <topyli> which is when they should explain that it's their name and means no offence, and perhaps ask for permission to keep it especially as that's how he's known elsewhere
[10:08] <topyli> (instead of linking to urban dictionary as proof that it's an indian airline)
[10:08] <elky> And generally not follow this up by saying they've been banned from a channel they never spoke in.
[10:09] <popey> I'm sure there are channels I would assert I have never spoken in, but logs would prove otherwise.
[10:27] <jussi> KB1JWQ: or staff if you are about, coline, spambot
[13:50] <popey> ... whereas "bastardchild1982" is an okay nickname?
[13:51] <LjL> please unban <IP_ADDRESS>, he doesn't appear to be an open proxy at the present time
[13:52] <IdleOne> LjL: done
[13:52] <LjL> thanks
[13:52] <IdleOne> thank yopu
[13:52] <IdleOne> you*
[13:52] <IdleOne> popey: ask him to change nick
[13:54] <IdleOne> IMO bastardchild is not as offensive as some nicks we have seen
[13:54] <popey> IdleOne: I am not an op in #ubuntu
[13:54] <IdleOne> popey: you don't have to be to help :)
[13:58] <IdleOne> well done :)
[14:00] <IdleOne> popey: just proved that a politely worded request does work
[14:00] <IdleOne> *sometimes*
[14:01] <popey> yeah, till he rejoins
[14:02] <IdleOne> yeah
[14:02] <IdleOne> I just noticed
[15:31] <esigolo> i`m not a bot
[15:31] <esigolo> oO
[15:31] <ikonia> ok
[15:31] <ikonia> esigolo: our bots think you are running on an open proxy
[15:31] <esigolo> ikonia, is because our firewall (watchguard)
[15:32] <ikonia> I don't know why, but possibly
[15:32] <ikonia> esigolo: do you want to try rejoining #ubuntu and I'll watch what happens ?
[15:32] <esigolo> what should i do?
[16:43] <mahen23> hi, eum why am i still banned?
[16:43] <ikonia> mahen23: because you didn't resolve the ban
[16:43] <ikonia> so it won't get lifted until you do
[16:44] <mahen23> resolve the ban?
[16:44] <ikonia> yes, work out / understand why you where banned, and agree to stop doing it
[16:45] <mahen23> U MEEN NEEDZ 2 ASK FORGIVENES?
[16:45] <ikonia> err no
[16:45] <ikonia> (don't need the caps or the l33t speak)
[16:46] <ikonia> I just mean understand why you where banned, and agree between ops/you to not to it
[16:46] <ikonia> apologies if I didn't say that clearly
[16:46] <mahen23> i asked to be banned.....
[16:46] <ikonia> ok, so that's why your banned then
[16:46] <ikonia> why are you surprised you are still banned ?
[16:47] <mahen23> i thought its a bot thing and i will be removed from a sort of list after a given amount of time
[16:47] <ikonia> no
[16:47] <ikonia> it's manual
[16:47] <ikonia> each case is different so it requries interaction from the operator
[16:48] <mahen23> so who is the operator
[16:48] <ikonia> this channel holds the operators
[16:48] <ikonia> you're welcome to talk to any of us
[16:49] <ikonia> mahen23: do you want to be unbanne ?
[16:49] <ikonia> unbanned even
[16:52] <ikonia> mahen23: hello ?
[16:52] <ikonia> oh
[16:54]  * jussi zaps ikonia in pm
[16:55] <ikonia> what what
[17:11]  * Pici blinks
[18:59] <mneptok> xX_vUvUZeLa_Xx: do you need something from the ops?
[20:27] <topyli> xX_vUvUZeLa_Xx: hello?
[20:55] <ikonia> xX_vUvUZeLa_Xx: hello ?
[21:03] <ikonia> !idle | xX_vUvUZeLa_Xx
[22:09] <ikonia> hello taybot
[22:13] <IdleOne> !idle | taypet
[22:13] <ikonia> taypet: hello
[22:14] <ikonia> taypet: its clear your active as you've just changed nicks, can you please respond
[22:17] <ikonia> taybot: can you please respond
[22:18] <ikonia> topyli: can you assist, it's clear taypet is trying to provoke
[22:18] <ikonia> topyli: sorry, I last saw you as active
[22:23] <topyli> gah! very sorry, was distracted by the simpsons
[22:27] <tsimpson|n800> don't blame me
[22:27] <topyli> hehe
[23:31] <ikonia> !info linux-image-#jaunty
[23:36] <elky> !info jaunty linux-image
[23:36] <elky> !info linux-image jaunty
[23:36] <elky> Theeeeeeeere we go
[23:36] <ikonia> I was having a moment
[23:36]  * elky pats ikonia on the head.


[09:20] <Rajiv9> Hi.. anyone here who knows about connecting via bluetooth
[09:20] <Rajiv9> to the internet
[09:20] <mdke> Rajiv9: you'll have more luck in #ubuntu probably
[09:21] <Rajiv9> okay.. thank you...
[11:53] <FoXs> Zdravim. mohl bych mit na nekoho otazku ohledne zvuku?


[21:04] <JLC> can somebody please help me fix windows?
[21:04] <JLC> i tried using boot repair, but it seemed to only make it worse
[21:04] <JLC> http://pastebin.ubuntu.com/6635888/
[21:05] <JLC> i kept getting bsod, but now it won't boot windows and just gives me graphical errors then bsod


[12:46] <webmind> no -d, clear. I have however. But I'm wondering if I need to fix something and how :)
[12:46] <webmind> the system runs, but don't want to reboot it now


[05:30] <cpaelzer> wgrant: cjwatson: hello, last week we talked about riscv64 build fails and you mentioned it might be about a timeout that was switched
[05:31] <cpaelzer> wgrant: cjwatson: but the rebuilds have failed again https://launchpad.net/ubuntu/+source/nss/2:3.55-1ubuntu3.1/+build/21363729
[05:31] <cpaelzer> and as I said before the very same source upload worked just a bit before https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4522/+build/21358522
[05:32] <cpaelzer> I still see "E: Build killed with signal TERM after 150 minutes of inactivity"
[05:33] <cpaelzer> So might there be anything else that changed in between that I need to consider ?
[05:52] <rbasak> Need some help with bug 1916250 please. Unversioned Breaks/Replaces? Unversioned Conflicts/Replaces? Something else?
[05:52] <rbasak> I wish this case were in https://wiki.debian.org/PackageTransition but I don't think it is.
[08:51] <seb128> mwhudson, hey, did you see that the ubuntu-drivers-common are failing now with the removed Depends?
[08:52] <xnox> vorlon:  sarnold: i'm not going to unleash a network firewall in, without security review. We would want it in 21.10 to at least have one release before shipping it in 22.04. It will not be ok to ship 22.04 without nftables.
[09:13] <cjwatson> cpaelzer: argh
[09:13] <cjwatson> cpaelzer: looks like I managed to screw up copying the master image over to the second of the two VM hosts, so only half of the builders were fixed
[09:14] <cjwatson> cpaelzer: I'll reschedule that nss build on one of the good builders, and reflash the bad ones properly this time
[09:17] <cpaelzer> ok it is currently running in a naive "hit rebuild button" from me
[09:17] <cpaelzer> feel free to abort and reschedule it on a better builder
[09:17] <cpaelzer> cjwatson: ^^
[12:35] <tseliot> mwhudson, why?
[12:44] <seb128> tseliot, the autopkgtests are failing now due to aplay not existing...
[12:47] <tseliot> seb128, I don't see that in the buildlog: https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.8.9
[13:02] <seb128> tseliot, the auitopkgtests are not part of the build, see https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[13:03] <tseliot> seb128, where can I find the test? I would like to see whether that test is still relevant or not
[13:03] <cjwatson> cpaelzer: All the riscv64 builders should actually have the proper timeout now.  Thanks for the note.
[13:15] <jdstrand> juliank: hey, I didn't follow your comment wrt "lxd bridge is broken by that if you enable ufw (need to add extra ufw rules to allow routing traffic to bridge; annoying)'. it is not surprising that ufw needs additional rules for lxd bridge but that shouldn't have anything to do with nft since ufw will follow the system. fwiw, I think nftables should be in main (though I wouldn't be the one doing
[13:15] <jdstrand> the work)
[13:22] <seb128> tseliot, in debian/tests from the package
[13:39] <cpaelzer> thanks cjwatson, if the old build durations are an indicator it will be another 6.5h until we know if it completes correctly this time
[14:03] <teward> jdstrand: juliank: does `lxd` know to use nftables rules if it doesn't find the traditional iptables legacy stuff, or ufw on it?  Last I checked the `lxd` snap doesn't ship with UFW rules, unless I'm blind and don't see it.
[14:04] <teward> (also, nftables is missing a lot of parity with some iptables features, so that's something to keep in mind and consider, also it hasn't passed MIR unless someone on Security's done an assessment of it and hasn't posted the results to the MIR bug.)
[14:14] <juliank> jdstrand: teward: lxd setups up its own iptables/nftables rules/chains that override ufw. well, the iptables do, but chaining in nftables works differently
[14:15] <teward> juliank: right, but i think it depends on the order of where things happen - if the rules aren't in place when you turn on ufw it *could* break those rules, if i'm reading jdstrand's comment
[14:15] <teward> (this is why I just wrote my own rule handlers for things into iptables :P)
[14:16] <teward> but as for `nft` if the rules are in place and chaining is different in nft then that may cause some headaches if nft ends up the default.
[14:16] <teward> (Though last I checked it still needs to go through MIR)
[14:16] <juliank> teward: ntftables is the default
[14:16] <teward> juliank: even though it's not passed MIR?
[14:16] <juliank> teward: just using the legacy iptables frontend
[14:16] <teward> how'd *that* happen?
[14:16] <juliank> teward: nftables the package is the new CLI
[14:16] <juliank> teward: it's different from nftables the kernel side :D
[14:17] <juliank> So we still use iptables tool in user space but in nft mode
[14:18] <teward> so... what's the backend then?  still iptables/netfilter since the kernel side nftables isn't enabled/usable?
[14:18] <teward> (FYI: clarify that in the release notes!)
[14:19] <juliank> teward: nf_tables kernel module is loaded and used by iptables userspace tool atm
[14:20] <teward> *headscratches* I think i missed some release notes then but that's a different issue
[14:20] <teward> in any case, i'm more concerned if lxd doesn't get a chance to properly chain the rules to get its rules in place for the bridges it might cause issues
[14:20] <juliank> teward: https://discourse.ubuntu.com/t/hirsute-hippo-release-notes/19221 says "nftables is now the default backend for the firewall.
[14:20] <juliank> So it's there :D
[14:20] <teward> sarnold: ^^ need your thoughts on this
[14:20] <teward> because MIR == NotComplete
[14:21] <teward> *defers to the SEcurity team for that*
[14:21] <teward> juliank: irregardless of the backend or not, i think jdstrand's question can be answered (feel free to correct me) as: "If something modifies the FIrewall rules after the LXD rules have been autoadded for the bridges, then the bridges can run into network issues due to the firewall rules having been modified after LXD added the rules"
[14:22] <teward> which... is always the case if you try and mix different rulesets together :P
[14:23] <jdstrand> juliank: sure (though, ufw sets up its own chains and iirc, so does lxd and neither strictly interfere with each other (ie, neither will flush the other's chains), but absolutely, if ufw is on, it would need rules to open things up, as you said
[14:24] <jdstrand> also, lxd will perform an algorithm to see what is being used and choose the right backend. ufw the deb just follows the system alternative (the ufw snap will do something like lxd and detect)
[14:25] <jdstrand> regardless of ufw or this discussion, I maintain that iptables should remain in main. nftables should be promoted. nftables should not replace iptables and both should be in main for the foreseeable future (in part cause of industry inertia, the iptables nft backend and teward's comments)
[14:26] <jdstrand> amurray, sarnold (cc sbeattie): fyi ^
[14:26] <teward> > though, ufw sets up its own chains and iirc, so does lxd
[14:26] <teward> jdstrand: except in NAT / mangle tables
[14:26] <teward> there's rules added
[14:26] <teward> but not chains (checksum rules among other things)
[14:27] <jdstrand> teward: yes, for sure, but they are separate chains from each other
[14:27] <teward> 'cept UFW does a blast of rules last I checked
[14:27] <teward> including NAT, mangle, etc.
[14:27] <teward> which i *have* seen cause problems in other deployments (not necessarily LXD)
[14:27] <teward> i can run some tests later but right now i'm putting out fires at work because email is being stupid
[14:29] <jdstrand> ufw loads its chains into INPUT, FORWARD and OUTPUT and then loads its rules into there. it tries to start early before other things. there are interactions between applications that manage rules, my only point is ufw won't flush lxd's rules (or libvirt's or docker's or ...) but the ordering they were loaded and their interaction need to be accounted for, to be sure
[14:29] <jdstrand> s/there/those chains/
[15:06] <vorlon> xnox, sarnold: ok, then we need to unseed nftables for hirsute
[17:51] <CarlFK> http://cdimage.ubuntu.com/ubuntu/releases/groovy/release/  Where is amd64?  LIke I would expect to see ubuntu-20.10-live-server-amd64.iso
[17:53] <CarlFK> ah, over here: https://releases.ubuntu.com/20.10/ubuntu-20.10-live-server-amd64.iso
[18:58] <CarlFK> wget http://cdimage.ubuntu.com/daily-canary/current/hirsute-desktop-canary-amd64.iso ... mount iso... pxeboot iso/casper/vmlinuz and initrd - "Detect network hardware" says "no card detected" has lots of drivers, but not for RTL810xE
[19:07] <CarlFK> I do find r8169.ko which is listed on https://linux-hardware.org/index.php?id=pci:10ec-8136-17aa-3975
[19:36]  * CarlFK uploaded an image: (4892KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/vsrALsIHXDfNvjlgDGriKWWT/63aa92f2-2f77-481a-b2e6-6467e2b5d0602625978591369286128.jpg >
[19:37] <CarlFK> the spinner is still spinning.  is this worth logging a bug?
[19:39] <dbungert> CarlFK: that one should be fixed in the latest server installer builds
[19:46] <CarlFK> ah right, this is me trying to figure out how to pxe install that.. and falling back to release because canary didn't load the nic driver
[22:03] <cjwatson> cpaelzer: nss/riscv64 succeeded eventually
[23:58] <amurray> jdstrand: yep I agree iptables should stay in main for the foreseeable future regardless of whether nftables gets promoted to main or not


[02:30] <micahg> doko: did you need something from me?
[02:33] <ScottK> Some days are better than others: https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.6/+bug/992941/comments/5
[02:34] <ajmitch> excellent!
[02:35] <micahg> awesome, now if we can just get rud of sqlite
[02:35] <micahg> *rid
[03:26] <pitti> Good morning
[03:33] <kees> infinity: you around?
[03:34] <infinity> kees: Nope.
[03:35] <kees> infinity: dang. I was gonna ask you about eglibc coordination.
[03:35]  * slangasek marks infinity absent
[03:36] <kees> infinity: I have a patchset that cleans up the existing patches (making them not ubuntu-specific)
[03:36] <infinity> kees: email would be better, I'm only sort of here.
[03:36] <kees> infinity: okidoky.
[03:37] <kees> infinity: alternatively, I could just upload it to quantal. ;)
[03:38] <infinity> You don't want a review of any sort? :P
[03:38] <kees> hehe
[03:38] <kees> emailing you the debdiff now.
[04:18] <pitti> SpamapS: I now added test cases and regression potential to all apport SRU bugs
[05:51] <pitti> rickspencer3, cjwatson, slangasek: FYI, just sent the May stable+1 status to u-devel@
[05:51] <rickspencer3> hi pitti
[05:51] <rickspencer3> thanks!
[06:23] <slangasek> pitti: thanks much :)
[07:09] <dholbach> good morning
[08:10] <larsduesing> good morning together
[08:26] <pitti> hello larsduesing
[08:42] <jibel> mvo, hey
[08:42] <jibel> mvo, is upgrade to quantal still blocked on py3 port of the release-upgrader ?
[08:44] <mvo> yes, afaict its still not working, but we need to make it work for a1
[08:49] <jibel> mvo, ta
[09:19] <brendand> what can i use in place of gobject.Mainloop in Python3?
[09:20] <pitti> brendand: use python3-gi, and GLib.MainLoop
[09:22] <xnox> If anyone knows autofs or likes cryptic patches, could you please take a look and tell me (1) what does this do (2) and why: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/autofs5/quantal/view/head:/debian/patches/16group_buffer_size.patch
[09:23] <brendand> pitti - from gi.repository import Glib?
[09:23] <brendand> pitti - i know for sure i have python3-gi installed
[09:23] <brendand> pitti - btw, i'm on precise
[09:24] <pitti> GLib, not Glib
[09:25] <brendand> pitti - ahem
[09:29] <xnox> Never mind found it: https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/591100
[09:37] <brendand> another question. what are we meant to use instead of pygst? am i correct in thinking some gi binding?
[09:41] <pitti> brendand: that's the general idea, but gstreamer 0.10 is not yet introspectable; gstreamer 1.0 will mostly be
[09:41] <pitti> (it's in universe now)
[09:42] <pitti> brendand: if you need gst 0.10, then you can't use python3 yet
[09:42] <brendand> pitti - will that be in precise?
[09:42] <pitti> no, it won't
[09:42] <pitti> precise -> python 2
[09:42] <pitti> (and pygst)
[09:43] <brendand> pitti - so i can't install gstreamer 1.0 on precise to test?
[09:44] <brendand> pitti - just want to know if i need to be updating to quantal
[09:44] <pitti> brendand: oh, you certainly can backport/build/install it, but it is not in precise prpoer
[09:44] <brendand> pitti, ok
[09:44] <pitti> brendand: I figure the gstreamer1.0 etc. packages will build on precise just fine
[09:45] <xnox> my piuparts is not up to date. Is there a latest / greatest way to set up piuparts for multiple ubuntu and debian distributions, considering i have switched to using pbuilder-dist?
[11:21] <smb> cjwatson, Sorry to ask again, I am just not sure whether this may be just a just about acceptable thing: would a 3-4 minute delay on each boot justify a SRU to initramfs-tools which looks to be low risk and testable (back into Lucid/10.04)? The alternative would be to document the workaround (I assume in the release note?).
[11:39] <cjwatson> mvo: I thought I'd fixed the upgrader; it's still not fully py3, but it shouldn't have those import bugs any more[6~
[11:40] <cjwatson> smb: All other things being equal, that looks like a reasonable SRU candidate
[11:41] <mvo> cjwatson: I haven't looked into details yet, but sudo ./dist-upgrade.py fails for me with import errors, I'm at r2435
[11:42]  * mvo actually looks closer
[11:43] <smb> cjwatson, Ok thanks. I tested a modified version in a vm and found it doing as claimed (so only adding the non-obviously depending module when the one that depends on it is requested to be in). So I will proceed to bring the report into proper state for SRU. Thanks again
[11:44] <cjwatson> mvo: I was sure I'd fixed that in revisions 2430 to 2432.  What's the exact error?
[11:44] <cjwatson> Oh
[11:44] <cjwatson> Ddamnit, it had worked
[11:44] <cjwatson> OK, give me a minute, I'll fix that
[11:46] <mvo> cjwatson: thanks! once that is done, I look at the merge from mterry and do a new upload for a1
[11:50] <cjwatson> Oh, wow, it's using __import__, what could possibly go wrong
[11:57] <mvo> *cough*
[11:58] <mvo> cjwatson: if its a hassle I'm happy to have a look at it myself, I just wanted to avoid digging into something that potentially was already done
[11:58] <cjwatson> It's OK, I broke it, I'll fix it
[11:58] <cjwatson> ... somehow
[12:02] <cjwatson> mvo: Try r2436
[12:02] <mvo> cjwatson: using importlib?
[12:02]  * mvo checks
[12:02] <mvo> cjwatson: oh, interessting!
[12:03] <cjwatson> Possibly ought to have passed locals() as well, but the docs say that the standard implementation only uses globals()
[12:03] <cjwatson> I'm fairly sure this won't work yet with Python 3, but that's for another day
[12:04] <mvo> cjwatson: thanks a bunch! I look at the py3, I think we can use importlib for this
[12:04] <mvo> cjwatson: I check that out and if its good commit
[12:05] <cjwatson> py3 can probably use __import__ too, with some extra fiddling - not susre
[12:05] <cjwatson> but yeah, importlib should be a possibility
[12:06] <cjwatson> The rest of update-manager isn't finished for py3 yet (I still have a stack of patches to sort out), so don't worry about it too much
[12:06] <mvo> ok
[13:01] <seb128> ev, pitti, ogra_: "* moving of the Launchpad retracers onto the crash database system" ... does that concern only errors.ubuntu.com or also the launchpad retracers?
[13:02] <ogra_> seb128, that was from ev's weekly report, he can probably elaborate
[13:03] <ev> seb128: pitti and I are discussing how we can reduce the duplication of effort around retracing. The functionality would remain the same, but behind the scenes the duplicate db that crash-digger uses would live in Cassandra and the Launchpad retracers themselves would run from the same server that the error tracker retracers are on.
[13:04] <ev> So this wouldn't remove Launchpad bug duplication. It would just mean that we have a single location for the apport duplicate db.
[13:05] <seb128> ev, ok, that's fine, so it means I should stop sshing to the retracers (I used to grep logs to get stats and help restarting them when they get stucked, that sort of things)
[13:06] <seb128> ev, but I feel like if you change the setup and I'm out of the loop I better step out to not create issues
[13:06] <ev> seb128: Eventually, yes. Stats will be available via a web API (let me know if there are specifics you need there). Restarting them and handling issues will fall on me and webops - so you wont have to worry about that anymore.
[13:06] <seb128> less work, I will not complain ;-)
[13:06] <seb128> ev, thanks!
[13:06] <ev> :)
[13:07] <seb128> I'm glad that ogra pointed that to -release and that I read it
[13:07] <ev> seb128: sure thing. Still in the planning stages, but I'll keep you in the loop.
[13:07] <seb128> thanks
[13:07] <seb128> ev, @stats: nothing specific, I used to build "bug which get the most duplicates" lists from the log before we had errors.ubuntu.com
[13:08] <ev> ah, glad I could automate that task away for you :)
[13:08] <seb128> ;-)
[13:31] <seb128> ev, is there a way to see the issues you submit on errors.ubuntu.com?
[13:41] <seb128> pitti, so, re. making easy to still report bugs to launchpad, we get an increasing number of users who report useless bugs about segfaults because they don't manage to use ubuntu-bug anymore
[13:41] <seb128> i.e they run it on the .crash and get a .upload and nothing else and they get confused on what happened
[13:41] <seb128> so they go on launchpad and open a bug saying they get a segfault and can't report it
[13:42] <pitti> hm, what kind of users? i. e. the "kenvandine" kind, or the "my mother" kind?
[13:42] <seb128> I'm not sure how we solve that and if we should wait on errors.ubuntu.com to improve
[13:42] <pitti> the whole point of disabling this was that we stop getting reports for stables, after all?
[13:42] <seb128> pitti, people who run quantal
[13:42] <pitti> seb128: oh, quantal; we can just re-enable LP bugs for quantal again
[13:42] <kenvandine> i was on precise though
[13:42] <pitti> there's no reason why it's disabled there other than "we did not get around to do it"
[13:43] <kenvandine> but that isn't the norm
[13:43] <seb128> pitti, do we have retracers for q yet?
[13:43] <pitti> seb128: sure, since day 1 :)
[13:43] <pitti> they are now trivial to set up
[13:43] <seb128> right, your new setups make that trivial ;-)
[13:43] <pitti> just copy the precise config file, s/precise/quantal/, done
[13:43] <seb128> pitti, ok, can we get apport turned on again in quantal soon then?
[13:43] <seb128> I think that's most of the issue I faced recently
[13:44] <ev> seb128: yes - http://errors.ubuntu.com/user/$your_sha512_hashed_system_uuid
[13:44] <seb128> users who jumped on quantal, have segfaults and struggled to report them
[13:44] <seb128> ev, how do I compute "your_sha512_hashed_system_uuid"? ;-)
[13:44] <ev> seb128: I'll have an upload of activity-log-manager soon that puts this into a button in the diagnostics tab of the privacy page
[13:44] <seb128> cool
[13:45] <seb128> ev, btw errors.ubuntu.com seems to regressed on something that worked the other day for me
[13:45] <seb128> ev, if I do
[13:45] <pitti> seb128: uploaded
[13:45] <seb128> "Error reports for "12.04" gnome-control-center "all installed version"" on a month
[13:46] <seb128> I get nothing listed
[13:46] <seb128> i.e "No data to display"
[13:46] <seb128> oh
[13:46] <ev> seb128: oh? (working on a one-liner for the compuation)
[13:46] <seb128> is "month" a "since the month start"?
[13:46] <seb128> i.e today?
[13:46] <ev> yes
[13:46] <seb128> ok
[13:46] <seb128> that's why :p
[13:46] <kenvandine> hehe :)
[13:46] <seb128> I though it was a month timeframe
[13:46] <kenvandine> good, no bugs yet today :)
[13:46] <ev> yeah, I'll fix this when we do the date range stuff
[13:46] <seb128> i.e sliding win
[13:47] <ev> indeed
[13:47] <ev> exactly that
[13:47] <seb128> ev, thanks
[13:47] <ev> sure thing
[13:48] <larsduesing> Hmpf... Short question.. I now have 3 different patches for aiccu, 2 of them possibly SRUable, one merge with debian sid... What should I do? Some ranking?
[13:48] <seb128> ev, and is there a way the repartition of a specific issue by versions?
[13:49] <ev> seb128: can you elaborate please?
[13:49] <seb128> ev, like the s-c listed first on first on e.u.c is supposed to be fixed in <IP_ADDRESS>, can we see if the reports we still get are from users who didn't upgrade yet?
[13:49] <seb128> -on first
[13:49] <larsduesing> all 3 are completely independent
[13:49] <seb128> ev, we have "last seen" in <IP_ADDRESS> but my guess is that because we don't have the "was the running version the current one"
[13:49] <hallyn> is there some nifty way to test apport hook triggers?
[13:50] <larsduesing> hallyn: yes :-)
[13:50] <larsduesing> hallyn: apport-bug
[13:50] <seb128> ev, I would like to see if on those 486 reports 480 were running <IP_ADDRESS> and 6 a false positive from users who still had the old binary running
[13:51] <larsduesing> hallyn: apport-bug <packagename>
[13:51] <hallyn> larsduesing: doesn't work well without x or without giving my lp id
[13:52] <ev> seb128: hmm, okay. I'll have a chat with mpt and see if we can come up with a good UI for that.
[13:52] <hallyn> oh wait, maybe that gets me far enough
[13:52] <hallyn> thanks :)
[13:53] <larsduesing> hallyn: it works in commandline-mode...
[13:53] <seb128> ev, well maybe my usecase is just created by the fact that we have that issue with "is the running version current", but I still think it would be somewhat useful to know the stats by version, it can give an indication of if the update worked most most user, some users, none of the users
[13:53] <larsduesing> hallyn: apport-bug --save <bugreportfilename> <packagename>
[13:53] <ev> I'll do that when we're back on Wednesday
[13:53] <hallyn> larsduesing: perfect.  thanks.
[13:53] <larsduesing> hallyn: np
[13:54] <larsduesing> hallyn: to be fair, I had these troubles a few days ago, and was helped here :)
[13:55] <hallyn> larsduesing: the libvirt apport hooks have been wrongly isntalled forever.  I needed a somewhat simple test case for SRU justification.  :)
[13:55] <hallyn> (that did not include "force libvirt to segv")
[13:55] <seb128> ev, I'm done with questions, thanks for the replies ;-)
[13:55] <seb128> pitti, thanks as well for the replies and for re-enabling apport in q ;-)
[13:57] <ev> seb128: noted. I have a branch that (at Matthew's suggestion) greys out lines that we reasonably believe to be fixed (either there are no instances of the crash in the latest version, or the attached bug is marked fix released). But I had not until now thought about separating out the frequency counts by version, so we could show the stats you mention.
[13:57] <ev> I've added that to my todo item for talking to Matthew
[13:58] <ev> seb128: sure thing. Always looking for ways to make this thing more useful for you guys.
[13:58] <seb128> ;-)
[14:00] <ev> seb128: printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum
[14:00] <ev> that should give you the other part of the URL
[14:00] <ev> so http://errors.ubuntu.com/user/$that
[14:00] <ev> without the dollar sign, of course
[14:01] <seb128> ev, excellent, thanks again ;-)
[14:05] <ev> seb128: I take it that worked?
[14:07] <seb128> ev, yes
[14:07] <ev> yay
[14:08] <hallyn> is there a way to force apport-cli, when doing --save, to give me output even though I'm running a custom built package?
[14:09] <hallyn> I don't see a '--override' option
[14:09] <seb128> ev, is there any way to go from those report to the "master" or to see if they have associated launchpad bugs?
[14:09] <ev> seb128: not as yet. Adding to the list. :)
[14:10] <seb128> ;-)
[14:10] <ev> seb128: I should've just created another blueprint/UDS session for "things Seb wants/needs" ;)
[14:11] <seb128> lol
[14:11] <ogra_> ++
[14:48] <PaoloRotolo> Hi all!
[14:54] <jamespage> how does apt determine the order in which packages are configured? does the Priority field get used in any way?
[14:54] <htorque> jono: hi! do the accomplishment descriptions use tabs or are spaces fine as well (for listing the steps)?
[14:58] <jono> htorque, tabs please :-)
[14:58] <htorque> jono: alright
[15:00]  * Sweetshark dances to the left ..
[15:00]  * Sweetshark dances to the right ..
[15:00]  * Sweetshark jumps and turns around.
[15:01] <Sweetshark> libreoffice-3.6.0~alpha1 succeeded building in 1h52min on precise.
[15:01] <Sweetshark> now only have to lob that over to quantal.
[15:05] <xnox> that quick! =)
[15:09] <jamespage> sbeattie, are the new openjdk-6 packages ready for < 12.04 yet?
[15:14] <Sweetshark> xnox: ccache+16GB RAM+SSD. Half an hour of that is tar/xz compressing the 2GB libreoffice-dbg package.
[15:14] <xnox> heh =)
[15:15] <Sweetshark> xz need multithreading.
[15:15] <Sweetshark> *nods*
[15:22] <stokachu> xnox: do you know if sunrpc's max_shared parameter was ever accepted upstream?
[15:23] <mvo> mterry: do you feel good about your software-updater branch to land in a upload for today?
[15:23] <xnox> stokachu: no clue. should check. this is with regards to nfs, right?
[15:23] <mterry> mvo, the move-changelogs one?  Sure
[15:23] <mvo> mterry: excellent
[15:23] <xnox> stokachu: or something else?
[15:23] <stokachu> xnox: yea
[15:24] <xnox> stokachu: I was under impression that sunrpc's max_shared is separately configured / enabled. but I do not know if it is upstream on linux. and which upstream of nfs. As far as I remember there were multiple implementations.
[15:24]  * xnox has vague and out-of-date nfs knoweledge, but I could pick up on it.
[15:24] <stokachu> xnox: i lowered the sunrpc.min_resvport=200 and can allow these 13k mounts to succeed
[15:25] <xnox> well done! =)
[15:25] <stokachu> but i dont want it to interfere with other services like samba
[15:26] <xnox> stokachu: cryptic. i am not even sure where to ask this to get wide exposure about this. try ubuntu-kernel mailing list or even ubuntu-devel to get more information on this.
[15:26] <stokachu> ok will do, thanks!
[15:27] <xnox> stokachu: try jelmer, he might know a lot.
[15:27] <xnox> https://launchpad.net/~jelmer
[15:27] <xnox> he is deep into samba and might now quirks like that
[15:28] <Laney> zul: you didn't actually make the change in nova-common.postinst ...
[15:29] <zul> Laney: fix is coming now
[15:30] <Laney> zul: I'm looking at 2012.2~f2~20120531.14249-0ubuntu1 now (the one you just uploaded), unless you mean that there is a second upload incoming
[15:30] <zul> Laney: second upload is coming
[15:31] <Laney> sweet
[17:21] <bdmurray> wasn't there a kernel team member asking about package install failures and postinst earlier this week?
[17:21] <cjwatson> bdmurray: apw possibly
[17:22] <apw> i was asking about postinst indeed, though not about errors
[17:22] <apw> i may have been asking about errors separatly, as there was an uptick but we didn't know if that was cause of an uptick in installs
[17:23] <bdmurray> okay, I'm just looking at bug 991282
[17:36] <bdmurray> and that bug seems to be a duplicate of bug 996373
[17:49] <jono> mterry, hey
[17:50] <mterry> jono, hello
[17:50] <jono> mterry, dpm mentioned that the Quickly flash template and /opt bug have been fixed in quickly trunk
[17:50] <mterry> jono, yup.  I pushed to precise-proposed too
[17:50] <jono> awesome! that was going to be my next question
[17:50] <mterry> jono, (and quantal)
[17:50] <jono> I will check proposed, thanks!
[17:51] <jono> I plan on upgrading to Quantal at A1 next week
[17:51] <jono> thanks
[17:51] <mterry> jono, please do, let me know of any issues so I can fix them before it actually hits users!  :)
[17:51] <jono> mterry, will do, will test now
[17:53] <slangasek> mhall119: swing global menu> !! wicked
[17:55] <highvoltage> what in the world is swing global menu?
[17:55] <jono> mterry, when did you push it to proposed?
[17:55] <slangasek> highvoltage: global menu integration for apps using swing java toolkit
[17:56] <highvoltage> aah
[17:56] <mterry> jono, oh right, it hasn't been accepted yet by an archive admin
[17:56] <jono> ahhh np
[17:57] <jono> mterry, did you manage to take a look at the qt-quick template?
[17:57] <jono> I am not sure if it has been submitted
[17:59] <mterry> jono, no I haven't looked yet
[18:00] <mterry> jono, was it ready for review?
[18:00] <jono> I am not sure, I am checking into it
[18:00] <jono> I just wasnt sure if he had submitted it yet
[18:00] <jono> I know there is the qt-quick one and the HTML5 template
[18:26] <bdmurray> oh that's fantastic all the dupes of bug 991282 are from the same person
[18:26] <mhall119> slangasek: if we can get that into OpenJDk and make it available by default for all Swing apps, that would be a big win
[18:27] <mterry> jibel, oh neat.  I was about to split the auto-upgrade-tester out of update-manager, but I see you already made a project (auto-upgrade-testing) that has done that?
[18:29] <mvo> mterry: yeah, jibel is made of awsome, it just needs a proper source package now and upload and we should be good :)
[18:29] <mterry> mvo, yar, I can do that
[18:30] <mvo> ta
[18:30] <mvo> mterry: one of my whishlist items there would also be to allow the upgrade tester to directly pull from a bzr branch instead of doing do-release-upgrade -d
[18:32] <mterry> mvo, you mean like bug 956175 ?
[18:33] <mvo> mterry: yeah
[18:33] <mterry> mvo, patches welcome...  ;)
[18:33] <mvo> hahahaha
[18:33] <mvo> thats not what you tell upstream, its the other way around ;)
[18:34] <mterry> mvo, isn't that what every feature request is?  A "patches welcome" to upstream?  :)
[18:34] <mvo> I shouldn't argue with you, you are too smart ;)
[18:35] <mterry> mvo, flattery will get you no patches, sir.  :)
[18:35] <mvo> *damm*
[18:35] <mvo> ;)
[18:35]  * mvo tries to offer some tea and cookies next
[18:35] <mterry> heh
[18:45] <maco> >< might be time to update my server precise. i can't apt-get build-dep the dependencies for a package added in oneiric on a lucid box
[18:51] <mterry> jibel, is lp:auto-upgrade-testing in a releasable state?  Like, can I package it up and put it in quantal?
[18:57] <larsduesing> Sorry, can anybody explain to me, what Mathieu wants me to do? https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/+merge/108302
[19:03] <micahg> cyphermox: ^^ what you're asking isn't possible in LP
[19:03] <dobey> cyphermox: ^^
[19:03] <cyphermox> the what?
[19:04] <micahg> cyphermox: it's yet another problem with UDD :)
[19:04] <cyphermox> isn't the merge done somehow?
[19:04] <cyphermox> what do you mean it's not possible, I've done it before ;)
[19:04] <micahg> cyphermox: oh, you mean in the changelog?
[19:04] <micahg> or in the LP diff?
[19:04] <cyphermox> yes
[19:05] <cyphermox> no, changelog should have the diff from what's left as a delta :)
[19:05] <larsduesing> Sorry, can anybody explain to me, what Mathieu wants me to do? https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/+merge/108302
[19:05] <micahg> cyphermox: ah, ok, yes
[19:05] <cyphermox> or actually, a description of what is left as changes
[19:05] <micahg> larsduesing: ^^ see above conversation, update the changelog with the list of changes over Debian
[19:05] <cyphermox> I must have written it in an unclear way :)
[19:06] <larsduesing> micahg: sorry, I got nothing here
[19:06] <larsduesing> netsplit or such
[19:06] <cyphermox> larsduesing: you're merging from Debian; which implies there are still changes left as differences from how the package is in Debian
[19:06] <cyphermox> these remaining changes should be listed in changelog :)
[19:07] <larsduesing> hmm
[19:07] <larsduesing> ok
[19:07] <micahg> larsduesing: something like this https://launchpad.net/ubuntu/+source/fox1.6/1.6.45-1ubuntu1
[19:07] <cyphermox> right
[19:07] <cyphermox> it should as a minimum be listing the upstart job file added
[19:08] <cyphermox> micahg: I'm curious as to what you said wasn't possible though?
[19:08] <micahg> cyphermox: having LP show the diff in the merge proposal from Debian :)
[19:09] <larsduesing> oh, so I should add all changes from ubuntu since the last merge from debian?
[19:09] <micahg> *diff from Debian in the merge proposal
[19:10] <cyphermox> larsduesing: yes
[19:10] <larsduesing> ok... I'm doing
[19:10] <cyphermox> micahg: no, indeed LP wouldn't show it, but that's fine as I should be able to generate that myself
[19:12] <cyphermox> and indeed it's just the upstart job that isn't listed
[19:18] <larsduesing> yes. That should be all.
[19:18] <larsduesing> sorry, I'm learning and learning
[19:18] <larsduesing> :)
[19:18] <larsduesing> thanks
[19:21] <cyphermox> larsduesing: no problem at all; I just didn't think I should be fixing this particular thing myself for your merge; it was a good opportunity to show bzr diff --old ;)
[19:21] <cyphermox> larsduesing: not sure how you committed your merge though, bzr commit or debcommit?
[19:21] <larsduesing> At least I have only a small package
[19:22] <larsduesing> debcommit
[19:22] <cyphermox> but a very useful one
[19:22] <larsduesing> All I saw was nobody is really caring for it, and so I try my best
[19:23] <cyphermox> larsduesing: (really just personal preference there) I'd use bzr commit for merges, to avoid having the commit list Debian changes; just the actual merge revision changelog
[19:23] <cyphermox> larsduesing: thanks for looking at it
[19:25] <larsduesing> simple learning how to do it in real world :)
[19:25] <larsduesing> (with more than 10-15 committers as normal...)
[19:26] <larsduesing> ok, so I should delte this branch, do a new one, and this time real correct :)
[19:27] <larsduesing> away for 10-15 minutes, got to fetch shopping out of the car from my wife :)
[19:33] <cyphermox> larsduesing: no real reason to delete the branch, you can just apply your fixes on top of it
[19:40] <bdmurray> mvo: I'm looking at bug 991282 and thinking about how to stop duplicates from the same reporter coming in
[19:40] <bdmurray> mvo: what do you think of search DpkgTerminalLog for the same 'DuplicateSignature' and stop reporting if it exists?
[19:41] <bdmurray> I guess that assumes they reported it before
[19:43] <mvo> yes, that sounds reasonable
[19:44] <mvo> we would have to SRU that, right?
[19:44] <bdmurray> well, doing it in Quantal alone would be fine with me
[19:45] <mvo> in this case feel free to just add it to trunk
[19:55] <cjwatson> larsduesing: in fact you should generally actively *not* delete branches when you get needs-fixing reviews; it's easier for your reviewer to see what you've fixed if you simply commit the fixes on top
[19:56] <cjwatson> LP merge proposals are much more useful when people do that
[20:34] <bdmurray> dobey: so is lptools not supposed to be Ubuntu specific?
[20:35] <dobey> bdmurray: not sure i understand that question
[20:35] <dobey> bdmurray: it is for tools that use the launchpad API
[20:38] <bdmurray> dobey: okay, I've a tool that parses the description for apport information not every project has bugs that are reported by apport
[20:38] <bdmurray> dobey: however, it'll do none apport specific things too
[20:38] <bdmurray> er non-apport
[20:38] <dobey> ok
[20:39] <bdmurray> lptools still seems like an okay place for it?
[20:39] <dobey> yeah, i don't see why not
[20:40] <bdmurray> cool, thanks
[20:41] <dobey> that doesn't seem ubuntu specific to me.
[20:41] <dobey> for things that are truly ubuntu specific, i guess ubuntu-dev-tools is where they'd belong though.
[20:59] <kees> infinity: did you get the eglibc patch?
[21:01] <slangasek> did ya get that THING I sent ya
[21:09] <dobey> can someone accpet ubuntuone-client into precise-proposed now please? i've gone through and added [Test Case] and [Regression Potential] headers to bugs. thanks
[21:14] <stgraber> cnd: looks like the SRU from bug 973297 is a fail, can you confirm?
[21:15] <ahasenack> hm, is bzr merge-upstream known to do something to po files? Like, wrap long lines?
[21:19] <slangasek> ahasenack: I thought my wishlist bug requesting that bzr merge do intelligent .po handling was still outstanding
[21:20] <ahasenack> slangasek: not sure what is happening, but I'm using merge-upstream with a new tarball, and in both the tarball and local branch some entries in the po are very long lines
[21:20] <ahasenack> slangasek: so no difference bar one real change, a typo
[21:20] <ahasenack> slangasek: yet the resulting po file has all long lines wrapped, resulting in a big diff
[21:20] <slangasek> interesting
[21:21] <ahasenack> if I just replace the po file with the one from the tarball, this is the diff: http://pastebin.ubuntu.com/1018636/
[21:22] <slangasek> ahasenack: bug #884270?
[21:22] <slangasek> apparently it is fixed :)
[21:22] <ahasenack> if I run merge-upstream with the tarball, I get this diff: http://pastebin.ubuntu.com/1018638/
[21:22] <ahasenack> slangasek: let me check that bug
[21:24] <slangasek> so it's configurable and overrideable
[21:24] <slangasek> but yeah, with that code enabled, by default your .po files are going to be in a normalized format after merge
[21:24] <ahasenack> ok, that explains it
[21:25] <slangasek> basically, because it's using the gettext merging tools that understand .po format, instead of bzr's default line-based merge
[21:25] <ahasenack> so, po_merge
[21:25] <ahasenack> I do have it
[21:25]  * ahasenack keeps on reading
[21:26] <cjwatson> I occasionally do bzr remerge --no-plugins when it annoys me
[21:26] <cjwatson> well, on the specific files
[21:26] <slangasek> good to know
[21:26] <cjwatson> that said, if your .po files aren't already run through msgcat before committing them to bzr, you're doing it wrong
[21:26] <slangasek> though honestly, everyone should normalize their .po files anyway, to reduce noise in the VCS diffs :)
[21:26]  * slangasek nods
[21:27] <cjwatson> you can do that once in one separate commit before merging
[21:27] <ahasenack> in this case both the previous and the current one are not normalized
[21:27] <ahasenack> and to normalize them I will have to add a package patch
[21:28] <slangasek> heh, yeah, not the thing to do in this case then
[21:28] <ahasenack> because the upstream tarball has them like that
[21:28] <slangasek> but I guess upstream is in poking distance, so they can fix it for next time ;0
[21:28] <slangasek> ;)
[21:28] <ahasenack> yeah, I could cheat even for this one I guess
[21:29] <ahasenack> anyway, good to understand what is going on
[21:29] <ahasenack> thanks
[21:31] <ahasenack> good to know about remerge too
[21:31] <ahasenack> since bzr merge-upstream --no-plugins wouldn't work :)
[21:31] <cjwatson> Indeed :)
[21:32] <SpamapS> hrm, this is an odd nut here..
[21:33] <SpamapS> https://launchpadlibrarian.net/106616529/apt-get-install.log
[21:33] <SpamapS> install zookeeperd on a fresh quantal box...
[21:33] <SpamapS> the dep chain is  zookeeperd->zookeeper->default-jre-headless->openjdk-7-jre-headless ...
[21:33] <SpamapS> but somehow, default-jre-headless is configured *before* openjdk-7-jre-headless
[21:34] <cjwatson> any Recommends or circular dependencies involved?
[21:34] <SpamapS> then zookeeper is  configured, and then zookeeperd, which then fails because start-stop-daemon: unable to stat /usr/bin/java (No such file or directory)
[21:34] <SpamapS> the java world is one big circular dependency .. so its quite likely
[21:35] <cjwatson> Doesn't seem likely that e.g. openjdk would depend on zookeeper though
[21:35] <SpamapS> ahh, --no-install-recommends produces a different order
[21:35] <SpamapS> the "correct" order
[21:36] <slangasek> SpamapS: I'm confused, I don't see the error you're describing in that log (zookeeper start/running, process 9007)
[21:37] <SpamapS> slangasek: thats just the script
[21:37] <SpamapS> slangasek: it fails shortly thereafter
[21:37] <dobey> hi SpamapS
[21:37] <slangasek> so the package configuration doesn't guarantee a working package?
[21:37] <slangasek> anyway, ca-certificates-java is almost certainly part of the lovely dependency loop... not sure why zookeeper turns up in the middle though
[21:38] <dobey> also, can someone accept ubuntuone-control-panel into precise-proposed ? i've added the test/regression headings as requested on its bugs as well.
[21:38] <slangasek> possibly because zookeeper only depends on default-jre-headless, which *is* configured, so dpkg/apt have no reason to think zookeeper can't also be configured?
[21:39] <SpamapS> slangasek: yeah not sure, start-stop-daemon should be returning 0, meaning that the job shouldn't show 'started' .. but maybe it returns non-zero *after* forking
[21:39] <slangasek> that's a buggy assumption of course, it should entirely solve the dependency loop before proceeding
[21:39] <SpamapS> slangasek: but default-jre-headless depends on openjdk-7-jre-headless
[21:39] <slangasek> yes, but there's a dependency loop
[21:39] <slangasek> it has to be broken *somewhere*
[21:39] <SpamapS> slangasek: so default-jre-headless shouldn't be configuring until after openjdk-7-jre-headless
[21:40] <slangasek> we appear to be going in circles about loops ;)
[21:41]  * SpamapS agrees and tries desperately to avoid crossing the streams
[21:41] <SpamapS> slangasek: something in the Recommends path changes the problem :p
[21:42] <slangasek> oh actually, I hallucinated that loop
[21:42] <slangasek> default-jre-headless isn't part of the loop
[21:43] <slangasek> SpamapS: this seems to not be the ca-certificates-java in quantal though, which is still -6-?
[21:44] <SpamapS> slangasek: right, seems to dep only on 6
[21:44] <SpamapS> slangasek: but openjdk-7-jre-headless does Provide: java6-runtime-headless
[21:45] <SpamapS> don't we have tools for finding circular deps?
[21:46] <slangasek> circular deps are not a bug
[21:47] <slangasek> ah, so the problem is that default-jre-headless *also* Provides: java6-runtime-headless
[21:48] <slangasek> so apt/dpkg get confused and decide that the circular dependency is between default-jre-headless, openjdk-7-jre-headless, and ca-certificates-java
[21:48] <slangasek> when it's supposed to only be between openjdk-7-jre-headless and ca-certificates-java
[21:48] <slangasek> SpamapS: I think the workaround is to drop the provides from default-jre-headless
[21:49] <slangasek> SpamapS: but it's still a bug in the package manager's configure ordering
[21:53] <SpamapS> slangasek: so, should I open a dpkg task on bug 1007433 ?
[21:53] <hyperair> why is upower refusing to allow me to hibernate? =\
[21:53] <slangasek> SpamapS: seems like it
[21:53] <hyperair> it seems to be a polkit issue.
[21:56] <hyperair> aha, found it: http://askubuntu.com/questions/94754/how-to-enable-hibernation-in-12-04
[21:59] <larsduesing> cyphermox: if you are still here, i fixed the changelog
[22:38] <ahasenack> Daviey: around?
[22:39] <ahasenack> Daviey: fwiw, #1004678 is back in sponsorship, I also just subscribed ubuntu-sponsors
[22:39] <ahasenack> Daviey: just pinging you because you took a look before
[22:40] <bdmurray> slangasek: do you have an idea of what is wrong in bug 991282?
[22:53] <slangasek> bdmurray: a wrong successful exit from mkinitramfs?  Maybe a wrong mkinitramfs on the path that's not from Ubuntu?
[22:58] <bdmurray> a modified mkinitramfs should show up in the bug description
[23:04] <slangasek> bdmurray: right, but it could be in /usr/local/bin or something
[23:05] <bdmurray> ah, sure
[23:05] <maco3> is there some sort of rule that says "the more you learn about how something works, the weirder the error conditions you hit become"?
[23:25] <penguin42> maco3: You do normally manage to make more complex configs and work past the simpler errors to points where less knowlegeable people won't have reached
[23:25] <penguin42> maco3: The other theory is the code  is just out to get you
[23:27] <maco3> penguin42: i learned today that doing a dist upgrade inside of byobu is a bad ide
[23:27] <maco3> *ideda
[23:27] <maco3> *idea
[23:27] <maco3> grawr
[23:27] <penguin42> the boyobu died during the upgrade?
[23:27] <maco3> yep
[23:27] <maco3> ps tells me dpkg is still running and trying to ask me questions
[23:27] <maco3> i just can't *answer* the questions
[23:28] <penguin42> is that a valid bug in byobu?
[23:28] <maco3> probably not? i think python is was mid-upgrade
[23:29] <maco3> you're technically supposed to close all applications before going to a new release
[23:29] <penguin42> hmm - I wouldn't expect screen to die in those circumstances
[23:29] <maco3> its just not the sort of thing i think of as an "application"
[23:31]  * penguin42 doesn't know enough about python to know if it's supposed to be able to cope - it's a mess if it can't
[23:33] <maco3> JanC just pointed out that when running an upgrade remotely is when you *really* want screen
[23:34] <JanC> I think the server upgrade notes recommend that actually
[23:35] <JanC> I'm sure Debian recommends it
[23:35] <penguin42> yeh it's good for when the network disappears during the upgrade
[23:37] <Laney> yeah it's known when screen gets upgraded
[23:38] <Laney> for example http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644788
[23:38] <JanC> ah, so screen is still running, but you can't attach?
[23:38]  * maco3 raises an eyebrow
[23:38] <Laney> if it is this bug
[23:39] <JanC> that's ugly  :-/
[23:40] <JanC> does tmux have the same issue?
[23:40] <maco3> that bug only talks about if you get disconnected from the ssh session
[23:41] <maco3> i was connected the entire time. screen stopped
[23:41] <JanC> Laney: I guess that's why Debian makes you upgrade some essential packages first, then the rest?
[23:42] <maco3> https://bugs.launchpad.net/ubuntu/+source/screen/+bug/1007658 <- my bug


[02:37] <Nyha> Does Eduuntu have some admin tool for the teacher to view students desktop?
[03:51] <mhall119> italc
[03:51] <mhall119> but you're not here anymore...
[13:12] <Nyha> Does Eduuntu have some admin tool for the teacher to view students desktop?
[13:16] <highvoltage> Nyha: there's a tool called iTalc that can be used for that
[13:18] <Nyha> I'll look in to that, thanks.
[13:23] <Nyha> highvoltage: do you know any others to compare with?
[13:28] <highvoltage> Nyha: none that I can think of, but if you hang around some other people may have some more suggestions :)
[13:34] <alkisg> Nyha: are your clients normal edubuntu workstations or are they thin clients (LTSP)?
[13:37] <alkisg> Anyway, there's also controlaula for normal workstations if you want to compare, but personally I wouldn't even install it because it doesn't get cleanly uninstalled. Some people use it though.
[13:38] <alkisg> And there's also http://wiki.tcosproject.org/Utils/TcosMonitor but I haven't tried it
[13:39] <alkisg> (i'm not sure if it runs outside of the tcos project)
[13:41] <Nyha> alkisg: Im working on building a workstation network and later a thin client, if I can get any here in South Africa ;)
[13:42] <alkisg> Nyha: well if you want to try the others go ahead, but your best bet is italc
[13:43] <Nyha> alkisg: Shu, I'll have a look at them all.
[13:44] <Nyha> alkisg: TcosMontiro use iTalc to remote view... :P
[13:45] <alkisg> Nyha: it can use either italc or vnc
[13:45] <alkisg> ...and, italc uses libx11vnc :)
[13:45] <Nyha> :P
[13:45] <alkisg> So they're all vnc inside...
[13:45] <Nyha> and is this secure?
[13:46] <alkisg> italc is. But of course security comes with a speed/cpu price.
[13:46] <alkisg> My only problem with italc is that it's barely maintained anymore... last release was years ago, I hope the advertised 2.0 version will come later on this year or at least in 2011.
[13:47] <alkisg> (so if it works for you, fine, if it crashes etc don't expect any fixes soon :))
[13:48] <Nyha> alkisg: ah :P
[13:48]  * alkisg had to create his own tools for classroom management - unfortunately not ready for international use yet.
[13:49] <Nyha> Okey?
[13:49] <Nyha> Scripted using other apps?
[13:49] <alkisg> Yes, but put a lot of pygtk in the mix too.
[13:49] <alkisg> +twisted for the networking backend
[13:50] <Nyha> okey :P
[13:50] <Nyha> So its a gui tool
[13:50] <alkisg> http://wiki.ubuntu-gr.org/sch-scripts/screenshots
[13:51] <alkisg> In 2 years, if italc 2.0 isn't ready yet, I'll try to push it in the ubuntu repositories :)
[13:51] <alkisg> So for now, go for italc and hope it works fine for you :)
[13:51] <Nyha> Ah elinika...
[13:52] <alkisg> Nyha: ? can you speak greek?!
[13:52] <Nyha> ligo
[13:52] <alkisg> Wraios!! :)
[13:53] <Nyha> I spent two years in tesaloniki and in rodos on rodos..
[13:53] <Nyha> and two mounth in kalamata.
[13:53] <alkisg> Wow, you've been all around Greece!
[13:53] <Nyha> Ofc.
[13:54] <Nyha> :P
[13:56] <Nyha> So you use this litle app as a teacher or as a it-cafe admin?
[13:58] <alkisg> We use it in almost all of the schools in greece that use ubuntu - as teachers ,yeah
[14:01] <Nyha> Cool, it looks like something I'd like to try, Im working on a project in cape town to build Ubuntu-based (ubuntu is Xhosa and Zulu language) computer arias for kids groing up with nothin in the townships..
[14:01] <Nyha> s/arias/areas
[14:03] <alkisg> Sounds good. Take a look at LTSP thin+fat clients too, they're much easier to maintain than standalone labs.
[14:04] <Nyha> alkisg: Ye, at the moment I have 20 "normal" workstations, so this is what I'll start with, than I'll try to find a way to get thin clients for expanding. :P
[14:05] <alkisg> I'm booting all the normal workstations as fat clients, it's much faster this way, and much easier to maintain.
[14:05] <alkisg> (we don't have actual thin clients in any greek schools - only old + new PCs used as thin/fat clients)
[14:07] <Nyha> I have found one problem so far, the workstations bios does not support network booting..
[14:07] <alkisg> That's not a problem, we put gpxe in the windows or linux boot manager
[14:08] <alkisg> Anyway, time to get some work done, bbl.
[14:08] <Nyha> alkisg: thanks for the help :P
[14:08] <alkisg> np - good luck
[22:27] <KE1HA> Is APT-PROXY the best approach for managing applicaiton versions & policy changes on a school LAN/WAN ?


[06:26] <tsimonq2> kees: Since you're chairing the TB meeting later, you're welcome to skip my agenda item (well, a review of an action item I had); I didn't quite get the time to follow through with that but I will have something before the next TB meeting.
[06:28] <tsimonq2> kees: Oh, and I totally misread the calendar, so unless I ping you after doing it tonight (which is possible, heh) then skip it...
[06:49] <_Marek_> hi
[06:50] <_Marek_> id like to ask about mdadm and ubuntu live install - i had 4 disks as raid5 starting with sda
[06:50] <_Marek_> sda sdb sdc sdd
[06:50] <_Marek_> during installation ubuntu accidentally picked sda instead of sdf
[06:51] <_Marek_> does ubuntu automatically recognize its a raid disk or did it just wipe one disk?
[07:44] <doko> LocutusOfBorg: any update on the llvm sanitizer issues?
[10:18] <juliank> LocutusOfBorg: gnutls28 merged
[10:24] <LocutusOfBorg> thanks juliank!
[11:02] <doko> xnox: could you have a look at<EMAIL_ADDRESS>?
[11:06] <juliank> mvo: If I run command-not-found petname, it shows me "snap petname" (OK) and "deb petname ()" - the () are confusing, should there be something in there?
[11:06] <mvo> juliank: its a bug, sorry for that
[11:07] <mvo> juliank: let me upload a fixed version right now. I was holding the upload back because there is some further output discussion
[11:07] <xnox> doko, thanks....
[11:10] <juliank> mvo: not a big deal, I was just wondering
[11:10] <mvo> juliank: its uploaded now
[11:11] <mvo> juliank: most likely the output will be tweaked but at least the most glaring bugs are fixed now (and tests are much much better too)
[12:21] <tsimonq2> mvo: If snapd isn't installed (like with Lubuntu), the snap output for command-not-found isn't shown, correct?
[12:22] <tsimonq2> If not, I consider that a regression which I'll happily submit a patch for.
[12:59] <mvo> tsimonq2: without snapd it should simply skip snaps - if that that is a bug
[13:23] <tsimonq2> mvo: ack
[13:30] <mvo> tsimonq2: if you notice any issues, please do let me know and I will fix
[14:15] <xnox> infinity, back to our conversation about "auto-bumping d-i netinst size". Imho to catch the "crazy, d-i should not have grown by 2x" it should be an autopkgtest that compares sizes of new d-i, versus previous upload and/or versus release pocket of the last LTS.
[14:15] <xnox> infinity, such that it would be an autopkgtest force-bad test, to say "nah, this is all good we really want to ship 10 MiB of network cards firmwares" vs "no this is dumb, somebody upload a fixed d-i"
[14:16] <xnox> infinity, because the current feedback loop of FTBFS, re-upload to bump d-i by 10 KiB is not fun at all.
[14:16] <xnox> and our current d-i sizings are not as tight as they could be.
[14:16] <xnox> infinity, thoughts?
[15:04] <sil2100> !dmb-ping
[18:29] <infinity> xnox: I think you're spending way to much time thinking about overengineering a solution for something you've had to commit *once* for in two years.


[14:31] <sarnold> good morning
[14:32] <slyon> heyho! o/
[14:32] <slyon> c_paelzer is out today. So I can run the meeting.
[14:32] <eslerm> hello o/
[14:32] <slyon> #startmeeting Weekly Main Inclusion Requests status
[14:32] <meetingology> Meeting started at 14:32:32 UTC.  The chair is slyon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:32] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:32] <joalif> ο/
[14:32] <slyon> Ping for MIR meeting - didrocks joalif slyon sarnold c_paelzer jamespage ( eslerm dviererbe )
[14:32] <slyon> #topic current component mismatches
[14:32] <slyon> Mission: Identify required actions and spread the load among the teams
[14:32] <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:32] <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:33] <slyon> Nothing new (as expected, archive is still frozen)
[14:33] <slyon> #topic New MIRs
[14:33] <slyon> Mission: ensure to assign all incoming reviews for fast processing
[14:33] <slyon> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
[14:33] <sarnold> oh hello perl
[14:33] <slyon> We have a bunch of reviews to do for the big libmail-dmarc-perl tree
[14:34] <slyon> I guess we have 3 reviewer here today (incl. didrocks who agreed to take 1 per week). So let's just assign a few.
[14:34] <slyon> I'd like to take the libnet-idn-encode-perl one as I have some context on that.
[14:34] <slyon> Any preference, joalif ?
[14:35] <joalif> none in particular, no preference
[14:35] <slyon> ok. So bug #2039456 for joalif
[14:35] -ubottu:#ubuntu-meeting- Bug 2039456 in libnet-ip-perl (Ubuntu) "[MIR] libnet-ip-perl (as libmail-dmarc-perl dependency)" [Undecided, New] https://launchpad.net/bugs/2039456
[14:35] <joalif> ok
[14:35] <slyon> bug #2038929 for slyon
[14:35] -ubottu:#ubuntu-meeting- Bug 2038929 in libnet-idn-encode-perl (Ubuntu) "[MIR] libnet-idn-encode-perl (as libmail-dmarc-perl dependency)" [Undecided, New] https://launchpad.net/bugs/2038929
[14:35] <slyon> bug #2037405 for didrocks
[14:35] -ubottu:#ubuntu-meeting- Bug 2037405 in libemail-abstract-perl (Ubuntu) "[MIR] libemail-abstract-perl (libemail-sender-perl dependency as libmail-dmarc-perl dependency)" [Undecided, New] https://launchpad.net/bugs/2037405
[14:36] <slyon> The rest needs to wait for next week due to our rate-limiting.
[14:36] <slyon> (of course anybody is free to voluntarily pick more)
[14:36] <slyon> #topic Incomplete bugs / questions
[14:36] <slyon> Mission: Identify required actions and spread the load among the teams
[14:36] <slyon> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
[14:37] <slyon> update on bug #1877696 from eslerm – nothing to do for us
[14:37] -ubottu:#ubuntu-meeting- Bug 1877696 in openscap (Ubuntu) "[MIR] openscap" [Undecided, Incomplete] https://launchpad.net/bugs/1877696
[14:38] <slyon> update on bug #2023971 ...
[14:38] -ubottu:#ubuntu-meeting- Bug 2023971 in libmail-dmarc-perl (Ubuntu) "[MIR] libmail-dmarc-perl" [Undecided, Incomplete] https://launchpad.net/bugs/2023971
[14:39] <sarnold> mirespace has been *busy*
[14:39]  * slyon re-assigning didrocks to bug #2039563 as that should get priority over the libemail-abstract-perl one, according to Miriam's update here
[14:39] -ubottu:#ubuntu-meeting- Bug 2039563 in libregexp-common-perl (Ubuntu) "[MIR] libregexp-common-perl (as a libmail-dmarc-perl dependency)" [Undecided, New] https://launchpad.net/bugs/2039563
[14:40] <slyon> Indeed! Lot's of work went into this package splitting and paperwork!
[14:40] <slyon> #topic Process/Documentation improvements
[14:40] <slyon> Mission: Review pending process/documentation pull-requests or issues
[14:40] <slyon> #link https://github.com/canonical/ubuntu-mir/pulls
[14:40] <slyon> #link https://github.com/canonical/ubuntu-mir/issues
[14:41] <slyon> Nothing new...
[14:41] <slyon> #topic MIR related Security Review Queue
[14:41] <slyon> Mission: Check on progress, do deadlines seem doable?
[14:41] <slyon> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
[14:41] <slyon> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[14:41] <slyon> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[14:41] <slyon> Internal link
[14:41] <slyon> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[14:41] <slyon> eslerm: sarnold: Any updates?
[14:42] <sarnold> I've been out for nearly three weeks, no context on anything lately :)
[14:42] <eslerm> we're going to make a PR to request no new security MIRs after a certain date, perhaps beta freeze, without approval from Alex or similar
[14:42] <eslerm> the x13s packages were a bit tight, and rough
[14:43] <slyon> Yes, those were VERY last-minute.
[14:43] <sarnold> we've never liked the lack of deadlines but understood that we didn't have the capacity to do better
[14:43] <slyon> Refining this policy through a PR sounds like a good plan. I'm looking forward to your proposal!
[14:44] <sarnold> we're doing better now, and having some more predictability on when exactly we expect a cycle's requests to be made has been making more and more sense, and the x13s packages just crystalized that this could be done better for everyone :)
[14:44] <eslerm> nothing much else new, we have been discussing fuzzing all the new perl packages
[14:44] <sarnold> i'm leaning towards MIRs need to be filed before feature freeze, but there's good arguments for lots of dates. please do try to think about what would make the most sense
[14:45] <slyon> Yes. We should all think about that already, so we can comment on the PR, once ready.
[14:45] <eslerm> will do, I was thinking of two dates possibly, the latter being actual assignment to our team
[14:46] <sarnold> I think that's us done
[14:47] <slyon> #topic Any other business?
[14:47] <eslerm> none
[14:47] <sarnold> i'll try to get to the new meeting time poll soon, but this is a hiring-heavy week
[14:48] <slyon> ^ Good! I think we're missing some more votes on that one (check your emails for the link)
[14:48] <eslerm> ^^
[14:49] <slyon> Thanks, that's all folks! Enjoy 10 min back :)
[14:49] <sarnold> woot, thanks slyon, eslerm, joalif :)
[14:49] <eslerm> thanks all o/
[14:49] <joalif> thnaks slyon, all :)
[14:49] <slyon> #endmeeting
[14:49] <meetingology> Meeting ended at 14:49:51 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-10-17-14.32.moin.txt