[00:00] <Bluefoxicy> geofft:  I checked for updates and patches and fixes.  14.04 wasn't this broke, and it had hundreds of updates in the first week or so. This has been a dead stick; no patches coming down.  I am completely up to date.  :|
[00:00] <Bluefoxicy> oh, and I'm using an Intel core i5 with Intel HD 3000 graphics
[00:00] <Bluefoxicy> If anything should not be broken, it's the Intel graphics driver :|
[00:01] <JanC> Bluefoxicy: keep dreaming  :p
[00:01] <Bluefoxicy> Seriously this is like when people had XP and installed Vista.  I was like "ahahaha I have Ubuntu over here"
[00:01] <JanC> (Intel driver did break several tbefore)
[00:01] <Bluefoxicy> and now I'm like A*<#AG<Y(%I#(CT#<IU)(#$C
[00:02] <JanC> *times*
[00:02] <Bluefoxicy> Gnome keeps forgetting my keymap, so I have to go load something else and then delete it to get dvorak back
[00:02] <JanC> but not sure this is what's happening here
[00:02] <Bluefoxicy> oh and then I get a pop-up dialog telling me I have multiple input methods installed and that it doesn't know what to do with my config.
[00:05] <JanC> do you?
[00:10] <JanC> (do you use multiple input methods?)
[00:20] <Bluefoxicy> JanC:  I mean like... ibus and imx or such
[00:20] <Bluefoxicy> it's found 2 different installed back-ends to type in Gapanese or Arab or something.
[00:20] <JanC> so, any reason why you have 2?
[00:20] <Bluefoxicy> Think of it like having SystemD and upstart both running
[00:21] <Bluefoxicy> no, no reason I have 2.  I wound up with 2 during the 14.04 to 14.10 upgrade and don't know why.
[00:22] <JanC> likely you had 2 before?
[00:23] <JanC> or maybe ibus got pulled in while you had another one
[00:23] <Bluefoxicy> Possibly.  Not sure how I got 2 in the first place.  I know how I got 1:  I had set up the keyboard a year ago to type japanese
[00:24]  * Bluefoxicy eats a pork chop.
[00:24] <Bluefoxicy> I'm pretty sure this is the first time I've actually regretted upgrading my OS.  Ever.
[00:36] <Bluefoxicy> oh
[00:36] <Bluefoxicy> my god.
[00:37] <Bluefoxicy> JanC:  it's sound.
[00:37] <Bluefoxicy> Rhythmbox hangs.  VLC won't play sound, but plays video.  Flash plays video, but no sound.
[00:41] <Bluefoxicy> http://pastie.org/9682073
[00:41] <Bluefoxicy> so is this bad?
[00:43] <Bluefoxicy> seems like an occasion to reboot, to me
[00:47] <Bluefoxicy> Yeah... that's bad.
[03:05] <hyperair> what's the colour of the default ubuntu tty?
[03:06] <hyperair> i mean the actual tty, not gnome-termianl
[03:07] <infinity> hyperair: Black?
[03:07] <hyperair> okay
[03:07] <hyperair> i'm still sane.
[03:07] <hyperair> still sane
[03:07] <hyperair> *deep breaths*
[03:07] <infinity> Doesn't sound like it...
[03:08]  * infinity backs away slowly.
[03:08] <hyperair> 11:00:14 <bonsaikitten> ubuntu just lacks basic QA
[03:08] <hyperair> 11:00:35 <hyperair> :/
[03:08] <hyperair> 11:00:39 <bonsaikitten> e.g. their black is still broken, startup flickers in ways that suggest no one cares, and distro upgrade usually self-destructs
[03:08] <hyperair> 11:00:44 <hyperair> black?
[03:08] <hyperair> 11:00:52 <bonsaikitten> yeah, black is purple
[03:08] <hyperair> deep calming breaths
[03:08] <hyperair> must not rage
[03:08] <hyperair> must not flip tables
[03:09] <rww> > gentoo developer
[03:09] <rww> > complaining about upgrade stability
[03:09] <rww> hrm.
[03:09] <infinity> hyperair: I'd love bug reports for the last thing.
[03:09] <hyperair> rww: lol! i didn't notice!
[03:09] <geofft> also it's not purple, it's aubergine. please.
[03:10] <hyperair> :)
[03:10] <infinity> hyperair: I mean, assuming he's interested in being constructive instead of just slagging Ubuntu for kicks.
[03:10] <RAOF> GRUB's background is aubergine, which is what most people will be seeing for most of the boot...
[03:10] <hyperair> infinity: unfortunately i haven't been able to reproduce the distro upgrading self-destructing issue, because once i'm done, it's kinda... gone..
[03:11] <hyperair> infinity: and i'm just stuck picking up the pieces with dpkg --configure -a
[03:11] <hyperair> and apt-get install -f
[03:11] <hyperair> and aptitude install -f
[03:11] <hyperair> i ran those commands almost 20 times, each time upgrading 200 packages or so
[03:11] <infinity> hyperair: There are logs from the upgrade, generally.  The first failure is the interesting one.
[03:11] <hyperair> whera?
[03:12] <hyperair> where*
[03:12] <infinity> hyperair: In your experience, is this with update-manager/do-release-upgrade, or raw apt-get?
[03:12] <hyperair> infinity: do-release-upgrade bails halfwya
[03:12] <hyperair> it's done that for the past few distro upgrades for me
[03:12] <hyperair> but this time was particularly bad, because apt-get install -f wouldn't budge
[03:12] <hyperair> a bunch of odd broken packages here and there
[03:12] <hyperair> aptitude install -f did work
[03:12] <infinity> Kay.  It leaves a log somewhere (I forget the precise name) when it explodes.
[03:13] <hyperair> but even that only managed to move 200 packages or so
[03:13] <infinity> I wonder if we could get away with taking "anonymous usage statistics" that grabbed people's package lists.
[03:13] <hyperair> and then it bailed again a few times due to broken postinst or something
[03:13] <infinity> Cause testing random upgrade paths is nice, but doesn't simulate real users.
[03:13] <hyperair> infinity: cue: ubuntu IS SPYWARE
[03:13] <infinity> hyperair: Yeah.
[03:14] <hyperair> god fucking damnit
[03:21] <ScottK> Well once you start sending local search results to remote servers by default, you can't blame people for being suspicious.
[04:30] <hyperair> yeah well, it's a little hard to benefit from hive-mind optimization without sending local search results to remote servers.
[04:36] <JanC> infinity: if you ask the users nicely, probably
[05:53] <Logan_> is it okay to forward patches to debian for build-depending on libappindicator-dev for indicator support? they do have that package as well
[05:57] <pitti> Good morning
[05:58] <hyperair> Logan_: it depends.
[05:58] <hyperair> Logan_: debian does have libappindicator
[05:58] <hyperair> but most people don't use it, and more importantly, it breaks the UX on DEs that use GtkStatusIcon
[05:58] <Logan_> ah, I see
[05:58] <hyperair> i mean the standard notification area
[05:59] <Logan_> so a given Debian maintainer probably wouldn't accept the patch?
[05:59] <Logan_> and I should keep the delta?
[05:59] <hyperair> i know appindicator has some fallback that stuffs itself into the notification area, but it clobbers left click launch, and launches the menu on left click
[05:59] <Logan_> well that's wonderful :P
[05:59] <hyperair> it depends. don't file a bug, just try looking for the maintainer directly
[05:59] <Logan_> he orphaned the package
[05:59] <hyperair> oh lol
[05:59] <hyperair> then it's up to qa.debian.org
[05:59] <hyperair> which package is this?
[06:00] <Logan_> flush
[06:00] <Logan_> some obscure Bittorrent client
[06:00] <hyperair> heh i see
[06:00] <hyperair> is upstream still alive?
[06:00] <Logan_> idk, I like forwarding things whenever possible
[06:00] <Logan_> no, it's inactive
[06:00] <hyperair> you could try forwarding
[06:00] <Logan_> I guess the worst that could happen is they don't accept the patch
[06:01] <hyperair> yeah
[06:01] <Logan_> usually Debian gets mad if we forward things without justification, though
[06:01] <hyperair> not Debian in general, but some maintainers
[06:01] <Logan_> yes, I should've clarified that
[06:01] <ScottK> If it's orphaned and dead upstream, removal is more likely the right move.
[06:02] <hyperair> true that
[06:02] <Logan_> the Git repo hasn't been touched in two years
[06:02] <Logan_> it's marked as inactive on Sourceforge
[06:02] <Logan_> and it doesn't even support magnet links :P
[06:03] <hyperair> Logan_: with my DD hat on, i'd say that the first time a dumb patch is uploaded, i'd reject it with an explanation. and the following times, possibly without an explanation
[06:03] <Logan_> if it's orphaned, do I have to ask for approval from QA before filing for removal in Debian?
[06:03] <hyperair> hmm
[06:03] <ScottK> Logan_: In Debian, the QA team is everyone.
[06:03] <Logan_> so I can ask myself
[06:03] <hyperair> i don't think there's any prereq for filing for removal
[06:03] <ScottK> Yes.
[06:04] <hyperair> check popcon
[06:04] <hyperair> some users might get annoyed
[06:04] <hyperair> but that could be a good thing
[06:04] <ScottK> Then they can maintain it.
[06:04] <Logan_> :D
[06:04]  * hyperair has stepped up as maintainer for things that have been RM'd before
[06:04] <hyperair> mostly out of rage
[06:04] <hyperair> like NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO DON'T REMOVE THIS I STILL WANT IT
[06:04] <Logan_> I was so surprised when they removed compiz
[06:04] <ScottK> Take your motivation where you can get it.
[06:04] <hyperair> indeed
[06:04] <hyperair> wait
[06:04] <hyperair> compiz was removed?
[06:05] <hyperair> seriously?
[06:05] <Logan_> yep
[06:05] <hyperair> =\
[06:05] <hyperair> meh
[06:05] <Tribaal> huh
[06:05] <hyperair> whatever floats their boat.
[06:05] <Logan_> they said it was dead upstream I believe
[06:05] <Logan_> which is BS
[06:05] <hyperair> is it still maintained?
[06:05] <hyperair> smspillaz has retired from compiz iirc
[06:05] <goodwill> compiz is not dead?
[06:06] <Logan_> it's definitely still being developed
[06:06] <hyperair> afaik it's an undead state
[06:06] <hyperair> unity's moving away from compiz
[06:06] <hyperair> and after what canonical's done to compiz, it's probably just going to die without unity's support
[06:06]  * hyperair shrugs
[06:06] <Logan_> there's now an ITP for compiz in Debian
[06:07] <Logan_> that's amusing
[06:07] <goodwill> http://cgit.compiz.org/?s=idle
[06:07] <goodwill> or is somewhere else now?
[06:08] <goodwill> last change anywhere was 5 months and compiz core has not been updated in 3 years
[06:08] <hyperair> Logan_: that typically happens with RM'd packages.
[06:08] <hyperair> Logan_: i think it happened for aircrack also
[06:08] <hyperair> goodwill: bzr possibly
[06:08] <hyperair> because canonical loves bzr
[06:09] <goodwill> I've been meaning to ask does anyone else use bzr? what is it about bzr that Canonical loves
[06:10] <goodwill> hmmm ... I guess it is not dead
[06:10] <goodwill> how nice
[06:10] <hyperair> hmm, i think emacs used to use bzr
[06:10] <Logan_> I think they haven't switched to Git because it would require changing the whole LP infrastructure
[06:10] <hyperair> then they moved to git
[06:10] <hyperair> like every other sane project ;-)
[06:10] <infinity> We're working on git in LP, it's just not done yet.
[06:11] <Logan_> there's nothing special about Bazaar, other than that it's backed by Canonical
[06:11] <hyperair> infinity: oh, so it's actually being worked on!
[06:11] <Logan_> infinity: that's music to my ears
[06:11] <hyperair> infinity: that's nice!
[06:11] <Tribaal> infinity: nice :) Good to hear
[06:11] <infinity> goodwill: As for "what Canonical loves about it", it's that we developed it (and it predates git), and inertia is hard to overcome, even when you've "lost".
[06:11] <goodwill> right
[06:11] <goodwill> mercurial is still alive right?
[06:11] <infinity> Alive and well.
[06:11] <goodwill> good
[06:11] <goodwill> :)
[06:11] <goodwill> love mercurial
[06:11] <hyperair> meh
[06:11] <hyperair> git ftw
[06:11] <ScottK> Written in Python and used by Python upstream.
[06:11] <infinity> Not my cup of tea, but some communities swear by it.
[06:12] <Logan_> Mozilla does, for sure
[06:12] <Logan_> although they've been using Git for some projects as well
[06:12] <hyperair> oh mariadb uses bzr too
[06:12] <infinity> I'm a simple man, though.  I still don't mind SVN, even though that makes me a social pariah in the modern DVCS world.
[06:12] <Logan_> they'll probably move away from it once Ubuntu does
[06:13] <Logan_> go away Adam, we don't want your outdated opinions here ;)
[06:13] <Tribaal> well, bzr is a GNU project technically
[06:13] <infinity> RCS FOR LIFE.
[06:13] <hyperair> i wouldn't mind bzr so much if git-bzr was actually properly usable
[06:14] <hyperair> but about half of the time, it fails with some kind of error due to some weird compatibility issue with the repo it's trying to fetch from
[06:20] <RAOF> Probably doesn't help that bzr has a slightly richer data model.
[06:21] <hyperair> heh
[06:21] <hyperair> i've found some repositories with unresolvable tags as well
[06:21] <hyperair> referring to wrong hashes
[06:22] <infinity> RAOF: The richer data model, unfortunately, is sometimes a hindrance.
[06:22] <Logan_> crap
[06:22] <Logan_> I accidentally wrote utopic in a changelog instead of vivid
[06:22] <infinity> RAOF: Overly complicates things like tracking moves in merges and such.
[06:22] <infinity> Logan_: Need a reject from the queue?
[06:22] <Logan_> can someone please reject 0.9.12-3.1ubuntu1 from topic?
[06:22] <Logan_> *utopic
[06:23] <infinity> Logan_: flush, I assume?
[06:23] <Logan_> yup
[06:23] <Logan_> thanks :)
[06:23] <Logan_> I probably shouldn't be doing package merges at 2:30 AM
[06:23]  * Logan_ goes to sleep
[06:23] <RAOF> infinity: Right. I've not found git's non-handling of moves problematic, whereas bzr sometimes gets shirty.
[06:25] <Logan_> infinity: I thoroughly appreciated your rejection reason
[06:25] <infinity> Logan_: :)
[06:25] <infinity> Logan_: That's my default for "people I know/like well enough to not be professional".
[06:26] <infinity> Logan_: So, welcome to the inner circle, I guess.
[06:26] <Logan_> I feel so honored
[06:26] <pitti> oh, upgrading util-linux triggers update-initramfs -u, which now synchronously starts fstrim.service
[06:26] <pitti> that causes the package upgrade to hang a looooong time
[06:26] <pitti> infinity: ^ that's presumably not intended? fstrim.service shouldn't be started on package install IMHO
[06:27] <infinity> pitti: I feel like there's a Debian bug about this that I've seen fly by my INBOX.
[06:27] <infinity> pitti: I've been amazingly disconnected from all of that, but I need to get involved again before ah shanks me in my sleep.
[06:27] <pitti> oh, it was mvo who merged that, nevermind
[06:28] <pitti> I don't see anything relevant on https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=util-linux, I'll file one then
[06:45] <pitti> filed now as Debian bug 767194, I'll have a look
[06:45] <pitti> it's highly annoying as each initramfs upgrade now takes 10 minutes or longer
[06:47] <pitti> wgrant: hey William!
[06:48] <pitti> wgrant: all the outstanding imports at https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ciborium/+imports?field.filter_status=all&field.filter_extension=all , are these normal? the pots got imported over a week ago
[06:48] <wgrant> pitti: Probably because of the arch in the path?
[06:48] <pitti> wgrant: well, I imported the armhf pot and deleted all the others (as this is RTM)
[06:48] <wgrant> Some packages end up with the POs in both the source and binary directories.
[06:49] <pitti> wgrant: but the outstanding PO files are from all arches
[06:49] <pitti> i. e. neither get the armhf ones imported nor the !armhf ones ignored
[06:49] <pitti> wgrant: yeah, unfortunately stuff only ends up in the per-arch build dir for ciborium
[06:50] <pitti> but then again, https://translations.launchpad.net/ubuntu/utopic/+source/ciborium/+imports?field.filter_status=all&field.filter_extension=all looks similar
[06:50] <pitti> so perhaps that's "normal"
[06:50] <wgrant> pitti: Are you sure? The template path is currently set to "po/ciborium.pot", no arch.
[06:50] <pitti> wgrant: hm, that's not what I imported, but perhaps someone else already did that
[06:51] <pitti> https://translations.launchpad.net/ubuntu-rtm/14.09/+source/ciborium/+pots/ciborium has translations, so supposedly it somehow works
[06:51] <wgrant> Examining the tarballs in the queue, they're in source/po/*.po too
[06:51] <wgrant> Someone should really fix all these cmake-y build systems to not produce both, though.
[06:51] <pitti> ok
[06:52] <wgrant> I don't think there's a problem here, besides the duplicated import entries.
[06:52] <wgrant> https://launchpad.net/ubuntu-rtm/14.09/+queue?queue_state=3&queue_text=ciborium, look at one of those tarballs.
[06:52] <pitti> wgrant: so po files in dirs where pot files got explicitly deleted/rejected don't get cleaned up, they just keep stuck in "needs review"?
[06:52] <wgrant> pitti: Files are approved based on templates, not based on other files.
[06:53] <wgrant> A queue entry has no idea that another queue entry was rejected.
[06:53] <wgrant> Though Blocked has some special handling.
[06:53] <pitti> wgrant: ok, so that is normal then?
[06:53] <wgrant> This particular case seems very common with qt things; someone should investigate and remove the duplication, I think.
[06:53] <wgrant> This behaviour is normal and expected given the input tarball, yes.
[06:53] <pitti> wgrant: ack, thanks for checking!
[06:54] <pitti> (and yay broken build systems)
[07:01] <wgrant> pitti: I guess that's probably easy enough to fix in pkgstriptranslations, too.
[07:09] <dholbach> good morning
[07:12] <pitti> hey dholbach
[07:14] <dholbach> hey pitti
[07:14] <dholbach> how's life over there?
[07:15] <pitti> dholbach: lots of catch-up to do from last week :)
[07:15] <dholbach> yep, I can relate to that :)
[07:51] <pitti> mvo: guten Morgen
[07:52] <pitti> mvo: so where's the magic in http://launchpadlibrarian.net/188488665/command-not-found_0.3ubuntu15_0.3ubuntu15.1.diff.gz ? is there an external blacklist which isn't represented in that diff, or did you hand-edit scan.data after scanning?
[07:54] <mvo> pitti: there is a external blacklist on nusakan
[07:55] <mvo> pitti: I ran a full scan with postgresql-xc blacklisted
[08:00] <pitti> mvo: ah, thanks; so SRUing this to trusty would merely mean to re-run scan, and it picks up the blacklist?
[08:02] <mvo> pitti: yeah, thats probably the most simple way, do you want me to prepare trusty too?
[08:03] <pitti> mvo: depends, if it's not too much effort for you; otherwise I can look into it. I mostly wanted to understand the mechanics how this works
[08:06] <pitti> mvo: I verified the utopic SRU, thanks!
[08:07] <mvo> pitti: no problem, I just started the extraction
[08:09] <Noskcaj> Does ubuntu have any plans to implement dep-11? https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCEQFjAA&url=https%3A%2F%2Fwiki.debian.org%2FDEP-11&ei=uaBQVPyeE8btmQW7oYLYCQ&usg=AFQjCNFAC6PqqgyxzcQWi42MmlGzNBouKQ&sig2=mZX3PiNYRlsX2hlWGzHwKg
[08:09] <mvo> pitti: it takes some time to run though
[08:10] <pitti> mvo: would hand-editing have been faster?
[08:10] <pitti> well, I assume "yes"; I meant "more appropriate"
[08:11] <mvo> pitti: either way is fine, the upside of running the extraction again is that we catch if more got changed in trusty (which really shouldn't be the case). but yeah, hand-editing is the fastest path :)
[08:21] <ogra_> mvo, i just noticed that ubuntu-core-system-image fails to build images in vivid ... with the same issue we had on touch and ubuntu-core yesterday (image builds accidentially using PPA builders) ... infinity knows what to do (he fixed the two others)
[08:27] <mvo> ogra_: thanks, but it seems like the latest image build was successful (3h ago) - I had to update a bunch of stuff in the PPA because of vidid changes
[08:27] <ogra_> ah, k
[08:28] <ogra_> sorry, didnt check the timestamp on the mail
[08:33] <mvo> ogra_: no problem :)
[09:02] <ogra_> hmm
[09:04]  * ogra_ has by accident looked into his router syslog ... runnint minimal trusty there and i just noticed os-prober running there
[09:04] <ogra_> is that normal ?
[09:04] <ogra_> i never saw that on an installed system
[09:09] <Laney> @pilot in
[09:09] <ogra_> irritating ...
[09:09] <ogra_> it also seems to load a lot of filesystem modules doing that
[09:10] <ogra_> even before os-prober runs
[09:13] <xnox> ogra_: os-prober is executed by update-grub
[09:13] <xnox> ogra_: well one of the snippets to test/check/detect/generate boot entries.
[09:13] <ogra_> xnox, why would that run on a regular basis on a running system  though ?
[09:13] <ogra_> i seem to see it pretty regular in syslog
[09:14] <xnox> ogra_: trusty gets new kernels every two weeks. so i'd expect it to run every two weeks.
[09:14] <ogra_> hmm
[09:14] <xnox> ogra_: unless your /boot is full, and unattended upgrades active, which would constantly try to configure new kernel, run os-prober, and fail.
[09:14]  * ogra_ checks his /boot
[09:15] <ogra_> indeed i run unattended upgrades  ... since its a router :)
[09:15] <ogra_> andin fact there is a newer kernel than i run
[09:16] <ogra_> so why didnt i get a reboot notification on login
[09:16] <ogra_> my trusty server install definitely gives me one ... weird
[09:17]  * ogra_ guesses ubuntu-minimal lacks that bit
[09:17] <ogra_> xnox, thanks ! you rock !
[10:11] <cjwatson> Laney: dh-autoreconf> I don't think so; part of the rationale for the split is that virtually nothing actually needs /usr/bin/libtool, and typically should be fixed if it does
[10:16] <LocutusOfBorg1> Laney, so should I ask for miniupnpc and transmission merges? I actually did them both, also rdesktop
[10:16] <LocutusOfBorg1> usually dholbach doesn't ask me to do, but I can ask if needed :)
[10:16] <LocutusOfBorg1> they are all trivial merges
[10:24] <Laney> cjwatson: Maybe so. I found three packages broken by this during the gi transition, which were using `libtool --mode=execute' in their test wrappers. (Okay, these three were Ubuntu specific)
[10:24] <Laney> LocutusOfBorg1: You risk duplicating work or missing some piece of knowledge
[10:24] <Laney> LocutusOfBorg1: See the first bullet https://merges.ubuntu.com/universe.html
[10:25] <Laney> This cycle I've already had two merges I was already working on performed by someone else
[10:26] <cjwatson> Laney: If they're doing that, then they should have a direct build-dependency anyway, rather than relying on dh-autoreconf to supply it for them.
[10:26] <cjwatson> Laney: But the right fix is to make them use the libtool in their build tree, not /usr/bin/libtool which may bear only passing resemblance in terms of configuration.
[10:27] <cjwatson> Laney: Compare e.g. http://git.savannah.gnu.org/cgit/man-db.git/tree/src/tests/testlib.sh#n17
[10:28] <Laney> Right
[10:28] <Laney> I'm just observing that there are things now which have become broken because they were assuming dh-autoreconf gave them /u/b/libtool
[10:28] <LocutusOfBorg1> oh indeed, so do you plan to merge gdcm? it is a package I worked on debian
[10:28] <cjwatson> Oh, yeah, just saying those are things to be fixed and not papered over
[10:29] <LocutusOfBorg1> bdrung, you there?
[10:30] <bdrung_work> LocutusOfBorg1, yes
[10:30] <LocutusOfBorg1> I would like to report a bug against wrap-and-sort
[10:30] <LocutusOfBorg1> but I ask you prior
[10:30] <LocutusOfBorg1> http://anonscm.debian.org/cgit/collab-maint/transmission.git/commit/?id=aa78e17e550005e12bd8251d694af450113f5d9c
[10:30] <LocutusOfBorg1> look at this
[10:30] <Laney> you know he's in #debian-devel too? :)
[10:30] <LocutusOfBorg1> wrap-and-sort dropped dpkg-dev b-d, because seems to strip everything after the first comment "#" in b-d
[10:30] <LocutusOfBorg1> ops :)
[10:31] <Laney> gdcm> go ahead
[10:31] <LocutusOfBorg1> Sometimes I feel more confortable here rather than in debian :)
[10:31] <bdrung_work> LocutusOfBorg1, i am 99% sure that this is a bug in python-debian (and it is probably already reported)
[10:32] <cjwatson> dpm: If you're talking about myspell-ca, I copied that in a few days back, you just weren't on IRC for me to respond at the time
[10:32] <darkxst> So Noskcaj posted a silly google link, but are there any plans for DEP-11 in ubuntu in the near future?
[10:32] <darkxst> pitti, cjwatson ^
[10:33] <darkxst> Ubuntu GNOME will probably switch to gnome-software at some point, but without that, is largely useless
[10:33] <pitti> I don't think it has ever been discussed so far
[10:33] <LocutusOfBorg1> bdrung_work, you mean something like #694142?
[10:34] <bdrung_work> LocutusOfBorg1, yes, that's exactly the bug you described
[10:34] <LocutusOfBorg1> :D thanks!
[10:34] <LocutusOfBorg1> I subscribed to it, thanks for avoiding me to report a new bug
[10:35] <bdrung_work> i should implement an option to just show the diff instead of applying it
[10:35] <bdrung_work> thanks for asking
[10:35] <LocutusOfBorg1> bdrung_work, I'm wondering how many times people drops b-d in an unaware mode
[10:35] <LocutusOfBorg1> seems dangerous!
[10:36] <bdrung_work> i only run wrap-and-sort in git repositories (where you can run 'git diff' afterwards to check the result)
[10:36] <LocutusOfBorg1> yes, but sometimes with huge dependencies it becomes difficult to track all of them, I double check them (this is why I spotted this one, in the transmission merge)
[10:37] <dpm> cjwatson, ah, awesome. I hadn't re-pinged as I wasn't sure if you were away. Thanks!
[10:37] <LocutusOfBorg1> but the "one-line" to multiline switch makes things hard
[10:38] <GunnarHj> dholbach: Thanks for uploading https://code.launchpad.net/~gunnarhj/ubuntu/vivid/im-config/merge-0.27-1/+merge/239853
[10:38] <GunnarHj> dholbach: Can you please push the branch too? (The bots didn't do their job.)
[10:40] <darkxst> pitti, right, would be good to start that discussion at some point, but not really a priority this cycle
[10:41] <darkxst> though given it require backend changes to the archives afaics it might be better to start sooner than later?
[10:44] <dholbach> GunnarHj, done
[10:45] <GunnarHj> dholbach: Great, thanks!
[10:57] <LocutusOfBorg1> Laney, can I give you the debdiff or should I open abug?
[10:57] <Laney> LocutusOfBorg1: bug please
[10:57] <LocutusOfBorg1> s/abug/a bug/
[10:57] <LocutusOfBorg1> ack
[11:01] <LocutusOfBorg1> FYI #1387114
[11:01] <LocutusOfBorg1> was trivial :)
[11:08] <ogra_> bah
[11:08]  * ogra_ glares at his half pushed livecd-rootfs branch
[11:09] <ogra_> damn
[11:17] <LocutusOfBorg1> so will the next ubuntu have systemd by default?
[11:18] <LocutusOfBorg1> most of the ubuntu deltas I'm looking at have upstart init scripts, I'm wondering if they can be synced over
[11:23] <ogra_> mvo, any objections to me uploading livecd-rootfs ?
[11:24] <ogra_> (just ran into your changes there)
[11:27]  * ogra_ uploads ...
[11:29] <Laney> ogra_: there's a sponsor request in the queue
[11:29] <Laney> can you take that at the same time?
[11:29] <Laney> actually two
[11:34] <cjwatson> LocutusOfBorg1: we'll need to retain upstart jobs as a transition mechanism for a while no matter what
[11:34] <cjwatson> LocutusOfBorg1: please don't drop those
[11:38] <ogra_> Laney, i'll have to do more subsequent uploads of livecd-rootfs today (this one is just to give you proper info in the build error so all needed changes are listed in it, i actually need to make these changes i teh next one)
[11:39] <ogra_> Laney, so yeah, i'll happily take them with the next one
[11:39] <Laney> thanks
[11:39] <Laney> One of them is basically a c+p of a script in ubuntu-touch hooks, wonder if they can be shared somehow
[11:40] <ogra_> i'll take a look
[11:40] <ogra_> hoperfully not the password hardcoding :)
[11:40] <ogra_> (since i'm just changing that bit)
[11:40] <Laney> nah, /etc/writable stuf
[11:41] <ogra_> ah, thats fine
[11:41]  * ogra_ notes that systemd causes issues in touch even before being the default
[11:42]  * ogra_ blames lennart ... because everyone does
[11:49] <mdeslaur> @pilot in
[11:54] <mvo> ogra_: none, thanks
[11:54] <ogra_> :)
[11:54] <mvo> ogra_: sorry for the delay, was having lunch
[11:54] <ogra_> to late anyway :)
[11:55] <mvo> ogra_: I meant to upload them but got distracted :)
[11:55] <ogra_> (i assumed if you merge into trunk the code would be ready)
[11:57] <mvo> ogra_: yes, it should be fine and got tested in our PPA for some time already
[11:57] <ogra_> right
[11:57] <mvo> thanks
[11:57] <ogra_> :)
[11:59] <mvo> ogra_: oh, just got the mail from the archive that I did indeed upload (and not dreamed it). so you will have to do another upload with your "  * properly redirect error output in 99zz-check-uid-gid.chroot" change and a new version number. maybe you looked while LP was still processing the upload
[11:59] <ogra_> hmm
[11:59] <ogra_> mvo, did you debcommit ?
[12:00] <ogra_> the tree didnt have a new tag
[12:00] <ogra_> oh, and there is the rejected mail :P
[12:01] <ogra_> hmm the tree is a mess
[12:02] <ogra_> mvo, please push --overwrite your upload and do a proper debcommit ... seems the tree has my debian/changelog and my tag now
[12:03] <mvo> ogra_: sure, done
[12:03] <ogra_> thx
[12:03] <mvo> ogra_: at r990
[12:03] <mvo> ogra_: sorry for the trouble, that was the part I meant to do and got distracted
[12:04] <ogra_> yeah, no prob ...
[12:04]  * mvo hugs ogra_
[12:05]  * ogra_ hugs mvo
[12:23] <LocutusOfBorg1> cjwatson, I never drop without asking first :) and of course *not* before any systemd transition :D
[12:23] <LocutusOfBorg1> and thanks for the clarification ;)
[12:53] <Laney> LocutusOfBorg1: are you going to handle rebuilds for gdcm?
[13:03] <LocutusOfBorg1> Laney, I have no upload privileges :( I can try a rebuild in a ppa if this helps
[13:03] <LocutusOfBorg1> should I?
[13:03] <Laney> test builds would be helpful
[13:04] <LocutusOfBorg1> camitk insighttoolkit insighttoolkit4 itksnap vmtk vtk-dicom right?
[13:05] <LocutusOfBorg1> this is what is given me with reverse-depends -b src:gdcm
[13:05] <Laney> anything that has a depends on libgdcm2.2
[13:06] <LocutusOfBorg1> ack
[13:12] <Laney> LocutusOfBorg1: miniupnpc is the same
[13:12] <geser> could someone please give-back gexiv2 and grilo. They failed as the gir files weren't in multi-arch directories, they should build now with the current gobject-introspection from vivid.
[13:12] <LocutusOfBorg1> ack
[13:14] <Laney> geser: yep
[13:15] <Laney> @pilot out
[13:48] <LocutusOfBorg1> Laney, uploading rdeps :)
[14:04] <seb128> bdmurray, pitti: do you know what that means?
[14:04] <seb128> SegvAnalysis: Skipped: missing required field "Disassembly"
[14:05] <seb128> unity8 segfault on the phone, apport failed to collect a dump, I wonder if that's the cause or a consequence
[14:17] <bdmurray> seb128: I believe the Disassembly is still in the report
[14:19] <bdmurray> seb128: I reported this as bug 1374544 a little while ago
[14:19] <seb128> bdmurray, thanks
[14:19] <seb128> in my case it is
[14:19] <seb128> no coredump/stacktrace in the .crash
[14:19] <bdmurray> ah, I believe that usually happens due to lack of memory on the device
[14:21] <LocutusOfBorg1> Laney, rebuilds for miniupnc done (I hope)
[14:21] <LocutusOfBorg1> some spurious armhf failures due to qemu crashes (multithread stuff)
[14:23] <LocutusOfBorg1> I also uploaded a vino merge in my ppa, I hope to have a feedback from seb128 :)
[14:23] <LocutusOfBorg1> ppa:~costamagnagianfranco/locutusofborg-ppa
[14:23] <seb128> LocutusOfBorg1, read https://bugs.launchpad.net/ubuntu/+source/vino/+bug/1271358 §?
[14:24] <seb128> LocutusOfBorg1, basically we can't update since the new version drops the UI for controlling it, which is used under !GNOME desktops, including Unity
[14:25] <LocutusOfBorg1> anyway vino at least in debian uses the embedded miniupnpc
[14:26] <LocutusOfBorg1> so I hope it can be patched to use again it also in ubuntu, right?
[14:28] <seb128> LocutusOfBorg1, no, we don't want to use the embedded one
[14:28] <seb128> LocutusOfBorg1, we can't update anyway due to what I wrote before
[14:35] <LocutusOfBorg1> mmm so  miniupnpc is blocked by 1271358?
[14:36] <seb128> LocutusOfBorg1, why would it?
[14:36] <seb128> LocutusOfBorg1, did miniupnpc change soname/abi? in which case somebody needs to rebuild vino/make it work with that version
[14:36] <seb128> LocutusOfBorg1, updating vino is not the only way to get there
[14:38] <LocutusOfBorg1> ok so I'll try to rebuild it :)
[14:38] <seb128> thanks
[14:40] <LocutusOfBorg1> thanks to you for pointing me to the best solution ;)
[14:45] <LocutusOfBorg1> :( https://launchpadlibrarian.net/188608080/buildlog_ubuntu-vivid-amd64.vino_3.14.0-2ubuntu2.is.3.8.1-0ubuntu3_FAILEDTOBUILD.txt.gz
[14:50] <seb128> LocutusOfBorg1, yeah, needs code changes...
[14:56] <LocutusOfBorg1> seb128, yes, working on it
[14:56] <seb128> great
[14:58] <mdeslaur> @pilot out
[15:35] <pitti> seb128: I'm back -- seems you figured that out?
[15:36] <LocutusOfBorg1> seb128, I fixed it :)
[15:36] <LocutusOfBorg1> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/6518423
[15:36] <LocutusOfBorg1> :D
[15:49] <LocutusOfBorg1> Laney,  miniupnpc seems fine :)
[15:50] <Laney> k, i'll look soon
[15:59] <LocutusOfBorg1> Laney, no hurry :) I was just giving you the information, sorry if I bother :D
[16:56] <Riddell> LocutusOfBorg1: ping
[16:56] <Riddell> LocutusOfBorg1: bug 1357270 you included multiarch-python-include-dirs.diff
[16:56] <Riddell> LocutusOfBorg1: that points to http://public.kitware.com/Bug/view.php?id=14156
[16:57] <Riddell> which xnox says should be dropped
[16:57] <Riddell> who's right?
[16:57] <jono> mdeslaur, hey, pal
[16:57] <mdeslaur> uh-oh :)
[16:57] <jono> mdeslaur, can I ask a favor? there is an interesting discussion going on on the Bad Voltage forum about packaging, and your name came up :-)
[16:57] <mdeslaur> jono: what'd I do?
[16:58] <jono> would you mind going and responding? http://community.badvoltage.org/t/on-package-creation-and-maintenance/8358
[16:58] <jono> :-)
[16:58] <jono> others are of course, welcome to respond too :-)
[17:01] <xnox> Riddell: it's mostly harmless. But imho should be dropped, but i didn't retest rebuilding cmakish/pythony packages.
[17:01] <Riddell> xnox: there's two other patches, should I submit them upstream?
[17:01] <xnox> Riddell: timeline-wise LocutusOfBorg1 simply did the merge, with his intended change, preserving all others.
[17:01] <Riddell> boost-multiarch.patch cmake-crosscompile.patch
[17:02] <teward> is there a list of supported ubuntu architectures for precise and later lying around anywhere?  trying to figure out what alternative architectures exist for any given release
[17:02] <xnox> Riddell: boost-multiarch.patch possibly can also be dropped, but needs reverse-dep builds test.
[17:02] <xnox> Riddell: cmake-crosscompile.patch is required to stay, and is not fully ready for submission to upstream.
[17:03] <xnox> Riddell: i'm adding cmake-crosscompile patch re-review to my floss todo list. Will look at it during mini-debconf uk next weekend.
[17:03] <Riddell> thanks xnox
[17:04] <xnox> Riddell: i don't even have a vivid chroot yet, so I haven't done anything for this cycle yet.
[17:04] <xnox> (well sans all the things that got synced in)
[17:17] <pitti> Noskcaj, Laney: FYI, your libmediaart sync broke tracker: https://jenkins.qa.ubuntu.com/job/vivid-adt-tracker/11/?
[17:17] <pitti> so it's held back in -proposed
[17:18] <pitti> (uploader notifications aren't yet reenabled for vivid)
[17:18] <pitti> looks like this needs some porting, maybe a newer tracker upstream version
[17:20] <LocutusOfBorg1> Riddell, yes, as xnox said, that patch was intended for cmake 3
[17:20] <LocutusOfBorg1> s/3/<IP_ADDRESS>
[17:20] <seb128> LocutusOfBorg1, nice
[17:20] <LocutusOfBorg1> with cmake 3 some things can be dropped, and the debian changelog from fgeyer was already mentioning that
[17:20] <LocutusOfBorg1> I didn't open a new one, sorry for that :)
[17:20] <LocutusOfBorg1> seb128, thaks, was trivial
[17:20] <seb128> pitti, not really, well I still don't know why apport doesn't collect dumps for unity8 segfault on my phone, I edited the .py to change the 3/4 of free memory requirement to see if it's that
[17:21] <pitti> seb128: the dash takes more than  half of available memory (~ 550 MB), so it's indeed difficult; but with that check disabled it might work (unless it then runs into OOM, of course)
[17:22] <mdeslaur> jono: replied, thanks
[17:22] <seb128> pitti, yeah, let's see, it would be nice if apport was writing in the log if that'sthe reason it doesn't do the collection
[17:23] <pitti> seb128: ack; bug report appreciated (and assign to me)
[17:24] <seb128> pitti, I can do that, thanks ;-)
[17:24] <Laney> pitti: Indeed, new versions fix this
[17:28] <LocutusOfBorg1> xnox, why MultiArchCross.cmake is not in debian?
[17:28] <LocutusOfBorg1> I'm wondering why a plain sync isn't possible now
[17:29] <xnox> LocutusOfBorg1: because it's incomplete, and relies on (not present in debian) at the time qt packaging changes.
[17:29] <xnox> i need to reconcile it with debian's developments.
[17:30] <xnox> and as i said, i'll do that soon.
[17:30] <xnox> please keep it for now. otherwise ubuntu-touch sdk will break.
[17:35] <jono> mdeslaur, thanks!
[17:35] <mdeslaur> jono: ARGH We're sorry, but new users are temporarily limited to 3 replies in the same topic
[17:35] <jono> mdeslaur, I can fix that for you if you like?
[17:36] <mdeslaur> jono:  please, I have a long post #4 :)
[17:36] <jono> mdeslaur, ok one sec
[17:36] <LocutusOfBorg1> thanks for clarifying
[17:36] <jono> mdeslaur, should be fixed now
[17:37] <mdeslaur> jono: awesome, thanks!
[17:38] <LocutusOfBorg1> we are in the early development, so if cmake breaks something in python we can handle it, right?
[17:38] <LocutusOfBorg1> anyway, keeping a patch is safer :D
[17:42] <jono> thanks mdeslaur, for replying :-)
[17:43] <mdeslaur> jono: FWIW, my wife agrees that I am rude.
[17:45] <ogra_> mdeslaur, lies !!! she doesnt know you as good as we do !
[17:45] <ogra_> :)
[17:45] <LocutusOfBorg1> ;)
[17:45] <mdeslaur> ogra_: I know, right? :)
[17:50] <jono> mdeslaur, LOL
[18:57] <Noskcaj> pitti: That was to be expected. The new version has been merged
[19:33] <infinity> Ick.  bash is telling me about sudo on every invocation now?
[19:36]  * infinity wonders what's meant to write in_successful /etc/bash.bashrc
[19:37] <infinity> Err..
[19:37] <infinity> What's meant to write $HOME/.sudo_as_admin_successful and why don't I have one?
[19:39] <mdeslaur> infinity: oh, did that get dropped in sudo? /me checks
[19:40] <mdeslaur> infinity: ah, crud, sudo is looking at the group called "admin" too
[19:42] <mdeslaur> infinity: I'll fix sudo
[19:42] <Jelle_> Hello guys. At the moment I got my Ubuntu server up and running, but I have to install the server-software for Jira. I followed the following tutorial: https://confluence.atlassian.com/display/JIRA/Installing+JIRA+on+Linux , altho at step 2.1 I need to execute a .sh file, but I get the 'Command not found' error. I hope someone can help me out :)
[19:42] <infinity> mdeslaur: Ah-ha.
[19:42] <infinity> mdeslaur: Make it check both, I guess, we get to retain backward compat forever.
[19:42] <mdeslaur> yep
[19:44] <infinity> mdeslaur: Might want to SRU the sudo change back too, so people on old releases get the semaphore created before they upgrade and get the message back for no good reason.  But I guess that's purely cosmetic, so meh.
[19:44] <jtaylor> Jelle_: you are probably missing the 32 bit linker
[19:44] <jtaylor> libc6-i386 I think
[19:45] <Jelle_> I've no idea what that could be.. :P I'm very new to linux actually
[19:45] <Jelle_> http://paste.ubuntu.com/8736982/  btw that is my output
[19:45] <jtaylor> Jelle_: try bash instead of sh
[19:46] <Jelle_> Nope didn't do the trick :/
[19:46] <Jelle_> looks like the same error
[19:47] <infinity> Which error are you referring to?
[19:47] <infinity> In your output, the only error is bashisms.
[19:47] <Jelle_> well the output link I just pasted
[19:48] <infinity> Right, using "sudo bash ./start-jira.sh" would fix the unexpected operator errors.
[19:48] <infinity> And I see no other errors.
[19:49] <infinity> Jelle_: Anyhow, this is very much not a support channel.  #ubuntu for Ubuntu support, or some Jira channel for Jira support would be much more appropriate.
[19:49] <Jelle_> Oh I'm sorry, I thought this would match devs
[19:50] <Jelle_> Couldn't find any jira support channel, excuse me!
[19:50] <sergiusens> Jelle_: only if it's for dev'ing ubuntu
[19:51] <Jelle_> i'm sorry :) good night!
[19:59] <Wellark> what super powers I need to be able to target bugs for ubuntu series?
[20:00] <Wellark> right now I can only nominate
[20:01] <Wellark> infinity: you probably know --^
[20:01] <ogra_> Wellark, #ubuntu-bugs does ...
[20:03] <Wellark> oh, we have such channel as well..
[20:04] <infinity> Wellark: There's a superpower team I can add you to if you make a solid argument for why you need to be in it.
[20:04] <infinity> Wellark: I'm heading out for lunch, so you have time to convince me while I'm gone. :P
[20:05] <Wellark> infinity: I'm upstream of i-network, unity-action-api and connectivity-api
[20:05] <Wellark> and would be easier for anyone if I get the powers to handle the targeting myself
[20:06] <Wellark> infinity: or other option is that I give you the list of multiple dozens of bugs and you can do the targeting for me ;)
[20:06] <Wellark> infinity: + there will be some other projects coming in during this cycle


[12:05] <ddaa> hello lifeless
[12:05] <ddaa> lifeless: I have a good news for you
[12:05] <sabdfl> ddaa: share!
[12:05] <ddaa> lifeless: I do not have anything VCS related to ask you about before going to bed today ;)
[12:06] <ddaa> sabdfl: just teasing rob :)
[12:07] <sabdfl> awwww :-/
[12:07] <sabdfl> the branch stuff is looking good
[12:07] <sabdfl> can you get kinnison and celso to show you the lp build control system during the distro sprint?
[12:07] <sabdfl> i'd like to blow away buildbot and make it all native
[12:07] <ddaa> thank you, I played a bit with the allbranches listing this afternoon and noticed there are quite a few non-import branches there
[12:08] <ddaa> maybe we could use an green/orange/red light icon to quickly see which branches are bogus or broken (according to the branch puller)
[12:09] <ddaa> sabdfl: you do not have to push me for that
[12:09] <ddaa> SteveA is arranging for me to meet Kinnison and celso on sunday June 25th.
[12:09] <sabdfl> we need to make that listing a touch more compact
[12:10] <sabdfl> ok cool
[12:10] <ddaa> We'll look for overlap between buildbot-ng and buildd-ng
[12:11] <sabdfl> right
[12:11] <ddaa> I think the listing is nice
[12:11] <ddaa> any more compact would be hard to read
[12:12] <ddaa> maybe it should exclude the vcs-imports branches
[12:13] <ddaa> sabdfl: btw, it would be nice to be able to delete some branches sometimes
[12:13] <ddaa> https://launchpad.net/people/vos-team/+branch/vos/main
[12:16] <lifeless> bradb: what do you think of the idea in bug 43893
[12:16] <Ubugtu> Malone bug 43893 in launchpad "Should be able to link to a wiki page with bug filing guidelines per source package." [Wishlist,Unconfirmed]  http://launchpad.net/bugs/43893
[12:18] <sabdfl> +1 but only medium priority (and you want a spec not a bug), lifeless
[12:21] <lifeless> sabdfl: yes, going to do a spec too
[12:21] <lifeless> sabdfl: was in the middle of a meeting - wanted a real fast 'write it down now'
[12:24] <lifeless> night ddaa
[12:29] <sabdfl> lifeless: one paragraph braindump and register it in the spec tracker, hmmk?
[12:29] <lifeless> sabdfl: just done that :)
[12:29] <lifeless> https://launchpad.net/products/launchpad/+spec/custom-bug-filing-instructions
[12:31] <sabdfl> v cool idea that
[12:31] <sabdfl> could even make them aggregate
[12:32] <lifeless> thanks :)
[12:32] <sabdfl> when filing on a package in ubuntu, show the custom message for ubuntu AND for that package-in-ubuntu
[12:32] <sabdfl> or product and project
[12:32] <lifeless> yes, that sounds nice
[12:32] <sabdfl> so Gnome can have one set of "this is how we do it" links, and GnomeBaker another
[12:32] <sabdfl> so, two paragraphs then
[12:33] <lifeless> on a conf call right now, will add that to the summary in a bit
[12:35] <sivang> lifeless: some packages have those instructions (noteably, GNOME) in the package itself. not sure if they follow a naming convention, if we got them to , LP could automatically extract this info from the source :)
[01:02] <lifeless> sivang: I'm inclined to walk before running here
[01:03] <lifeless> sivang: this isn't something that changes radically all the time, so providing a manual means to document it will improve the process immediately.
[01:03] <sivang> lifeless: 100%, was just a wild thought ;)
[01:42] <lalo> hey, quickie.  I registered a project; but the products I was thinking about are already auto-registered by vcs-import.  What's the procedure for requesting these to be transferred to the project?  I want to encourage the other upstream devs to use launchpad
[01:42] <lalo> or more generally... what's the procedure for admin requests?  Do I file a bug?  :-)
[01:53] <sivang> lalo: is it plone btw? :)
[01:53] <lalo> no, crossfire
[01:54] <lalo> I don't really contribute to plone anymore.  Or even use it.  But I haven't gained a new freenode cloak yet, so until some plone admin remembers to remove mine, I guess I'm keeping it :-P
[01:55] <lalo> it seems freenode has a bigger admin overhead for removing a cloak than for adding one
[01:55] <sivang> lalo: lol
[01:57] <sivang> lalo: crossfire as in online multi player game?
[01:57] <lalo> yes
[02:00] <sivang> lalo: anywas, you need one of the admins to do that for you, or you could probably open a bug about it and assign it to the registry admins, wait I'm trying to find you the team's name in LP.
[02:00] <lalo> crossfire :-P
[02:00] <lalo> both team and project are named crossfire
[02:00] <lalo> there are three products, crossfire, crossfire-client and crossfire-maps
[02:01] <lalo> there's a fourth, but this one wasn't registered yet, so I just registered it manually with the right ownership
[02:02] <sivang> lalo: this is team you need to assign the bug to, https://launchpad.net/people/registry
[02:02] <lalo> ok
[02:03] <lalo> ah, you meant the registry team, I thought you were referring to "my" team :-)
[02:03] <lalo> I open a bug on... where?  the launchpad product?
[02:04] <sivang> lalo: on the one you want to be merged in to the other
[02:04] <lalo> ok
[02:04] <sivang> lalo: and ask in the bug for it to be merged
[02:04] <lalo> not merged, just change ownership
[02:04] <sivang> lalo: sure, sorry, I am doing some other things in parallel ;-)
[02:05] <lalo> sigh
[02:05] <sivang> lalo: so change ownership of the one to be managed with the ownership of the auto imported one, then?
[02:05] <lalo> "       Crossfire does not use Malone as its bug tracker."
[02:06] <sivang> lalo: care to toss me the url?
[02:06] <lalo> ah, the product name is actually crossfire-server rather than crossfire
[02:06] <lalo> https://launchpad.net/products/crossfire-server
[02:09] <sivang> lalo: see if you can get this page https://launchpad.net/products/hubackup/+launchpad
[02:09] <sivang> lalo: for your product
[02:09] <sivang> lalo: then you can indicate of you guys are using rosetta and/or malone officically
[02:09] <sivang> lalo: then it will get updated IIRC
[02:10] <lalo> no :-) "Not allowed here"
[02:10] <lalo> obviously, only a maintainer can change launchpad usage
[02:11] <sivang> lalo: well, either the registrant of the product or, maintainer as named it , yes.
[02:11] <lalo> yeah.  And the registrant and maintainer are both the registry team :-)
[02:12] <sivang> lalo: okay, so then we go back to the bug report assigned to them :)
[02:12] <lalo> yes :-)
[02:12] <sivang> anyway, it's bedtime here for several hours already. night all.
[02:13] <lalo> I'll file it on launchpad
[02:14] <sivang> lalo: sub the registry team nonetheless, even if not assigning directly to them.
[02:15] <lalo> yes
[02:15] <lalo> I'll do either... if lp allows me to :-)
[02:15] <lalo> if not I'll just bug ddaa personally on irc, later :-P
[02:16] <sivang> lalo: it should :) night.
[02:18] <lalo> night
[02:18] <lalo> hmm, actually, looking at the list of support tickets for lp, it seems there _is_ a procedure for that after all... just file a support ticket at lp
[02:46] <hypatia> Hey launchpad folk (if any of you are awake).
[02:46] <hypatia> News from spiv: he's been excused from jury duty for the long (10 week) trial. He is going up for selection for a short trial.
[02:47] <hypatia> So even if he gets selected, he will be off for max 2 weeks.
[02:54] <sivang> hypatia: jury duty is in .AU as well? :)
[02:54] <hypatia> Yes, we have trial by jury.
[02:54] <sivang> cool :)
[02:55] <hypatia> spiv was summoned for a trial and we were very worried about it because it was meant to be 10 weeks long.
[02:55] <hypatia> But apparently he has been allowed to move to selection for a shorter trial.
[02:56] <sivang> good to know
[03:17] <sabdfl> morning mpt__
[03:17] <sabdfl> hypatia: that's good news. spiv will be a good juror
[03:18] <hypatia> sabdfl: He hasn't made it to that stage yet, he's still at selection. I don't mind him being a good juror as long as it's not 10 weeks!
[03:19] <sabdfl> hypatia: agreed :-)
[03:19] <sabdfl> night all
[04:40] <lifeless> good news
[04:40] <lifeless> spiv got a get out free card
[04:41] <stub> Too many people turned up, or they decided he was an unreliable juror?
[04:41] <lifeless> not sure
[04:41] <stub> I told him that claiming to be pregnant would work
[04:44] <jbailey> 0.8 uploaded to DApper
[04:46] <mpt> Must have been the ponytail
[04:46] <stub> jamesh, lifeless: Can I get a trivial review? https://chinstrap.ubuntu.com/~dsilvers/paste/filetLjlVl.html
[04:49] <lifeless> if team.id == self.id: - is 'team is self' or 'team == self' equivalent ? they would be clearer I think
[04:51] <lifeless> do we have a consensus on the abuse of class attributes to provide defaults ?
[04:51] <lifeless> +    # XXX: This cache should no longer be needed once CrowdControl lands,
[04:51] <lifeless> +    # as apparently it will also cache this information.
[04:51] <lifeless> +    _inTeam_cache = None
[04:51] <lifeless> +
[04:51] <lifeless> that really should in in __init__ imo
[04:51] <jamesh> stub: for correctness, would you need to clear entries from the cache in _cleanTeamParticipation()?
[04:52] <stub> I couldn't remember if SQLObject instances had standard __init__ methods you can mess with
[04:52] <jamesh> or maybe _removeParticipationFromTeamAndSuperTeams() would be the place to do it
[04:53] <stub> Where is this _cleanTeamParticipation?
[04:55] <stub> Ahh... I see.
[04:56] <stub> That will not be necessary - TeamParticipation is only messed with by the Person instances, so we can keep it nicely encapsulated and clear the caches in the same class that populates it.
[04:57] <stub> Clearing the cache is likely not even necessary - I just did it to guarantee no tests would break.
[05:01] <jbailey> mpool: I've sent the email.
[05:01] <jbailey> mpool: If there's more you want to add in, that would be lovely.
[05:02] <jamesh> stub: don't we call TeamMembership.setStatus() in the team management pages?
[05:02] <jbailey> Whups, ECHAN
[05:02] <jamesh> and changing the membership status can result in TeamParticipation records being deleted
[05:03] <dilys> Merge to devel/launchpad/: [trivial]  forgot to bzr add the pagetest for bug 39011 (Add distro packaging form needs input validation) (r3544: Diogo Matsubara)
[05:03] <Ubugtu> Malone bug 39011 in launchpad "Add distro packaging form needs input validation" [Major,Fix committed]  http://launchpad.net/bugs/39011
[05:07] <stub> jamesh: The worst that can happen in that case is an admin remains a member of a team that they just removed themselves from for the remainder of the transaction.
[05:07] <stub> I might clear it there too for laughs anyway though.
[05:08] <jamesh> stub: so inTeam is only used for auth checks against the current user?
[05:08] <stub> we only ever do auth checks for the current user
[05:09] <jamesh> but is inTeam() used for things other than auth checks?
[05:09] <stub> Nope
[05:10] <stub> We ask teams for lists of members, which is different (and not cached)
[05:10] <stub> But don't ask random people if they are members of particular teams
[05:10] <stub> I've added the clear at that point anyway, and a test too now I've realized I can test this a bit.
[05:11] <jamesh> fair enough
[05:11] <stub> Bah - need to unwrap the person to poke at their internals :-(
[05:12] <jamesh> or get participation.person
[05:12] <jamesh> which won't be security wrapped
[05:15] <stub> jamesh: https://chinstrap.ubuntu.com/~dsilvers/paste/fileqn1eli.html
[05:20] <jamesh> stub: looks good
[05:20] <stub> r=jamesh ?
[05:21] <jamesh> yeah
[05:28] <lifeless> stub: I'd still prefer the _inTeam_cache be declared in __init__
[05:29] <stub> Do we have other code overriding SQLObject __init__ methods?
[05:29] <lifeless> ah, if we dont then thats fine as is
[05:29] <lifeless> I'll discuss it with spiv as a general issue later
[05:31] <stub> We don't seem to have any - I'm not sure if it can be done or if it involves magic.
[06:38] <mpt> jamesh, got five minutes spare to answer some silly questions of mine?
[06:38] <jamesh> sure
[06:39] <mpt> jamesh, I'm trying to run a CGI on localhost, to test the new menus stuff
[06:39] <mpt> and I thought oh, that'll be easy, I have Apache installed already for LP development
[06:39] <mpt> then I discovered that I didn't
[06:40] <mpt> and nor do I appear to have Zope installed
[06:40] <jamesh> "sudo aptitude install apache2" should give you a basic apache install to play with
[06:41] <mpt> and launchpad-dependencies' dependencies don't include anything that looks like a server
[06:41] <jamesh> I don't really know much about getting Zope running outside of the LP tree
[06:41] <mpt> so, I'm missing one or two obvious things
[06:41] <jamesh> the server you start when you do "make run" in your LP tree is a Python web server
[06:42] <mpt> ahhh, and Zope doesn't show up as being installed because it's just part of the Launchpad codebase?
[06:42] <jamesh> yep
[06:43] <mpt> ok, thanks
[07:20] <stub> Weee.... new bzr
[07:55] <robitaille> what's the best way to request a comment to be removed from a Malone bug report?  The last comment in bug 34490 is some sort of spam
[07:55] <Ubugtu> Malone bug 34490 in imagezoom "Postinst and postrm fail to complete leaving dpkg in a broken state" [Major,Confirmed]  http://launchpad.net/bugs/34490
[08:00] <jamesh> robitaille: we don't have a mechanism to remove comments
[08:01] <robitaille> jamesh:  so we stuck with that junk comment forever?
[08:02] <jamesh> I guess so
[08:34] <stub> robitaille: We will get the feature at some point
[08:34] <stub> robitaille: They can be removed - I just have to do it manually
[08:35] <robitaille> stub: ok.  thanks
[09:27] <carlos> morning
[09:53] <mpt> SteveA, ping
[09:55] <carlos> lifeless: latest bzr from dapper removes bzrtools, is that normal?
[09:56] <SteveA> mpt: on phone...
[09:58] <lifeless> carlos: just means bzrtools wasn't uploaded at the same time
[09:58] <carlos> ok
[10:10] <SteveA> mpt: ping
[10:11] <SteveA> lifeless: what do i need to do to get "tickcounter" into sourcecode?
[10:11] <lifeless> SteveA: put it in a bzr branch
[10:11] <lifeless> give it a Makefile with a 'build' and 'check' target
[10:11] <lifeless> they can be stubs if there is nothing to do
[10:11] <lifeless> email me
[10:12] <SteveA> ok, cool
[10:12] <SteveA> thanks
[10:17] <mpt> lifeless, how do I get apache2 to treat a CGI as a CGI?
[10:17] <jamesh> SteveA: given the "make clean" problems with pygettextpo, it might be worth putting the extension module in a package
[10:18] <lifeless> mpt: script-alias usually
[10:18] <jamesh> SteveA: so that "make clean" in the sourcecode directory doesn't result in a dangling symlink in lib/
[10:18] <mpt> lifeless, /etc/apache2/sites-available/default has "+ExecCGI" for a parent directory of the directory containing the .cgi
[10:18] <mpt> but it still gets treated as plain text
[10:18] <SteveA> jamesh: you mean in a subdirectory with an __init__.py ?
[10:18] <jamesh> SteveA: yeah
[10:18] <SteveA> jamesh: ok
[10:18] <lifeless> SteveA: better yet, if its going to be mostly static an unchanging, put it in a deb, open source it, and stash it in ubuntu
[10:19] <SteveA> lifeless: yes, that would be nice.  however, i am not going to do that
[10:19] <SteveA> i'm am quite happy for someone else to do so
[10:19] <jamesh> SteveA: you can probably steal the Makefile from pygpgme almost unchanged too
[10:19] <SteveA> my only goal is to have this available for QA work on launchpad
[10:20] <lifeless> SteveA: if thats a preferrable option, we can package it up quickly.
[10:20] <SteveA> lifeless or jamesh: are either of you interested in packaging it?
[10:21] <lifeless> happy to do so, packaging a python module is quite easy :)
[10:21] <SteveA> in the next day or two?
[10:21] <jamesh> I haven't gotten round to learning debian packaging yet
[10:21] <sivang> re all
[10:21] <jamesh> I probably should at some point
[10:21] <lifeless> SteveA: I could do it tomorrow I think
[10:22] <SteveA> lifeless: okay.  thanks.  i'll make changes from jamesh's code review today, and put a bzr branch up somewhere and mail you
[10:23] <lifeless> mpt: I'm not sure that a bug reporting template matches what I am proposing
[10:23] <lifeless> mpt: see the spec https://launchpad.net/products/launchpad/+spec/custom-bug-filing-instructions for an expanded summary
[10:25] <jamesh> mpt: try creating a file /etc/apache2/conf.d/dotcgi containing the line "AddHandler cgi-script .cgi"
[10:25] <jamesh> mpt: restarting apache afterwards
[10:30] <SteveA> mpt: i'd like to have that skype call now.  i have other things to do in 30 mins.
[10:37] <Znarl> We are preforming network testing in the data centre for the next hour.  This may result in a small amount of connectivity problems to the data centre.
[11:07] <Znarl> Network testing has finished.
[11:07] <lifeless> mpt: ping
[11:09] <mpt> lifeless, pong
[11:09] <lifeless> 18:23 < lifeless> mpt: I'm not sure that a bug reporting template matches what I am proposing
[11:09] <lifeless> 18:23 < lifeless> mpt: see the spec https://launchpad.net/products/launchpad/+spec/custom-bug-filing-instructions for an expanded summary
[11:10] <lifeless> I think you've inappropriately turned my bug into a duplicate
[11:10] <lifeless> they are certainly related.
[11:10] <lifeless> but I disagree about being the same.
[11:10] <mpt> lifeless, that pretty much matches what I thought the original was about
[11:11] <mpt> hmmm
[11:11] <mpt> though the cascading is a bit more complicated
[11:11] <lifeless> the way I read the template concept its about giving a customised malone input screen
[11:11] <lifeless> with things to tab between, space to attach multiple files etc
[11:12] <mpt> They're the same underlying problem, right?
[11:12] <mpt> I mean, we wouldn't have the template solution and the custom instructions solution simultaneously
[11:12] <lifeless> what I'm talking about is much lower tech, its about bringing in documentation from the project's web page, as a link. And the cascade *may* be cuteness, or may be essential, dont know yet.
[11:13] <lifeless> for instance, you might want the user to *read* the documentation, *then* follow a guided input form.
[11:13] <lifeless> the guided input form is what I think your templates are about
[11:14] <mpt> ok
[11:14] <lifeless> does this make sense? Do you agree they are separate things? Or should I leave it as a dup ?
[11:15] <mpt> I'm just un-dupping them
[11:15] <lifeless> thanks
[11:15] <mpt> and I'll move the paragraph I added to 3383 to 43893 instead
[11:16] <mpt> I like the idea of including product-/package-/prorject-/distro-specific instructions
[11:17] <mpt> but I think linking to an external page would be a waste of time - people won't read it
[11:22] <SteveA> mpt: you're back!
[11:22] <mpt> SteveA, yes, had to reset the router, then send my mail to guido
[11:40] <BjornT> SteveA, stub: re bug 39393, it seems to fail since we import * from zope.app.testing.functional in canonical.functional. what's the reason for importing * instead of importing everything we need explicitly?
[11:40] <Ubugtu> Malone bug 39393 in launchpad "Import fascist disabled" [Normal,Unconfirmed]  http://launchpad.net/bugs/39393
[12:13] <sabdfl> SteveA: call?
[12:14] <sabdfl> 1pm today?
[12:14] <SteveA> sabdfl: i've got a call scheduled with you for 1h45 from now
[12:14] <SteveA> conf call with kiko
[12:14] <sabdfl> ok great
[12:15] <aa_> hi :)
[12:15] <aa_> is the email interface the only remote procedural way I can do bug reports to launchpad?
[12:15] <aa_> I have just moved from trac, and I need to update my applications bug reporting tool
[12:15] <SteveA> aa_: hello
[12:16] <SteveA> right now, yes
[12:16] <SteveA> we'll be doing an xmlrpc interface in the near future
[12:16] <aa_> I love Malone, by the way. I was actually writing my own tracker, until I found it
[12:16] <SteveA> but it won't be ready for a little while
[12:16] <SteveA> cool, thanks for the feedback
[12:16] <aa_> need a hand? or all in-house stuff?
[12:16] <SteveA> please do file bugs on malone when you find things you'd like to be improved
[12:17] <SteveA> it's in-house, although if you want to be involved in writing clients for it, we should talk sometime
[12:17] <aa_> ok, will do, I would love it to have a wiki, not in Malone per se, but as part of the launchpad mega-app
[12:17] <SteveA> yeah, me too
[12:17] <SteveA> sorry -- got a phone call to have now
[12:17] <aa_> SteveA: I have to write a client for it before y next release, I have no choice :)
[12:17] <aa_> ok, thanks for helps
[12:21] <aa_> oh woo, I guess would it be allowed if I wrote a script that accepts http POST requests and files them as bugs by email?
[12:21] <aa_> I just can't force my users to register a GPG key with launchpad
[12:42] <SteveA> aa_: what do you want to do?
[12:42] <SteveA> are you talking about importing your data into launchpad?
[12:46] <dilys> Merge to devel/launchpad/: [r=SteveA]  Fix bug 36866 (Searching for bugs after selecting a certain status from the Right-Hand-Menu resets the search) (r3545: Brad Bollenbach)
[12:46] <Ubugtu> Malone bug 36866 in malone "Searching for bugs after selecting a certain status from the Right-Hand-Menu resets the search" [Major,In progress]  http://launchpad.net/bugs/36866
[12:53] <fabbione> hey guys
[12:53] <fabbione> SteveA: this is for you too :)
[12:53] <fabbione> so i am trying to get an idea on how many bugs our X has
[12:53] <fabbione> and this is getting kind of hard
[12:53] <fabbione> the "Package Reports" has no summary
[12:54] <fabbione> the "Subscribed" includes packages that are not X related
[12:54] <fabbione> there is no way to exclude bugs that have been fixed in Ubuntu or do not apply to ubuntu (like the ones imported from Debian)
[12:55] <fabbione> i will pretty much like to have an idea of what is the status of what i maintain
[12:56] <fabbione> what can i do other than start summing up manually the numbers from "Package Reports"?
[12:56] <SteveA> hi fabbione
[12:57] <SteveA> so, i want to know a bit more about X
[12:57] <SteveA> i guess there are several X packages
[12:57] <fabbione> SteveA: tons yes
[12:57] <SteveA> and you want to know about them as a group, all together
[12:57] <SteveA> is this what you're asking about?
[12:57] <SteveA> (at least in part)
[12:58] <fabbione> i am team foo and i maintain N pkgs..
[12:58] <fabbione> i want to know how many bugs i have in total
[12:58] <fabbione> i can see the summary per package already
[12:58] <SteveA> okay, so i can see all the X related packages, because one particular team is the maintainer for just these packages
[12:59] <SteveA> (sorry that i'm being slow.  i don't have much experience in exactly how the distro team use malone at this level)
[01:00] <fabbione> SteveA: no problem..
[01:00] <fabbione> https://launchpad.net/people/ubuntu-x-swat/+packagebugs
[01:00] <fabbione> here
[01:00] <fabbione> this is the page i am talking about
[01:00] <fabbione> this page only shows ubuntu bugs
[01:00] <fabbione> but no summary
[01:00] <fabbione> so i can't say for example that in warty i had 150 bugs and in dapper with have 250
[01:01] <fabbione> because there is no summary
[01:01] <fabbione> so i can't track the progress
[01:01] <SteveA> are you asking for a summary for each table column?
[01:01] <fabbione> yes
[01:02] <fabbione> but how can i do it on they fly now without waiting a rollout in 3 months?
[01:03] <SteveA> if you want the sum of the numbers for each table column on that page, that's easy to do
[01:03] <SteveA> and i can get that into production quite fast
[01:04] <fabbione> ok thanks
[01:04] <SteveA> anything other than adding that "totals" row?
[01:05] <fabbione> well i would like to be able to exclude bugs in other distros from the advanced search
[01:06] <SteveA> fabbione: for advanced bug search, talk with kiko/brad later today
[01:06] <fabbione> SteveA: i won't be around later.. do you think you can proxy my request?
[01:06] <fabbione> it's my wife bday
[01:06] <fabbione> and i will be dragged all over
[01:06] <SteveA> i'll pass on what you just said
[01:07] <fabbione> thanks
[01:07] <fabbione> i don't mind if you copy/paste from here...
[01:07] <SteveA> but i also need to know
[01:07] <fabbione> or whatever
[01:07] <SteveA> what is the reason this feature is important to you right now?
[01:08] <SteveA> you explained why you need the "totals" part on the package bugs page
[01:08] <fabbione> because i know for a fact that i had ~100 bugs in X warty, 150 in hoary and 200 in breezy
[01:08] <fabbione> i want to know how the progression goes
[01:09] <fabbione> compared to our approx user base
[01:09] <SteveA> so, are you talking about wanting to select not just the distro but the distrorelease
[01:09] <fabbione> that gives me an idea if we are doing bad or good
[01:09] <SteveA> in the advanced search form?
[01:09] <fabbione> no no.. this is just for the totals
[01:09] <fabbione> i can keep track manually of that number
[01:09] <fabbione> for the advanced search it's enough i can filter by distro
[01:09] <fabbione> because when i go bug hunting i don't care to see baltix or Debian problems
[01:10] <fabbione> i want to see what affects ubuntu only
[01:10] <SteveA> i see
[01:10] <SteveA> okay, that's clear
[01:10] <SteveA> i'll talk with kiko later
[01:10] <fabbione> when i open the bug then i can see if it affects debian or baltix too
[01:10] <fabbione> for example
[01:10] <SteveA> yep
[01:10] <fabbione> thanks SteveA
[01:10] <SteveA> enjoy the bday
[01:19] <aa_> oh shoot
[01:19] <aa_> SteveA: I want to submit bug reports to malone over http
[01:19] <aa_> more importantly, anonymous bug reports I guess
[01:22] <lifeless> aa_: what differentiates anonymous bug reports from spam ?
[01:23] <aa_> well, the plan is to send the annonymous ones to me, and I would sign them and send them as email
[01:23] <aa_> and well, maybe a spammer would work out the weird rpc I use, but I doubt they would bother
[01:24] <aa_> I don't get it, do spammers often submit bug reports?
[01:24] <aa_> I have seen wiki pages mutilated, but bug reports?
[01:25] <lifeless> debian had huge bug spam problems
[01:25] <lifeless> before it got its cross assassin etc shit all together
[01:25] <aa_> so um, basically providing a way for my users to submit anonymous bug reports is um utterly no no
[01:26] <lifeless> well
[01:26] <lifeless> its something that should be done with due care and caution
[01:26] <lifeless> who are your users ?
[01:27] <aa_> a gui application
[01:27] <aa_> um, developers I guess, it is an IDE
[01:27] <lifeless> do you think they are unlikely to create accounts on launchpad ?
[01:27] <lifeless> developers seem clueful enough to do it to me
[01:27] <aa_> not at all, I am actually sure most would
[01:28] <lifeless> so why do you need anonymous bug reports ?
[01:28] <aa_> but it is the few that wouldn't even know what it all was
[01:28] <aa_> if anythiong, those are the ones who need it most
[01:28] <aa_> but yes, you are right
[01:33] <aa_> unfortunately, the issue blocks my next release. Would it be reasonable to submit a bug against launchpad so that there can be some discussion about anonymous reports, or has it already been discussed?
[01:33] <lifeless> it has come up a lot
[01:33] <lifeless> I'm not sure if there is an informational spec about it or not
[01:34] <aa_> I will, just get them sent to myself
[01:34] <aa_> and then pass them on to launchpad after ensuing they are not spam
[01:34] <aa_> yeah, I suspected it had been discussed a lot :)
[01:36] <aa_> in an ideal world, I would make users have a gpgp key etc and email them in, but well, that ain't ever going to happen
[01:36] <`6og> hi sivang
[01:37] <aa_> that would save the whole "save password" stuff
[01:45] <sivang> hey kgoetz :) what's up?
[01:46] <kgoetz> :) just going through my bug email, and trying to get stuff done so i can start learning python and c (again...)
[01:47] <kgoetz> sivang: what's been happening mate?
[01:48] <sivang> aa_: I'd say you better try and educate them to open accounts on LP, might be more worthwhile then setting up all this juggelry. You could attached documentation inside your IDE for how to do so. /me notes this could be a good use for a client app style GNOME launchpad. (proposed as SoC project)
[01:48] <kgoetz> i just looked for my external usb hdd to test an hubackup bug (or comment on). cant find the bugger :S
[01:49] <sivang> kgoetz: let's take this to #u-devel okay?
[01:49] <kgoetz> sivang: sure
[01:49] <sivang> kgoetz: other then that everything's fine, but reports continue to flow in :)
[01:49] <aa_> sivang: right, I wish I was a student, and I only have a few days to write it, not all summer, but yes it will be a pygtk launchpad client of sorts
[01:50] <sivang> aa_: There's a proposal for that sort of app, we'll see how to progresses :)
[01:50] <aa_> oh excellent, you don't happen to have a url do you please?
[01:51] <aa_> one of my developers was wanting to do this, he is a student, and well, he actually wanted to write a front-end for all bug trackers, but he might be interested in this
[01:55] <cprov> good morning, hackers
[01:57] <sivang> aa_: lemme see if I can find it
[01:58] <sivang> aa_: actually, application were already due.
[01:58] <ploum> hello
[01:58] <ploum> sivang: are you a MOTU today ?
[01:58] <sivang> aa_: https://wiki.ubuntu.com/GoogleSoC2006#head-c63d73c3e2785fdb9f52077630b50dcac426b2ad
[01:59] <sivang> ploum: I am :-)
[01:59] <ploum> cool :-)
[01:59] <ploum> congratulations
[01:59] <ploum> I just see you were talking about a Gnome frontend to launchpad
[02:00] <ploum> any news from the SoC about this ?
[02:01] <salgado> stub, around?
[02:01] <sivang> ploum: let's continue on -motu
[02:10] <aa_> sivang: any idea how they were planning on doing "It must have an automated launchpad account registration.
[02:14] <sivang> aa_: no idea, this is still in the idea phase IMHO.
[02:14] <aa_> oh, fair enough
[02:15] <aa_> would be nice if it was more generic, that could be used in other applications other than ubuntu
[02:15] <aa_> and someone has drafted a proposal, he says he needs a mentor
[02:15] <aa_> https://launchpad.net/distros/ubuntu/+spec/smart-bugreporting-tool
[02:17] <aa_> oh well, meeting time. Thanks for the helps
[02:17] <sivang> aa_: np, apologies for not being to help furhter.
[02:18] <aa_> never hire an open source programmer, he hacks on his own stuff in lunch! muahah
[02:24] <sivang> aa_: you just need to make his stuff your stuff, and you're set :)
[02:29] <sabdfl> SteveA, kiko-zzz: now ok?
[02:29] <lifeless> night all
[02:29] <sabdfl> night lifeless
[02:29] <SteveA> sabdfl: sure.  i'll dial in
[02:30] <SteveA> kiko will be here shortly
[02:33] <matsubara> carlos: ping
[02:33] <carlos> matsubara: pong
[02:33] <matsubara> carlos: have you seen OOPS-129D14?
[02:33] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/129D14
[02:35] <carlos> sure
[02:35] <matsubara> carlos: is there a bug open on it?
[02:37] <carlos> matsubara: the bug there is that we are not showing a 404 error, you know that, right?
[02:37] <carlos> and no, I don't think we have a bug for it
[02:37] <matsubara> carlos: right, I'll report it then.
[02:38] <carlos> matsubara: ok, thanks
[02:38] <matsubara> carlos: assign it to you?
[02:38] <carlos> matsubara: yes, please
[04:17] <kiko-zzz> hello hello
[04:26] <SteveA> kiko: i have two feature requests from fabionne i said i'd mention to you
[04:26] <kiko> oh?
[04:26] <SteveA> 1. https://launchpad.net/people/ubuntu-x-swat/+packagebugs
[04:27] <SteveA> he'd like totals for each column added to that page
[04:27] <kiko> okay
[04:27] <SteveA> so he can see how many bugs that team has open on ubuntu altogether
[04:27] <SteveA> 2. he wants to be able to find bugs that have ubuntu bugtasks from the advanced search page
[04:28] <SteveA> because right now, he is concerned only with ubuntu bugs
[04:28] <SteveA> not bugs with upstream or other distro tasks
[04:28] <kiko> I am confused by request #2
 for the advanced search it's enough i can filter by distro
 because when i go bug hunting i don't care to see baltix or Debian problems
 i want to see what affects ubuntu only
[04:28] <kiko> that's what /distros/ubuntu/+bugs is
[04:29] <kiko> I don't quite see... oh
[04:29] <kiko> is he talking about the +packagebugs assigned view?
 well i would like to be able to exclude bugs in other distros from the advanced search
[04:29] <SteveA>
[04:30] <kiko> well /which/ advanced search?
[04:30] <SteveA> you'll have to ask the padrino
[04:30] <SteveA> he's away this afternoon though
[04:30] <kiko> heh
[04:30] <kiko> ok
[04:31] <SteveA> btw, http://en.wikipedia.org/wiki/Tuva_or_Bust
[05:01] <kiko> heh
[05:15] <kiko> uhm
[05:15] <kiko> carlos?
[05:15] <carlos> kiko: yes?
[05:16] <kiko> carlos, should we go over the rosetta import statistics for a bit?
[05:16] <kiko> how are they looking?
[05:17] <carlos> well, is not a good moment atm, I'm finishing the extra testing for PoMsgSet that BjornT asked and I was planning to take a look to all missing entries, we could do it after my review
[05:17] <kiko> that's great.
[05:17] <kiko> okay.
[05:27] <aa_> surely not async kiko!
[05:27] <kiko> aa_, the one and only!
[05:28] <aa_> heh, I am ali, a kiwi user :)
[05:28] <kiko> well I knew that already :)
[05:28] <aa_> :P
[05:29] <aa_> kiko: you guys wrote launchpad?
[05:29] <aa_> oh ignbore me I am on crack
[05:29] <kiko> well, we work on part of it.
[05:30] <aa_> nice one, I just discovered it, but am desperate to get a gtk reporting tool going
[05:31] <kiko> tell me about your problems
[05:31] <aa_> well, it all started when I was a child...
[05:31] <aa_> maybe even before then
[05:32] <kiko> let's fast-forward a bit
[05:32] <aa_> ok ok, well I can't decide whether to use email or https or wait for the XMLRPC
[05:32] <aa_> strikes me all have pros and cons
[05:32] <kiko> email is nice because it is store-and-forward
[05:32] <kiko> but it's async
[05:32] <kiko> https is very easy
[05:33] <aa_> and needs gpg signing
[05:33] <kiko> to file new bugs? mmmm
[05:33] <aa_> yeah
[05:33] <kiko> okay let me be quiet as I may just have gotten myself in trouble there :)
[05:33] <aa_> yikes, best not to do that
[05:33] <kiko> general XMLRPC is on its way; we could add a bug-filing API pretty easily
[05:34] <aa_> well SteveA mentioned it is on the cards
[05:34] <kiko> using https is in the short term effective and very easy
[05:34] <aa_> well, people still need a launchpad account
[05:34] <aa_> but yes I agree, https
[05:35] <aa_> and an excuse to learn how to programmatically sign emails
[05:36] <aa_> oh and https adds a dependency
[05:37] <aa_> and signup still needs email
[05:38] <kiko> aa_, a dependency? httplib?
[05:39] <aa_> pyopenssl
[05:39] <aa_> I am just guessing
[05:40] <aa_> (not a biggie, except I get mercilessly flamed by my users for each new dependency)
[05:40] <aa_> you should have seen the day I switched to Kiwi :P
[05:41] <aa_> zakame: ping?
[05:42] <kiko> aa_, no, urllib/httplib do https.
[05:42] <aa_> oh good one, thanks
[05:42] <aa_> zakame: I saw your proposal for the bug reporting client, I am interested in helping and discussing with you, please /msg me any time, thanks
[05:42] <kiko> >>> import urllib
[05:42] <kiko> >>> urllib.urlopen("https://launchpad.net")
[05:42] <kiko> <addinfourl at 806357432 whose fp = <httplib.SSLFile instance at 0x301009e0>>
[05:42] <kiko> aa_, enjoy
[05:43] <aa_> :) thanks
[05:45] <aa_> I *love* screen scraping
[05:45] <aa_> is there a sandbox pproject on launchpad that I can use for testing things?
[05:46] <ddaa> staging.launchpad.net
[05:46] <aa_> wow, thanks
[05:46] <kiko> you can use anything on staging, it's blown away nightly
[05:46] <ddaa> it runs the latest crack of the minute code too
[05:46] <aa_> mm, crack
[05:47] <aa_> so jsut to doubly reiterate, no one will mind me posting 100 bugs to staging
[05:47] <ddaa> absolutely not
[05:47] <ddaa> just be ready to do it again tomorrow
[05:48] <aa_> haha
[05:48] <lalo> kiko: thanks a lot
[06:02] <fabbione> kiko: one second and i will show you
[06:02] <kiko> fabbione, email or bugs would be better, I'm juggling like crazy
[06:02] <fabbione> kiko: ok
[06:11] <kiko> matsubara, in your analysis, if you can say "Existing bug" when it is existing it will help me somewhat
[06:11] <kiko> matsubara, as for the out of order sql queries, one idea might be looking at the server logs, considered that?
[06:12] <kiko> matsubara, at the server sql logs, more precisely
[06:14] <matsubara> kiko: where can I find they? There's no reported bug for the +bugs page yet.
[06:16] <carlos> BjornT: hi, around?
[06:17] <BjornT> hi carlos
[06:17] <carlos> BjornT: I'm trying to write tests for the traversal code as you requested in your review
[06:18] <carlos> BjornT: but I don't know how to write doctests for it
[06:18] <carlos> I tried using a method that is not supported by my code ('PUT') and I don't get any error. Are the pagetests the only way to test the traversal code?
[06:19] <carlos> I guess that I don't get errors because the traversal code is not executed with getView()
[06:20] <carlos> zope.component.getView
[06:21] <kiko> matsubara, I think only stub can see them.
[06:21] <kiko> matsubara, what +bugs page?
[06:21] <BjornT> carlos: i was thinking that you should test it by manually creating an instance of the class, passing a IPOFile and a test request. then you'd call .traverse(name) manually and check what it returns.
[06:21] <carlos> ok, so that's the way to test it.
[06:21] <carlos> I was not sure if there was a better way to do it
[06:21] <kiko> matsubara, also, about the +bugs search timeout, I think stuart wrote an analysis on it to the launchpad list
[06:22] <carlos> BjornT: thanks
[06:22] <stub> matsubara, kiko: What do we need logged? Full logging isn't running on production at the moment.
[06:23] <kiko> stub, I'm trying to see if we can find a way to tackle the apparently-out-of-order queries we are seeing occasionally.
[06:24] <matsubara> kiko: he answered the email pointing to the bug. thanks stub.
[06:24] <kiko> yep
[06:47] <aa_> oh well, this isn't easy, or too easy
[06:48] <aa_> before I try everything under the sun, any ideas what the crucial part of the login procedure is?
[06:48] <aa_> I have got a cookie, and I have a form I am trying to send to,
[06:48] <aa_> oh I am making no sense!
[06:49] <aa_> maybe missing to send something on the login form, something like the submit buttons, do they get passed to the form handler?
[06:50] <aa_> oh that totally worked!
[07:00] <aa_> muahah https://staging.ubuntu.com/products/bzr/+bug/43906
[07:09] <carlos> aa_: congratulations ;-)
[07:09] <kiko> aa_, you can also use basic auth, ftr
[07:17] <Keybuk> random
[07:17] <Keybuk> would it be possible for a source package to have a "default" upstream?
[07:17] <Keybuk> so when you click on "+ Upstream" on the bug, it automatically fills in the product and Bug tracking system for you?
[07:17] <kiko> what does that mean?
[07:18] <Kinnison> Umm 'source package' is an ephemeral concept
[07:18] <kiko> oh
[07:18] <kiko> Keybuk, done via packaging, for instance?
[07:18] <Keybuk> for instance
[07:18] <Kinnison> that's an idea
[07:18] <kiko> yes, that'd be doable, we've discussed it before
[07:18] <Keybuk> Kinnison: only to Launchpad developers
[07:19] <Kinnison> Keybuk: true
[07:19] <Keybuk> should I file a wishlist somewhere for that?  where?
[07:19] <Kinnison> probably against the launchpad product since it's a concept which would be used all over the place
[07:27] <kiko> Keybuk, it's actually malone, I think
[07:28] <Keybuk> bug 44052
[07:29] <Ubugtu> Malone bug 44052 in launchpad "Default upstream bug reporting details" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/44052
[07:31] <aa_> kiko: hmm, basic auth would only have saved me two hours
[07:31] <kiko> aa_, now you're being cruel
[07:33] <aa_> hehe, oh forgive me master
[07:33] <aa_> cookie auth rules though
[08:13] <bradb> BjornT: Any news on that testbrowser exception I showed you the other day? Is there a bug report open anywhere or should I open one?
[08:15] <BjornT> bradb: i plan to fix it tomorrow. there's no bug open on it.
[08:16] <bradb> BjornT: Should I open the bug on the Launchpad product?
[08:16] <BjornT> bradb: yeah, that'd be good.
[08:19] <kiko> carlos, how are your 1-2h going today?
[08:19] <carlos> not yet started
[08:19] <kiko> carlos, don't forget to start :)
[08:19] <carlos> I was distracted this morning
[08:19] <carlos> yeah, don't worry
[08:19] <kiko> it's easy to get bogged down and not swap
[08:20] <carlos> kiko: I was thinking on doing the translation domains review as part of that 1-2h slot
[08:21] <kiko> okay, sounds good
[08:21] <kiko> a task which can start and end in the allotted time
[08:21] <carlos> right
[08:21] <dilys> Merge to devel/launchpad/: [r=jamesh]  Person.inTeam caching to avoid timeouts (r3546: Stuart Bishop)
[08:22] <kiko> no way
[08:22] <kiko> no way
[08:22] <kiko> no way!
[08:22] <kiko> teamparticipation caching?
[08:22] <kiko> and no CC?
[08:22] <kiko> SteveA?
[08:22] <SteveA> yeah, it's cool
[08:22] <SteveA> minimal performance hack.  it'll get more elegant with CC
[08:23] <kiko> we just lost the one thing I could wave around to make you work on it!
[08:23] <SteveA> btw...
[08:23] <kiko> about that dvd? :)
[08:23] <SteveA> stu's landing did two trivial unrelated things too
[08:23] <kiko> grumble
[08:23] <SteveA>       Enable XMLRPC listener on production
[08:23] <SteveA>       Don't bitch about CVEs without descriptions, as the datasource is external and we just have to cope
[08:23] <kiko> that's so stub
[08:24] <kiko> so XMLRPC can be used now
[08:24] <kiko> nice
[08:24] <SteveA> that's so "branches are more expensive than they should be"
[08:24] <kiko> so or cause?
[08:24] <SteveA> that's *so*
[08:24] <SteveA> val speak
[08:24] <kiko> I see
[08:24] <kiko> he could have done 3 merges
[08:24] <SteveA> the next format would be cooties
[08:25] <kiko> then again, merges take 4h minimum each
[08:25] <SteveA> yeah
[08:25] <SteveA> apparently gcc has a huge test suite
[08:25] <SteveA> so they don't run it on every commit, so jbailey tells me
[08:25] <SteveA> OTOH, stu tells me there are some simple things he's looking at to make the test suite faster
[08:25] <SteveA> to do with faster DB and librarian setup/teardown
[08:35] <bradb> BjornT: bug 44064
[08:35] <Ubugtu> Malone bug 44064 in launchpad "Pagetest using testbrowser causes ValueError and AttributeError" [Normal,Confirmed]  http://launchpad.net/bugs/44064
[08:41] <BjornT> thanks
[09:03] <carlos> BjornT: tomorrow, I will need your help for the widget usage you suggested for the language selector
[09:04] <carlos> I have more or less done, but I had to do a needed small change, and I'm not able to get it working
[09:04] <carlos> I need to switch tasks now
[09:05] <kiko> rock on carlos
[09:06] <aa_> well, nothing amazing I guess, but: http://pida.berlios.de/images/br.png gives https://staging.ubuntu.com/products/bzr/+bug/43925
[09:36] <sabdfl> kiko: there is definitely an oops
[09:36] <sabdfl> easy fix
[09:37] <sabdfl> and easy test for future reference
[09:38] <sabdfl> i have a branch off current RF
[09:38] <sabdfl> patch should apply cleanly to whatever is going to be rolled out this week (or is rolled out)
[10:19] <kiko> sabdfl, hah. I should have seen that -- it was obvious
[10:22] <sabdfl> with hindsight yes :-)
[10:23] <sabdfl> should add the IFoo.providedBy(dummy_foo) test everywhere we have dummy_foo's
[10:23] <sabdfl> what's the rollout story this week?
[10:23] <kiko> tomorrow I hear
[10:24] <kiko> rollout was delayed because producing the production branch is taking too long
[10:24] <sabdfl> bzr-ness?
[10:24] <kiko> mmmmm
[10:24] <kiko> topic of the day
[10:24] <sabdfl> i feel better about it now i have a plan to win
[10:24] <SteveA> we should be using the interface verification APIs more than we are
[10:25] <sabdfl> yes, it's such an easy test
[10:25] <SteveA> that includes the providedBy check, and also checks an object's methods and attributes against the interface
[10:25] <sabdfl> be nice if the test failure told you what was missing
[10:25] <SteveA> yep
[10:25] <SteveA> we should find a way of doing this by inspecting what is registered
[10:25] <SteveA> rather than manually
[10:26] <SteveA> we can explicitly disable things that won't verify and we know why they won't
[10:26] <SteveA> (like special magic going on, for example)
[10:29] <aa_> hey, guys, is there a sneaky way I can get a product list from the launchpad?
[10:29] <kiko> aa_, products/+all?
[10:29] <kiko> it's not very sneaky
[10:29] <aa_> my client is working quite nicely, has console and gui front-ends
[10:30] <kiko> ali, you are remarkable
[10:30] <aa_> (and of course can be used direct from peethon)
[10:30] <SteveA> interesting
[10:30] <SteveA> one thing to watch out for is this
[10:31] <SteveA> when we have xmlrpc APIs, we'll be careful about changing them, to be nice to people writing tools to access launchpad that way
[10:31] <SteveA> we can't make a similar promise about pages of launchpad that are for browsers to use
[10:31] <kiko> tis life
[10:31] <aa_> yeah, of course
[10:32] <aa_> this is just temporary until the xmlrpc anyway
[10:41] <aa_> um, any way to insert <pre> style text in a comment? I am thinking about exceptions
[10:41] <kiko> not really -- kind of a wart.
[10:41] <aa_> I am sure it is in a document somewhere, I just can't find it
[10:41] <aa_> oh
[10:41] <aa_> well, let's get a scalpel and some cold coagulant
[10:45] <sivang> aa_: are you ali from #pygtk ?
[10:49] <aa_> sivang: yikes, um maybe
[10:51] <sabdfl> kiko, stevea, can we get a production rollout this week? seems we have good stuff in the queue
[10:52] <sabdfl> salgado: ping
[10:52] <salgado> sabdfl, pong
[10:52] <SteveA> sabdfl: i think stub is planning one.  he was going to do one tuesday, but there were bzr issues.
[10:53] <SteveA> he avoided one today, because of hug day
[10:53] <SteveA> so, i expect stub will do one tomorrow
[10:53] <SteveA> he is aware that one is due
[10:54] <sabdfl> thanks
[10:55] <sabdfl> salgado: on mirror management, if i register a mirror now, does it immediately show up on a list?
[10:55] <sabdfl> it would be nice to be able to call for mirrors to register this week
[10:55] <sabdfl> show them all irrespective of probing status
[10:55] <sabdfl> then bring up the probing scripts for the release
[10:55] <salgado> yes, they will show up on a list automatically
[10:56] <sabdfl> even if they have not been probed?
[10:56] <salgado> yes
[10:56] <sabdfl> ok, thanks
[10:56] <salgado> and the mirror probed is already running on production
[10:56] <sabdfl> i'm going to play with it locally, can I do some UI tweaks if I find low-hanging fruit or is that likely to get conflicts?
[10:57] <salgado> I've got some feedback from mdz on that, but I'm working on the cdimage stuff, so I didn't touch the UI since it landed
[10:57] <sabdfl> salgado: http://localhost:8086/distros/ubuntu/+allmirrors
[10:57] <sabdfl> dude
[10:58] <sabdfl> balance that page!
[10:58] <sabdfl> i'll DOIT
[10:58] <kiko> spoken like a true cowboy ;)
[10:59] <sabdfl> http://localhost:8086/distros/ubuntu/+mirror/valid-mirror
[10:59] <sabdfl> what's with the balance there, too?
[10:59] <sabdfl> why is that a 2col?
[10:59] <sabdfl> or rather, badly balanced 3col
[10:59] <salgado> well. when it landed it had the menu on the right side and two portlets on the left. I didn't touch it since them
[10:59] <sabdfl> ah, right, we changed the template
[10:59] <sabdfl> the menu moved
[11:00] <sabdfl> i mailed asking folks to rebalance their pages
[11:00] <sabdfl> will do these two and also tweak the pages
[11:00] <salgado> yeah, I didn't got time to do that, sorry
[11:04] <sabdfl> salgado: why the links to allmirrors at the top of a lot of those pages?
[11:08] <sabdfl> salgado: you have name, displayname, description all as textlines
[11:08] <sabdfl> and no explanation as to what to put in each of those, why they are different, why you need all three
[11:09] <salgado> sabdfl, bzr tells me the +allmirrors link was added by mpt. not sure if that was intentional or not
[11:12] <SteveA> sabdfl: i just saw that kiko has added "rebalancing portlets" to the meeting agenda for the launchpad allhands meeting tomorrow
[11:19] <sabdfl> hey bradb
[11:19] <sabdfl> did mpt discuss that new UI approach with anyone?
[11:19] <sabdfl> kiko? stevea?
[11:20] <salgado> I think the way I defined them, the description doesn't make much sense, at least. I'll check if all of them are really important to have
[11:20] <bradb> sabdfl: hi
[11:24] <SteveA> sabdfl: new UI approach?
[11:25] <SteveA> i haven't been following the discussion on irc here
[11:25] <SteveA> i'm due to have a talk with mpt tomorrow morning
[11:25] <SteveA> sabdfl: i'm up for a brief phone call if you want to clarify some UI direction
[11:25] <lifeless> morning
[11:27] <SteveA> hi robert
[11:27] <sabdfl> SteveA: calling
[11:30] <SteveA> https://staging.ubuntu.com/distros/ubuntu/+mirror/arcticnetwork-archive
[11:32] <sabdfl> https://launchpad.net/distros/ubuntu/+spec/zeroconf
[11:40] <carlos> kiko: I just updated https://wiki.ubuntu.com/MissingPotFiles
[11:40] <carlos> kiko: the ones assigned to me are the ones that I need  to import manually or that I need to check to be sure that should not be on language packs
[11:42] <sabdfl> carlos: great work!
[11:44] <sabdfl> salgado: how do i use the "upload file list" feature?
[11:44] <carlos> sabdfl: thanks
[11:46] <salgado> sabdfl, this is one of the things that wasn't clear in the spec, so it was implemented and is being removed now that we defined how we'll work with RELEASE mirrors
[11:47] <salgado> (that was supposed to give us the list of files to probe on a RELEASE mirror, but every mirror owner would be responsible for uploading one for his mirror)
[11:47] <sabdfl> ok
[11:48] <sabdfl> better that it just get the files from the mirror being mirrored
[11:48] <salgado> we could do that, and then fall back to http://releases.ubuntu.com/.manifest if one is not found in the mirror, can't we?
[11:48] <sabdfl> salgado: i'd like to ensure this is not enabled for read-only distributions
[11:49] <sabdfl> salgado: all distributions using this system could be expected to publish a .manifest
[11:49] <sabdfl> it's only ubuntu and its derivatives
[11:51] <salgado> but that is going to be the same .manifest we have on releases.u.c. I was thinking that somebody could change things and then generate a new file list for us, but that doesn't make much sense
[11:52] <sabdfl> no
[11:52] <sabdfl> they either fully mirror ubuntu, or they don't
[11:52] <salgado> is there an easy way to tell if a distribution is read only or not?
[11:52] <sabdfl> kiko: ping
[11:53] <sabdfl> salgado: no, i'm adding it now :-)
[11:53] <sabdfl> basically, we only want mirror management for some distros
[11:53] <sabdfl> like we only want soyuz (archive management etc)
[11:54] <salgado> right
[11:54] <sabdfl> night and thanks, SteveA
[11:54] <salgado> kiko left already
[11:55] <sabdfl> np if he's left
[11:55] <sabdfl> just wanted to point out that we need to be careful to filter out the read-only distros from some services
[11:55] <sabdfl> like shipit and mirror management
[11:55] <sabdfl> and archives, uploads, publishing etc
[11:56] <sabdfl> how do i disable a menu item?
[11:56] <salgado> sabdfl, I usually remove it from the ApplicationMenu.links
[11:56] <salgado> IIRC
[11:57] <salgado> I did that somewhere
[12:00] <salgado> wow, playing with self.links inside the menu class is obviously crack
[12:03] <SteveA> um... return Link('+whatever', title, enabled=False) should do it
[12:03] <elmo> look, stevea is sleep-ircing
[12:03] <SteveA> salgado: yeah, your sense is good.  i'm not sure we'll support playing with self.links in the future