[12:49] <darkbyte> Hi all !
[12:50] <darkbyte> Anyone knows how I can recompile the current dapper kernel without modifying version number (2.6.15-26-386) to be able to use the current restricted modules available ?
[12:52] <crimsun> sorry, but the question's confusing. Why would you need to recompile the current Dapper kernel to use the current [Dapper]  l-r-m?
[12:54] <darkbyte> I need to modify the ide-probe.c driver file to be able to use a Promise TX4 card with my VIA chipset motherboard. And I would to use as much as posible of the repository packages, as the linux restricted modules.
[12:54] <darkbyte> If I can rebuild the kernel only with the patched ide driver I don't need to touch enything else.
[12:56] <crimsun> do said modifications to ide-probe.c export additional symbols or anything of the like? If so, you'll still need to bump the ABI, which means you'll end up recompiling l-r-m
[12:56] <darkbyte> I only need to comment 3 lines of code
[12:57] <crimsun> then just recompile using the infrastructure you get via ``apt-get source linux-image-$(uname -r)''
[12:57] <crimsun> it's documented on the wiki (see topic) afair
[12:58] <darkbyte> I don't see this (glups) ...
[01:00] <darkbyte> downloading rith now, thanks crisum a try it ...
[01:01] <darkbyte> right, I try
[07:52] <crimsun> BenC: hi, hope the tourney went well. The patches sent to the list should be applied to Dapper's and Edgy's linux-sources. There are enough fixes in alsa's tree that syncing the aoa driver to Edgy's linux-source is recommended.
[08:31] <TheMuso> C
[12:57] <thom> right, i guess i get to find out in a while whether i've fixed #37452 finally
[01:19] <rodarvus> BenC, ping
[02:31] <zul> hey
[02:49] <zul> BenC: how was the tournament?
[03:32] <BenC> rodarvus: pong
[03:32] <BenC> zul: didn't play the tournament, just played for some cash
[03:33] <rodarvus> BenC, I have two FTBFS, depending on (theoretical) updates to l-k-h, do you think you can spend some time on these issues today? (or soon)
[03:34] <rodarvus> in both cases, missing include files
[03:34] <rodarvus> BenC, I talked with fabbione last week, but he wanted to talk to you, before adding/changing stuff on l-k-h
[03:35] <rodarvus> BenC, http://librarian.launchpad.net/3640193/buildlog_ubuntu-edgy-sparc.xorg-server_1%3A1.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[03:35] <rodarvus> and
[03:35] <rodarvus>  gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -Wall -Wall -g -O2 -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg -I../../src -MT evdev_drv_la-evdev.lo -MD -MP -MF .deps/evdev_drv_la-evdev.Tpo -c ../../src/evdev.c  -fPIC -DPIC -o .libs/evdev_drv_la-evdev.o
[03:35] <rodarvus> In file included from ../../src/evdev.c:66:
[03:35] <rodarvus> ../../src/evdev.h:74:24: error: asm/bitops.h: No such file or directory
[03:35] <rodarvus> ../../src/evdev.c: In function 'EvdevReadInput':
[03:35] <rodarvus> ../../src/evdev.c:95: warning: format '%ld' expects type 'long int', but argument 6 has type 'unsigned int'
[03:35] <rodarvus> ../../src/evdev.c: In function 'EvdevParseBits':
[03:35] <rodarvus> ../../src/evdev.c:348: warning: implicit declaration of function 'set_bit'
[03:35] <rodarvus> make[3] : *** [evdev_drv_la-evdev.lo]  Error 1
[03:36] <rodarvus> (the second one was from xserver-xorg-input-evdev, which I didn't uploaded yet, due to the FTBFS be happening on all archs)
[03:40] <rodarvus> the two are rather serious: the first prevents xorg-server (and and thus *all* drivers) to be built on sparc
[03:40] <rodarvus> the second basically prevents anyone from using evdev on current Edgy
[03:40] <zul> BenC: ah cool..
[03:41] <BenC> rodarvus: ok, I can fix that
[03:43] <BenC> rodarvus: bitops.h is a bogus include
[03:44] <BenC> well, it is on some arch's anyway
[03:44] <BenC> on sparc, it's wrapped in __KERNEL__, so it's blank
[03:44] <BenC> if all it's using is set_bit(), then evdev should just define that locally using a generic one
[03:46] <BenC> rodarvus: look in include/asm-generic/bitops/atomic.h for a version of set_bit that evdev.c can use locally
[03:47] <BenC> rodarvus: as for kbio.h:
[03:47] <BenC> $ find include/ -name kbio.h
[03:47] <BenC> $
[03:48] <BenC> there is no such file, so that definitely is bogus
[03:50] <rodarvus> BenC, so just remove asm/kbio.h from xorg-server, then?
[03:51] <BenC> yeah
[03:51] <rodarvus> BenC, I'll do it - thanks!
[03:55] <infinity> BenC: Have you tried to push -fno-stack-protector upstream yet?
[03:56] <infinity> BenC: It'd be swell if upstream sources built on the edgy toolchain unmodified by the time we release.
[03:58] <BenC> infinity: someone grabbed it from Ubuntu source and sent it upstream, but I don't know if it got accepted
[04:01] <zul> there was a patch to fix the kernel so it can compile with ssp
[04:01] <zul> hey jeff
[04:02] <jbailey> Heya Zul
[04:02] <jbailey> There was something you asked me the other day.
[04:02] <jbailey> hmm
[04:02] <zul> the xen stuff..
[04:02] <jbailey> I replied, and someone else had stolen your nick  /me checks for logs.
[04:02] <jbailey> Right!
[04:03] <jbailey> I confused some guy because he wanted to know why a stranger was asking for straces of ls on his bsd system.
[04:03] <zul> hmmm..
[04:03] <zul> thats weird
[04:04] <jbailey> I'll paste the conversation to you.  It was amusing.
[04:04] <zul> heh ok
[04:06] <BenC> I had to switch my nick to secure because if I'm off for > 12 hours, there's always this same guy that grabs my nick and I end up having to /kill him from nickserv
[04:06] <zul> jbailey: lol
[04:06] <jbailey> BenC: Is that the auto-kick if you don't identify stuff?
[04:07] <zul> same here..
[04:07] <BenC> jbailey: if I understand correctly, /m nickserv set secure on, makes it so you have to identify or you get /kill'd
[04:07] <jbailey> Nice!  I should set that.
[04:08] <BenC> I should let one of you guys take my nick for a minute to see if it works :)
[04:09] <jbailey> Sure.  I'll use my jb-home account.
[04:10] <BenC_> jbailey: ok
[04:10] <benc> -NickServ- This nickname is owned by someone else
[04:10] <benc> -NickServ- If this is your nickname, type /msg NickServ IDENTIFY <password>
[04:10] <benc> So let's see. =)
[04:11] <BenC_> it's been > 60 seconds
[04:11] <infinity> This feature seems lacking.
[04:12] <BenC_> very
[04:12] <infinity> Yay!
[04:12] <BenC_> lol
[04:12] <benc> Even that wasn't enough to shock the system into working
[04:12] <benc> Clearly defective.
[04:12] <BenC_> specially, darwin :)
[04:12] <thom> BenC_: 15:12 <thom> set kill on
[04:12] <thom> 15:12 -NickServ(NickServ@services.)-   Always the same guy as well.
[04:15] <infinity> But in my case, I'm usually connected for weeks at a time.
[04:15] <infinity> And if I'm off for more than a few minutes, he's got my nick.
[04:16] <BenC> same here...it's just times like when I travel
[04:16] <infinity> Bizarrely antisocial behavious.
[04:16] <infinity> behaviour, too.
[04:16] <thom> infinity: irc
[04:16] <infinity> thom: yeah, but it's not eactly efnet.
[04:16] <BenC> hehe...efnet
[04:16] <thom> infinity: true 'dat
[04:17] <BenC> it's strange that I can go on there every few months or so and see ppl that I used to chat with 6-7 years ago still hanging out in the same channels
[04:17] <infinity> it's hard to give up one's channel list.
[04:18] <infinity> I have a 25 year old friend who still hangs in "#12-15teenz", cause he founded it (ironically, when we was 11)
[04:18] <BenC> lol
[04:19] <BenC> those are the kinds of channels just begging for pedaphiles :)
[04:20] <infinity> I'm pretty sure no one in there is 12-15 anymore, since it's been the same group of friends from around the globe since its inception, and no one else seems to poke their heads in.
[04:20] <infinity> THough I made the same comment, when I first saw it on his channel list.
[04:21] <zul> jbailey: once i get it working :)
[04:57] <BenC> mdz: ping
[04:57] <mdz> BenC: pong
[05:09] <BenC> mdz: nm, you replied via email
[05:09] <BenC> thanks
[05:14] <jbailey> BenC: BTW,  last kernel I tried on the G5 still had the sata_ whatever problem and the kernel panic (if you turn off quiet and splash)
[05:15] <jbailey> BenC: Got magic smoke out the back of the power supply on Friday, though, so it might be a bit before I can test again.
[05:15] <jbailey> I had planned this weekend to copy down the oops and post it.  Oh well.  =/
[05:19] <kbyrd> mdz: just got your email.
[05:19] <BenC> jbailey: ok
[05:19] <mdz> kbyrd: welcome
[05:20] <kbyrd> thanks.
[05:20] <kbyrd> So, I completely misunderstood the l-r-m packages. I thought it was a single user-installable package containg a bunch of .ko files.
[05:21] <BenC> kbyrd: mostly it is, but we can create separate module .deb's from it if needed
[05:22] <kbyrd> perfect.
[05:22] <mdz> kbyrd: currently it builds one binary package per kernel ABI containing kernel modules, plus a few extra things (like X drivers) which aren't tied to a kernel ABI
[05:22] <BenC> but being built from a common source package means we can keep the ABI in sync more easily
[05:23] <mdz> kbyrd: what will complicate things is needing to keep things in sync as the kernel ABI changes
[05:23] <kbyrd> That sounds like the right spot then. The player package we handed off to mvo builds both a binary and source package (so people can use module-assistant)
[05:23] <mdz> kbyrd: we handle that with metapackages built from linux-meta which pull in the rgiht versions
[05:23] <mdz> this will mean two additional metapackages for the vmware modules, which is doable but not very convenient
[05:24] <kbyrd> Since there is not vmware-server yet (our legal team is doing it's thing right now), what can I do to help get vmware-player-kernel in the l-r-m build?
[05:25] <infinity> Fix the license to not require a click-through.
[05:25] <infinity> That's the only thing preventing me from rolling it in.
[05:26] <infinity> Cause I refuse to require a click-wrap on all of LRM, for the sake of one module.
[05:26] <kbyrd> I didn't do the original player-kernel package, I didn't realize the player-kernel package had a EULA. That's not right.
[05:26] <infinity> (Well, fix the license, fix your policy regarding the license, whichever. :))
[05:26] <kbyrd> inifinity: I agree.
[05:27] <infinity> The guy who originally did the packaging was told from on high that he had to do it that way.  He also violently disagreed with the whole idea.
[05:27] <kbyrd> So, we'll still have a click thru on vmware-player, just not on vmware-player-kernel. That work?
[05:27] <infinity> Yeah, that would be fine.
[05:27] <kbyrd> Yea, we're fighting that from that ground up.
[05:27] <infinity> I'd be happy to roll it into LRM as soon as we can do so, which was discussed in the dapper cycle.
[05:28] <kbyrd> (maybe we'll get the modules open sourced here if we get what we want).
[05:28] <kbyrd> but not soon.
[05:28] <infinity> It would be amazingly cool if the modules were not only open-sourced, but shared a common code-base between player/workstation/server, but that'll be a while to co-ordinate, I suspect.
[05:28] <infinity> (Cause it would be pretty cool if we shipped the "right modules" out of the box for any of your products)
[05:30] <kbyrd> infinity: For us, those are two different problems. VMware has never had a good, co-install story. The code is all very similar, just different branches for QA / support reasons.
[05:30] <infinity> Yeah, I know, I've discussed this in the past. :)
[05:30] <infinity> But it's a shame, that's all.
[05:30] <kbyrd> embarrassing actually.
[05:31] <kbyrd> When I've got a non-click thru vmware-player-kernel package source, should I just come back here?
[05:31] <kbyrd> thanks all.
[06:02] <BenC> wow, we are totally not ready to have ubuntu work on pSeries machines...having trouble even doing a boot with our stuff that expects a lot of mac'isms
[06:03] <zul> BenC: send me one and i can help ;)
[06:15] <mdz> BenC: any objection to me tightening the linux-meta dependencies as discussed?  it only affects the top-level metapackages which depend on -image-foo and -restricted-modules-foo
[06:16] <mdz> BenC: also, can we make linux-686-smp and linux-k7-smp transitional packages now?  they seem obsolete
[06:18] <BenC> mdz: yeah, sounds good
[06:28] <kbyrd> infinity: you around?
[06:34] <kbyrd> anyone else then... Earlier, infinity said the thing holding up vmware-player-kernel being built as part of l-r-m was that it had a click-thru EULA. I just downloaded the package and checked it out. I found nothing requiring user interaction. I bet we had something like this originally, but it's not in the current version. There is still a click-thru EULA for vmware-player, just not the kernel mod
[06:34] <kbyrd> ules.
[06:43] <BenC> kbyrd: if that's the case, then we can just pull it into lrm for edgy no problem
[06:45] <kbyrd> BenC: 1) Can one of you confirm I'm not crazy? If I'm wrong, I'd rather find out now and fix it now. 2) Is there any way to get it done before the next kernel ABI update for Dapper?
[06:46] <BenC> doubtful that it will happen for dapper
[06:48] <BenC> I just need to add vmware modules to my list of things to update for dapper kernel ABI bumps...but since those wont happen very often (if ever again), then I don't expect it to be a problem there
[06:49] <kbyrd> BenC: hmmph. Ok, any way to get notified when an kernel ABI change is in the queue for Dapper before  it hits the repository?
[06:51] <kbyrd> That "ever again" thing worries me. Since it happened twice pretty quickly so far.
[06:51] <kbyrd> Since you said that out loud, it's sure to happen again ;-)
[06:51] <BenC> that's because we had a lot of updates for dapper that just didn't make release
[06:52] <BenC> heh, well, even if it does, we always get it our within a day or two of the update, or likely at the same time now
[06:54] <kbyrd> Cool, thanks. Ok, last thing for now. Is someone looking at my *-9 update that I sent last week? That'll fix the  bug about module-assistant builds not working.
[06:56] <BenC> ping zul, he did the last few uploads of the modules, which by law makes him responsible for everything after that with the package :)
[06:58] <kbyrd> Nice, sort of like when I comment on some code in our source. I'm forever destined to fix all future bugs about it even it it's not my code.
[06:59] <BenC> you've experienced this development model before...excellent :)
[07:00] <kbyrd> I just msg'd zul, is his email @ubuntu.com as well?
[07:01] <BenC><EMAIL_ADDRESS>I think
[07:23] <zul> or<EMAIL_ADDRESS>[07:26] <zul> since when was i responsible :)
[07:39] <thom> BenC: wrt #37452 i at least have a built kernel with the two patches i mention. I'll test them tomorrow morning.
[07:42] <BenC> thom: ok
[07:43] <zul> BenC: oh yeah im entering in a tournament tonight
[07:43] <BenC> private or casino?
[07:43] <BenC> or online?
[07:44] <zul> casinoish...its at a restatunt/bar
[07:44] <zul> i should last about an hour ;)
[07:46] <BenC> is it a freeroll?
[07:50] <zul> yeah
[07:53] <BenC> ah, those are mainly an all-in fest
[07:53] <BenC> no skill involved :)
[07:54] <zul> yeah but i rather play live than online
[07:54] <BenC> play tight...if you get aces, just go all-in, someone will call you
[07:54] <BenC> no doubt
[08:09] <jbailey> BenC: Did you read about the world strip poker championships going on next month?
[08:10] <jbailey> I have a feeling that's one tournament I wno't watch...
[08:10] <zul> if they have women in it i would watch
[08:10] <BenC> heh, I imagine I wont be watching it either :)
[08:11] <BenC> High Stakes Poker on Game Show Network has become my new Poker TV addiction
[08:11] <BenC> it's much more exciting and the game play is much more realistic to what you normally see in a live game
[08:12] <BenC> ppl watching World Poker Tour and WSOP tend to think you play poker just like those guys, but it's a totally different situation than most poker games that ppl play :)
[08:12] <jbailey> Right.  As opposed to "Let the bear win" type of strategy. =)
[08:38] <mdz> BenC: any reason to keep l-s-2.6.15 and l-r-m-2.6.15 around in edgy?
[08:47] <BenC> mdz: none
[08:49] <mdz> BenC: please request their removal via ubuntu-archive then, so that we don't forget before the release and pitti doesn't cry
[08:50] <BenC> mdz<EMAIL_ADDRESS>[08:50] <mdz> BenC: file it in Malone and subscribe ubuntu-archive to the bug
[08:51] <BenC> ok
[08:55] <BenC> mdz: done
[08:56] <mdz> thanks
[09:26] <zul> ouch...BLK_LOOP is compiled into the kernel
[10:10] <jbailey> BenC: Got a checkout of reasonably current upstream git handy and a sec to look something up for me?
[10:11] <zul> later folks
[10:11] <jbailey> g'n chuck
[10:32] <BenC> jbailey: sure
[10:33] <jbailey> BenC: I managed to trace it, sorry for the noise.
[10:40] <BenC> np
[11:10] <makx> hmm bogl uses PAGE_SIZE inside of asm/page.h
[11:10] <makx> is that still exported?
[11:15] <BenC> there's nothing in it
[11:15] <BenC> at least not on ppc
[11:16] <makx> yup it's failing to build on ppc debian buildd
[11:17] <BenC> PAGE_SIZE is a little ambiguous on ppc
[11:18] <BenC> depends on 32-bit or 64-bit kernel, so even if it's 32-bit userspace, if you are really concerned about what the kernel is using, then you cannot be sure
[11:18] <BenC> I suggest getpagesize(2)
[11:19] <makx> yup will do
[11:21] <jbailey> live checks, good. =)


[02:34] <hyperactivecrond> err... according to https://wiki.ubuntu.com/DocteamProjects there is "help wanted." i've actually been doing (italics)something(end) with it, so we are working on it ftr
[04:10] <Madpilot> Burgundavia: that odd HowToInstall page on the wiki is ompaul's work
[09:38] <Burgundavia> Madpilot, thanks
[03:05] <mhz> has anyone seen jelkner or kjcole today?
[03:16] <mdke> yep :)
[03:16] <mdke> kjcole, mhz is looking for you
[03:16] <mhz> mdke: thx
[03:16] <mhz> ;)
[03:57] <Hendikins> Quick question. Any idea why the wiki breaks a link to FirefoxAMD64FlashJava? It only linkifies the D64FlashJava section, which has left me needing to use an "external" link on FirefoxPlugins
[03:58] <mdke> Hendikins, link using ["NameOfPage"]  or [:NameOfPage:Text for link]
[03:58] <mdke> Hendikins, see HelpOnEditing for more details
[03:58] <Hendikins> Ah, right.
[06:43] <damnhil> how do I use https://docteam.ubuntu.com/repos/ ?
[06:59] <damnhil> is rob1 here?
[07:16] <mdke> damnhil, hello. that url is a subversion repository
[07:17] <mdke> see https://wiki.ubuntu.com/DocteamStepByStepRepository
[07:17] <mdke> in general, https://wiki.ubuntu.com/DocteamGettingStarted should be useful for you
[07:20] <mdke> as for the preview site, you have to wait a while sometimes, the server is a bit slow
[07:27] <damnhil> mdke: how do I commit changes after I modify the doc files at  https://wiki.ubuntu.com/DocteamStepByStepRepository ?
[07:27] <damnhil> I got email from ubuntu doc mailing list saying I am not a member. How do I become a member of the doc mailing list?
[07:29] <mdke> damnhil, go to http://lists.ubuntu.com/mailman/listinfo/ubuntu-doc and subscribe
[07:30] <mdke> damnhil, as for committing changes, it should all be explained on the DocteamStepByStepRepository page, you need to send a patch to the mailing list
[07:34] <damnhil>  mdke: I sent the patch to the person who edited the page instead. How do I commit the changes? I think I need username and password to access the doc CVS
[07:34] <mdke> damnhil, hang on a second.
[07:35] <mdke> damnhil, what did you patch?
[07:36] <mdke> if you patched a document from our repository, you need to send the patch to our mailing list, someone will take a look at it, and commit it, if it works
[07:37] <damnhil> I did not actually patch the webpages. I addressed the errors in the pages in the sent emails. I am compiling the 3 sent emails to send to the ubuntu doc mailing list. If I patch the doc repo, I will send it to the doc mailing list.
[07:38] <mdke> ok
[07:38] <mdke> damnhil, you understand that the webpages at doc.ubuntu.com are generated from xml source, which is contained in our repository, right?
[07:40] <mdke> i have to go now, but feel free to ask any more questions on the mailing list
[07:40] <mdke> /a/away
[11:36] <damnhil> What's the webpage that has yes/no questions regarding to receiving email from the ubuntu doc mailing list?
[11:37] <Burgundavia> damnhil, what is the issue
[11:39] <damnhil> Burgundavia: I found it. It is at http://lists.ubuntu.com/mailman/options/ubuntu-doc/freehil%40gmail.com Sorry.
[11:44] <damnhil> Burgundavia: how do I see the message  I sent to the mail list ?
[11:44] <Burgundavia> lists.ubuntu.com
[11:44] <Burgundavia> look for ubuntu-doc


[03:20] <duflu> Hmm, has Jenkins approved anything yet?
[13:41] <dandrader> I'm going through Alf's "Mir in VMware quick-start guide"
[13:41] <dandrader> "6. If you are using Mesa drivers, stop the virtual machine"
[13:41] <dandrader> how do I know if I'm using such drivers?
[13:41] <greyback> dandrader: what GPU have you?
[13:42] <dandrader> onboard intel
[13:42] <dandrader> greyback, ^
[13:42] <greyback> dandrader: you're using MESA then
[13:42] <dandrader> ok, thanks
[13:43] <dandrader> greyback,  "7. sudo apt-get install glmark2 and run 'glmark2' to ensure that it runs and
[13:43] <dandrader>    shows SVGA as the renderer (not llvmpipe!)"
[13:44] <dandrader> greyback, that's from inside the vm, right?
[13:44] <greyback> dandrader: yep
[13:44] <greyback> just to confirm you're using the host's GPU, instead of emulating GL using CPU inside the vm
[14:28] <dandrader> greyback, it's using llvmpipe. how do I fix that?
[14:30] <greyback> dandrader: hmm go back over the steps and double-check. It just worked for me


[19:36] <sarnold> cpaelzer: sorry, I lost power; I had hoped the 'not going' link in the calendar entry would have done something useful, bummer :*
[21:13] <cpaelzer> sarnold: ok
[21:13] <cpaelzer> sarnold: don't we all try to ignore calendars :-)
[21:13] <sarnold> cpaelzer: my usual problem is ignoring them when going to bed the night before :)
[21:13] <cpaelzer> sarnold: I hope you are back online and also otherwise ok again
[21:13] <cpaelzer> hehe
[21:13] <sarnold> cpaelzer: yes, all good now, thanks :)
[23:11] <wxl> #startmeeting Community Council meeting
[23:11] <meetingology> Meeting started at 23:11:02 UTC.  The chair is wxl.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[23:11] <meetingology> Available commands: action, commands, idea, info, link, nick
[23:11] <wxl> welcome everyone to yet another episode of the Community Council meeting
[23:11] <wxl> i'll be your chair today
[23:11] <wxl> unfortunately, i didn't do my job and create an agenda so we'll go off of the minutes from the last meeting
[23:11] <wxl> https://discourse.ubuntu.com/t/minutes-for-the-2021-02-03-community-council-meeting/20761
[23:12] <wxl> that said…
[23:12] <jose> #chair wxl teward linaporras jose Eickmeyer toddy nhaines
[23:12] <teward> *burps*
[23:12] <meetingology> Current chairs: Eickmeyer, jose, linaporras, nhaines, teward, toddy, wxl
[23:12] <wxl> oh yeah thanks for that. i forget how to work this thing :)
[23:12] <wxl> #topic Local Communities Research Committee
[23:13] <toddy> I have created the vote
[23:13] <wxl> so we have all of our nominations
[23:13] <jose> we have all voted I think
[23:13] <wxl> we didn't get the full representation we wanted globally, but we did pretty good
[23:13] <toddy> yes, but from two regions we have no nominations
[23:14] <wxl> so do we have a tally?
[23:14] <linaporras> Yes we still have that problem, mabe through the research they committee can find active members there...
[23:14] <linaporras> *maybe
[23:15] <jose> I'd say let's give toddy some time to tally and process the votes, and communicate the results via email
[23:15] <toddy> Now, all council members have vote
[23:15] <toddy> I will communicate the results via email
[23:15] <linaporras> cool!
[23:15] <wxl> ok that works
[23:15] <nhaines> yay!
[23:15] <wxl> in any case we're moving forward and that's a good sign
[23:16] <toddy> yes
[23:16] <wxl> outside of informing the members of their new roles, is there anything else we need to do to get them started on the work at hand?
[23:16] <linaporras> I do not know if a meeting with them would be useful...
[23:16] <toddy> should we create a launchpad project for them?
[23:17] <jose> for tracking work items?
[23:17] <jose> that would work
[23:17] <wxl> i think maybe both of those ideas are good ones
[23:17] <toddy> yes
[23:17] <linaporras> 🤔
[23:17] <nhaines> Couldn't hurt.
[23:17] <wxl> maybe we should have them set it up?
[23:19] <jose> either way works for me
[23:19] <toddy> I think we can do it and so we are the owner of the project/group
[23:19] <wxl> ah fair point toddy
[23:19] <wxl> ok so who wants to do that?
[23:19] <toddy> o/
[23:20] <wxl> okie dokie then
[23:20] <wxl> #action toddy to set up a Launchpad project for the LCRC with the CC as owner.
[23:20] <meetingology> ACTION: toddy to set up a Launchpad project for the LCRC with the CC as owner.
[23:20] <wxl> linaporras: do you want to try to set up a meeting? your idea was a good one, i think
[23:21]  * wxl drops a pin
[23:21] <linaporras> Yes
[23:21] <wxl> okie dokie then :)
[23:21]  * nhaines picks up a pin
[23:21] <nhaines> wxl: you dropped this.
[23:21] <wxl> oh!
[23:22] <linaporras> I can do it, we can set the meeting at this channel or do you prefer something like a videocall...
[23:22] <wxl> #acction linaporras to set up a meeting between the LCRC and the CC.
[23:22] <wxl> i kan spel
[23:22] <wxl> #action linaporras to set up a meeting between the LCRC and the CC.
[23:22] <meetingology> ACTION: linaporras to set up a meeting between the LCRC and the CC.
[23:22] <wxl> i don't think it matters too much. whatever works best for the lcrc i think
[23:22] <wxl> anyone else have anything else on the LCRC?
[23:22] <nhaines> That can be their first decision!
[23:23] <wxl> i'll take that apparent silence as a no
[23:23] <linaporras> 😀
[23:23] <wxl> #topic IRC Council
[23:23] <wxl> as i understand nhaines was supposed to report about the IRC Council and the current status of memberships at the last meeting
[23:24] <nhaines> Yes.  I've emailed out (a bit late) and expect to hear back... but by next meeting.
[23:24] <wxl> ok
[23:24] <nhaines> So no updates on that but I'll start harassing people via IRC if I don't hear back in a week.  :)
[23:24] <wxl> #action nhaines to provide status of IRC Council by next meeting.
[23:24] <meetingology> ACTION: nhaines to provide status of IRC Council by next meeting.
[23:24] <nhaines> +1
[23:25] <wxl> i'm going to skip GSOC as it seemed to me like we had generally discounted that idea
[23:25] <wxl> that said
[23:25] <jose> sounds fair
[23:25] <wxl> #topic New business
[23:25] <linaporras> ok
[23:25] <wxl> anything else?
[23:26] <linaporras> https://www.irccloud.com/pastebin/ANtbzX9s/
[23:26] <linaporras> I saw the e-mail Confusion over ESM and "Standard Support" vs. End of LIfe
[23:26] <linaporras> any news on that?
[23:26] <teward> nothing
[23:26] <linaporras> Sorry by the snippet...
[23:26] <teward> that literally went out last night
[23:26] <teward> so it's very new in the list.
[23:27] <teward> THIS SAID
[23:27] <linaporras> Ok... Guess could be a topic for our next meeting... to see how that evolves... is that ok?
[23:27] <teward> there seems to be consensus among multiple individuals that we need hard definitions made
[23:27] <teward> hence the email going out
[23:27] <teward> (hggdh of the IRCC agreed)
[23:27] <wxl> i agree
[23:27] <wxl> teward: can i assign an item to you to report on your findings next meeting?
[23:27] <teward> message was CC'd to the Community Council and TB, and I have an email to CC responses to for IRCC.
[23:27] <nhaines> I agree, I think the categories are pretty simple, we just need them defined.
[23:28] <teward> wxl: assuming I get any responses, yes.
[23:28] <nhaines> Because they've changed since the beginning.  :)
[23:28] <teward> indeed, not to mention we need a firmer definition of "at what point should the Community Support Options be unsuable?" and generally that'd be "End of Standard Support"
[23:28] <wxl> #topic teward to provide an update by next meeting on the ESM/Standard Support/EoL confusion
[23:29] <wxl> ugh i made that a topic?
[23:29] <teward> namely that ESM as a paid service has Paid Support which is the only way to get extended support via Canonical
[23:29] <wxl> wow help me
[23:29] <teward> wxl: *wags the Finger of Shame at you*
[23:29] <wxl> #action teward to provide an update by next meeting on the ESM/Standard Support/EoL confusion
[23:29] <meetingology> ACTION: teward to provide an update by next meeting on the ESM/Standard Support/EoL confusion
[23:29] <wxl> so moving on
[23:29] <wxl> #topic any other business
[23:29] <wxl> anything else??/
[23:31] <nhaines> I do want to mention that Ubuntu members get ESM, too.  I forget if that's available to the community for a couple machines as well.
[23:31] <wxl> huh i didn't know that
[23:31] <nhaines> But it's similar to the Livepatch situation.
[23:31] <wxl> ok well it sounds like that's it so i'm going to call the meeting in 10 seconds
[23:31] <jose> i do
[23:31] <jose> just wanted to bring you up to speed
[23:31] <nhaines> jose with the last minute.
[23:32] <linaporras> jajajaja
[23:32] <wxl> second, almost
[23:32] <jose> Canonical now has two community representatives, Rhys and Monica. I'll be meeting with them within the month in order to chat about their role and what our priorities are, so they can also help us with moving forward any items that might need an insider push
[23:32] <wxl> nice!
[23:32] <nhaines> \o/
[23:32] <toddy> cool
[23:33] <wxl> #info Canonical now has two community representatives, Rhys and Monica!
[23:33] <madhens> Hello, all :)
[23:33] <nhaines> madhens: hello!  :)
[23:33] <wxl> oh hai
[23:33] <wxl> NICE
[23:33] <madhens> I just wanted to drop in casually but I am so excited about working with all of you, and please, reach out here or at<EMAIL_ADDRESS>anytime. :)
[23:34] <linaporras> the benefit... that mention  nhaines, we should put it here: https://wiki.ubuntu.com/Membership, right?
[23:34] <nhaines> After we confirm it, yes.
[23:34] <wxl> OH WAIT IT'S YOU, MONICA???? oh man, this is great!
[23:34] <linaporras> Hi, nice to meet u
[23:34] <jose> I would delegate that item to the RMBs since they own the membership process
[23:34] <madhens> wxl: Hahahahaha!!!
[23:35] <jose> welcome to the party :)
[23:35] <linaporras> I found this: https://ubuntu.com/blog/ua-services-deployed-from-the-command-line-with-ua-client but yes we can confirm and delegate...
[23:35] <madhens> jose: Thank you! Next time I'll bring snacks. :)
[23:35] <nhaines> linaporras: yes, I thought I remembered that.  Thanks! :)
[23:36] <wxl> don't forget the tea!
[23:36] <madhens> lina: Very nice to meet you too!
[23:36] <jose> that's all I had, I'll share more news as I have them. It's going to be a long working cycle, I'm sure :)
[23:36] <madhens> wxl: Oh, I never forget the tea. :)
[23:36] <nhaines> madhens: Welcome! :)
[23:36] <linaporras> cool!
[23:36] <wxl> ditto that :)
[23:37] <madhens> nhaines: Hello, and thank you!
[23:37] <linaporras> so for the benefit jose... for the delegation an update of that item... can you write to them or ?
[23:39] <jose> would you be able to take that action item, please? I'm a bit busy with work so can't make a commitment at this point
[23:39] <linaporras> ok i'll do it
[23:39] <linaporras> no problem
[23:39] <jose> thank you :)
[23:39] <wxl> this is updating the membership thingy?
[23:39] <wxl> with esm?
[23:40] <linaporras> yes
[23:40] <wxl> ok
[23:40] <linaporras> confirm the benefit and updated
[23:40] <linaporras> update it
[23:40] <linaporras> jaja
[23:40] <wxl> #action linaporras to confirm that Ubuntu members get ESM as a benefit and update the wiki accordingly.
[23:40] <meetingology> ACTION: linaporras to confirm that Ubuntu members get ESM as a benefit and update the wiki accordingly.
[23:41] <wxl> ok we done now?
[23:41] <jose> no
[23:41] <jose> we have to choose a chair for the next meeting
[23:41] <linaporras> me
[23:42] <linaporras> i told u the previous meeting
[23:42] <jose> oh okay, I forgot
[23:42] <jose> there, problem solved
[23:42] <jose> now we done
[23:42] <linaporras> I will do my first chair here jeje
[23:42] <nhaines> That was easy!
[23:42] <nhaines> Thanks linaporras  :)
[23:42] <wxl> #action linaporras is our next meeting chair!
[23:42] <meetingology> ACTION: linaporras is our next meeting chair!
[23:42] <wxl> ok now we're done? :)
[23:42] <linaporras>  👍
[23:43] <wxl> ok shutting it down then
[23:43] <wxl> thanks everyone
[23:43] <wxl> #endmeeting
[23:43] <meetingology> Meeting ended at 23:43:10 UTC.  Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-02-17-23.11.moin.txt
[23:43] <toddy> thanks wxl for chairing
[23:43] <wxl> np
[23:43] <linaporras> ☕
[23:44] <madhens> Great to see you all, and jose, just let Rhys and I know whenever you'd like to meet!
[23:44] <jose> Rhys will be setting up some time soon - I'll ping him otherwise :) I poked him yesterday, tried to reach you but it seems like you were still being onboarded
[23:46] <madhens> Yuuuuup. Yesterday was my first day!
[23:46] <wxl> many congrats madhens, seriously. and so glad to see you in particular filling that role. you'll do great!
[23:47] <nhaines> madhens: congrats!  :)
[23:47] <madhens> wxl thank you so much. That really means a lot, and I'm really excited to get in and to start helping in a role that really can help. :)
[23:48] <toddy> madhens: congrats and welcome to the show :)
[23:48] <madhens> toddy: Thanks! Good thing I pop my own popcorn. :D
[23:48] <toddy> :D
[23:49] <linaporras> 🍿
[23:50] <madhens> Speaking of food, I am going to go poke around my friends for something I can turn into dinner! But have a good night/late afternoon, wherever everyone is, and I'll see you all in two weeks, if not sooner!
[23:50] <madhens> My fridge, even.
[23:50] <wxl> night be well!
[23:51] <toddy> Oh yes, it is time for the bed. good night!
[23:55] <linaporras> see u


[02:17] <nlsthzn> cheers all
[08:23] <chesedo> It seems to be some fox...
[08:23] <chesedo> what's the new release named again?
[15:09] <Kilos> afternoon guys, hope you are all well
[15:09] <Kilos> here is some good news from firefox i think
[15:10] <Kilos> https://fullcirclemagazine.org/2018/03/29/new-firefox-extension-builds-a-wall-around-facebook/
[15:10] <Kilos> that should stop FB finding out what colour panties we wear
[15:24] <Kilos> till they buy the fox maybe
[16:34] <Kilos> where is maaz?
[16:34] <Kilos> inetpro: fix it
[16:34] <Kilos> chesedo: why you so quiet lad
[16:35] <Kilos> all of you, dont you communicate anymore??
[16:36] <Kilos> ai ai ai ai ai
[16:37] <Kilos> inetpro: where are the ibids
[16:38] <Kilos> superfly: you broke it
[16:50] <Kilos> i even forgot my bots name
[16:50] <Kilos> but one of you broke her
[16:51] <Kilos> oh yeah QA was her name
[16:52] <Kilos> paddatrapper: whats happening here?
[17:16] <paddatrapper> Kilos: pretty quite, not much has happened lately. How are you doing?
[19:22] <pavlushka> o/
[19:27] <pavlushka> how to route between <IP_ADDRESS>(host) and <IP_ADDRESS>(host) manually? and how to set route in <IP_ADDRESS>(host) to be able to ping <IP_ADDRESS>(host)?


[01:14] <phillw> hi, is there anyone here with  a dedicated GPU card ?
[02:20] <Noskcaj> !nano
[02:20] <Noskcaj> is nano a default app for 13.10?
[02:28] <Noskcaj> IS anyone online with a working 13.10 install?
[02:28] <Noskcaj> if so, is nano still a default app?
[03:37] <balloons> Noskcaj, nano a default app? well nano is command line :-)
[03:44] <Noskcaj> balloons: one of the hardware test cases uses nano, i was wondering if we still ship it
[03:44] <balloons> yes..
[03:45] <Noskcaj> ok
[03:45] <Noskcaj> dumb question
[04:15] <Noskcaj> Can someone check the multiple hard drive part of the Entire disk install testcase. it is outdated and confusing
[05:39] <Noskcaj> balloons, if you're online. i have another big merge comming up
[06:24] <shadeslayer> phillw: yep
[06:25] <shadeslayer> phillw: have a : 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Seymour [Radeon HD 6400M/7400M Series]
[06:26] <shadeslayer> hmm ... when trying out otto + kubuntu I get : lxc container failed to recieve answer for command
[06:26] <shadeslayer> also : lxc container failed to send command
[07:31] <shadeslayer> jibel: <shadeslayer> hmm ... when trying out otto + kubuntu I get : lxc container failed to recieve answer for command
 also : lxc container failed to send command
[07:35] <shadeslayer> I am unsure as to what command it's trying to send there ...
[07:35] <shadeslayer> ( that is right after sudo bin/otto -d start saucy-otto )
[09:58] <apw> gema, i was asking for the sheet you do have
[11:52] <gema> apw: I don't have a sheet
[11:53] <gema> apw: I am trusting the driver implementation
[11:53] <apw> gema, i was asking for the sheet for the one you said you had a sheet for, i have since found it
[11:53] <gema> ahh, sorry
[11:53] <gema> I thought you meant the nexus 4
[12:49] <DanChapman> Good afternoon :-)
[13:57] <phillw> balloons: https://wiki.ubuntu.com/QATeam/Hardware is alive. Just need someone else to also check it, as Linda's link is wrong.....
[14:50] <apw> gema, this n4 driver, its remaining charge is calculated purely using the integer percentage, which seems utterly inaccurate
[14:53] <gema> apw: otp
[14:54] <balloons> phillw, :-)
[15:06] <gema> apw: sorry, lost context completely
[15:06] <gema> I am back
[15:07] <gema> apw: I am not sure what you mean, it seems to me that full charge would be the result of doing something like calculate_fcc_uah - calculate_unusable_charge
[15:07] <apw> gema, i was saying in this n4 driver, the raw coulombs output are already exposed, and that the remaining_charge as calculated is simply made up from teh full capacity and the integer
[15:07] <gema> and remaining charge should be charge now
[15:07] <apw> remaining charge is (full_charge * current_percentage)
[15:08] <apw> so it is woefully inaccurate
[15:08] <apw> i may be able to use the raw coulombs to make that more accurate but, thats not how it is now
[15:10] <gema> apw: the state of charge is calculated based on charge now (which we don't have) not the other way around
[15:11] <gema> apw: I think we are wasting more time discussing than it would take to just expose that
[15:11] <gema> apw: then we can do the calculations if you want and see what's more accurate
[15:12] <apw> gema, the driver exposes percentages and raw coulombs, it uses raw coulombs and a significant amount of guess work to generate the percentage
[15:12] <apw> gema, it them makes its idea of charges internally using those percentages, at 1% resolution
[15:13] <apw> exposing those is not going to give you any accuracy (even asuming for now that the device has accuracy)
[15:13] <gema> apw: I'd like to be able to validate that empirically
[15:13] <gema> rather than argue each other to death
[15:13] <apw> gema, and i am working to expose them, and when writing the code and testing it, i can see how it is calculated
[15:14] <apw> gema, and i can see that the value i am exposing changes like every time the percentage changes, which is how i _know_ it is based on the percentage
[15:14] <apw> gema, and why am i asking if it is any use what so ever given your comment on the percentage from the GN
[15:14] <gema> apw: what percentage are you talking about?
[15:15] <gema> capacity?
[15:15] <apw> the driver as it stands is calculating its remaining_charge from its (estimate of full charge * 100) / current percentage
[15:15] <apw> its percentage charge remaining estimate.
[15:17] <apw> remaining_charge_uah = calculate_remaining_charge_uah() .... that is using:
[15:17] <apw>         return (fcc_uah * pc) / 100;
[15:17] <apw> ie, it is taking estimated full and using the percentage previously reported, and returning some other estimate in 100's of the maximum capacity
[15:17] <apw> i am trying to get you to confirm that is of little use
[15:19] <apw> and that therefore i need to try and expose something more granular
[15:19] <apw> gema, ^^
[15:26] <gema> apw: are you saying that there is a circular dependancy in the driver? (I haven't really seen enough of it to be able to pinpoint that) in any other case, I am pretty sure the value you are getting is a good start, I can run a test if you give me a kernel with it and figure out if it makes sense
[15:28] <apw> gema, i am saying the value you asked to be exposed is in 100th's of full capacity, i am asking if there is any value in that value, or do i need to work out how to make a better value
[15:28] <apw> gema, to my mind it is pretty clear it is useless as it doesn't change for 10s of seconds
[15:29] <gema> apw: can you give me some example values
[15:31] <apw> gema, the actual value would be like 2088105 and remains like that while the percentage is 91 (ish) and changes only when the reported percentage changes to 90
[15:32] <apw> gema, never mind, i am taking an executive decision that these values are too low resolution to be useful
[15:32] <apw> gema, and i am going to figure out how to get more accurate values out
[15:32] <gema> apw: ack, thanks
[19:43] <Noskcaj> balloons, about my merge proposal
[19:45] <Noskcaj> i think you should let this one in as the hardware tests are less agonistic currently and netboot has a glitch where dd was dt and vice-versa
[20:08] <balloons> Noskcaj, howdy
[20:08] <Noskcaj> hello
[20:10] <balloons> I like your changes, although I'm on the fence about the is vs should be stuff
[20:10] <balloons> but yea, there still needs to be some work done on some of them.
[20:10] <balloons> I can't merge everything as-is.. that's why we like the smaller merge proposals that are more on point..
[20:11] <Noskcaj> balloons, i did all this at school. i can't make merge proposals on the school laptop
[20:12] <balloons> Noskcaj, ahh.. well, your editing all those files right? Just make several branches
[20:12] <balloons> does that make sense?
[20:12] <balloons> make a branch, fix netboot
[20:12] <balloons> make a branch fix is vs should be
[20:13] <Noskcaj> makes sense
[20:13] <balloons> make a branch fix hw tests
[20:13] <balloons> then it's 3 mp's, but it can be reviewed easier
[20:20] <Noskcaj> balloons, i've just fixed netboot. uploaded. could you explain you issues with "should be"
[20:20] <samgabbay> Hi I have a laptop with a broken screen and i wanted to know how i can install ubuntu on it
[20:21] <samgabbay> oops
[20:21] <samgabbay> wrong room
[20:21] <Noskcaj> samgabbay, you might have to replace the screen. tht's pretty simple though
[20:22] <balloons> Noskcaj, well, I'm wondering about how it reads
[20:22] <samgabbay> Noskcaj,  but the laptop is too old for that
[20:22] <Noskcaj> samgabbay, then plug an external screen in
[20:22] <samgabbay> yea but when i do i dont know what key it is to choose what to boot and like i want to make the external monitor the default
[20:23] <Noskcaj> balloons, we need a wording that is constant, so do we want "should" or "is"?
[20:23] <samgabbay> is there a way to make like the external monitor input like the main one
[20:23] <samgabbay> just on like desktop pcs
[20:23] <Noskcaj> samgabbay, should be, once you're in ubuntu
[20:24] <Noskcaj> but it can't be too old to replace the screen
[20:24] <samgabbay> it is its like 6 years old or so
[20:24] <samgabbay> like how do i know what key to press on boot
[20:24] <samgabbay> cause on the external monitor it wont display like when you first turn it on and it  says dell for example and it shows like f1 is bios
[20:25] <elfy> Noskcaj balloons I'm not sure what you're talkign about exactly - but if it's testcases - then there shouldn't be should - it either is and a pass or it's a fail
[20:26] <Noskcaj> elfy, the wording of

[20:26] <balloons> Noskcaj, in theory you should read the test as do this, expect that. it should be written as fact.. so we don't want should, might, could, etc in there
[20:26] <Noskcaj> i have to go, i'll be back later
[20:26] <samgabbay> guys anything i can do to make the external monitor primary so i can see when it first boots and know the  boot keyu
[20:26] <balloons> however when I explained it to you, yes, the result is what should happen, else it's a back :-)
[20:26] <samgabbay> pleaaassasseee
[20:26] <samgabbay> :?
[20:26] <samgabbay> :/
[20:26] <elfy> samgabbay: you need a support channel - try #ubuntu
[20:27] <samgabbay> but like no one is responding :
[20:27] <samgabbay> :/
[20:27] <balloons> it's a non-ubuntu problem to be fair.. and laptops are laptop specific.. likely no one can help you but yourself, google, and trial and error
[20:27] <samgabbay> :/
[20:28] <balloons> i will say ubuntu has a screenreader mode that will talk to you during installation.. but again, without a screen there's no point.. and it's impossible to know what's going on
[20:28] <balloons> hello elfy !
[20:28] <elfy> hi balloons :)
[20:28]  * elfy is back for a week again :)
[20:29] <balloons> aweosme
[20:29] <balloons> can you make the hackfest tomorrow?
[20:29] <elfy> so get ready for the next installment of how do I upload this again ...
[20:30] <samgabbay> balloons,  like im gonna be using the computer with an external monitor, keyboard, and all i just wanna get it working until i get a new pone
[20:30] <elfy> balloons: eventually - got some r/l to attend to and a xubuntu meeting
[20:30] <elfy> balloons: but if it's autopilot then I'll wander off :)
[20:34] <Noskcaj> balloons, so we want it worded as "this happens" ?
[20:34] <balloons> elfy, it's for everyone.. we've just specifically invitied new folks who might want t hack on autopilot for qml
[20:34] <balloons> don't be scared ;-)
[20:34] <elfy> lol
[20:35] <elfy> so that's 2 things that I'll go pfft at then
[20:35] <Noskcaj> balloons, let me know if there's a hackfest i can attend
[20:35] <elfy> I thought qml was a downmarket sports shop chain ...
[20:37] <elfy> balloons: and of course the other thing being that 99% of anyone will be fiddlign with ubuntu things too ;)
[20:37] <balloons> Noskcaj, there is tomorrow
[20:37] <balloons> it runs through this time, so if your around as normal, you can be a part :-)
[20:37] <Noskcaj> balloons, i mean a time when i'm not sleeping
[20:37] <Noskcaj> ok, i'll try and attend
[20:38] <balloons> Noskcaj, tomorrow at this time we'll be finishing up, so you can attend :-) However, we can try something later on a weekend and see if more folks from down-under and asia can make it
[20:38] <elfy> I shall be attending my own hackfest and working away on xubuntu testcases
[20:38] <balloons> elfy, lol.. just know I'll be dedicating my time to helping whomever get testcases in
[20:38] <Noskcaj> elfy, let's have an official xubuntu test hackfest
[20:38] <balloons> all day long you'll get me
[20:39] <elfy> balloons: I know :)
[20:39] <elfy> Noskcaj: afaik there are 2 people working on xubuntu testcases
[20:39] <elfy> though I think sergio is working on gnumeric
[20:40] <Noskcaj> then mabe a hackfest is wasteful
[20:40] <Noskcaj> *maybe
[20:41] <elfy> balloons: do I remember us having a conversation about the dates on the release schedule staying as they are even though they are patently wrong?
[20:42] <balloons> elfy indeed..
[20:42] <balloons> heh
[20:42] <balloons> ping in #ubuntu-release about it
[20:42] <elfy> but cadence week dates are right?
[20:44] <elfy> balloons: ^^
[20:44] <balloons> elfy, what do you mean?
[20:44] <elfy> the dates on https://wiki.ubuntu.com/QATeam/Cadence/Saucy are right ?
[20:45] <elfy> I need to talk with xubuntu about what we're going to do and when
[20:45] <Noskcaj> balloons, you have more stuff to merge
[20:46] <balloons> elfy, yes I don't plan to change them unless we discuss first and have a reason
[20:46]  * elfy thinks it's absolutely ridiculous that release schedule is wrong because someone in the past set them up and no-on can be assed to deal with it now things have changed
[20:47] <elfy> balloons: k - just need something concrete to work with
[20:47] <balloons> elfy, there was a note and action item to change the release schedule rpoperly
[20:47] <elfy> lol
[20:48] <balloons> but again, I haven't seen any changes
[20:48] <elfy> well - if it doesn't get soon it can be marked as invalid :p
[20:48] <balloons> I have to work on getting our first week ready :-)
[20:49] <balloons> that's my concenr
[20:49] <elfy> yep
[20:49] <elfy> I understand that - that'll be your job :)
[20:50] <elfy> I don't suppose it matters much as long as we get 'week' with the same image to test
[20:51] <elfy> anyway - I should be about at some point tomorrow - now I am off
[20:53] <balloons> Noskcaj, ok, let me go look at th enew mp
[21:15] <balloons> Noskcaj, so what's this? https://code.launchpad.net/~noskcaj/ubuntu-manual-tests/xfce4panel/+merge/168858
[21:16] <Noskcaj> balloons, i re-based that, it's enough for the guy to merge into ubuntu-manual-tests
[21:16] <balloons> Noskcaj, ok
[21:16] <balloons> i'm re-merging your branch :-)
[21:19] <Noskcaj> balloons, there's more changes, tell me when you want them
[21:19] <balloons> ok on testcases/hardware/1480_USB Mouse I think the bit about creating a file is a bit silly. we can just ask them to test left, right and dragging
[21:20] <balloons> Noskcaj, you can push whatever you have :-)
[21:21]  * balloons just realized he has media keys on the top of his keyboard
[21:21] <balloons> huh..
[21:21] <Noskcaj> lol
[21:21] <balloons> Noskcaj, I'm curious about this one:
Press the Search key

[21:21] <balloons>
[21:21] <balloons> 91
[21:21] <balloons>
The tracker desktop search tool should open

[21:21] <Noskcaj> balloons, i don't know what that is, it was already there
[21:22] <balloons> right.. I wonder what "search" tool they could mean
[21:22] <balloons> there is no more tracker
[21:22] <balloons> go ahead and remove it if you would :-)
[21:22] <Noskcaj> ok
[21:22] <balloons> all the new changes look better
[21:22] <balloons> I saw up to rev 123
[21:23] <Noskcaj> 124 is uploading now
[21:24] <Noskcaj> i made the search test agnostic
[21:38] <Noskcaj> balloons, you have merges waiting
[21:39]  * balloons looks
[21:41] <balloons> Noskcaj, (might be call "monitor" or "display") to might be "called"
[21:41] <Noskcaj> i approved slickymaster's one, but it needs merging
[21:41] <balloons> all those changes look good
[21:41] <balloons> I'll merge his
[21:41] <balloons> so I think the only thing left is the is -> should be stuff right?
[21:42] <Noskcaj> balloons, that and the wireless networking test
[21:42] <balloons> excellent
[21:43] <balloons> Noskcaj, this https://code.launchpad.net/~noskcaj/ubuntu-manual-tests/xfce4panel/+merge/168858 has to be done by david
[21:43] <balloons> ohh nvm, I see it ;-)
[21:43] <Noskcaj> :)
[21:49] <Noskcaj> balloons, the last upload is going now. i think that's all the hardware tests
[21:54] <balloons> i'm looking over
[21:55] <balloons> ok, everything looks good
[21:55] <balloons> let me do a full review again Noskcaj
[21:55] <Noskcaj> ok, ty
[21:58] <balloons> Noskcaj, :-( This is still using unity stuff for no reason..
[21:58] <balloons> /home/nskaggs/projects/ubuntu-manual-tests/testcases/hardware/1477_Builtin Keyboard
[21:58] <balloons> can you make it generic?
[21:58] <Noskcaj> one sec
[21:58] <balloons> sure.. I'll just keep rambling my thoughts here
[22:02] <Noskcaj> balloons, uploaded
[22:05] <balloons> Noskcaj, another small tweak..
Insert a media card into the reader.

A suggestion window should open for the card

[22:05] <balloons> I'm not sure we can assume or need to assume a suggestion window will appear on every flabor
[22:05] <Noskcaj> ok
[22:06] <balloons> this is from 1484_Internal Data Card Reader
[22:06] <balloons> you can simplify the whole thing and just say open the card up with a file manager
[22:06] <balloons> we want to test the read and writing to the card, etc
[22:07] <balloons> in the suspend and resume, you don't need to mention using firefox specifically
[22:07] <balloons> 1486_Suspend & Resume
[22:07] <Noskcaj> ok
[22:07] <balloons>
Open a few applications in on the desktop, including Firefox

[22:07] <Noskcaj> pushing now
[22:09] <balloons> ok, the final tweaks I see
[22:09] <Noskcaj> balloons, can you explain test 1399_unity startup? it seems to have a translation part
[22:10] <balloons> 1300,1301,1302,1465,1504,ubuntu touch/1518 and ubuntu touch/1519 all should drop the 'should be' language and keep the 'is' language. The other tweaks in those files are good
[22:10] <balloons> Noskcaj, let me look at it
[22:11] <balloons> ohh right
[22:11] <balloons> that was imported from the old unity manual tests
[22:11] <Noskcaj> ok
[22:11] <balloons> essentially it's just a gut check that unity starts up and the desktop loads
[22:11] <balloons> including translations..
[22:12] <Noskcaj> I just updated it so it made sense, but i doubt it will every be looked at
[22:16]  * Noskcaj leaves for school
[23:57] <kotux> hello!


[03:23] <magn3ts> How can I get nginx to start on boot in Oeniric?
[12:48] <FernandoMiguel> good afternoon folks
[15:59] <FernandoMiguel> how is WUBI latelly ?
[15:59] <FernandoMiguel> haven't used it since it got "stable"
[16:03] <FernandoMiguel> LOL
[16:03] <FernandoMiguel> wubi tried to download a 64bits image on a 32 atom
[16:03] <FernandoMiguel> fuuu
[17:33] <FernandoMiguel> RT @eloisavaldes gnome-terminal? xD
[17:33] <FernandoMiguel> gnome?
[17:33] <FernandoMiguel> Where's the garden?
[17:33] <FernandoMiguel> lolol
[19:30] <FernandoMiguel> what's the installer package name? want to file a bug
[19:32] <jtaylor> can someone do me a favor and give me the ssl certificate fingerprint of yahoo.com?
[19:32] <yofel> FernandoMiguel: which one? Either ubiquity or debian-installer
[19:32] <jtaylor> preferable someone not in germany
[19:32] <FernandoMiguel> jtaylor: checking
[19:33] <FernandoMiguel> wth... mine is defaulting to mobile ui
[19:33] <jtaylor> mine appears to do that too
[19:33] <jtaylor> and login is unencrypted
[19:33] <jtaylor> unless one manually changes to ssl
[19:34] <FernandoMiguel> jtaylor: 0F:58:49:41:52:C3:35:4B:6D:EB:E7:20:9E:72:6E:67
[19:34] <FernandoMiguel> login.yahoo
[19:34] <FernandoMiguel> from digicert
[19:35] <jtaylor> thats the serial number
[19:37] <jtaylor> but it appears to be fine, I was just confused by the unencrypted different login, don't use yahoo that often so I don't ahve their cert saved :/
[19:37] <jtaylor> better save than sorry
[19:39] <FernandoMiguel> sure
[19:40] <FernandoMiguel> is ubuntu keyserver working for you guys???
[19:40] <FernandoMiguel> timeout here
[19:41] <FernandoMiguel> bbl
[19:41] <jtaylor> works here
[22:11] <FernandoMiguel> jtaylor: about to install keepass from your ppa
[22:11] <FernandoMiguel> you better be a "good" guy
[22:15] <FernandoMiguel> jtaylor: you need to update that pocket.... to 11.10 and 12.04 :)


[09:50] <seb128> goood morning IRC
[12:31] <lissyx> hello
[12:31] <lissyx> is there a way to completely deny gdm3 to start on Xorg?
[12:36] <seb128> lissyx, what do you mean? you want it to error out if wayland is not working instead of falling back to X?
[12:36] <lissyx> yes
[12:37] <seb128> not that I know of, that seems like a weird feature
[12:37] <seb128> 'please don't try to work'
[12:37] <lissyx> I've noticed a gdm3 restart might restart as xorg instead of wayland
[12:37] <lissyx> seb128, we're working on adding wayland (better) CI
[12:37] <seb128> that would be a bug to fix
[12:37] <lissyx> xorg fallback already tricked us several times
[12:38] <lissyx> I dont have time to fix that, and I dont even know if it's fixable
[12:38] <seb128> I guess you could check at the start of the CI if you are under wayland or xorg and error out if that's the latter?
[12:38] <seb128> also is that about gdm or the user session?
[12:38] <lissyx> we could, but it's really inconvenient to have to perform another check
[12:38] <lissyx> well if gdm starts as xorg, it will autologin as xorg
[12:39] <seb128> it shouldn't
[12:39] <lissyx> this is what I saw
[12:40] <seb128> that's weird, afaik we had (still have?) gdm always use xorg so it would work on more config and then users could pick up an xorg session as fallback on the greeter if wayland isn't working
[12:45] <lissyx> if i WaylandEnable=true it might not auto fallback ?
[12:45] <lissyx> at least I can't repro anymore
[14:37] <jbicha> yes, it's possible for gdm3 to start in a mode where it won't offer the GNOME on Wayland session. I experienced this with the multi-monitor issues with GNOME Shell 45 Beta
[14:39] <jbicha> I don't think it's easily possible to avoid that behavior. Red Hat is working on making an option to build GNOME without Xorg sessions, perhaps for GNOME 46
[14:40] <jbicha> but Ubuntu 24.04 LTS will definitely include both Xorg and Wayland sessions by default


[02:05] <jderose> pull request for lp:1394348 - https://github.com/tseliot/nvidia-graphics-drivers/pull/7


[00:34] <poolie> hi spiv?
[00:37] <spiv> Hi poolie
[00:37] <poolie> hey
[00:37] <poolie> i was just going to check you were still ok to pilot
[00:37] <poolie> and to see if you wanted reviews or anything
[00:38] <poolie> i was going to work on launchpad flags and dkim but i could do that first if you want
[00:39] <spiv> The queue looks fairly short... although there are a couple of patches from me in it.
[00:40] <spiv> Perhaps take a look at https://code.launchpad.net/~spiv/bzr/fetch-spec-everything-not-in-other/+merge/42811 ?  It's a prereq for the other two mps from me, although it is a pretty large diff.
[00:41] <spiv> Oh, although I see jam looked at a the previous iteration of it, so perhaps I should just ask him.
[04:48] <exarkun> Are there tools for looking directly at a repository's contents?
[04:50] <exarkun> or, which python api should I be looking at? :)
[04:52] <exarkun> like say I wanted to enumerate all of the leaf revision ids in a shared repository, can I do that?
[04:53] <spiv> exarkun: just a sec
[04:54] <exarkun> (I think I deleted a branch that had some stuff in it that I want, and my assumption is that I didn't completely destroy the data since it was a branch in a shared repository...)
[04:57] <spiv> exarkun: API-wise it's something like python -c "from bzrlib.repository import Repository; repo = Repository.open('code/testtools'); repo.lock_read(); g = repo.get_graph(); print g.heads(repo.revisions.keys())"
[04:58] <spiv> exarkun: but now that I see you don't really care about the API, try "bzr heads" or "bzr heads --all", from the bzrtools plugin
[04:58] <exarkun> Oh cool.  Thankee.
[05:01] <exarkun> yay recovered
[05:32]  * spiv sighs and restarts his gnome-terminal process, which has run out of fds.  Someone really needs to add that fix to maverick-updates...
[06:01] <spiv> poolie: any thoughts on the UI change proposed in https://code.launchpad.net/~jelmer/bzr/diff-git/+merge/44185 ?  (allow "bzr diff --git" rather than requiring "bzr diff --format=git")
[07:24] <vila> hi all !
[07:29] <poolie> hi spiv
[07:33] <poolie> hi vila
[07:33] <vila> poolie: hey there !
[07:38] <poolie> spiv, i answered
[07:40] <poolie> spiv: are you still here?
[08:42] <vila> Funny trick with the new 'bzr config' command: when I do a review locally, I generally create a branch whose parent is lp:bzr
[08:42] <vila> so when people update their branch I have to type again the url to get updates
[08:42] <poolie> right
[08:42] <vila> well, I had.
[08:42] <vila> Now I do: bzr config reviewed=lp:<review_url>
[08:43] <vila> and 'bzr pull -v `bzr config reviewed`
[08:43] <vila> or 'bzr diff --old `bzr config reviewed`'
[08:43] <vila> no more need to defined specific directory aliases like submit: , parent: and all, and it's supported by all bzr commands :)
[08:47] <poolie> hm
[08:47] <poolie> only on unix though
[08:47] <poolie> that's a nice reason to have config emit only the url
[08:50] <vila> yup, I'm so totally convinced now :)
[08:56] <poolie> :)
[08:56] <poolie> on windows we could do something like bzr pull config:reviewed
[08:59] <poolie> vila, we should probably defer b5 until during/after the sprint
[08:59] <poolie> do you want to hack on it there?
[08:59] <poolie> or switch to tarmac there?
[09:00] <vila> yeah, I think that would be the best, having everyone involved and aware of all the issues and debugging all nits
[09:01] <vila> yeah, definitely for 2.3b5 *and* tarmac, I'll update the release date
[09:02] <vila> .. and discuss how we reach 2.3.0 final
[09:03] <poolie> well, we'll need to schedule it with the sysadmins too
[09:04] <vila> yeah, but we can play with it on a scratch branch and ask the sysadmins to switch with a working setup
[09:04] <vila> (unless I miss something on how tarmac is supposed to work)
[09:05] <vila> but yeah, we can tell them we *will* switch around 2012-01-13 (I've update the 2.3b5 date on lp)
[09:51] <zyga> anyone here knows how to use bazaar.conf and lp-propose-merge to get an implicit push location
[10:06] <vila> zyga: Most of the time I do: bzr push lp:~vila/bzr/`bzr nick`
[10:07] <vila> zyga: the only way to go further today is to use locations.conf but it will take precedence over anything defined in branch.conf which is certainly not what you want
[10:07] <vila> zyga: there is a work in progress to allow path-based default values to be defined in bazaar.conf though
[10:09] <zyga> vila, I want to "bzr push"
[10:09] <zyga> vila, salgado gave me bazaar.conf that doesn't work that works for him
[10:09] <zyga> http://paste.ubuntu.com/544906/
[10:09] <zyga> vila, could it be possible that salgado is riding bzr.dev wave?
[10:10] <zyga> vila, my real problem is on usability of lp-propose-merge
[10:10] <zyga> it takes bzr push + bzr lp-propose-merge while I just wanted to lp-propose-merge
[10:10] <zyga> (and push also is verbose as you explained, you need to specify the push branch which is tedious)
[10:11] <vila> zyga: sections defined in bazaar.conf are just ignored
[10:11] <zyga> hmm
[10:11] <vila> zyga: unless salgado has written a plugin... which I doubt
[10:11] <zyga> vila, that's what salgado is using, I need to check with him again
[10:11] <vila> zyga: may he uses locations.conf instea
[10:11] <zyga> hmm? should I put that in locations conf and see if it worsk?
[10:12] <zyga> I'm on 2.2.1
[10:12] <vila> zyga: but the aim of locations.conf is to *override* branch.conf (so whatever is defined in branch.conf is ignored if a matching is found in locations.conf)
[10:13] <vila> zyga: it will work even for 2.0 I think (95% sure)
[10:13] <zyga> that's okay, I just want to stop having to type everything twice all the time
[10:13] <zyga> (something is happening)
[10:13] <zyga> yayt
[10:13] <zyga> it worked
[10:13] <zyga> bzr lp-propose-merge
[10:13] <zyga> no push needed :D
[10:13] <zyga> thanks :-)
[10:13] <zyga> hmm
[10:13] <zyga> (premature happines)
[10:13] <vila> zyga: you need to type it once, once it's defined in branch.conf it will be used (--remember can change it)
[10:14] <zyga> vila, I keep making branches
[10:14] <vila> zyga: type it once unless you define a default in locations.conf I mean
[10:14] <zyga> I have ~10 branches a day
[10:14] <zyga> http://pastebin.ubuntu.com/545877/
[10:14] <zyga> what does that message mean?
[10:15] <zyga> this is my locations.conf
[10:15] <zyga> http://pastebin.ubuntu.com/545878/
[10:15] <vila> hmm, it may come either from launch-control not being a project defined on launchpad or some weirdness in the stacked-on branches defined on lp (and dev focus too)
[10:16] <zyga> hmm
[10:16] <zyga> launchpad.net/launch-control exists
[10:16] <vila> ok
[10:16] <mok0> Does anyone here have experience maintaining a gnu autotools dependent project in bzr?
[10:16] <vila> may be a missing trailing '/' ?
[10:17] <zyga> let's see
[10:17] <vila> zyga: if you use bzr trunk, 'bzr config' will display the expanded values that apply in the current dir
[10:17] <zyga> vila, I don't use trunk, sorry :/
[10:17] <vila> np np
[10:18] <zyga> vila, is there any difference between lp:~something and the bzr+ssh://longish version?
[10:18] <mok0> I'd like to know what your opinion on the autogenerated files is: do you store them in the repo?
[10:18] <zyga> can I just use the lp: shorthand?
[10:19] <vila> mok0: strictly speaking versioning generated files is... akward, but it may help when creating tarballs, but generally you don't mix the too, you version only files that a re modified by humans
[10:19] <vila> zyga: yes you can
[10:19] <zyga> I hacked the locations conf a bit and bzr info in the branch I'm working on now says: http://pastebin.ubuntu.com/545881/
[10:19] <zyga> it looks good IMHO
[10:19] <zyga> btw, what is submit branch?
[10:19] <mok0> vila: that's exactly the problem I have: "make dist" seems to work at cross purposes of bzr
[10:19] <zyga> I never figured that part out
[10:20] <vila> zyga: the difference is that the lp: shorcuts can be expanded into their http: variant under some circumstances
[10:20] <zyga> vila, yeah I know, if lp-login is not used
[10:20] <vila> zyga: submit_branch is the branch your merge from or against, a bit confusing
[10:21] <vila> mok0: only if you version generated files
[10:21] <zyga> "merge from" ?
[10:21] <zyga> vila, can you give me an example of what command uses that submit_branch?
[10:21] <vila> zyga: when you work on a feature branch and you want to update from trunk (merge new changes)
[10:21] <vila> zyga: merge
[10:21] <vila> zyga: send
[10:22] <vila> zyga: lp-propose :)
[10:22] <zyga> hmm
[10:22] <mok0> vila: well, I don't like to store configure, aclocal.m4 and friends, but that means I need to generate configure, and that fails unless you have all the dependencies installed.
[10:22] <vila> mok0: exactly
[10:22] <zyga> vila, so bzr push worked for me
[10:22] <mok0> Which is aPITA
[10:22] <vila> zyga: don't forget the :policy=append_path bit
[10:22] <zyga> vila, but lp-propose-merge again said that "bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/launch-control/ is not registered on Launchpad"
[10:23] <mok0> OTOH, storing configure and friends in the repo is a PITA because they keep changing and it pollutes your history
[10:23] <vila> mok0: it's more a work flow issue than a VCS issue per se, but depending on the project they often overlap
[10:23] <mok0> vila: yeah... I was just wandering if anyone had a smart solution
[10:23] <vila> mok0: the question is how you distribute your sources and how you want people to contribute to the project
[10:24] <mok0> vila: I'm not upstream, only trying to maintain a deb package
[10:24] <mok0> vila: and I _need_ to patch configure.ac
[10:24] <vila> mok0: either you version only non-generated files and requires devs to have the generating tools installed or you version the generated files but should ensure you're in sync at commit time
[10:24] <vila> oh, packaging... that's  different :)
[10:25] <vila> mok0: In this case you have the additional issue that upstream may be versioning generated files
[10:25] <mok0> vila: yes, because you do build work etc. in the directory
[10:25] <zyga> vila, okay, one step closer, I removed merge_target and submit_branch from locations.conf, now lp-propose-merge wants to have a reviewer, can I make it use the default reviewer for lp:launch-control somehow?
[10:25] <vila> zyga: search for the stacked-on branch and check that the dev focus is correct too
[10:26] <vila> zyga: isn't it the default ???
[10:26] <zyga> hmm
[10:26] <vila> zyga: -R reviewer ?
[10:26] <zyga> vila, I don't understand either part
[10:27] <vila> zyga: (from 'bzr help lp-propose' I rarely use this command myself)
[10:27] <zyga> vila, I could use that but lp already knows who is the reviewer
[10:27] <vila> zyga: EPARSE
[10:27] <zyga> so I want to avoid having to type that, It must be a configuration issue somewhere
[10:27] <zyga> note: https://code.launchpad.net/~linaro-infrastructure/launch-control/trunk this is the branch I want to submit to this is the development target
[10:27] <vila> zyga: yeah probably
[10:28] <zyga> vila, if I do lp-propose-merge lp:launch-control
[10:28] <zyga> it says: $ bzr lp-propose-merge lp:launch-control
[10:28] <zyga> bzr: ERROR: bzr+ssh://bazaar.launchpad.net/%2Bbranch/launch-control/ is not registered on Launchpad
[10:28] <zyga> did I make a typo I cannot see or is there something wrong here?
[10:29] <vila> zyga: weird, I can 'bzr info' it but not 'bzr config' it :-/
[10:29] <zyga> vila, hmm?
[10:31] <zyga> bzr bug somewhere?
[10:31] <vila> zyga: for bzr config, probably
[10:31] <zyga> vila, how about lp-propose-merge, why does it say that launch-control is not registered?
[10:32] <zyga> do I need to spell out the actual location of the branch: lp:~linaro-infrastructure/launch-control/trunk
[10:32] <vila> zyga: you could try that yes
[10:33] <zyga> that worked but said that no reviewer is specified
[10:33] <zyga> sigh
[10:33] <zyga> how did salgado make this work without passing all those arguments
[10:33] <vila> sounds like a launchpad config issue then
[10:34] <vila> zyga: check with salgado, either he has a different config or you're not part of the same teams ?
[10:34] <zyga> is the maintainer the default reviwer?
[10:34] <zyga> we are both part of the ~linaro-infrastructure team
[10:34] <vila> but who review the proposals ?
[10:34] <zyga> that team
[10:34] <vila> is it properly configured on lp ?
[10:34] <vila> 'it' being vague :)
[10:35] <zyga> vila, good question, how can I check that
[10:35] <zyga> https://launchpad.net/launch-control
[10:35] <zyga> maitainer is set
[10:35] <vila> but not driver ?
[10:35] <zyga> no, driver is not set
[10:35]  * zyga never understood what that really meant
[10:35]  * vila neither :)
[10:36] <zyga> I set the driver too
[10:36] <zyga> let's see if lp-propose-merge will work now
[10:36] <zyga> nope
[10:37] <zyga> I just want this whole review thing to get out of my way ;-)
[10:37] <vila> zyga: hmm, I think that's something that should be specified on the target branch or something
[10:37] <zyga> vila, thanks for all the help
[10:37] <zyga> target branch being?
[10:37] <zyga> trunk?
[10:37]  * vila looks at the bzr lp project
[10:38] <vila> zyga: there is a review team for lp:bzr
[10:38] <zyga> bzr info does not say
[10:38] <vila> zyga: it's a launchpad thing
[10:38] <vila> zyga: look at https://code.launchpad.net/~bzr-pqm/bzr/bzr.dev
[10:39] <vila> there is a review team there, but nothing comparable on launch-control (may be because I'm not part of the team there, can't say for sure)
[10:41] <mok0> Is there a special channel for discussing packaging in bzr?
[10:41] <mok0> Or is that here :-P
[10:41] <vila> mok0: here is fine
[10:41] <mok0> vila, thanks
[10:42] <vila> mok0: #ubuntu-devel may be better if you're targeting Ubuntu (or even debian)
[10:42] <mok0> So now I am wondering, should I just make all changes in the autobuild system that I need on my bzr branch
[10:42] <mok0> ... and somehow create my package from that
[10:42] <vila> mok0: you're *creating* a package ?
[10:42] <mok0> vila: ytes
[10:42] <mok0> yes
[10:43] <mok0> Upstream doesn't provide a recent tarball, source is distributed via svn
[10:43] <vila> mok0: hmm, I'll be on limited help then, I don't have a significant experience here
[10:43] <mok0> I have it mirrored in an LP project
[10:43] <vila> good
[10:43] <mok0> Then I have a branch off that called "ubuntu" :-)
[10:43] <vila> mok0: you're targeting Ubuntu ?
[10:43] <mok0> vila: for now, yes
[10:44] <vila> mok0: did you look at bzr-builddeb ?
[10:44] <mok0> vila: I've used it now and then, but I found it got in my way
[10:44] <vila> mok0: you should definitely ask in #ubuntu-devel and file bugs when it gets in your way !
[10:44] <mok0> I wasted hours until I discovered that it stashes away its own copy of the tarball in the buildarea
[10:45] <mok0> I couldn't understand WFT was going on
[10:45] <vila> mok0: I don't know the details but there are several possible workflows, with a bit luck you're just not using the right one
[10:45] <mok0> vila: perhaps yes
[10:46] <mok0> vila: and then there's quilt..........
[10:46] <zyga> vila, checking
[10:46] <vila> mok0: james_w wrote a very succint document about that, but I don't remember if/where it's published
[10:46] <zyga> vila, sorry, my son is ill and needed some help
[10:46] <vila> zyga: that's a *priority* interrupt
[10:46] <mok0> vila, lemme see if mr. Google will come to my help :-)
[10:48] <zyga> vila, the review team _is_ set
[10:48] <zyga> https://code.launchpad.net/~linaro-infrastructure/launch-control/trunk/+reviewer
[10:48] <zyga> I can see linaro-infrastructure as the reviewer
[10:48] <vila> zyga: no permission to look at that
[10:49] <zyga> vila, right but it's set there
[10:49] <mok0> vila, would you be referring to this? https://wiki.linaro.org/BzrIntroduction
[10:49] <zyga> I think lp might not show the reviewer if it's the same as owner
[10:49] <vila> zyga: :-/ I'm out of my league then
[10:49] <vila> mok0: no, it was one with pretty pictures :)
[10:50] <vila> mok0: but james_w is mentioned so you're on the right track ;)
[10:51] <mok0> vila, hehe. I found this now, it looks like I need to read that: http://jameswestby.net/bzr/builddeb/user_manual/
[10:52] <mok0> No pretty pictures though
[10:52] <vila> mok0: certainly a must read :)
[10:54] <vila> mok0: may be https://wiki.ubuntu.com/UbuntuDevelopment/ is a good starting point too
[10:55] <mok0> vila: Indeed... thought it mostly looks like a link-collection
[10:55] <vila> mok0: could be, but #ubuntu-devel can better answer than me for that
[10:56] <mok0> vila: you've been most helpful, thanks
[10:56] <vila> mok0: np, happy to help but I know bzr better than packaging (I'm learning though ;)
[10:57] <mok0> vila: I think  dvcs packaging is very much in its infancy
[10:57] <vila> mok0: yup, actively working on though ;)
[10:58] <mok0> vila: AFAIK you still need a tarball
[10:58] <mok0> vila: which is kinda crazy if the source can be pulled from a branch and you can construct the debian/ from the packaging branch
[10:58] <vila> mok0: that's the part I'm unsure about (since I always start with a bzr branch myself)
[10:59] <vila> mok0: that's what 'pristine tar' is about: re-create tarballs from a branch
[10:59] <mok0> vila: then that's a new definition... it used to be "the tarball you download from upstream"
[11:00] <mok0> vila: anyway, I don't see there's a need for tarballs
[11:00] <vila> mok0: but for many operations builddeb re-creates the tarball from the branch
[11:00] <mok0> vila: I know... as I wrote above, I was burned by that
[11:00] <vila> so instead of downloading it from upstream you just use the equivalent version
[11:01] <mok0> vila: because when you edit edit edit in the branch, the old tarball is still sitting there :-(
[11:01] <vila> mok0: which is why I think you may not be using builddeb as intended
[11:01] <mok0> vila: and so it seems your edits are gone
[11:01] <mok0> vila: perhaps you are right
[11:02] <vila> mok0: because you seem to be doing 'normal' things, so builddeb should know how to deal with them
[11:02] <mok0> vila: which is why I'd like to see a description of a proper workflow
[11:02] <mok0> vila: I agree
[11:02] <vila> mok0: have you read the user manual you pointed above ?
[11:03] <mok0> vila: not yet ... I'm not THAT fast :-)
[11:04] <vila> mok0: hehe, just checking, but I'm 60% sure you'll find many answers there
[11:04] <mok0> vila: I am sure I kan learn a lot
[11:04] <mok0> s/kan/can
[13:52] <johnf> I'm running bzr annotate filename and I'm getting something like "bzr: ERROR: The file id "file-20060906040903-s4f1zy3gz43haztt-3" is not present in the tree" any ideas as to what the problem could be?
[13:58] <jelmer> hi johnf
[13:58] <johnf> jelmer: howdy
[13:58] <jelmer> johnf: I thought you were based in .au ?
[13:58] <jelmer> johnf: In what context?
[13:58] <johnf> jelmer: I usually am. In Germany for the holidays
[13:59] <johnf> jelmer: Let me pastie the whole thing
[13:59] <jelmer> johnf: Ah, nice. Enjoying the snow ? :-)
[14:00] <johnf> jelmer: Yes :) I've never really experienced snow before. This is totally surreal!
[14:01] <johnf> jelmer: sent you the pastie privately since it has some email addresses etc I'd rather not make public :)
[14:01] <jelmer> johnf: np
[14:02] <jelmer> johnf: what's the status of that file in the current working tree?
[14:03] <johnf> jelmer: Hmm OK maybe I'm doing something dumb
[14:04] <johnf> I have a branch which is currently up to rev130 and I've done this "bzr up -r 20; bzr annotate file"
[14:04] <johnf> that is when I get the error
[14:04] <johnf> if instead I do "bzr branch -r 120 orig  copy; cd copy; bzr annotate file" it works fine
[14:05] <johnf> should the first approach work?
[14:05]  * jelmer wonders what "bzr up -r" does exactly
[14:07] <johnf> jelmer: yeah I think that't the problem. It makes the working tree the same as rev 20. But I think when I run say the annotate command it is still working on revision 130 where the file no longer exists
[14:22] <jelmer> johnf: does "bzr status" report a lot of changes?
[14:22] <jelmer> johnf: You might want to try "bzr annotate -r -1 <filename>" or "bzr annotate -r 120 <filename>"
[14:23] <johnf> jelmer: bzr status says "working tree is out of date, run 'bzr update'"
[14:23] <jelmer> johnf: ah, so "bzr up" only changes the working tree, not the branch
[14:24] <johnf> jelmer: yeah. Adding -r to annotate worked fine
[14:32] <ThiasG> Hello, thank you for making bazaar available. We switched recently from git to bazaar.
[14:32] <ThiasG> Now a coworker hat done a bzr rmbranch bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/trunk
[14:32] <ThiasG> Is there an easy way to undo this change?
[14:35] <jelmer> ThiasG: hi
[14:35] <jelmer> ThiasG: You should be able to run "bzr heads --dead" to find the previous tip revision
[14:37] <jelmer> after that you should be able to create that branch again and then update it to that revision using "bzr pull -rrevid:<revid> ."
[14:38] <ThiasG> I found the revid.
[14:39] <ThiasG> The branch I just create with bzr init bzr+ssh://bazaar@bzr.openpetra.org:2208/openpetra/trunk ?
[14:41] <jelmer> ThiasG: yep
[14:41] <jelmer> ThiasG: if you don't have local access you'll need a somewhat more complicated pull command
[14:41] <jelmer> ThiasG: rather than using "." you should probably specify the same branch URL, once for the target (with -d) and once as source
[14:42] <ThiasG> I have local access to the shared repo.
[14:42] <ThiasG> In the trunk dir, I typed in bzr pull<EMAIL_ADDRESS>[14:43] <jelmer> ThiasG: you'll probably need the "." after that as well, unless the default pull location has that revision
[14:43] <ThiasG> But this gave me "bzr: ERROR: No pull location known or specified."
[14:43] <ThiasG> okoay
[14:43] <ThiasG> Now he is working
[14:44] <ThiasG> All changes applied successfully.
[14:44] <ThiasG> Now on revision 1035.
[14:44] <ThiasG> I'm finished?
[14:44] <jelmer> should be, yeah
[14:45] <ThiasG> Is it correct, that I could remove the content of the trunk directory except the .bzr directory? It is the shared remote repo.
[14:46] <jelmer> ThiasG: yes; "bzr rmtree" should do that for you
[14:47] <ThiasG> I dod a bzr status, which gave me 8 modified files.
[14:48] <jelmer> if there are modified files you should probably check why they are modified, just in case they're changes you'd like to keep..
[14:49] <ThiasG> Okay, thank you very much for your help.
[14:50] <ThiasG> Does someone already have a hook for restricting removing of branches? Otherwise I have to write one ;-)
[14:56] <jelmer> I don't think there is anything like that at the moment
[14:58] <ThiasG> Aber dann ist es nicht so tragisch. Ich checke sie ein, oder?
[14:58] <Tak> ja, selvfølgelig!
[14:59] <ThiasG> Sorry, wrong channel...
[15:05] <ThiasG> Just for completeness: The command for removing the working tree is "bzr remove-tree"
[15:06] <ThiasG> Thank you for your fast help :-)
[17:26] <mhall119> hi, I'm using bzrlib to do the equivilent of "bzr branch $src $dst"
[17:27] <mhall119> given a remove url for $srf
[17:27] <mhall119> and a local file path for $dst
[17:27] <mhall119> I have:
[17:27] <mhall119> src_branch.create_clone_on_transport(get_transport(destination), revision_id=rev_id)
[17:27] <mhall119> but that doesn't give me a working tree in $destination
[17:27] <mhall119> what am I doing wrong?
[17:31] <jelmer> mhall119: that's correct, branch.create_clone_on_transport() only creates a branch (and copies revisions where necessary)
[17:32] <jelmer> you can create a tree later by calling bzrdir.create_workingtree()
[17:46] <mhall119> that did the trick, thanks a bunch
[17:46] <jelmer> np
[21:15] <lifeless> mgz: hi
[21:31] <mgz> hey lifeless.
[23:31] <mkanat> spiv: Thanks for acknowledging and helping clarify that bug.
[23:43] <spiv> mkanat: you're welcome :)
[23:43] <mkanat> :-)


[00:11] -queuebot:#ubuntu-release- New binary: wireshark [i386] (cosmic-proposed/universe) [2.6.1-1] (no packageset)
[00:32] -queuebot:#ubuntu-release- New binary: wireshark [armhf] (cosmic-proposed/universe) [2.6.1-1] (no packageset)
[00:33] -queuebot:#ubuntu-release- New binary: wireshark [arm64] (cosmic-proposed/universe) [2.6.1-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: libmath-gsl-perl [s390x] (cosmic-proposed/universe) [0.39-2] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: libmath-gsl-perl [amd64] (cosmic-proposed/universe) [0.39-2] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: libmath-gsl-perl [ppc64el] (cosmic-proposed/universe) [0.39-2] (no packageset)
[05:21] -queuebot:#ubuntu-release- New binary: libmath-gsl-perl [i386] (cosmic-proposed/universe) [0.39-2] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: libmath-gsl-perl [arm64] (cosmic-proposed/universe) [0.39-2] (no packageset)
[05:27] -queuebot:#ubuntu-release- New binary: libmath-gsl-perl [armhf] (cosmic-proposed/universe) [0.39-2] (no packageset)
[06:36] -queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [amd64] (cosmic-proposed) [0.39-2]
[06:36] -queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [armhf] (cosmic-proposed) [0.39-2]
[06:36] -queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [ppc64el] (cosmic-proposed) [0.39-2]
[06:36] -queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [arm64] (cosmic-proposed) [0.39-2]
[06:36] -queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [s390x] (cosmic-proposed) [0.39-2]
[06:36] -queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [i386] (cosmic-proposed) [0.39-2]
[06:37] -queuebot:#ubuntu-release- New: accepted wireshark [amd64] (cosmic-proposed) [2.6.1-1]
[06:37] -queuebot:#ubuntu-release- New: accepted wireshark [armhf] (cosmic-proposed) [2.6.1-1]
[06:37] -queuebot:#ubuntu-release- New: accepted wireshark [ppc64el] (cosmic-proposed) [2.6.1-1]
[06:37] -queuebot:#ubuntu-release- New: accepted wireshark [arm64] (cosmic-proposed) [2.6.1-1]
[06:37] -queuebot:#ubuntu-release- New: accepted wireshark [s390x] (cosmic-proposed) [2.6.1-1]
[06:37] -queuebot:#ubuntu-release- New: accepted wireshark [i386] (cosmic-proposed) [2.6.1-1]
[06:37] -queuebot:#ubuntu-release- New: accepted opencascade [amd64] (cosmic-proposed) [7.3.0+dfsg1-3]
[06:37] -queuebot:#ubuntu-release- New: accepted opencascade [armhf] (cosmic-proposed) [7.3.0+dfsg1-3]
[06:37] -queuebot:#ubuntu-release- New: accepted opencascade [ppc64el] (cosmic-proposed) [7.3.0+dfsg1-3]
[06:37] -queuebot:#ubuntu-release- New: accepted opencascade [arm64] (cosmic-proposed) [7.3.0+dfsg1-3]
[06:37] -queuebot:#ubuntu-release- New: accepted opencascade [s390x] (cosmic-proposed) [7.3.0+dfsg1-3]
[06:37] -queuebot:#ubuntu-release- New: accepted opencascade [i386] (cosmic-proposed) [7.3.0+dfsg1-3]
[06:38] -queuebot:#ubuntu-release- New: accepted libtorrent [amd64] (cosmic-proposed) [0.13.7-1]
[06:38] -queuebot:#ubuntu-release- New: accepted libtorrent [armhf] (cosmic-proposed) [0.13.7-1]
[06:38] -queuebot:#ubuntu-release- New: accepted libtorrent [ppc64el] (cosmic-proposed) [0.13.7-1]
[06:38] -queuebot:#ubuntu-release- New: accepted xmlsec1 [amd64] (cosmic-proposed) [1.2.26-3]
[06:38] -queuebot:#ubuntu-release- New: accepted libtorrent [arm64] (cosmic-proposed) [0.13.7-1]
[06:38] -queuebot:#ubuntu-release- New: accepted libtorrent [s390x] (cosmic-proposed) [0.13.7-1]
[06:38] -queuebot:#ubuntu-release- New: accepted libtorrent [i386] (cosmic-proposed) [0.13.7-1]
[06:38] -queuebot:#ubuntu-release- New: accepted ros-common-msgs [amd64] (cosmic-proposed) [1.12.6-3]
[06:39] -queuebot:#ubuntu-release- New: accepted libskk [amd64] (cosmic-proposed) [1.0.3-1]
[06:39] -queuebot:#ubuntu-release- New: accepted libskk [armhf] (cosmic-proposed) [1.0.3-1]
[06:39] -queuebot:#ubuntu-release- New: accepted libskk [ppc64el] (cosmic-proposed) [1.0.3-1]
[06:39] -queuebot:#ubuntu-release- New: accepted libskk [arm64] (cosmic-proposed) [1.0.3-1]
[06:39] -queuebot:#ubuntu-release- New: accepted libskk [s390x] (cosmic-proposed) [1.0.3-1]
[06:39] -queuebot:#ubuntu-release- New: accepted libskk [i386] (cosmic-proposed) [1.0.3-1]
[07:48] <sil2100> eh, daily cosmic image failed to build
[07:52] <Laney> it SURE did!
[07:52]  * sil2100 was looking forward to it
[07:52] <jibel> sil2100, https://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[07:53] <jibel> sil2100, also bug 1779068
[07:53] <sil2100> jibel: yeah, that one's fixed now
[07:53] <sil2100> jibel: that's why I was looking forward to the new image
[07:53] <jibel> it's with ubuntu10 which should keep grub-pc-bin
[07:54] <sil2100> jibel: yeah, but it was not enough
[07:54] <sil2100> jibel: ubuntu11 is needed
[07:54] <jibel> k
[07:54] <Laney> Please to fix those perl component-mismatches
[07:54] <Laney> There's some "rule" where they don't need MIRs
[07:55] <Laney> (don't ask me for a reference)
[07:55] <sil2100> I guess would be nice for someone from the MIR team to take a look
[07:56] <sil2100> doko: ^
[07:57] <Laney> not needed, but as you wish
[07:59] <sil2100> I don't know the rules for this so if there's anyone else that knows those and can promote them, sure!
[08:08] <doko> hmm, somebody demoted those three days ago, not sure why ...
[08:08] <doko> promoted again
[08:12] <sil2100> doko: thanks!
[08:12]  * sil2100 will kick a new cosmic build in a bit
[08:25] -queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [170-1~ubuntu18.04.1 => 171-1~ubuntu18.04.1] (no packageset)
[08:36] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [171-1~ubuntu18.04.1]
[08:39] -queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [170-1~ubuntu16.04.1 => 171-1~ubuntu16.04.1] (no packageset)
[08:44] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [171-1~ubuntu16.04.1]
[10:55] -queuebot:#ubuntu-release- Unapproved: ebtables (xenial-proposed/main) [<IP_ADDRESS>-3.4ubuntu<IP_ADDRESS> => <IP_ADDRESS>-3.4ubuntu<IP_ADDRESS>] (ubuntu-server)
[11:17] -queuebot:#ubuntu-release- New: accepted veusz [amd64] (cosmic-proposed) [3.0-1]
[11:17] -queuebot:#ubuntu-release- New: accepted veusz [s390x] (cosmic-proposed) [3.0-1]
[11:17] -queuebot:#ubuntu-release- New: accepted veusz [i386] (cosmic-proposed) [3.0-1]
[14:17] <LocutusOfBorg> jamespage, I'm going to fix python-taskflow to work with python-networkx 2.0
[14:17] <LocutusOfBorg> there is a patch upstream...
[14:17] -queuebot:#ubuntu-release- Unapproved: ebtables (artful-proposed/main) [<IP_ADDRESS>-3.5ubuntu<IP_ADDRESS> => <IP_ADDRESS>-3.5ubuntu<IP_ADDRESS>] (edubuntu, ubuntu-server)
[14:42] -queuebot:#ubuntu-release- Unapproved: accepted python3-defaults [source] (bionic-proposed) [3.6.5-3ubuntu1]
[14:59] -queuebot:#ubuntu-release- Unapproved: accepted python3-defaults [source] (artful-proposed) [3.6.3-0ubuntu3]
[15:20] -queuebot:#ubuntu-release- Unapproved: partman-auto (bionic-proposed/main) [134ubuntu8 => 134ubuntu8.1] (core)
[15:20] -queuebot:#ubuntu-release- Unapproved: partman-efi (bionic-proposed/main) [71ubuntu2 => 71ubuntu2.1] (core)
[15:22] -queuebot:#ubuntu-release- Unapproved: grub-installer (bionic-proposed/main) [1.128ubuntu8 => 1.128ubuntu<IP_ADDRESS>] (core)
[15:22] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8 => 2.02-2ubuntu8.1] (core)
[15:22] -queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93 => 1.93.1] (core)
[15:22] -queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [<IP_ADDRESS> => <IP_ADDRESS>] (core)
[15:38] -queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (bionic-proposed) [<IP_ADDRESS>-3.5ubuntu<IP_ADDRESS>]
[15:39] <blackboxsw> sil2100: or bdmurray we've had a cloud-init SRU queued for a while that hasn't progressed to pending it's targeted to Xenial, Artful, Bionic.
[15:39] <blackboxsw> it's affiliated with the following SRU bug https://bugs.launchpad.net/bugs/1777912
[15:40] <blackboxsw> if there is time it'd be great to queue that
[15:40] <blackboxsw> or rather, get it into proposed so I can start validation work
[15:44] -queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (artful-proposed) [<IP_ADDRESS>-3.5ubuntu<IP_ADDRESS>]
[15:45] <sil2100> blackboxsw: I guess that would have to be bdmurray, since I'm too tired now so I'll be probably EODing soon
[15:45] <blackboxsw> sil2100: +1 yeah I figured looking at timestamps of backlog :)
[15:45] <blackboxsw> take car
[15:45] <blackboxsw> e
[15:48] <bdmurray> blackboxsw: I've got a tab open
[15:48] <blackboxsw> excellent good sir
[15:50] -queuebot:#ubuntu-release- Unapproved: rejected ebtables [source] (xenial-proposed) [<IP_ADDRESS>-3.4ubuntu<IP_ADDRESS>]
[17:05] <bdmurray> blackboxsw: bug 1770712 is missing a test case / SRU information but I won't block on it
[17:06] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [18.3-0ubuntu1~18.04.1]
[17:07] <bdmurray> slangasek: Could you review / merge https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/time-to-release/+merge/348100?
[17:18] -queuebot:#ubuntu-release- Unapproved: ebtables (artful-proposed/main) [<IP_ADDRESS>-3.5ubuntu<IP_ADDRESS> => <IP_ADDRESS>-3.5ubuntu<IP_ADDRESS>] (edubuntu, ubuntu-server)
[17:18] -queuebot:#ubuntu-release- Unapproved: ebtables (bionic-proposed/main) [<IP_ADDRESS>-3.5ubuntu<IP_ADDRESS> => <IP_ADDRESS>-3.5ubuntu<IP_ADDRESS>] (edubuntu, ubuntu-server)
[17:18] -queuebot:#ubuntu-release- Unapproved: ebtables (xenial-proposed/main) [<IP_ADDRESS>-3.4ubuntu<IP_ADDRESS> => <IP_ADDRESS>-3.4ubuntu<IP_ADDRESS>] (ubuntu-server)
[17:42] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (artful-proposed) [18.3-0ubuntu1~17.10.1]
[17:47] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [18.3-0ubuntu1~16.04.1]
[18:12] -queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (bionic-proposed) [<IP_ADDRESS>-3.5ubuntu<IP_ADDRESS>]
[18:13] -queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (artful-proposed) [<IP_ADDRESS>-3.5ubuntu<IP_ADDRESS>]
[18:14] -queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (xenial-proposed) [<IP_ADDRESS>-3.4ubuntu<IP_ADDRESS>]
[19:37] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (bionic-proposed) [3.28.2-0ubuntu<IP_ADDRESS>]
[19:46] -queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.2-2~ubuntu18.04.1]
[19:57] <bdmurray> coreycb: Where is aodh 6.0.1 for cosmic?
[20:03] <coreycb> bdmurray: that would be good, wouldn't it. i'll get that up soon.
[20:03] <bdmurray> coreycb: are the other uploads squared away?
[20:04] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (bionic-proposed) [<IP_ADDRESS>]
[20:05] <coreycb> bdmurray: yes they're good
[20:05] <bdmurray> coreycb: okay
[20:22] <coreycb> bdmurray: i've just uplaoded aodh 6.0.1-0ubuntu2 to cosmic
[20:31] <bdmurray> infinity: can you some SRU stuff to bug 1778811?
[20:37] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (bionic-proposed) [3:13.0.1-0ubuntu1]
[20:42] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.5-0ubuntu1]
[20:51] -queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (bionic-proposed) [1:10.0.1-0ubuntu<IP_ADDRESS>]
[20:57] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.3-0ubuntu1]
[21:05] -queuebot:#ubuntu-release- Unapproved: ostree (bionic-proposed/universe) [2018.4-2 => 2018.6-0ubuntu0.1] (ubuntugnome)
[21:07] <infinity> bdmurray: If you can verb your sentences.
[21:08] <infinity> bdmurray: (I'll fix up the bug later, not that it's a big deal given that the only person who's going to verify it is the uploader, who usually self-accepts CD build system stuff. :P)
[21:08] <bdmurray> infinity: its like a madlib
[21:16] <infinity> bdmurray: Been awake since yesterday, but I'll get you paperwork tonight.
[21:16] <infinity> Not all here right now.
[21:16] <infinity> Not really even half here.
[21:54] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (bionic-proposed) [2:12.0.3-0ubuntu1]
[22:16] -queuebot:#ubuntu-release- Unapproved: accepted grub-installer [source] (bionic-proposed) [1.128ubuntu<IP_ADDRESS>]
[22:21] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [<IP_ADDRESS>]
[22:30] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.1]
[22:33] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.1]
[22:36] -queuebot:#ubuntu-release- Unapproved: accepted partman-auto [source] (bionic-proposed) [134ubuntu8.1]
[22:38] -queuebot:#ubuntu-release- Unapproved: accepted partman-efi [source] (bionic-proposed) [71ubuntu2.1]
[22:43] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8 => 2.02-2ubuntu8.1] (core)
[22:49] -queuebot:#ubuntu-release- Unapproved: accepted libjsyntaxpane-java [source] (bionic-proposed) [0.9.6~r156-6ubuntu<IP_ADDRESS>]
[22:54] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [<IP_ADDRESS>-0ubuntu24]
[23:51] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.1 => 2.02-2ubuntu8.1] (core)


[18:31] <redwolf> o/
 @VikingRedwolf WOLF! ._.
 Aye
 How are you?
 Horny .__.
 Why? ._.
 Dunno. It's my natural status :D