[11:56] <scizho> kde seems require more cpu resources compare to gnome
[11:56] <cody> what version of X.org does 5.04 use?
[11:56] <jasoncohen> cody, 6.8.2
[11:56] <unome> scizho: true, Gnome runs better on older pcs
[11:57] <nalioth> scizho: you are correct, kde is more cpu intensive
[11:57] <scizho> yes..
[11:57] <cody> thanks jason
[11:57] <scizho> pentium III
[11:57] <socomm> freddy: If you don't have hardware acceleration, yes.
[11:57] <topyli> it's the RAM guys
[11:57] <scizho> just like i use right now
[11:57] <jasoncohen> gnome runs better on newer pcs, heh
[11:57] <scizho> :P
[11:57] <jasoncohen> 2.10 is a big step up from 2.8 in my opinion. the addition of the administrative/preferences menus is great
[11:58] <scizho> not mentions when you run kde on thin client
[11:58] <jasoncohen> what's going to be in 2.12?
[11:58] <topyli> jasoncohen: almost no-one knows yet :)
[11:58] <socomm> Everything runs better on newer pcs ...
[11:59] <scizho> yes
[11:59] <scizho> including my diet
[11:59] <jasoncohen> i notice that on a 1.6 ghz laptop with 640 MB of pc2100 ram, it takes longer to load programs from RAM and programs stay longer in RAM in gnome than in KDE by a very noticeable amount
[11:59] <unome> Look, KDE and Gnome are like Intel and AMD, Republican and Democrat, McDonalds and BurgerKing ...etc lol
[11:59] <unome> oh Pepsi and Coke
[11:59] <matt_> PLease can someone help me get this mx 1000 mouse working
[11:59] <Will__> pepsi sucks
[11:59] <matt_> I can't get the driver working


[06:18] <alkisg> I've been testing 16 bpp depth with the modesetting driver, and it has issues everywhere that I tested it: intel => crash, vboxvideo (vbox) and virtio (kvm) => corrupted double image, cirrus (kvm) => corrupted small image etc
[06:18] <alkisg> But there's something I don't understand. Ubuntu 16.04.1 and 16.04.2 have the same modesetting driver, right?
[06:19] <alkisg> So, why e.g.  `kvm -vga cirrus -ctrl-grab -m 1024 -cdrom ubuntu-mate-16.04.1-desktop-i386.iso` works, while 16.04.2 has issues?
[06:37] <alkisg> Hey, it's Xorg 1.18.3 vs 1.18.4, let me test if that's to blame....
[06:46] <alkisg> So, I've booted with ubuntu-mate-16.04.2-desktop-i386.iso which does have the 16 bpp issue, then I downgraded from xserver-xorg-hwe-16.04 (1.18.4) to xserver-xorg (1.18.3), and it still has the issue. What does that prove, that the issue is in the cirrus driver and not in the modesetting driver?!
[06:46] <alkisg> (while 16.04.1 with xserver-xorg (1.18.3) does not have the issue)
[06:47] <alkisg> (unless installing a different xorg requires a reboot too, not just a xinit...)
[06:51] <alkisg> Sorry my bad, I didn't notice that the xserver-xorg-core version was unrelated to the xserver-xorg-* stack. By installing xserver-xorg-core=1.18.3, the problem disappeared
[06:52] <alkisg> So I believe that the regression happened somewhere between 1.18.3 and 1.18.4. Testing more...
[07:17] <alkisg> I filed this one: https://bugs.freedesktop.org/show_bug.cgi?id=100295
[07:18] <alkisg> What real hardware can I test, that would use the modesetting driver? Except for intel, which crashed and I've already reported that?
[07:23] <tjaalton> whatever you have
[07:31] <alkisg> tjaalton: I can specify "Driver modeset" in xorg.conf in e.g. a radeon laptop that I have here?
[07:31] <tjaalton> yes
[07:31] <alkisg> ty, testing...
[08:57] <alkisg> I updated the bug report with the results of the real hardware test, which are similar.
[08:58]  * alkisg checks if he can find any recent commits that could have caused this...
[09:00] <tjaalton> there aren't too many between 1.18.3..1.18.4
[09:00] <tjaalton> bisect
[09:01] <tjaalton> or just try reverting a commit at a time that touches modesetting
[09:01] <tjaalton> 62 commits in 1.18.4
[09:02] <tjaalton> 11 on modesetting
[09:07] <alkisg> tjaalton: I'm a little lost between apt source and upstream git, is it possible to git/bzr clone and bisect something from launchpad instead? E.g. is there a bzr branch of xserver-xorg-hwe-16.04 in launchpad?
[09:07] <tjaalton> no
[09:08] <alkisg> I'm seeing this: https://cgit.freedesktop.org/xorg/xserver/log/hw/xfree86/drivers/modesetting, and I can't find out which commit maps to the 1.18.3 release
[09:09] <tjaalton> git clone upstream, git log xorg-server-1.18.3..xorg-server-1.18.4
[09:09] <tjaalton> then start reverting the commits that touch modesetting, starting from the latest
[09:09] <alkisg> ty, trying...
[09:09] <tjaalton> next git format-patch -1 <sha>, drop the patch in debian/patches and add to series. build a package
[09:10] <tjaalton> it's probably f091528457cc62f modesetting: Implement 32->24 bpp conversion in shadow update
[09:30] <alkisg> Yup, that was the one
[09:30] <alkisg> Thank you Timo, commenting on the report...
[09:42] <alkisg> tjaalton: eh, it's also the one that's causing the broadwell crash on 16bpp :D
[09:43] <tjaalton> figured


[08:57] <Riddell> wow image size today is 858M, I know that's below our new limit but how the heck has it got so big so quick
[09:05] <jussi> Riddell: ouch. btw, are we now going to ship LO or calligra?
[09:06] <Riddell> mm that didn't come up during the spec review
[09:06] <Riddell> but "include Calligra in Alpha images, decide on inclusion before beta" is still what I'd like
[09:10] <jussi> Yeah, id be interested in that
[09:13] <jussi> I think the biggest sticking point for most people is the lack of ability to create MS office format docs
[09:13] <Riddell> not spreading that proprietary format is an advantage for me!  </idealist>
[09:14] <jussi> I guess thats why I said "most people" ;)
[09:14] <jussi> btw, where is our latest calligra version housed?
[09:15] <starbuck> Riddell: when you right click in dolphin to create a document, what is the default filetype for word, spreadsheet and presentation in kubuntu 12.04?
[09:15] <starbuck> for the file that gets created?
[09:16] <jussi> starbuck: they seem to be LO odp/t etc
[09:26] <Riddell> does anyone use the Create New in file managers?
[09:28] <Riddell> whee today's image working well and universal
[09:29] <inetpro> Riddell: if I may chime in, I often use it to create a new folder and create new txt document
[09:29] <inetpro> but the rest of them I don't use often
[09:30] <Riddell> fair enough
[09:42] <starbuck> Riddell: isnt it kpr for koffice presentation in 12.04?
[09:42] <starbuck> i wonder, i think its not odf?
[09:42] <starbuck> or odp?
[09:43] <starbuck> i think its old koffice based...
[09:45] <Riddell> starbuck: koffice doesn't exist in 12.04, only calligra does which uses odp
[09:47] <starbuck> oh, then i wonder if I right click why does it offer me kpr extension for presentation?
[09:47] <starbuck> did i install some package that influences it?
[09:48] <Riddell> I didn't think even koffice used kpr any more
[09:48] <Riddell> let me look
[09:50] <Riddell> starbuck: calligrastage does open kpr documents but it doesn't save them and dolphin has a Create New Presentation option which gives me a .odp OpenDocument file
[09:53] <starbuck> oh
[09:53] <Riddell> kpr is a pretty old format, koffice moved to opendocument a while ago
[09:56] <starbuck> yes,
[09:56] <starbuck> so any settings where i can decide on create new documents type and endings?
[09:59] <Riddell> that's a .desktop file somewhere and a template /me looks
[10:01] <starbuck> Riddell: thanks.
[10:10] <debfx> Riddell: re image size, kde-wallpapers is quite large: http://felix.fobos.de/kubuntu/kubuntu-quantal-cd-amd64-diff.htm
[10:17] <Riddell> starbuck: /usr/share/templates/ is the magic directory they are in
[10:18] <Riddell> e.g. /usr/share/templates/Presentation.desktop
[10:18] <Riddell> which points to /usr/share/templates/.source/Presentation.odp as template
[10:21] <starbuck> Riddell: great, that helps :)
[10:35] <BluesKaj> Hey all
[12:48] <shadeslayer> Riddell: not anymore :)
[12:50] <Riddell> shadeslayer: what what?
[12:51] <shadeslayer> Riddell: ec2
[12:57] <Riddell> aah, slow conversation this one
[13:00] <shadeslayer> :P
[13:01] <shadeslayer> Riddell: Could you possibly test calligra ? And maybe upload kile?
[13:01] <Riddell> shadeslayer: hmm spose so
[13:01] <shadeslayer> https://launchpad.net/~rohangarg/+archive/experimental < from here
[13:01] <Riddell> where are they?
[13:01] <Riddell> ok
[13:02] <shadeslayer> calligra packaging can also be found in bzr
[13:06] <Riddell> mm, this calligrawords is opening any proprietary format file I throw at it well
[13:06] <ScottK> Opens, but can you create a new one?
[13:06] <apachelogger> good morning
[13:07] <shadeslayer> ^_^
[13:07] <shadeslayer> apachelogger: ahoy
[13:08] <Riddell> ScottK: goodness no, whyever would I want to spread evil formats like that?
[13:09] <ScottK> Because there's not a lot of point is sending someone a file they can't open.
[13:09] <apachelogger> before we talk about offices
[13:09] <apachelogger> can we talk about browsers?
[13:10]  * apachelogger asked for testing on potential rekonq update on ML ... 2 people replied, one of them with any sort of feedback
[13:10] <apachelogger> logical deduction is that almost one in the team uses rekonq on a regularly basis
[13:10]  * ScottK doesn't.
[13:10] <apachelogger> what with doog food and stuff that seems slightly odd
[13:11] <Riddell> apachelogger: you asked for 0.9.2 which is already in quantal?
[13:11] <apachelogger> yeah
[13:12] <apachelogger> except our users are on precise, are they not?
[13:12] <ScottK> I have been using Calligra Words a bit lately and I fine it generally nice, but the MS Office thing is still a killer, IMO.
[13:12] <apachelogger> AAMOF I am on precise
[13:12] <ScottK> I gotta run (be offline all day), so have fun.
[13:12] <Riddell> apachelogger: on -devel many will be on quantal I guess
[13:13] <Riddell> and with ubuntu's stable each day policy I'd like to move upstream devs and testers to the development release
[13:13] <apachelogger> even so, they would be able to talk about rekonq 0.9.2's quality I'd think
[13:13] <jussi> btw, where is our latest calligra version for precise housed?
[13:13] <shadeslayer> uhh
[13:13] <shadeslayer> jussi: I'll work on that
[13:13] <shadeslayer> now that my visa is all sorted out
[13:14] <dantti_laptop> rbelem: ping
[13:14] <Riddell> shadeslayer: visa for akademy?
[13:14] <shadeslayer> apachelogger: do you want me to work exclusively on pgst?
[13:14] <shadeslayer> Riddell: yeah
[13:14] <Riddell> whee
[13:14] <shadeslayer> They were so awesome, they didn't even charge me for it
[13:15] <apachelogger> shadeslayer: I thought you grew up to be >minion ^^
[13:15] <shadeslayer> so free visa
[13:15] <jussi> shadeslayer: +++
[13:15] <shadeslayer> apachelogger: I didn't ask you to mentor me, I just asked if it's specifically pgst that needs fixing
[13:16]  * jussi hugs shadeslayer
[13:16] <apachelogger> you could also have a look at phonon/general bugs
[13:16] <apachelogger> pvlc is the working
[13:16]  * shadeslayer hugs jussi back
[13:16] <shadeslayer> hmm
[13:17] <apachelogger> http://goo.gl/bbkva
[13:17] <apachelogger> shadeslayer: oh, actually, if you want something kdeish you can also look at the phonon crap in kde-multimedia
[13:18] <apachelogger> kcm/kded/platformplugin/streamer
[13:18] <apachelogger> OHOHOH
[13:18] <apachelogger> actually
[13:18] <apachelogger> shadeslayer: you might want to look at KIO streaming
[13:18] <shadeslayer> #kde-multimedia would a better place for this :P
[13:18] <apachelogger> *shrug*
[13:19] <apachelogger> cwickert says kubuntu doesn't do anything upstream
[13:20] <jussi> You know in response to the calligra export thing, we should just annoy people from all the lovely stakeholders, LO, Canonical, Calligra and everyone else we can find to sponsor a single converter for MS Office formats, that is maintained by one group, and has an API that everyone can hook into and redistribute with their application...
[13:20] <jussi> apachelogger: lol
[13:24] <Riddell> MS Office can jjjjjjjjjjjj
[13:24] <jussi> heh
[13:24] <jussi> anyways, off home now
[13:24] <jussi> laters
[13:26] <Riddell> MS Office can open ODF
[13:30] <apachelogger> Riddell, jussi, ScottK: more interestingly. ... last I checked a lot of the format support development was actually founded by nokia... :S
[13:30] <apachelogger> or was it funded
[13:30]  * apachelogger needs coffee
[13:31] <shadeslayer> iirc didn't MS promise ODF support ?
[13:31] <shadeslayer> in the next version of Office
[13:32] <Riddell> shadeslayer: yes
[13:32] <Riddell> in no other industry would it be acceptable for people to not use the standard
[13:35] <shadeslayer> right, so what's the problem with sending odf documents, I mean, if someone does recieve a ODF document and it's not supported, they could *easily* upload it to GDocs and convert it to doc
[13:35] <shadeslayer> although, this might be a problem in commercial situations
[13:35] <shadeslayer> Riddell: does calligra work ok?
[13:36] <Riddell> shadeslayer: it works great, uploaded
[13:37] <Riddell> shadeslayer: fancy changing the seeds to calligra for the experiment?
[13:38] <shadeslayer> I'll do it tonight :)
[13:38] <Riddell> great
[13:38] <Riddell> shadeslayer: what needs doing with kile?
[13:38] <shadeslayer> uploading, you already tested it
[13:38] <shadeslayer> as did yofel I think
[13:39] <Riddell> shadeslayer: you're in the right group to be able to upload?
[13:39] <shadeslayer> for kile? no
[13:39] <shadeslayer> assuming kile isn't in the kubuntu package sert
[13:40] <Riddell> shadeslayer: I think it can be if you just add it to the supported seed
[13:40] <Riddell> uploaded thanks
[13:40] <shadeslayer> <3
[13:40] <shadeslayer> I need to look into this supported/unsupported seed stuff
[13:40] <Riddell> we all do
[13:41] <Riddell> but supported is just another seed file next to desktop et al
[13:41] <Riddell> which I think will put packages into kubuntu-dev so elite people like you can upload them
[13:41] <Riddell> previously it pulled them into main but shouldn't do that now
[13:41] <ScottK> shadeslayer: I don't get to tell my customers "Just upload it to GDocs and convert it."
[13:42] <shadeslayer> ScottK: right
[13:42] <ScottK> Also some people have privacy concerns about uploading their documents to cloud services.
[13:42] <shadeslayer> ScottK: that's why I added that it might not work in commercial setups
[13:42] <ScottK> It would also violate the principal of least surprise for non-technical users.
[13:43] <ScottK> But I have to go.
[13:46] <shadeslayer> cya
[13:50] <apachelogger> ScottK: do you plan on rolling out oneiric to customers?
[13:50] <apachelogger> because if not, I am not opposed to the idea of giving calligra a one-release trial, particularly after LTS
[13:50] <apachelogger> if upstream is ok with that
[13:51] <apachelogger> if it starts a shitstorm we can always go "use 12.04"
[13:52] <Riddell> oneiric?  surely quantal?
[13:56] <apachelogger> ah, yes ^^
[13:56]  * apachelogger has not got enough sleep
[13:57] <apachelogger> the price one has to pay for a bug free phonon vlc :(
[13:57] <Riddell> it's worth it
[13:57] <Riddell> what do we want in our language packs? (i.e. meta packages)
[13:58] <Riddell> so far I have Depends: ${misc:Depends}, language-pack-aaaUBUNTULANGCODEbbb, kde-l10n-aaaUBUNTULANGCODEbbb
[13:58] <Riddell> and I'm going to work out how to put in calligra where it exists
[13:58] <Riddell> anything else?
[13:58] <apachelogger> k3b-i18n? amarok-i18n?
[13:59] <Riddell> is there a separate amarok-i18n?
[14:00] <Riddell> I think it's all in amarok-common
[14:01] <shadeslayer> Riddell: btw there are calligra lang packs as well
[14:01] <shadeslayer> what do we do about those
[14:01] <debfx> Riddell: pulling in the right language support packages is handled by muon/language-selector and the seeds
[14:01] <Riddell> shadeslayer: package them up same as currently
[14:02] <Riddell> shadeslayer: so make a big calligra-l10n package
[14:02] <shadeslayer> mmm ...
[14:02] <Riddell> debfx: language-selector is going to go away, what does muon do?
[14:02] <shadeslayer> that's going to be fun
[14:03] <Riddell> the seeds bring in language-pack-kde-xx which is going to go away
[14:03] <Riddell> and I'm planning on replacing launchpad made language-pack-kde-xx with meta package language-pack-kde-xx
[14:05] <debfx> muon is calling language-selector. I think only the frontend of l-s is going away.
[14:06] <debfx> are you absolutely sure that we don't want lp translations for some packages?
[14:07] <debfx> and do we have no patches in kde sc that introduce user-visible strings?
[14:08] <Riddell> lp translations just cause problems in my experience
[14:08] <Riddell> the only user-visible string I can think of is one saying "translations edited in launchpad"
[14:09] <debfx> for example synaptiks has nearly no translations upstream. while I'd say translations should be done upstream when possible it's clearly not working well in this case.
[14:10] <Riddell> synaptiks has just been moved to universe along with everything else
[14:11] <debfx> that doesn't matter, universe packages are translated if you set a control field
[14:12] <debfx> kde-workspace has: +            m_installDefaultWallpaperButton->setText(i18nc("@action:button", "Install Default Wallpapers..."));
[14:13] <Riddell> upstream have always said they'd welcome disto strings like that translated upstream (havn't you tsdgeos?)
[14:13] <debfx> which is a bit weird since default wallpapers should be installed already ;)
[14:14] <tsdgeos> Riddell: ECANTPARSESENTECE
[14:14] <tsdgeos> Riddell: what do you mean
[14:14] <tsdgeos> ?
[14:15] <Riddell> debfx: the default selection was split out to save cd space, only the default default one was included
[14:15] <Riddell> tsdgeos: if we don't use launchpad for translations can we put strings like "Install Default Wallpapers..." upstream for translation?
[14:15] <tsdgeos> Riddell: yes, if you define kde svn to be your upstream translation location we can do that
[14:16] <tsdgeos> we do that for the commit digest web and stuff
[14:16] <tsdgeos> though it has to be seen how you upload the .po files
[14:16] <tsdgeos> for commit digest et all it's manual update
[14:17] <tsdgeos> since we "don't trust" running MEssages.sh contained in "foreign" repos
[14:17] <tsdgeos> but it can be wokred out
[14:17] <tsdgeos> if you want
[14:24] <rbelem> dantti_laptop, pong
[14:25] <dantti_laptop> rbelem: dfaure already told me where smb kio lies :P
[14:26] <rbelem> dantti_laptop, :-)
[14:26] <dantti_laptop> rbelem: I'm going to change it to also display the printer share so you can add it directly from the dolphin page :)
[14:27] <rbelem> dantti_laptop, nice :-)
[14:27] <dantti_laptop> rbelem: it will be *much* easier that using libsmbclient directly  :P
[14:27] <dantti_laptop> and more integrated too
[14:28] <rbelem> dantti_laptop, which kio r u talking about?
[14:29] <dantti_laptop> rbelem: the browse one not the your share
[14:29] <rbelem> dantti_laptop, ah! ok
[14:29] <rbelem> dantti_laptop, i think afiestas_ was working on that
[14:30] <rbelem> dantti_laptop, there are two kio for browsing
[14:30] <rbelem> dantti_laptop, one of them is more maintained and complete
[14:31] <rbelem> dantti_laptop, but i dont remember which of them is the one
[14:32] <dantti_laptop> oh
[14:33] <dantti_laptop> ok I'll poke him thanks for the head up
[14:33] <rbelem> :-)
[14:55] <Riddell> jussi: why use precise instead of quantal?
[14:55] <Riddell> say if you want the latest and greatest calligra
[15:01] <yofel> Riddell, shadeslayer: from the things that I added to supported, perlkde and kile were skipped in the packageset it seems - needs a manual override?
[15:02] <yofel> shadeslayer: digikam is in though, so feel free to upload that
[15:02] <shadeslayer> won't upload digikam today, needs a bit of work that I've planned for tomorrow
[15:03] <shadeslayer> the packaging wasn't in sync between bzr and the archive
[15:03] <shadeslayer> so, while I've sync'd it ... someone needs to go over the last few revision once
[15:03] <yofel> debfx: as Riddell said that was because of kde-wallpapers split - if we leave it merged that should be changed to install kdewallpapers again as it did before
[15:04] <yofel> ah, I'll take a look later maybe
[15:04] <shadeslayer> and libkvkontakte-data might need a kick from binary new
[15:04] <Riddell> we could look at unsplitting kde-wallpapers with our larger image size now, depends on how much it adds
[15:05] <Riddell> I wonder how translations are done in digikam
[15:05] <yofel> Riddell: it is merged now - that's what makes the images larger
[15:05] <shadeslayer> I'd really like to see more wallpapers on the ISO, just having one lonely wallpaper seems bad
[15:05] <Riddell> yofel: oh right, I didn't spot that happening
[15:06] <yofel> kde-wallpapers-default is a transitional package now, but still in the seeds until we're sure we'll leave it like this
[15:06] <Riddell> shadeslayer: yeah yeah next you'll be asking for language and then games and then you'll be moaning that 1GB isn't enough!
[15:07] <debfx> yofel: I know, I was merely commenting on the ambiguity of what "default wallpapers" means. to me it sounds like "install the wallpapers that are installed by default".
[15:07] <apachelogger> what we need is multi-size wallpaper
[15:07] <apachelogger> not one for all
[15:07] <apachelogger> which then looks like the crap pile of crap
[15:07] <yofel> ah ok
[15:08]  * debfx notes that killing kde-wallpapers-default means diverging from Debian
[15:10] <yofel> why did they split it?
[15:11] <Riddell> to save ISO space
[15:12] <yofel> did I miss something or aren't debian install images a set from the whole archive?
[15:14] <Riddell> yofel: why do you think you might have missed something?
[15:15] <debfx> yofel: there is a debian kde cd image
[15:15] <yofel> ok, I didn't know about that one
[15:15] <yofel> (last time I checked (quite a while ago) all I found were a set of many images and the netinst for installation)
[15:23] <soee> hi
[15:25] <yofel> so, do we want to keep it like this? I merged it to make things simplier, but considering the size and that it's easy to install it would probably make more sense to merge some of the harder to notice splits
[15:25] <yofel> (esp. those that aren't done in debian)
[15:26] <Riddell> if it's split in debian we should keep it that way
[15:27] <yofel> ok, I'll revert it
[15:40] <highvoltage> ScottK: howdy! I see pairs end up under the "Other" menu in Gnome. would it be ok if I update the .desktop file so that it ends up under the right place?
[15:47] <jussi> Riddell: my system needs to "kinda" work, ie. the wife needs to be able to use it a bit - Ill upgrade usually about alpha3
[15:47] <jussi> an the work system...well...
[16:04] <Riddell> jussi: see ubuntu has this new dev-release-always-stable policy, I'm wondering if anyone in practice has used it
[16:05] <Riddell> highvoltage: is it an upstream bug?
[16:05] <Riddell> have you worked out what the problem is?
[16:14] <shadeslayer> well that's weird .. words and stage don't want to compile on precise
[16:14] <shadeslayer> and the CMake diff is insanely large
[16:15] <yofel> oh, you need that -DHAVEPATCHEDQT define or what it was called in rules for qt 4.8.1 - see precise package
[16:15] <yofel> or wait, I'll get it
[16:16] <shadeslayer> uh ok
[16:17] <shadeslayer> Someone needs to write a backporting guide with all these caveats :P
[16:18] <yofel> shadeslayer: http://paste.kde.org/502718
[16:19] <shadeslayer> building
[16:26] <yofel> Riddell: I'm always running the dev release here on my work notebook - with a backup system not too far away. Works fine 95% of the time, and then something from the "doesn't boot anymore" scale happens.  Uploading to -proposed and auto-copying to release will only prevent apt breakage, it's still unstable
[16:31] <Riddell> mm
[16:31] <Riddell> I'm mindful that backports take a lot of time to do and are only used by the sort of people who could upgrade to the development release
[16:33] <yofel> well, we could drop the beta backports? Those happen during the times when we don't really have time for them. Backporting a stable release once a month for including ~2 point releases is ok IMHO
[16:33] <yofel> s/for//
[16:33] <kubotu> yofel meant: "well, we could drop the beta backports? Those happen during the times when we don't really have time  them. Backporting a stable release once a month for including ~2 point releases is ok IMHO"
[16:33] <yofel> sed fail
[16:34] <JontheEchidna> lol
[16:35] <soee> noo :) keep on with beta backports
[16:40] <CIA-45> [lp:~kubuntu-packagers/kubuntu-packaging/kde-wallpapers] Philip Muškovac * 38 * debian/ (5 files) Revert kde-wallpapers[-default] merge from 4:4.8.80-0ubuntu1
[16:41] <yofel> that'll fix most of the image size
[16:50] <Riddell> yofel: mm dumping beta backports is an interesting middle ground
[16:51] <debfx> yofel: I think we should include all sizes of the default wallpaper in kde-wallpapers-default
[16:51] <Riddell> Mamarok as a non-dev how would that make you feel?  to get beta from neon and devel release rather than beta backports
[16:51] <yofel> debfx: didn't think about that, right
[16:52] <Mamarok> the problem with Neon is that it needs a separate installation, so not something I can test on the same machine
[16:52] <yofel> Mamarok: it doesn't - and if it does then something's broken
[16:53] <Mamarok> yofel: oh, then I was misinformed, and that would be perfect for beta testing
[16:54] <Mamarok> so I can get Neon packages and once I want stable I just disable it?
[16:54] <yofel> one issue with neon is that I never got the python bindings done - so all python parts are missing (It's a PITA to do really)
[16:54] <Mamarok> hm, what app would that influence?
[16:55] <yofel> printer settings at least, and whatever else uses python
[16:55] <Mamarok> and is it possible to mix stuff, e.g. getting just one app from Neon but keep Precise for the rest?
[16:56] <yofel> neon is installed seperately (which is what makes it tricky to do) - so you keep everything from precise
[16:56] <Mamarok> yofel: didn't you just say it was not?
[16:57] <Riddell> it's installed into /opt so you have to log out and in to run it
[16:57] <Mamarok> ah, crap
[16:57] <Mamarok> I think I will reactivate my old laptop instead
[16:58] <yofel> you can run specific apps from konsole in the normal session - but not plasma etc.
[16:58] <Mamarok> or as a different user?
[16:58] <Riddell> apachelogger: why amarok no output to headphones when dragon does!  phonon smells!
[16:58] <yofel> it doesn't share the settings with the normal KDE install, so a seperate user isn't really needed
[16:58] <Mamarok> Riddell: I blame PA
[16:59] <Mamarok> yofel: but I have a second user, so that would suffice?
[16:59] <yofel> sure
[16:59] <Mamarok> so I can just switch user for testing, which doesn't need me to log out
[16:59] <yofel> ah, yeah, should be fine
[17:01]  * Mamarok needs to get a bigger HD then, or use the old laptop instead
[17:04] <Mamarok> so yes, dump the beta backports, since we have an alterantive
[17:05] <Mamarok> alternative even :)
[17:10] <shadeslayer> and since we're setting up qemu images for neon, testing is going to be even easier
[17:11] <shadeslayer> you could run stable KDE and run neon in a virtual image
[17:11] <shadeslayer> also, yay : /tmp/buildd/calligra-2.4.91a/active/src/MainWindow.h:27:26: fatal error: kdeclarative.h: No such file or directory
[17:11] <shadeslayer> !find kdeclarative.h quantal
[17:11] <yofel> quantal: kdelibs5-dev, precise: kdelibs5-experimental-dev
[17:12] <starbuck> anyone knows the email of david edmundson (from lightdm-kde?)
[17:12] <shadeslayer> yeah
[17:24] <snele> hi guys. do you plan to update plasma-nm for precise? current version in precise is <IP_ADDRESS> and newer releases have some important fixes.
[17:24] <snele> http://lamarque-lvs.blogspot.com/2012/06/plasma-nm-0903.html
[17:29] <yofel> kubotu: newversion networkmanagement <IP_ADDRESS> http://lamarque-lvs.blogspot.com/2012/06/plasma-nm-0903.html
[17:29] <kubotu> https://bugs.launchpad.net/bugs/1014753
[17:31] <yofel> snele: we'll at least backport it to precise, as for -updates we'll have to see
[17:31] <yofel> snele: we'll at least backport it to precise, as for -updates we'll have to see
[17:34] <snele> yofel: ok. lamarque (plasma-nm dev) is asking distributions to update it in their repositories: "We receive duplicates of this bug twice a day because users have not updated their Plasma NM installations. Unfortunately, some distributions still have not created updates for <IP_ADDRESS>, which was released more than 40 days ago. Please distributions, help me and provide updates for your users, ok?"
[17:36] <snele> btw I am not experiencing any bugs with precise's plasma-nm but seems that a lot of other kubuntu users do
[17:50] <yofel> shadeslayer: are you going to upload calligra-l10n or should I?
[17:50] <shadeslayer> if you're free do it
[17:50] <shadeslayer> I'm trying to make calligra compile on precise
[17:55] <shadeslayer> `.text._ZN24KisShadeSelectorLineBaseD2Ev' referenced in section `.text._ZN24KisShadeSelectorLineBaseD1Ev[KisShadeSelectorLineBase::~KisShadeSelectorLineBase()]' of CMakeFiles/kritacolorselectorng.dir/kis_shade_selector_line_combo_box.o: defined in discarded section `.text._ZN24KisShadeSelectorLineBaseD2Ev[_ZN24KisShadeSelectorLineBaseD5Ev]' of CMakeFiles/kritacolorselectorng.dir/kis_shade_selector_line_combo_box.o
[17:55] <shadeslayer> collect2: ld returned 1 exit status
[17:55] <shadeslayer> \o/
[17:56] <yofel> looks like ccache mess
[17:56] <shadeslayer> yeah, now I'll have to rebuild the entire thing again :|
[18:11] <Peace-> ok 12.10 tested good
[18:33] <soee> Peace-, tested what :>
[18:37] <apachelogger> Riddell: how would I know
[18:44] <highvoltage> Riddell: it's like that in the upstream tarball
[18:45] <highvoltage> (regarding pairs)
[18:45] <BarkingFish> Evening guys :)  Wonder if you could help me... I'm trying to install some packages for debugging kmail 4.8.3 - it's died, and yet the crash assistant is telling me it can't find debug packages for the trace.  Do we have all the necessary symbol packages out there please?
[18:45] <yofel> calligra-l10n is fun
[18:45] <yofel> at least the debian folks ship a script to set that up
[18:46] <yofel> BarkingFish: depends on the file that's missing, can you pastebin the incomplete trace?
[18:46] <BarkingFish> sure, one mo
[18:47] <BarkingFish> yofel, http://pastebin.com/uDgH3rvf
[18:48] <yofel> symbols are there, it probably complains about "Backtrace stopped: previous frame inner to this frame (corrupt stack?)"
[18:49] <BarkingFish> hm.  So the trace is unusable?
[18:49] <BarkingFish> it's marked up a 2* in the assistant - i was basically doing a mass delete, and it just died outright.
[18:50] <yofel> well, a few symbols are there... not sure
[18:50] <BarkingFish> it might be worth submitting, i suppose. Whatever is there could still match something i would imagine
[18:51] <BarkingFish> but if there are any missing symbols, i guess it would make it harder to figure out what the heck had gone wrong.
[18:54] <BarkingFish> yep, it's already hit the bug, it's a duplicate yofel
[18:54] <yofel> heh
[18:55] <BarkingFish> 286708 - Kmail crashes while adding/deleting old mails to/from inbox
[18:55] <BarkingFish> i'll submit it and it'll get attached to that one I'd assume
[18:57] <BarkingFish> not filed, it's a common crash, 139 bugs marked duplicate off it, and I have nothing new to add on.
[19:10] <ScottK> highvoltage: We'd want something that could be upstreamed.
[19:25] <shadeslayer> jussi: ping
[19:25] <shadeslayer> jussi: I'm going to put calligra into staging, could you test after it's built?
[19:27] <highvoltage> ScottK: any of you have commit rights? could I just provide an updated .desktop file for you?
[19:27] <shadeslayer> highvoltage: I have commit rights
[19:27] <ScottK> highvoltage: I don't, but I believe Riddell or apachelogger could.
[19:28] <shadeslayer> though it would be best to just post the patch on reviewboard
[19:28] <apachelogger> shadeslayer can
[19:30] <shadeslayer> calligra for precise uploaded to staging
[20:12] <jussi> shadeslayer: likely, likely, but definately not tonight
[21:09] <JontheEchidna> any symbols experts know what to do w/ a symbols file that works on amd64 but not i386? https://launchpadlibrarian.net/107917253/buildlog_ubuntu-quantal-i386.libkgapi_0.4.0-0ubuntu2_FAILEDTOBUILD.txt.gz
[21:15] <solid_liq> JontheEchidna, use it on amd64
[21:23] <debfx> JontheEchidna: you should use pkgkde tools to create symbol files
[21:24] <debfx> JontheEchidna: they generate this: http://paste.ubuntu.com/1048139/
[21:26] <debfx> (with "1.7" replaced by "0.4.0" ;) )
[21:31] <JontheEchidna> debfx: thanks
[21:58] <Riddell> highvoltage: yes can commit fixes


[01:11] <guiverc> Bashing-om, Hub, desktop roadmap; "screenshots and covers Provisioning"  is the upper case of provisioning correct?  looks wrong to me today
[01:12] <guiverc> though upper case (heading probably) are there, so it's how that summary was written..
[01:13] <guiverc> (if change is made; lots of upper case would need flipping)
[01:13] <Bashing-om> guiverc: verifying ^
[01:18] <guiverc> GSoC article; s/l/L ... "that. links to"   Links to..
[01:18] <Bashing-om> guiverc: Provisioning - lowercase - I make the change while you keep looking.
[01:19] <guiverc> review case in that paragraph; I think i used case as per headings/sections of the article, but the case looks out of place when reading only summary...
[01:19] <guiverc> s/paragraph/summary ^
[01:23] <guiverc> I've finished my read thru.. looks good (one lower case 'l' that needs change)
[01:24] <guiverc> (the roadmap one;' usage of case had me confused; the 'provisioning' being what was 'most' wrong & only one that 'felt' really wrong)
[01:25] <Bashing-om> guiverc: going in :P
[01:29] <Bashing-om> guiverc: Done the 2 minor edits; saved and out.
[01:30] <guiverc> thanks Bashing-om , looks good
[01:33] <Bashing-om> guiverc: In publishing tomorrow - I pull the "comments/reply" when "WIP" is removed // final cleanups too.
[01:45] <guiverc> ack...
[03:42] -ubottu:#ubuntu-news- ::planet:: Stéphane Graber: Schedule for the containers and kernel devrooms at FOSDEM 2024 @ https://stgraber.org/2023/12/17/schedule-for-the-containers-and-kernel-devrooms-at-fosdem-2024/
[11:32] -ubottu:#ubuntu-news- ::ubuntuonair:: Data Science in production: Crossing the chasm @ https://www.youtube.com/watch?v=NO_-MJYfbiM
[11:32] -ubottu:#ubuntu-news- ::ubuntuonair:: ML saving 2000 jobs with less than 100 lines of code @ https://www.youtube.com/watch?v=UY5MHbqcYrE
[11:32] -ubottu:#ubuntu-news- ::ubuntuonair:: Updates from the GNOME Land: 2023 edition @ https://www.youtube.com/watch?v=rcqn26mnBPE
[18:29] <Eickmeyer> https://mastodon.art/@ubuntustudio/111602837659994703
[20:27] <Bashing-om> guiverc: Eickmeyer: IRT "Noble Numbat daily images" Tjough the post is today = as important as this may be let
[20:28] <Bashing-om> s run it in this week's publishing.
[20:47] <Eickmeyer> Bashing-om: Yeah, that's fine, they'll see it when they click on the link in this week's publishing.
[20:48] <Eickmeyer> I updated the post and it mentions the builds working up top.
[21:03] <Bashing-om> Eickmeyer: Lemme re-look - see if a re-do is needed :)
[21:08] <Bashing-om> guiverc: Eickmeyer: Think here is best to re-do the original summary with the update.
[21:42] <guiverc> Bashing-om, sorry I'm behind today (currently); maybe 30 mins if you want me
[21:48] <Bashing-om> UWN: 818; U-studio summary updated - see that it fits // added too the Pt LoCo meeting; clean-ups done - ready now to push ?
[22:03] <guiverc> Bashing-om, rather than an update; I'd prefer to re-write summary so as to include updated info; want me to do it? (when I can)
[22:06] <Bashing-om> guiverc: Sure - you write summary better than I - we have some time yet :)
[22:11] <guiverc> replace final sentence of initial summary with "An update tells us the booting problem has been fixed, but an installer issue (common with Ubuntu Desktop) still exists, with command required to manual start installer."  maybe  (ie. replacing 'We’re given reasons for this and told it’ll be fixed in the new year.'
[22:11] <guiverc> Bashing-om, ^
[22:14] <Bashing-om> guiverc: guiverc:  "with a command required given to manually start the installer" ??
[22:15] <guiverc> An update tells us the booting problem has been fixed, but an installer issue (common with Ubuntu Desktop) still exists, providing the command required to manual start installer.
[22:15] <guiverc> any better?
[22:17] <Bashing-om> guiverc: Better - but manual start the installer.
[22:17] <guiverc> sorry ; i meant 'manually'
[22:18] <Bashing-om> the
[22:18] <guiverc> yeah, that too :)
[22:19] <Bashing-om> guiverc: Leave the bulleted link for additional exposure ?
[22:20] <guiverc> I have no issue with it being left.
[22:21] <Bashing-om> :)
[22:33] <Bashing-om> guiverc2: Revert the WIKI and start the push now ?
[22:35] <guiverc> sorry i don't follow Bashing-om  (I'm far from my best)
[22:40] <Bashing-om> guiverc: I do not see an edit - restart Discourse to see ? awaiting confirmation to begin the publishing cycle - stil need to change the page from WIKI access.
[22:41] <guiverc> i've not edited to add "The Ubuntu Studio team provides us with an update of progress, in relation to Ubuntu Studio 24.04 LTS. Covered is the move to the new flutter-based frontend of Subiquity, which has the current unintended consequence of daily images not booting. An update tells us the booting problem has been fixed, but an installer issue (common with Ubuntu Desktop) still exists, providing the command required to manually start the
[22:41] <guiverc> installer." so it won't be there..   (sorry i've a headache & not really with it..)
[22:42] <Eickmeyer> That command starts the installer in a text mode, fwiw. Not ideal.
[22:42] <guiverc> better a less than ideal installer, than none at all though.
[22:43] <Eickmeyer> Yeah.
[22:43] <Eickmeyer> This is why pre-release is unsupported. :)
[23:38] <Bashing-om> UWN: U-studio edited - begining the push soonest.


[00:10] <davecheney> thumper: menn0 waigani i've been working on some visualisation tools to help me
[00:10] <davecheney> https://twitter.com/davecheney/status/534135954420678656
[00:10] <davecheney> here is an example
[00:10] <davecheney> dealing with something the size of juju/state is still daunting
[00:10] <waigani> nice!
[00:10] <davecheney> that is cmd/juju
[00:10] <davecheney> sorery
[00:10] <davecheney> cmd/go
[00:11]  * menn0 is still waiting for twitter to load the image
[00:12] <waigani> davecheney: is that d3?
[00:12] <menn0> wow that's awesome
[00:12] <menn0> what are you using to do the rendering?
[00:13] <davecheney> waigani: d3js.org
[00:13] <waigani> thought so
[00:26] <davecheney> http://imgur.com/t57nMob
[00:26] <davecheney> ^ juju/state
[00:26] <waigani> menn0: can I talk over the allwatcher store with you? I can see two ways to go
[00:26] <davecheney> http://imgur.com/3oErTdQ
[00:26] <davecheney> juju state, from the perspective of mgo/v2
[00:26] <waigani> davecheney: omg...
[00:28] <menn0> waigani: i was about to go for lunch...
[00:28] <menn0> waigani: did you want to hangout/
[00:28] <waigani> menn0: should be a quick question
[00:28] <waigani> menn0: standup hangout?
[00:28] <menn0> waigani: ok
[00:30] <davecheney> http://i.imgur.com/ioxieyg.png
[00:30] <davecheney> something to consider with the juju/version pacakge
[00:33] <davecheney> http://imgur.com/d9xNtae
[00:33] <davecheney> who's using loggo, and who isnt ...
[00:35] <thumper> davecheney: so the picture is showing what?
[00:35] <thumper> what are the lines?
[00:35] <thumper> and how do you know?
[00:35] <thumper> is there meaning to the relative thickness?
[00:36] <davecheney> thumper: it's a bit hard to tell
[00:36] <thumper> davecheney: it is almost like you need two graphs rather than one
[00:36] <davecheney> i stole most of the code from an example comparing people who like different hair color
[00:36] <davecheney> i'll keep working on it tonight
[00:37] <thumper> kinda cool picture though
[00:37] <davecheney> at leats it tells me who is relaed to what
[00:37]  * thumper nods
[00:37] <davecheney> like juju/version imports bson ...
[00:38] <davecheney> http://imgur.com/UKYv5j3
[00:38] <davecheney> this is all the things that importing juju/version brings in
[00:39] <davecheney> which seems excessive
[00:39] <davecheney> like why does juju/version depend on sync ...
[00:40] <davecheney> http://imgur.com/nmfRE4r
[00:45] <anastasiamac> davecheney: these look pretty!
[00:45] <anastasiamac> davecheney: are they available on the fly?
[00:45] <anastasiamac> davecheney: kinf of like "graph usage of blah"?
[00:46] <anastasiamac> s/kinf/kind
[00:48] <davecheney> anastasiamac: go get github.com/davecheney/junk/glyph
[00:48] <davecheney> $GOPATH/bin/glyph
[00:48] <davecheney> then go to localhost:8080/chord/cmd/go
[00:48] <davecheney> it works just like godoc, the first url is the visualisation, the rest is a package path to start from
[00:48] <davecheney> be warned
[00:48] <davecheney> it is very very slow
[00:48] <davecheney> took two minutes to generate the first image
[00:49] <anastasiamac> davecheney: it's monday... i feel slow too :-)
[00:49] <davecheney> i'm doing to much processing in the browser
[00:49] <davecheney> i need to offload that to the backend
[00:51] <anastasiamac> davecheney: thnx :-) visually seeing dependencies is enormously helpful!
[00:51] <davecheney> that's why i built this
[00:51] <davecheney> i need it to help me
[00:52] <thumper> davecheney: juju/version brings in io (to read the file), io brings in sync
[00:52] <thumper> davecheney: easy to pull in heaps
[00:52] <davecheney> versino is also bringing in sync directly
[00:52] <davecheney> which is odd
[00:53] <davecheney> hmm
[00:53] <davecheney> no it isnt
[00:53] <davecheney> ok
[00:53] <davecheney> i screwed up
[00:53] <davecheney> doesn't surprise me
[01:03] <thumper> davecheney: just checking that we both aren't sitting in a different hangout with the same name
[01:03] <thumper> google gets things wrong occasionally
[01:04] <davecheney> thumper: nope, my bad
[01:04] <davecheney> i ingored the reminder
[01:04] <davecheney> be there in a sec
[01:21] <davecheney> thumper: http://godoc.org/github.com/juju/juju/state?import-graph
[01:23] <davecheney> thumper: http://imgur.com/TT3xgeD
[01:25] <davecheney> thumper: http://imgur.com/2iKJC2O
[01:58] <thumper> davecheney: https://github.com/juju/errors/pull/13
[01:58]  * thumper takes broken kid to physio
[02:41] <menn0> waigani: http://reviews.vapour.ws/r/471/ reviewed
[03:30] <axw> wallyworld_: when you have a minute, can you PTAL at http://reviews.vapour.ws/r/442/
[03:30] <wallyworld_> sure
[03:31] <axw> wallyworld_: I've parameterised the function to list block devices in worker/diskmanager.NewWorker
[03:31] <axw> with a default
[03:31] <axw> jujud tests now override that default
[03:38] <wallyworld_> axw: looks good, now tests will pass in a container
[03:40] <axw> yep
[03:40] <axw> thanks
[03:49] <waigani> menn0: thanks for the review. testing the constraints upgrade, I've expected three records because there is a preexisting environment constraints doc
[03:49] <waigani> menn0: i.e. it has a local i.d. of "e" - the global env key
[03:51] <thumper> wallyworld_: hey, can I get you to look at this for me? https://github.com/juju/loggo/pull/7/files
[03:51] <wallyworld_> sure
[04:00] <wallyworld_> thumper: the location stuff is just for tests to avoid hard coding line numbers?
[04:00] <thumper> wallyworld_: exactly
[04:00] <thumper> stolen from the errors tests, which I got from rog
[04:00] <wallyworld_> can you add a doc comment then so the next person doesn't need to fiure it out?
[04:00] <thumper> sure
[04:00] <wallyworld_> also, i think then the test commnt is wrong
[04:00] <wallyworld_> as it still mentions line number fragility
[04:01] <thumper> ah... will fix
[04:04] <thumper> wallyworld_: changes pushed
[04:04] <wallyworld_> +1
[04:05] <thumper> cheers
[04:10] <menn0> waigani: of course... I didn't think of that
[04:13] <waigani> menn0: cool, so good to ship?
[04:13] <menn0> I think so
[04:14] <menn0> just wondering if the test should check that the "e" key is still in good shape post migration
[04:14] <menn0> waigani: ^
[04:14] <waigani> menn0: shesh, just caught me - mouse was over the 'commit' button
[04:15] <thumper> wallyworld_: and a useful one: https://github.com/juju/loggo/pull/6/files
[04:16] <menn0> waigani: it's probably ok
[04:16] <waigani> menn0: I do check that in TestAddEnvUUIDToConstraintsIdempotent
[04:16] <waigani> menn0: so it is covered. good enough?
[04:17] <menn0> waigani: so you do. that's great then. can you just add a comment with the assertion that check for a length of 3 to avoid confusion
[04:17] <menn0> waigani: then merge away
[04:17] <waigani> menn0: will do
[04:18] <menn0> thumper: so State.NewEnvironment doesn't give you an environment you can do anything with
[04:18] <thumper> no
[04:18] <thumper> menn0: it just adds an environment into the collection
[04:18] <thumper> menn0: happy if you want to change that
[04:18] <thumper> menn0: it probably isn't used in many places
[04:18] <wallyworld_> thumper: so how to developers decide to use the Stack vs non Stack variants of the various log methods
[04:19] <wallyworld_> shouldn't they just use Warningf() and a log setting decides
[04:19] <thumper> wallyworld_: if you are logging a message, you go `logger.Infof("some garbage")`
[04:19] <menn0> thumper: it isn't used anywhere, except tests
[04:19] <thumper> wallyworld_: the InfoStackf takes an error as the first param
[04:20] <thumper> wallyworld_: magical introspection of the args... params would be a bit too magic
[04:20] <menn0> thumper: so basically we need Initialize (in open.go) to happen afterwards right?
[04:20] <thumper> wallyworld_: if you want the error stack logged, call the stack message
[04:20] <thumper> menn0: if you want to use it, yes
[04:20] <wallyworld_> ok
[04:20] <wallyworld_> i'm not sure then we need all the variants
[04:21] <thumper> wallyworld_: there are many many occurrances of logging where we go `logger.Warningf("something horrible: %v", err)`
[04:21] <wallyworld_> would we really want to see a stack trace for an Info message
[04:21] <thumper> I'm thinking that it would be `logger.WarningStackf(err, "something horrible")`
[04:21] <thumper> wallyworld_: I don't want to make that call
[04:21] <thumper> wallyworld_: someone may want a stack at a different level
[04:22] <wallyworld_> if they need stack trace with an info there's something wrong
[04:22] <wallyworld_> but ok
[04:22] <wallyworld_> i think this will be absed
[04:23] <thumper> abused?
[04:23] <wallyworld_> yeah
[04:23] <thumper> I'm not sure.. I guess time will tell
[04:23] <menn0> thumper: Initialize doesn't quite work as it dials it's own mongo connection and create its own uuid etc
[04:23] <wallyworld_> our log output will become oven more of a firehose
[04:23] <thumper> I have a better one coming
[04:23] <menn0> thumper: I will do some refactoring
[04:23] <thumper> menn0: ack
[04:24] <wallyworld_> thumper: what do we do when our log files are full of stack traces and even harder to read than they are now
[04:25] <thumper> wallyworld_: I think this becomes one of those pragmatic things, don't record a stack for an expected error
[04:26] <wallyworld_> i think we need x-team collaboration or a policy that reviewers are aware of so that this will not be misused
[04:27] <wallyworld_> clear guidelines on what an "expected" error is
[04:27] <wallyworld_> what's the driver for this?
[04:27] <wallyworld_> is there an issue that is being solved?
[04:30] <thumper> one of the issues was our logging, and that I was looking for occurrances of ": %v" in the codebase
[04:30] <thumper> I saw that many were to log errors
[04:30] <thumper> we now catch error stack info which is important for debugging
[04:30] <thumper> that was the rationale
[04:31] <thumper> wallyworld_: along with this one: https://github.com/juju/testing/pull/38/files
[04:31] <wallyworld_> i content you don't need the error stack 99% of the time
[04:32] <wallyworld_> and if you do, it is for debugging, and not warning or error or info output
[04:32] <wallyworld_> i have very rarely if ever wished to have the stack trace when debugging a juju issue
[04:32] <thumper> hmm...
[04:33] <wallyworld_> sorry for being -1 on this, i just see a whole lot of extra logging for little benefit
[04:33] <wallyworld_> but that's just IMHO
[04:34] <thumper> I'm happy to hold off landing that one until we talk as a team through it more
[04:34] <thumper> I can take it to the list
[04:34] <wallyworld_> i'd personally be happier if this were a trace level thing that could be turned on when needed
[04:34] <thumper> but probably tomorrow
[04:34] <thumper> wallyworld_: or just a separate method:
[04:34] <thumper> logger.StackTrace(err)
[04:34] <thumper> although...
[04:34] <wallyworld_> so long as it can be turned on/off
[04:34] <thumper> I had thought of having other helper methods:
[04:35] <thumper> one to get a limited stack trace of where you are
[04:35] <thumper> the other to get the stack trace of the error you have
[04:35] <wallyworld_> this could be useful when developing (not foe me, but others might like it)
[04:36] <wallyworld_> but it should not get into our std log output by default
[04:36] <wallyworld_> happy to concede if the majority want it
[04:36] <thumper> I'll take this one to the list
[04:36] <wallyworld_> ta
[04:36] <thumper> the other is `jc.IsNil`
[04:36] <wallyworld_> ok
[04:37] <thumper> which does " if not nil, and it is an error, and it has a StackTrace method, show the stack trace in the test fail message"
[04:37] <wallyworld_> now, that is useful
[04:37] <thumper> which I have wanted for a while
[04:38]  * thumper goes to make dinner for the little beings that live at his house
[04:50] <wwitzel3> axw: can you take a look at https://github.com/juju/juju/pull/1157
[04:50] <axw> looking
[04:54] <axw> wwitzel3: I can't spot the problem that was fixed - can you please describe?
[04:54] <wwitzel3> axw: well this was actually done before you merge landed adding in the break.
[04:56] <waigani> wtf?
[04:56] <axw> wwitzel3: so is this really necessary then? there are tests for zone selection already, TestStartInstanceDistribution.*
[04:57] <waigani> I just merged trunk and pushed my diff up to RB. What should be a four line diff has turned into a 400 line diff.
[04:57] <axw> also, the "continue" in the refactored function should still do an index check, otherwise the message is wrong on the last iteration
[04:57] <waigani> http://reviews.vapour.ws/r/473/diff/
[04:57] <wwitzel3> axw: well I think the refactor is better, since it extracts the concern out of a big monolithic method and helps to isolate the testing :)
[04:58] <waigani> other than the megawatcher changes, none of those changes are mine.
[04:58] <axw> wwitzel3: yes, that is a fair point
[04:58] <waigani> from this branch at least
[04:58] <wwitzel3> axw: yeah, I think that got clipped out in a merge, I just noticed that
[04:59] <wwitzel3> axw: I wanted you to give me a review on it since you did the code, but I'd stil like to land it
[04:59] <axw> wwitzel3: sure. LGTM with the continue condition readded
[05:01] <davecheney> http://imgur.com/94R6MwG
[05:01] <davecheney> the agent package is a bit of a beast
[05:01] <wwitzel3> axw: on the condition, is can I use <= instead of i+1 < ?
[05:01] <axw> wwitzel3: that's fine with me
[05:02] <wwitzel3> axw: k, yeah, that is what I changed, but I think I foobar'd a merge and ended up squashing the entire if block :/
[05:02] <axw> davecheney: looks like a DHT; it's got some extra deps in case someone removes one ;)
[05:04] <wwitzel3> axw: thanks, addressed both of those
[05:05] <axw> wwitzel3: thanks for making it better :)
[05:05] <axw> wwitzel3: did you figure out that latest MAAS provider bug btw? last I looked you couldn't repro
[05:10] <waigani> menn0: something between git, github and RB crapped itself along the way, so new PR: http://reviews.vapour.ws/r/474/
[05:21] <wwitzel3> axw: yeah, the bug was their code didn't have the back port of the "break" yet.
[05:21] <wwitzel3> axw: so instead of stopping after finding the right zone, it just kept running until the last zone.
[05:21] <wwitzel3> axw: and it just happened their last zone was full
[05:22] <wwitzel3> axw: I couldn't repo at first because my last zone had a free slot.
[05:23] <axw> wwitzel3: ahh I see, thanks
[05:28] <wwitzel3> axw: now I just have to figure out why my test fails on the bot , but works locally :( .. sad day, guess I will save that for tomorrow
[05:31] <axw> wwitzel3: nothing jumps out
[06:09] <anastasiamac> axw: could u plz clarify juju convention when creating pair of corresponding commands?
[06:09] <anastasiamac> axw: do they sit in one file like in environment.go - set/unset
[06:10] <anastasiamac> axw: do they sit in different files like addmachine.go and removemachine.go?
[06:10] <axw> anastasiamac: I think most people prefer one command per file
[06:10] <anastasiamac> axw: sorry ;-(
[06:10] <anastasiamac>  set/get for environment
[06:11] <anastasiamac> axw: k.. one file  is gr8 ;-)
[06:11] <anastasiamac> axw: thnx
[06:11] <axw> anastasiamac: nps
[06:11] <anastasiamac> axw: so where would u put shared functionality?
[06:12] <anastasiamac> axw: i'd like to avoid duplicate code
[06:12] <axw> anastasiamac: I'd just stick all common functionality in one or the other, doesn't matter which... just as long as it's together
[06:13] <anastasiamac> axw: k. sure :-) thnx
[07:10] <wallyworld_> jam: you ok for the juju status meeting later?
[07:28] <jam> wallyworld_: I should be able to be around
[07:29] <wallyworld_> great, we need to get the spec approved, and there's a fair bit of disagreement
[07:31] <axw> dimitern: why does goamz use a different API version for RunInstances when specifying VPC attributes? were you being paranoid, or is there actually different behaviour?
[07:32] <dimitern> axw, because the VPC API is a newer version than the classic api it otherwise uses
[07:32] <dimitern> axw, and yes, I was being a bit paranoid :)
[07:32] <axw> dimitern: I realise.. I meant, why not use the newer version on all
[07:32] <axw> ok
[07:33] <axw> dimitern: I'm just asking because I'm going to have to bump the version we use to support allocating additional EBS volumes
[07:34] <dimitern> axw, sure, if you need to, but please sync up with niemeyer
[07:34] <axw> dimitern: will do
[07:48] <jam> wallyworld_: any news about the remaining critical bugs ? Do you need some extra manpower to work on them ?
[07:49] <jam> like https://bugs.launchpad.net/juju-core/+bug/1392544 isn't assigned yet
[07:49] <mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544>
[07:49] <wallyworld_> jam: i poked tim about bug 1392745 as i suspect he'll be across it, but he deferred till tomorrow
[07:49] <mup> Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745>
[07:50] <wallyworld_> the local provider one i'm going to start looking at
[07:50] <wallyworld_> the default value one is not assigned yet, if you had someone who could look that would be good
[07:50] <wallyworld_> otherwise i'll do tomorrow
[07:50] <jam> wallyworld_: k, if you want someone on my team, I'm perfectly happy having us polishing a release branch
[07:51] <wallyworld_> ok, thanks, maybe the default value one then
[07:52] <mattyw> morning all
[07:53] <jam> wallyworld_: k, I'm not sure if they'll get up to speed before someone like Tim could fix it, but I can get them started.
[07:54] <wallyworld_> jam: tim will do the 1.20.11 juju run one
[07:55] <wallyworld_> i haven't look in default at the default value one
[07:55] <wallyworld_> in detail
[07:55] <jam> ah, ok
[07:56] <wallyworld_> bug 1392544 should just be some generic snafu maybe
[07:56] <mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544>
[07:56] <jam> wallyworld_: yeah. It looks like something is casting everything to a generic boolean type
[07:57] <jam> wallyworld_: I've tasked dimitern with it
[07:57] <wallyworld_> the other one - the local provider log issue - is likely tim's aread also, but i'll did into it
[07:57] <wallyworld_> ty
[07:57] <wallyworld_> and the maas one is well in hand
[08:03]  * fwereade_ was up late last night, is going for a bit of a walk before he starts properly
[08:22] <axw> fwereade_: when you have started, if you have some time would you please take a glance over https://github.com/juju/charm/pull/77? doesn't need to be a full review, but I'd like to know if you have had differing thoughts on how the storage metadata should look
[10:00] <dimitern> fwereade_, ping
[10:00] <fwereade_> dimitern, pong
[10:01] <dimitern> fwereade_, re https://bugs.launchpad.net/juju-core/+bug/1392544 - what's the purpose of the "default: true|false" field in juju get svcname output?
[10:01] <mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged by dimitern> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544>
[10:02] <fwereade_> dimitern, it tells you whether it's that value because [nothing was set, and it will therefore change if there's a charm upgrade that changes the default] or [that's the actual value that was explicitly set, even if it happens to match the default, and will persist so long as there's a matching config entry]
[10:02] <jam> TheMue: voidspace: standup ?
[10:03] <dimitern> fwereade_, so if "default: true" it means yeah the respective config setting is not set (i.e. uses the default value) ?
[10:03] <fwereade_> dimitern, yeah
[10:04] <fwereade_> dimitern, looking at that bug I suspect it's a documentation issue more than anything
[10:04] <dimitern> fwereade_, it seems to me as well, but I'll do a quick test to make sure we don't set default: true for non-default values
[10:04] <fwereade_> dimitern, thanks
[10:04] <fwereade_> dimitern, don't close the bug without fixing the docs, though, please :)
[10:04] <voidspace> jam: oops
[10:04] <voidspace> jam: omw
[10:04] <dimitern> fwereade_, sure
[10:05] <fwereade_> dimitern, <3
[10:06] <jam> fwereade_: so for compat reasons, can we ever change that to "is-default" rather than "default" confusing people ?
[10:08] <fwereade_> jam, yes and no. no for `juju get`; yes for `juju service get`, which I'll need to sync up with thumper on
[10:09] <fwereade_> jam, however, for `juju service get` we really want the default output to be something we can pass back into `juju service set`
[10:09] <fwereade_> jam, so a sane implementation would probably just skip the ones with default values
[10:09] <fwereade_> jam, and a --schema flag or something could tell you what the defaults were
[10:10] <jam> fwereade_: we *could* have that as "--as-set" or some other flag that indicates the output you want. I think you *do* sometimes want to see what the value is, even if you haven't set it
[10:10] <fwereade_> jam, that is not perfect for sure
[10:10] <jam> I've used it often to figure out what I *could* set
[10:10] <fwereade_> jam, I agree we do
[10:10] <jam> fwereade_: you'd prefer the minimal form as the default output ?
[10:10] <fwereade_> jam, but the asymetry between get and set is really kinda nasty
[10:11] <fwereade_> jam, I *think* so, yeah -- in my mind the main tension is in what happens if you get, upgrade, set
[10:11] <fwereade_> jam, and whether that final set shoudl change values or not
[10:11] <fwereade_> jam, (assuming it's not rendered irrelevant by the original get having values that are invalid/unknown post-upgrade
[10:11] <fwereade_> )
[10:12] <fwereade_> jam, not saying it should be *hard* to see the possibilities, but I don't think it's the *most* important thing
[10:13] <jam> fwereade_: well, I do think it is the primary use case of get, isn't it ? (what are all the current settintgs)
[10:13] <jam> fwereade_: or do you feel it is more the way you transfer settings to some other place
[10:14] <fwereade_> jam, `get --all` feels appropriate for "and include the defaults please" -- it's more consistent with charm-side config-get apart from anything else
[10:15] <fwereade_> jam, and `get --schema` feels appropriate for "tell me what the possible keys and their meanings are"
[10:15] <fwereade_> jam, and I'm not automatically opposed to some nice human-readable combination of the two
[10:15] <fwereade_> jam, but it feels like a lot of disparate info to cleanly fit into the default output
[10:16] <fwereade_> jam, that's what we signally failed to do with the current implementation ;)
[10:26] <perrito666> morning
[10:29] <dimitern> fwereade_, so it does work - setting a service config setting to a non-default value causes juju get svcname to *not* include "default: true" for that setting
[10:30] <fwereade_> dimitern, that's good anyway
[10:30] <fwereade_> dimitern, not really much less confusing
[10:30] <fwereade_> dimitern, but at least working as intended
[10:31] <dimitern> fwereade_, so what do you suggest to add to juju help get to clarify the behavior?
[10:31]  * fwereade_ looks at documentation for `juju get`
[10:32] <fwereade_> dimitern, um, some documentation ;p
[10:32] <dimitern> fwereade_, because this is what I think the "fix" for that bug
[10:32] <fwereade_> dimitern, concur
[10:32] <dimitern> fwereade_, barely :)
[10:32] <fwereade_> dimitern, seriously, all it has is a "purpose"
[10:32] <fwereade_> dimitern, give it a Doc as well
[10:32] <dimitern> fwereade_, yeah, a lot of commands (simpler ones) are like that
[10:32] <fwereade_> dimitern, indeed
[10:33] <fwereade_> dimitern, this is not actually a good thing ;)
[10:33] <dimitern> fwereade_, ok, I'll describe the output in the Doc of get
[10:35] <fwereade_> dimitern, cool, thanks
[11:33] <dimitern> fwereade_, trivial review (mostly proof-reading I guess) ? https://reviews.vapour.ws/r/477/diff/
[11:35] <fwereade_> dimitern, ship it
[11:35] <dimitern> fwereade_, cheers!
[11:35] <fwereade_> dimitern, hey, btw, apparently malta played football against bulgaria and didn't lose, I feel quite unwarrantedly smug on behalf of my place of residence
[11:36] <dimitern> fwereade_, :) yeah, I've heard of that
[11:36] <dimitern> fwereade_, and also BG won 2nd place in the kids eurovision in malta
[11:36] <fwereade_> dimitern, cool, I didn't know that until today either :)
[11:37] <dimitern> fwereade_, btw can you actually click on Ship it! ? :)
[11:37] <dimitern> fwereade_, ah, sorry - I've just seen it, it must've been lagging behind
[11:42] <dimitern> niedbalski, ping
[11:47] <dimitern> voidspace, jam, can any of you please approve https://reviews.vapour.ws/r/478/ ? it's the same fix for bug 1392544, this time for master
[11:47] <mup> Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1392544>
[11:49] <voidspace> dimitern: looking
[11:49] <dimitern> voidspace, ta
[11:51] <voidspace> dimitern: lgtm
[11:51] <dimitern> voidspace, thanks
[11:53] <dimitern> voidspace, did you click "Ship It!" btw?
[11:53] <voidspace> dimitern: yes
[11:54] <voidspace> dimitern: I really did
[11:54] <voidspace> dimitern: I've done it twice, but it doesn't seem to be showing up
[11:54] <dimitern> voidspace, yeah, weird...
[11:54] <voidspace> dimitern: I got an "untrusted connection" warning when I went to RB too
[11:54] <dimitern> voidspace, anyway, ta, I'll ping eric later about this
[11:55] <voidspace> dimitern: if I use http it works
[11:55] <voidspace> dimitern: https fails
[11:55] <voidspace> odd
[11:55] <voidspace> dimitern: Ship It! now visible anyway
[11:56] <dimitern> voidspace, ha! I've seen this as well - using https I had to add an exception because the cert was self-signed most likely
[11:56] <voidspace> dimitern: yeah, I added the exception ok
[11:56] <voidspace> dimitern: but if I use https then ship it doesn't work
[11:57] <dimitern> voidspace, really odd
[11:57] <voidspace> rogpeppe3: ping
[11:57] <voidspace> rogpeppe2: ping
[11:57] <voidspace> rogpeppe1: ping
[11:57] <rogpeppe3> voidspace: pong
[11:57] <voidspace> rogpeppe3: hello Roger
[11:57] <rogpeppe> voidspace: hiya
[11:57] <voidspace> rogpeppe: morning
[11:57] <rogpeppe> voidspace: how's it going?
[11:57] <voidspace> rogpeppe: is there a tool for applying changes  to go code that works by ast rewriting
[11:57] <voidspace> rogpeppe: like "go fix" but a general tool
[11:57] <rogpeppe> voidspace: gofmt :)
[11:58] <voidspace> rogpeppe: ah!
[11:58] <voidspace> rogpeppe: cool, thanks
[11:58] <rogpeppe> voidspace: check out gofmt -r
[11:58] <voidspace> rogpeppe: all is good, how's you?
[11:58] <rogpeppe> voidspace: but it depends what you want to do
[11:58] <voidspace> rogpeppe: do I need "gofmt" rather than "go fmt"
[11:58] <rogpeppe> voidspace: excellent, thanks
[11:58] <rogpeppe> voidspace: go fmt invokes gofmt
[11:58] <voidspace> rogpeppe: I want to rename an Interface method and all uses
[11:58] <voidspace> rogpeppe: ah, ok - I understood there were some historical differences
[11:59] <rogpeppe> voidspace: you possibly want to (brand new) gorename tool actually
[11:59] <rogpeppe> voidspace: the interface to go fmt is in terms of packages; the interface to gofmt is stdin/stdout and files
[11:59] <voidspace> rogpeppe: ok
[12:00] <rogpeppe> voidspace: i haven't succeeded in using it on a large code base yet though
[12:00] <voidspace> rogpeppe: ah :-)
[12:00] <rogpeppe> voidspace:  but take a look at https://groups.google.com/forum/#!topic/golang-nuts/96hGPXYfqsM
[12:00] <voidspace> rogpeppe: I'm there already
[12:00] <rogpeppe> voidspace: if the method name is distinctive, then gofmt -r will probably do your job ok
[12:05] <voidspace> hmmm... gorename can't find the environs package it seems
[12:05] <voidspace> I'll try go fmt
[12:05] <wallyworld> jam: meeting?
[12:05] <jam> wallyworld: omw
[12:06] <jam> wallyworld: .... firefox just froze, be there in a sec
[12:06] <wallyworld> np
[12:23] <voidspace> dimitern: when you get a chance http://reviews.vapour.ws/r/479/
[12:23] <voidspace> dimitern: it builds fine (so is probably correct), just running all tests
[12:23] <voidspace> dimitern:  I used gofmt, but ended up having to use sed to fix comments (and then manually unfix some of things sed did)
[12:24] <voidspace> dimitern: so I might as well just have started with sed...
[12:26] <dimitern> voidspace, :) ok, looking
[12:27] <voidspace> dimitern: ooh
[12:27] <voidspace> dimitern: "Subnets returns basic information about all networks known"
[12:27] <voidspace> dimitern: should probably be
[12:28] <voidspace> dimitern: Subnets returns basic information about all subnets known
[12:28] <voidspace> dimitern: I'll make that change
[12:28] <dimitern> voidspace, yeah, I've just added a comment for this
[12:29] <voidspace> dimitern: pushed
[12:29] <voidspace> dimitern: I don't think you've published that comment yet anyway
[12:30] <dimitern> voidspace, LGTM, just sent my comment
[12:30] <voidspace> dimitern: cool, thanks
[13:04] <dimitern> voidspace, a bit of a problem
[13:04] <dimitern> voidspace, did you remember to rename ListNetworks to Subnets in environs/interface.go ?
[13:05] <dimitern> voidspace, because I see lots of build errors like *joyentEnviron does not implement environs.Environ (missing ListNetworks method)
[13:05] <dimitern> voidspace, I can't even say how this managed to land, because it does not build :)
[13:24] <dimitern> voidspace, ah, sorry - something was messed up with my local git repo - now it seems to work and there are no failures
[14:11] <sinzui> wwitzel3, is bug 1392390 not fix committed in master?
[14:11] <mup> Bug #1392390: maas zone selected for deployment that is occupied <cloud-installer> <landscape> <maas-provider> <placement> <regression> <juju-core:Fix Committed by wwitzel3> <juju-core 1.21:In Progress by wwitzel3> <https://launchpad.net/bugs/1392390>
[14:12] <rogpeppe> fwereade_: do we check anywhere that a charm must have an install and/or a start hook?
[14:12] <fwereade_> rogpeppe, nope
[14:13] <rogpeppe> fwereade_: ok, cool
[14:13] <rogpeppe> fwereade_: i could've sworn it did, but couldn't find the code
[14:13] <wallyworld> wwitzel3: is nate around?
[14:19] <jw4> mgz, wallyworld out of disk space on CI build server?
[14:20] <wallyworld> jw4: just retry
[14:20] <jw4> kk
[14:20] <jw4> tx wallyworld
[14:20] <wallyworld> happens sometimes :-(
[14:20] <jw4> :)
[14:21] <wallyworld> perrito666: when wwitzel3 or nate are around, could you mention bug 1392602 - i cannot find wtf is happening. it could be related to recent logging work, but i'm not sure. maybe they will have an idea
[14:21] <mup> Bug #1392602: local provider agent fails to restart on reboot of host - log dir missing <local-provider> <lxc> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1392602>
[14:37] <mgz> jw4: it's still not clear what triggers that failure... but just retrying works
[14:38] <jw4> mgz: yeah weird.  I've $$retried$$ and so far it's looking good
[14:38] <jw4> mgz: tx
[14:39] <jw4> mgz: derp... now I get "failed to find "mongod"
[14:39] <mgz> >_<
[14:39] <voidspace> fun
[14:39] <mgz> jw4: I'll investigate, also seems like an 'ec2 is ill' type of issue
[14:39] <jw4> bummer
[14:40] <jw4> thx mgz
[14:40] <jw4> mgz: shall I $$retry$$ or wait?
[14:40] <mgz> jw4: this one is just "no reachable servers" no? an intermittent test failure.
[14:40] <jw4> mgz: yeah
[14:41] <mgz> though... I agree I've not seen MongoSuite.TestAddRemoveSet fail quite like that before
[14:43] <jw4> mgz: lol it was because the build number was '1337'
[14:43] <jw4> ;)
[14:43] <mgz> http://paste.ubuntu.com/9057111/
[14:43] <mgz> jw4: send it through again
[14:44] <jw4> k
[14:49] <wwitzel3> sinzui: it is fix commited in master, I am getting the patch up for 1.21 now, not sure how it go reverted in lp, probably my fault :)
[14:49] <sinzui> wwitzel3, thank you for following up
[14:57] <perrito666> wwitzel3: natefinch ericsnow Ill be a couple of mins later, I am hogging my bw with a deploy
[14:58] <natefinch> k
[15:05] <natefinch> wwitzel3: ping?
[15:05] <wwitzel3> natefinch: yep, sorry
[15:16] <sinzui> natefinch, I think bug 1392745 needs to attention, can you find someone to look into it? I amd jjo can gather information as needed
[15:16] <mup> Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745>
[15:16] <sinzui> natefinch, and I can offer access the the juju-ci3 env if someone needs to be on an affected env
[15:17] <mgz> jw4: you're a lucky one today
[15:17] <mgz> latest run, not seen a failure on this test before...
[15:17] <mgz> FAIL: metricmanager_test.go:20: MetricManagerSuite.TestRunner
[15:17] <mgz> looks like it's timing dependent though
[15:22] <mgz> jw4: test you added, so probably needs fixing?
[15:23] <mgz> wait... is that run not yours? I am confused
[15:23] <mgz> mattyw: ^
[15:24] <mattyw> mgz, ah shit - I'll take a look, didn't realise that test had landed yet - probably only landed 10 minutes ago
[15:24] <jw4> hmm; I'll investigate... I don't think it was mine
[15:25] <mattyw> mgz, jw4 it's all good
[15:25] <mattyw> mgz, jw4 it's failed trying to land the branch that test was added in - so the tests are doing their job
[15:25] <jw4> mattyw: cool, tx!
[15:25] <jw4> I'll try mine again for the fourth time
[15:26] <mattyw> jw4, I don't think you'd have seen that error? looks like my branch hasn't landed
[15:26] <jw4> mattyw: right - my integration builds were failing due to space issues on the ci server
[15:27] <mgz> yeah, I'd just assumed the in-progress landing was jw4's again, but it was mattyw's, hence the confusion, sorry :)
[15:27] <jw4> mgz: no worries - nice chat :)
[15:28]  * perrito666 is told that amazon will actually ship ram to his country without the 1 month wait in customs and he grins
[15:28] <mgz> perrito666: real live rams?
[15:29] <perrito666> mgz: well, they will be alive when shipped
[15:36] <perrito666> rick_h_: btw, I loved the composition on rog/uros pic on your post
[15:37] <rick_h_> perrito666: ty :) was playing with my fancy lens during the sprint a lot
[15:58] <voidspace> anyone here familiar at all with gomaasapi ?
[15:59] <perrito666> voidspace: I have been around there but most likely dont hve enough info to help youi
[15:59] <voidspace> perrito666: :-)
[15:59] <voidspace> perrito666: I need to call the api to claim a static ip address
[15:59] <perrito666> voidspace: just ask the question and we can see
[15:59] <voidspace> I am doing...
[16:00] <voidspace> perrito666: I believe it looks like the following
[16:00] <voidspace> ipaddresses := environ.getMAASClient().GetSubObject("ipaddresses")
[16:00] <voidspace> _, err = ipaddresses.CallPost("", params)
[16:00] <voidspace> (response is not useful - either it succeeds or we get an error)
[16:00] <voidspace> perrito666: it's that empty string as the first argument to CallPost that bothers me
[16:00] <voidspace> perrito666: that's the "operation" parameter
[16:00] <voidspace> perrito666: but there's no operation here
[16:00] <perrito666> voidspace: ah I have dealt with it
[16:01] <voidspace> it's a post to the ipaddresses api end point
[16:01] <voidspace> perrito666: right - have you called any endpoints without operations?
[16:01] <perrito666> voidspace: you are dealing with a restful api there you not always have an op
[16:01] <voidspace> it looks odd
[16:01] <voidspace> perrito666: right
[16:01] <voidspace> I guess I have to try it :-)
[16:01] <voidspace> perrito666: I have a working maas server - I'll whip up some code to check it
[16:01] <voidspace> perrito666: thanks anyway
[16:02] <perrito666> voidspace: so iirc that translates to /path/to/node?operation
[16:02] <voidspace> perrito666: this particularcall is directly paddresses/
[16:03] <voidspace> no operation and no node id
[16:03] <perrito666> voidspace: ahh addresses yes, that one is specially ugly
[16:03] <perrito666> hold a sec, I was around there not long ago
[16:03] <voidspace> perrito666: ooh, I might be wrong
[16:03] <voidspace> perrito666: the GET is without an operation
[16:03] <voidspace> perrito666: looks like it's "reserve"
[16:03] <voidspace> POST /api/1.0/ipaddresses/ op=reserve
[16:04] <voidspace> my mistake then :-)
[16:04] <perrito666> voidspace: you did look at http://maas.ubuntu.com/docs/api.html#ip-addresses right?
[16:04] <voidspace> perrito666: I did...
[16:04] <voidspace> perrito666: I think I looked at the GET by mistake :-D
[16:04] <voidspace> just looked now and seen "reserve" is the op...
[16:04] <voidspace> perrito666: thanks
[16:05] <perrito666> voidspace: heh yes, happened to me too :p also there are a few with similar names so beware of not getting the wrong endpoint :p
[16:47] <katco> hey, go question: with a map, do you think it would be better to delete keys, or nil out their values? i would think that if the key had a good chance of being re-inserted, you'd want to nil out the value so the hash wouldn't continually be recomputed. thoughts?
[16:48] <mgz> katco: if it's not a giant map, I wouldn't worry about resizing
[16:49] <mgz> so, likely deleting makes better logical sense and is less likely to result in surprising bugs
[16:49] <katco> mgz: kind of thinking that as well
[16:49] <katco> mgz: b/c i would expect for people to be checking for "ok", not != nil
[16:50] <mgz> yup
[16:50] <katco> cool, ty sir!
[16:50] <katco> mgz: you've given me the confirmation bias that upholds my world-view! ;)
[16:52] <mgz> :)
[16:53] <natefinch> katco: definitely delete.  Don't prematurely optimize... just do the most simple and straightforward thing .
[16:54] <katco> natefinch: i recognize and applaud your agreement with me.
[16:54] <katco> natefinch: seriously, thanks for chiming in ;)
[16:55]  * natefinch is the king of chiming in. ;)
[16:55] <katco> haha
[18:24] <voidspace> g'night all
[18:59] <bodie_> if I find that I keep needing to repeat myself with methods like map recursion, or a conformer for map keys, I would normally extract these into a library and import it.  but, I don't know how I would handle this with juju
[18:59] <bodie_> I expect importing a personal library would be unkosher
[19:06] <bodie_> who could tell me where to put such things?  e.g. a method for coercing map[interface{}]interface{} to map[string]interface{}
[19:07] <bodie_> I'm kinda tempted just to open a PR with a personal import and see if it flies :S
[20:07] <bodie_> it looks like charm master breaks its own tests
[20:09] <bodie_> rogpeppe, config_test line 408: YAML error: reflect: reflect.Value.Set using unaddressable value
[20:09] <bodie_> maybe it's an issue with my deps
[20:10] <bodie_> doesn't seem to be
[20:13] <bodie_> https://github.com/juju/charm/pull/80 rogpeppe
[20:13] <bodie_> one-line fix
[20:13] <bodie_> not sure if this is how it *should* work, but it patches the breakage
[20:18] <bodie_> ah
[20:18] <bodie_> I see
[20:19] <bodie_> my charm master is out of sync with upstream because my upstream is gopkg.in/juju/charm.v4
[20:21] <rogpeppe> bodie_: oops. looks like juju-core needs latest version of yaml package
[20:21] <rogpeppe> bodie_: i think it should anyway - if you could do that, i'd be happy :)
[20:22] <rogpeppe> bodie_: i'm not here BTW :)
[20:22] <bodie_> rogpeppe, ack, so tweak the charm or the deps?
[20:22] <bodie_> er, rogpeppe's IRC away bot
[20:26] <mgz> heads up for juju-core... talking about server moving to systemd, which means our dynamically upstart jobs will need adapting for vivid
[20:27] <ericsnow> thumper: ping
[20:27] <thumper> ericsnow: hey
[20:28] <ericsnow> thumper: I've addressed just about everything on http://reviews.vapour.ws/r/346/
[20:28] <thumper> ericsnow: ok, will look again
[20:28] <ericsnow> thumper: left one open issue
[20:28] <ericsnow> thumper: thanks
[20:40] <thumper> ericsnow: was trying to look at the differences, and all I get is empty files and errors: http://reviews.vapour.ws/r/346/diff/16-17/?page=2
[20:40] <thumper> ericsnow: I'm assuming rb shouldn't do this?
[20:42] <ericsnow> thumper: it's because the branch depended on another branch
[20:42] <thumper> ah
[20:42] <thumper> ericsnow: ship it!
[20:42] <ericsnow> thumper: try diff'ing between 14 (where you last reviewed) and the latest
[20:42] <ericsnow> thumper: okay!
[20:57] <katco> well. i now know that my machine does not like spawning 100,000 instances of this test.
[21:00] <bodie_> heh
[21:01] <bodie_> my machine doesn't like running the juju core tests at all :/ I'm still trying to determine why I keep getting a reversed port number in the firewaller test
[21:03] <katco> i didn't expect it to become completely unresponsive... i thought the kernel scheduler was better than that
[21:03] <katco> 608s before it started giving me back control lol
[21:04] <katco> kind of. ugh.
[21:06] <katco> or gosh... maybe it's the window manager...
[21:07] <katco> ssh is working fine
[21:07] <katco> cpu and mem aren't under load...
[21:17]  * thumper goes to lie down for a bit
[21:32] <waigani> thumper/menn0: after I take out the machineID and NetworkName from the openPorts doc, what should the localID of the doc look like?
[21:33] <waigani> right now it is: "m#<machineid>#n#<networkname>
[21:34] <waigani> if we update the quires to use the fields, should we let the localID just be generated by mongo?
[21:34] <cmars> bodie_, i've seen that firewaller bug as well, intermittently
[21:34] <cmars> bodie_, is it fairly repeatable for you?
[21:35] <cmars> bodie_, what version go compiler are you using
[21:35] <bodie_> cmars, I wouldn't call it repeatable, but I've seen it I think three times now
[21:35] <bodie_> cmars, 1.3.3
[21:35] <cmars> bodie_, i'm using 1.3, and mgz just mentioned this could be a map ordering issue
[21:35] <waigani> thumper/menn0: just looking at how portsGlobalKey is used ...
[21:36] <bodie_> cmars, that might make sense.  should be a SameContents, perhaps
[21:36] <mgz> would explain why bot and others havenb't seen it, small maps are deterministically ordered on 1.2
[21:36] <mgz> one of you needs to file a bug :P
[21:40] <cmars> bodie_, firewallerSuite.TestGetMachinePorts ?
[21:41] <bodie_> cmars, aye
[21:41] <cmars> bodie_, i'll open it
[21:41] <bodie_> much appreciated cmars, I'm already way over EOD trying to get something else landed
[21:48] <ericsnow> thumper: when would be a good time to talk about MESS and backups?
[22:15] <waigani> thumper/menn0: machineid and networkname need to be in the id for the watcher
[22:16] <menn0> waigani: sorry, I don't actually know what you're doing
[22:16] <thumper> waigani: I didn't say to take them out of the id
[22:16] <thumper> waigani: just make sure they are also available outside the id
[22:16] <menn0> waigani: why did you want to remove machineID and NetworkName from the openPorts doc?
[22:16] <waigani> thumper: right
[22:16] <thumper> like the envuuid
[22:16] <waigani> menn0: I misunderstood
[22:16] <menn0> ok
[22:22] <rogpeppe> bodie_: tweak juju-core deps
[22:24] <katco> wallyworld: "This webpage has a redirect loop"
[22:24] <katco> not sure what's going on
[22:24] <wallyworld> :-(
[22:24] <wallyworld> i'l try opening hangout again
[22:25] <katco> wallyworld: i bet this is that stupid cookies issue i was having
[22:25] <mgz> don't eat the stupid cookies!
[22:25] <wallyworld> chocolate chip?
[22:26] <ericsnow> perrito666: FYI, all four of those patches have now landed
[22:26] <perrito666> ericsnow: niiice, Ill start integration right away
[22:54] <menn0> thumper: how do you feel about NewEnvironment's signature changing from this:
[22:54] <menn0> NewEnvironment(env, server names.EnvironTag, owner names.UserTag, name string) (*Environment, error)
[22:54] <menn0> to this:
[22:54] <menn0> NewEnvironment(cfg *config.Config, server names.EnvironTag, owner names.UserTag, ownerPassword string) (*Environment, error)
[22:55] <thumper> so it creates an environment uuid?
[22:55] <thumper> why have ownerpassword?
[22:55] <thumper> and why remove the name?
[22:56] <menn0> the name comes from the config
[22:56] <menn0> ownerpassword is needed to set up the owner user
[22:56] <menn0> the uuid also comes from the config
[22:56] <menn0> thumper: ^
[22:56] <thumper> the owner must already exist
[22:57] <menn0> you're right
[22:57] <menn0> createInitialUserOp should only be done by Initialize and not by NewEnvironment
[22:57] <menn0> i'll fix that
[22:58] <thumper> perhaps, remove the server, and just add a comment that the environment will have the same server as the initial environment
[22:58] <thumper> the server uuid was added to enable us to store records to remote environments
[22:58] <thumper> which we have no use case for right now
[22:58] <thumper> maybe soon with cross environment relations
[22:58] <thumper> which will need other commands anyway
[22:58] <thumper> so...
[22:58] <menn0> that makes sense
[22:59] <thumper> NewEnvironment(cfg *config.Config, owner names.UserTag) (*Environment, error)
[22:59] <thumper> or
[22:59] <thumper> NewEnvironment(cfg *config.Config, owner names.UserTag) (*Environment, *State, error)
[22:59] <menn0> I was wondering about returning the new state
[22:59] <thumper> so it returns a *State that would operate in that env?
[22:59] <menn0> but it's easy to get with State.ForEnviron
[23:00] <thumper> sure
[23:00] <menn0> and NewEnvironment doesn't need to create it itself
[23:00] <menn0> so it's probably outside its responsibility to return it
[23:03] <menn0> thumper: thanks I'll run with this
[23:03] <thumper> ok
[23:03] <thumper> cool
[23:03] <thumper> alexisb: are we meeting today?
[23:04] <alexisb> yes
[23:05] <thumper> k, be there in a sec
[23:12] <wallyworld> thumper: when you finished your meeting, i need to talk about bug 1392745
[23:12] <mup> Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745>
[23:12] <thumper> :-(
[23:58] <wallyworld> anastasiamac: review done, let me know if you have questions


[10:14] <brobostigon> morning boys and girls.
[11:44] <foobarry> morning
[11:44] <foobarry> just borrowed a vax cleaner
[11:44] <foobarry> they are amazing
[20:56] <mintsauce> Hello. I'm trying to do-release upgrade Ubuntu 10.04.4 to 12.10. It aborts after a message along the lines of :'It was not possible to authenticate some packages.' which precedes a long list of packages, including apache2.
[20:57] <mintsauce> How do I get past this error?
[22:05] <daftykins> impressive, both dead releases
[22:05] <daftykins> users be cray.
[22:11]  * zmoylan-pi sells red hat 5.2 floppies in dark internet cafés... :-)
[22:12] <zmoylan-pi> 3.5" AND 5.25"
[22:13] <zleap> i had that
[22:13] <zleap> on cd as a box set
[22:13] <daftykins> oof :)
[22:13] <zmoylan-pi> it was more fun installing from floppy... :-)
[22:13] <zmoylan-pi> not as fun as installing windows 95 mind...
[22:13] <zleap> yeah ra write to disk for each disk set, root / boot floppies, a1,a2 etc


[02:43] <Snakes> hey all; installed 14.10; I am confused that at the login, it didnt have an option to run under mir or x
[02:44] <Snakes> is it just running under mir right now?
[03:07] <akiva_> is there a repo for the core apps, or do I have to build them all by source?
[03:07] <akiva_> I'd like to contribute to testing
[07:57] <lordievader> Good morning.
[14:27] <ice9> does Ubuntu 14.10 will have unity 8, unity 8 is made by Qt right?
[16:30] <mkovarik> Hi is anyone  else running into dependency problems with libc ?
[23:02] <Akiva-Thinkpad> how do I tell if I am using mir or not?
[23:18] <Beldar> Akiva-Thinkpad, It has not been fully implemented yet I believe.
[23:18] <Akiva-Thinkpad> Beldar, pong
[23:18] <Akiva-Thinkpad> Beldar, im on 14.10;
[23:18] <Akiva-Thinkpad> I am just... curious how to check
[23:18] <Beldar> Akiva-Thinkpad, Yes you are on the 14.10 channel that was my assumption.
[23:19] <Akiva-Thinkpad> :o   DOH!
[23:19] <Akiva-Thinkpad> :P
[23:20] <Beldar> Akiva-Thinkpad, http://www.omgubuntu.co.uk/2014/06/unity-8-daily-build-images-go-live be aware that when you go outside the repos you loose support here IE ppa's etc.
[23:20] <Akiva-Thinkpad> :P
[23:20] <Akiva-Thinkpad> http://askubuntu.com/questions/330862/how-do-i-find-out-if-my-system-is-using-mir
[23:21] <Akiva-Thinkpad> apparently I am
[23:21] <Akiva-Thinkpad> no
[23:21] <Akiva-Thinkpad> no apparently I am not...
[23:21] <Akiva-Thinkpad> okay I am confused :P
[23:23] <Beldar> Akiva-Thinkpad, read this please, http://www.phoronix.com/scan.php?page=news_item&px=MTY4MDk
[23:24] <Akiva-Thinkpad> Beldar, that was back in may... yah I am still not clear
[23:25] <Beldar> Akiva-Thinkpad, mir has not replaced x period yet.
[23:25] <Akiva-Thinkpad> ps afx | grep unity-system-compositor gives me :  4868 pts/4    S+     0:00                  \_ grep --color=auto unity-system-compositor
[23:26] <Akiva-Thinkpad> according to ask ubuntu, that says I am running mir
[23:26] <Beldar> Akiva-Thinkpad, part of it is in the system, not fully implemented is all, that beyond your ability to reason. ;)
[23:27] <Beldar> it is not black or white
[23:27] <Akiva-Thinkpad> Ah I see what you are saying
[23:28] <Beldar> cool


[21:39] <blotchy> would it be horrible forum to make a minimal upstart script that just calls the old sysV script (after it's been moved)?
[21:39] <blotchy> form, not forum


[05:38] <cpaelzer> hi, question around the context of auto-sync. If we have a package as a sync but need a rebuild - yet want to keep it being a sync we could make the current "29.0-1" a no change rebuild like "29.0-1build1"
[05:39] <cpaelzer> that would do the trick, but what happens if Debian (unlikely but possible) decides to do "29.0-1build1" themselve or soemthing in between the two versions ?
[05:39] <cpaelzer> I wonder if there is a better version avoiding this problem yet keeping it as a auto-sync package
[06:21] <wgrant> cpaelzer: That's the right way to do it. A version like that isn't compliant with Debian's archive policies (they have binNMUs which usually use a suffix of "+b1"), so I don't think a collision has ever occurred.
[06:30] <cpaelzer> thanks
[09:42] <cjwatson> And any other scheme you might invent would have exactly the same kind of possible collision problem anyway.l
[09:43] <cjwatson> So might as well stick with the known one.
[10:01] <xnox> vorlon:  hm, about mountfail hooks vs local-block. When ben hutchings and I, introduced local-block it was meant to replace all the mountfail hooks. Because we realized that a single pass of failure hooks is insufficient.
[10:01] <xnox> and if any one of the failure hooks "progresses things" (i.e. mounts something degraded) then all the hooks need to be rerun to retrigger udev events, and retry mounting stuff.
[10:02] <xnox> at the moment, at least in lvm2, I see that we have "udev triggered mounting", "broken mountfail hook", "local-block lvm2" hooks. Which seems redundant, and not working correctly.
[10:05] <xnox> I do like "local-block" as it does things similar to how e.g. systemd-shutdown works - iterrate all the things, if anything makes progress
[10:10] <xnox> vorlon:  i also don't quite understand how wait-for-root works, given that it doesn't allow for cryptsetup to kick in and ask for passphrase after raid was assembled, but before lvm2 is scanned.
[10:10] <xnox> which local-block loop does correctly.
[10:11] <xnox> thus the comment that "local-block" should never be reached in the initramfs-tools cannot be true.
[10:16] <xnox> vorlon:  i.e. I think we should stop using failure-hooks, and use local-block instead.
[10:55] <guidocalvano> hey, I've been playing around with the ui shell and want to try and make workspaces savable to better fit my workflow
[11:00] <guidocalvano> in order to do this I would like to store which files I have open with say a code editor or some graphical application
[11:14] <guidocalvano> i.e. save workspace goes through the list of applications on the workspace, then creates files, that then allow to reopen all the applications including the files/urls they had open
[11:15] <guidocalvano> and load workspace creates a new workspace, and starts the applications with the files urls they had open when saved
[11:15] <guidocalvano> I was thinking of using criu for this
[11:20] <guidocalvano> but when I have a browser open or a text editor it can remember its own open files as well
[11:20] <guidocalvano> so I was wondering how it does this
[11:20] <guidocalvano> where does it store what files it has open?
[11:24] <guidocalvano> and can I somehow create separate contexts the same application?
[14:16] <cpaelzer> paride: from your +1 duty is anyone on libfile-desktopentry-perl ?
[14:16] <cpaelzer> that shows up in component mismatches like a tree (many subdependencies)
[14:28] <paride> cpaelzer, not afaik. I am currently trying to sort out the regression preventing mysql-8.0 from migrating
[14:29] <paride> cpaelzer, as you mention a tree, is there anything better than https://people.canonical.com/~ubuntu-archive/component-mismatches.txt to look at component mismatches?
[14:49]  * paride saw the SVGs
[16:16] <sarnold> xnox: am just frustrated that my old habits of eg dpkg -S `which foo` are useless now :(
[16:17] <sarnold> xnox: doubly so since I never understood what problem is being solved by adding symlinks
[16:19] <gpiccoli> vorlon, xnox - can I ask your opinion on LP #1879980 ?
[16:20] <gpiccoli> I found various duplicate issues from the last 8 years or so about the same problem..it's a long-term issue
[16:20] <gpiccoli> I have an user that tested my proposed solution on Bionic with success
[16:21] <xnox> sarnold:  i wonder if we can fix -S to try both ways
[16:22] <sarnold> xnox: ooh ooh apt-file too please :)
[16:24] <xnox> sarnold:  what is apt-file?
[16:25] <sarnold> xnox: it's a simple wrapper around the contents files from the archives, eg you can find all packages that ship an apparmor profile via apt-file search /etc/apparmor.d  https://paste.ubuntu.com/p/D5pcTCMzjk/
[17:05] <xnox> sarnold:  ack
[18:13] <Eickmeyer> xnox: Were you ever able to find that gfxboot code for Ubuntu Studio?
[18:20] <xnox> nope, the thing i thought it was, was not it
[18:21] <xnox> vorlon:  what shall we do about gfxboot-theme-ubuntu? remove our attempts and publish back the binary that was there?
[18:30] <RikMills> Eickmeyer: the .pcx and .pngs in this? https://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/files/head:/data/groovy
[18:33] <RikMills> xnox: I assume that is what is used in production/iso builds? ^
[18:36] <Eickmeyer> RikMills: Yeah, that's the one. *cringes at the oldness*
[18:40] <Eickmeyer> 12 years old, goes back to first release of Studio (gutsy).
[18:42] <RikMills> "This branch is an import of the Bazaar branch at https://people.canonical.com/~cjwatson/bzr/debian-cd/ubuntu"
[18:43] <RikMills> o_O
[18:44] <Eickmeyer> Woooow.
[18:45] <RikMills> but looks like you can propose merges against the LP one all the same. odd
[18:46] <Eickmeyer> Yeah. I'll probably just do that.
[18:46] <RikMills> cjwatson: is that the correct route to get changes into the ISO build there?
[18:47] <RikMills> Eickmeyer: wow. your logo is retro!
[18:50] <Eickmeyer> RikMills: That's what I've been saying! lol
[18:57] <Eickmeyer> RikMills: I showed my son and he said, "Ok, that is SO bad!" LOL!
[19:13] <vorlon> xnox: so you're saying gfxboot-theme-ubuntu is still broken, even with your non-empty font?
[20:28] <xnox> vorlon:  yeap
[20:28] <vorlon> xnox: reference?
[20:29] <xnox> vorlon:  i booted pending ubuntu-live-server iso in bios mode, hit ESC, and the gfxboot menu had no readable labels on any buttons (as per screenshots from the bug report)
[20:30] <xnox> RikMills:  Eickmeyer: oooooh that could be it.
[20:30] <xnox> RikMills:  Eickmeyer: no idea how that is copied in, or when. But yeah, you can make merge proposals.
[20:30] <vorlon> xnox: which bug report?  I didn't see a bug link in scrollback
[20:30] <Eickmeyer> xnox: MP is done, awaiting merge.
[20:32] <xnox> vorlon:  https://bugs.launchpad.net/ubuntu/+source/lubuntu-artwork/+bug/1880394 https://photos.google.com/share/AF1QipOalqGwK-nonwRFp9T3VwQ2V1Yji3SpVAENeMjixTWb-CTCbo6gQ8jqeesaAOQoiA?key=eDMzTF9RTXpXY21CSkFpZmVFZEpsd1NMX3dXM2dB
[20:32] <xnox> vorlon:  i see the same, but with ubuntu logo
[21:13] <cjwatson> RikMills: err, tbh it's been five years and I've basically forgotten.  IIRC the release team follows https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup
[21:13] <cjwatson> I think it's committed on nusakan and then there's a mirror that goes via my home directory.  It should really be turned into proper LP-hosted branches
[21:14] <cjwatson> But all this stuff is super-old, it predates bzr even existing never mind LP code hosting
[21:14] <cjwatson> I would very much support a current cdimage person sorting it out
[21:19] <xnox> RikMills:  Eickmeyer: do make a launchpad merge proposal against lp:~ubuntu-cdimage/debain-cd/ubuntu on launchpad and it will be sorted
[22:09] <sarnold> hello :) how does this directory have only .deb packages and no tarballs, no dsc files, etc? http://archive.ubuntu.com/ubuntu/pool/universe/u/uucp/
[22:10] <tumbleweed> the source is in main
[22:10] <sarnold> ahhh
[22:10] <sarnold> http://archive.ubuntu.com/ubuntu/pool/main/u/uucp/
[22:10] <sarnold> I was just getting to that. funny. I never expected uucp to have main sources so I didn't look there until after asking on irc..
[22:11] <tumbleweed> it's there for "cu"
[22:12] <sarnold> tumbleweed: cool, thanks
[22:51] <mwhudson> bryce: are php-horde packages reappearing in groovy something we want or an accident?
[22:59] <bryce> mwhudson, the intention was for them to go away for good; what's causing them to reappear?
[23:07] <mwhudson> bryce: they are being synced from debian i assume
[23:08] <mwhudson> e.g. https://launchpad.net/ubuntu/+source/php-horde-argv/2.1.0-5
[23:09] <mwhudson> i guess if they are being maintained in debian again we might be happy to have them back
[23:09] <bryce> https://bugs.launchpad.net/ubuntu/+source/php-horde/+bug/1868281
[23:15] <bryce> mwhudson, hmm, last I checked the stack had been abandoned in Debian.  Even if it's been re-adopted, it comprises over a hundred packages that pop up stuck in proposed migration frequently.
[23:15] <mwhudson> bryce: seems a bunch of them got uploaded again about a week ago
[23:16] <mwhudson> bryce: so we should work them back into release or delete them again and blacklist them so they stop syncing
[23:16] <bryce> mwhudson, delete and blacklist.  Intent was to blacklist them, although looking at the bug I guess maybe this wasn't done last cycle
[23:18] <mwhudson> bryce: want to file a bug for that and subscribe ~ubuntu-archive then?
[23:22] <bryce> mwhudson, can do
[23:22] <mwhudson> bryce: thanks
[23:22] <bryce> I'm recovering from an X crash I just had a bit ago, will do so post-reboot
[23:24] <bryce> (aka with a 6-monitor layout, vtswitching is an adventure)


[05:03] <ianorlin> http://mirror.linux.org.au/linux.conf.au/2010/wednesday/50178.ogg is an intesting talk I am listening too but is before my time
[05:03] <darthrobot> Content type: [audio/ogg] Size: [15088092]