[04:22] <AfC> jelmer: that import is stuck at about average 10 rev per minute at
[04:22] <AfC> jelmer: fetching revisions 149790/264178
[04:22] <AfC> Should I be trying the "pull 1000 revisions at a time in a loop" trick, maybe?
[04:26] <AfC> (the bzr process is at over 3 GB VSZ, so there's now a lot of swapping going on. It's pretty ugly)
[06:47] <AuroraBorealis> well that was dissapointing
[06:47] <AuroraBorealis> bzr ran out of memory =(
[06:56] <AuroraBorealis> after 15 hours of fast-import xD
[06:56] <AfC> AuroraBorealis: mine hasn't run out of memory, but at 25 hours elapsed it is essentially stuck, constantly swapping
[06:56] <AuroraBorealis> are you still branching?
[06:57] <AfC> [bad Python VM doing reference count based GC, bad]
[06:57] <AfC> AuroraBorealis: yep
[06:57] <AuroraBorealis> what are you branching, a git repo?
[06:57] <AfC> AuroraBorealis: the kernel, yes
[06:57] <AfC> as we were discussing yesterday
[06:57] <AuroraBorealis> yeah thats why its taking so long =P
[06:57] <AuroraBorealis> i thought you were branching a bazaar repo
[06:57] <AfC> if it's making progress, I don't care. But it's just spinning it's wheels.
[06:58] <AfC> | fetching revisions 151486/264178
[06:58] <AfC> It was at 140000 this morning
[06:58] <AuroraBorealis> mine got to 16,000
[06:58] <AuroraBorealis> then ran out of memory as it was repacking the repo :>
[06:58] <AfC> 3 GB virtual memory, 1.5 phys... swap swap swap
[06:59] <AfC> I'm going to try the pull a 1000 revisions at a time trick.
[06:59] <AfC> That worked on GTK a couple years ago when pulling from Subversion
[06:59] <AfC> → pub
[06:59] <AuroraBorealis> heh
[07:00] <AuroraBorealis> but yes, this could defenitly be faster. and not run out of memory xD
[09:41] <iaindalton> I'm following the Emacs Bzr guide. It says to do "bzr branch<EMAIL_ADDRESS>trunk", but I get Permission denied (publickey). bzr: ERROR: Connection closed: Unexpected end of message. (etc.) Why is it doing this and how can I fix it?
[09:50] <lifeless> your ssh key is not present on the server. I don't know why its not, nor the process for getting it on that server - I would hope the guide covers both points.
[09:53] <iaindalton> It doesn't AFAICT
[12:18] <rly> Is there any way to know the repository size before downloading it completely?
[12:20] <jelmer> rly: "bzr info -v" should tell you the number of revisions
[12:21] <rly> jelmer: also, how does the whole brz foo:bar thing work?
[12:21] <jelmer> rly: do you mean lp:<project> ?
[12:21] <rly> jelmer: yes
[12:22] <jelmer> rly: lp: is a shorthand for addressing branches on Launchpad, provided by the "launchpad" plugin that's bundled with bzr
[12:22] <andy> hey guys, can someone please help me with an bzr - buildbot issue? It might not be related to buildbot at all, that's why i am asking here
[12:22] <rly> jelmer: bzr branch lp:calibre is already at 600MB (!).
[12:22] <rly> jelmer: I want to know how long it will continue.
[12:23] <rly> I think the Linux kernel is even smaller.
[12:24] <jelmer> andy: please ask your question, if anybody here can help we'll reply
[12:26] <andy> alright, thanks
[12:26] <andy> i  got a buildbot master running. a bzr repo is hooked to it. so the bzr_buildbot.py is my plugins directory. i also adjusted the locations.conf file. but everytime i am trying to check something in, ill get an error:
[12:27] <andy> $:~/tmp/repo$ bzr ci
[12:27] <andy> Committing to: /home/.../tmp/repo/
[12:27] <andy> modified setup.py
[12:27] <andy> bzr: ERROR: exceptions.AttributeError: 'Revision' object has no attribute 'get_apparent_author'
[12:27] <andy> the script i used can be found here: https://raw.github.com/buildbot/buildbot/master/master/contrib/bzr_buildbot.py
[12:27] <Peng> andy: ...What version of bzr?
[12:28] <andy> andy@europa:~/tmp/buildbot/basedir$ bzr --version
[12:28] <andy> Bazaar (bzr) 2.3.4
[12:28] <andy>   Python interpreter: /usr/bin/python 2.7.1
[12:28] <andy>   Python standard library: /usr/lib/python2.7
[12:28] <andy>   Platform: Linux-2.6.38-11-generic-x86_64-with-Ubuntu-11.04-natty
[12:28] <andy>   bzrlib: /usr/lib/python2.7/dist-packages/bzrlib
[12:28] <andy>   Bazaar configuration: /home/.../.bazaar
[12:28] <Peng> yeah ok ok ok!
[12:28] <andy>   Bazaar log file: /home/.../.bzr.log
[12:28] <andy> sry :-)
[12:31] <andy> buildbot doesn't even have to be running if you want to get that error
[12:32] <andy> the problem might be here aswell:
[12:32] <andy> $ cat locations.conf
[12:32] <andy> [~/tmp/repo]
[12:32] <andy> buildbot_on = change
[12:32] <andy> buildbot_server = localhost
[12:36] <jelmer> rly: it finished pretty quickly here
[12:36] <jelmer> rly: what version of bzr are you running?
[12:37] <rly> jelmer: are you on a 100Mb network?
[12:37] <jelmer> rly: 336.910  Transferred: 390815kB (1160.6kB/s r:390814kB w:1kB)
[12:37] <rly> jelmer: I have a 6 as a first number?
[12:37] <jelmer> rly: what version of bzr are you running?
[12:38] <rly> jelmer: 2.1.2
[12:38] <jelmer> there have been some major performance fixes recently, perhaps that's relevant here
[12:39] <jelmer> rly: I suspect 2.4 will be a lot faster for you, and use less bandwidth
[12:39] <rly> jelmer: what kind of connection do you have, btw>
[12:40] <jelmer> rly: it took 5 minutes at 1.1Mb/s
[13:13] <andy> do you have any idea if gary poster (the maintainer of the bzr_bulidbot.py) is here sometimes?
[13:17] <jelmer> andy: he's often in #launchpad-dev
[13:18] <jelmer> andy: though usually during the week rather than in the weekend
[13:28] <jelmer> andy: still there?
[13:30] <jelmer> andy: the call to get_apparent_author() should be changed to get_apparent_authors()[0]
[13:34] <Peng> Ah, I *knew* there was an API compatibility issue around get_apparent_author(), but I was thinking that it was too new, not that it was too old. It was killed around 2 years ago, wasn't it?
[13:35] <jelmer> Peng: yep, and then deprecated for a long time. I didn't realize it had been deleted
[15:39] <andy> Peng: sorry, was afk. I found the same solution. should i file a bug for this? or are you able to fix it?
[15:40] <andy> Peng: in the buildbot IRC they told me to file a bug with the fix.... but if you can fix it right away this might be better.
[15:51] <Peng> Sorry, not me. Filing a bug's probably the best bet.
[15:51] <Peng> merge proposal
[15:52] <Peng> Bah. / merge proposal.
[15:52] <Peng> (* Actually, I might have commit rights to it, but I've never touched it.)
[15:54] <andy> Peng: alright. please give it try, otherwise i am gonna file it
[15:59] <Peng> I don't wanna give it a try. >.> I feel weird jumping in.
[16:00] <Peng> Wait, it's part of buildbot, not part of bzr? Then I certainly don't have commit rights. And I've only used Github once in my life. :P
[16:00] <andy> ah, sorry, i missunderstood it
[16:09] <bpierre> hi
[16:14] <bpierre> vila: I'm looking at the UI thing, and I'd like to be sure about you use case
[16:14] <bpierre> *your
[16:15] <bpierre> on my side, I don't call bazaar from VIM, but rather use VIM python bidings to directly use bzrlib
[16:16] <bpierre> I provide my own UIFactory implementation, but since shelf_ui does not use get_boolean, it does not work
[16:17] <bpierre> calling bzr from VIM (e.g. :!bzr shelve), does work
[16:18] <bpierre> using "yes no | bzr shelve" in a terminal however, does not
[16:21] <bpierre> so my question is: looking at your change, it seems that the isatty check is not enough, why?
[16:33] <vila> bpierre: almost not there, I'll try to be quick
[16:33] <vila> "yes  no | bzr shelve" is seen as 'y' 'e' 's' ' ' 'n' 'o'
[16:34] <bpierre> not on the version without your patch
[16:34] <vila> bpierre: with  patch I landed and INSIDE_EMACS=1 it will see 'yes no'
[16:34] <vila> s//the/
[16:34] <bpierre> sorry, the example was using the unix yes command
[16:35] <vila> bah, sorry
[16:35] <bpierre> :)
[16:35] <vila> you still need INSIDE_EMACS :)
[16:35] <bpierre> so can't have a controling terminal when using shell command in emacs?
[16:35] <bpierre> switch to VIM! (kidding) ;)
[16:35] <vila> hehe
[16:36] <bpierre> so now that it's in UI, better to change the environement variable name
[16:36] <bpierre> no?
[16:36] <vila> the trick is that the isatty() is not appropriate under emacs, there is no way to automatically detect the right kind (char or line)
[16:36] <bpierre> I know there is one for progress
[16:36] <bpierre> ok
[16:36] <vila> the plan *is* to change that, yes
[16:36] <vila> gtg, bbl
[16:36] <bpierre> ok
[16:37] <vila> i.e. prpose your branch, we'll sort out the details :)
[16:37] <vila> bpierre: I'm patch pilot next week anyway, so will have more time
[16:37] <bpierre> ok
[16:44] <vila> bpierre: back, urgent, but quick ;)
[16:44] <andy> Peng: i made a pull request for the fix. Thanks for your help
[16:45] <Peng> andy: It was mostly jelmer's help :P
[16:45] <vila> bpierre: start by proposing your branch and if you still want to tweak before it's reviewed, you can.  After that you just use ./bzr selftest -s bt.test_shelf_ui
[16:48] <vila> to test your changes
[16:49] <vila> or if you want to observe the behavior of 'bzr shelve': 'INSIDE_EMACS=1 ./bzr shelve'
[16:49] <bpierre> by how do you control the shelf ui from emacs?
[16:49] <vila> oh ! Sorry
[16:49] <bpierre> with VIM, :!bzr uncommit
[16:49] <vila> I run a shell under emacs
[16:49] <bpierre> works ok
[16:49] <bpierre> so how do you start the shell, that's all I'm asking!
[16:49] <vila> a regular bash shell *except* the input is line based
[16:50] <vila> M-x shell
[16:50] <vila> M for meta, 'ESC x' works too
[16:50] <bpierre> ok! and not M-! command
[16:50] <bpierre> got it
[16:53] <vila> bpierre: just curious, how well do you know emacs ?
[16:53] <vila> hmm, you have it installed obviously
[16:54] <bpierre> no well at all! just installed it, for that and testing notmuch, started with it, before converting to vim :)
[16:54] <bpierre> 10 years ago
[16:59] <vila> bpierre: OMG, you went to the Dark Side ! vi, vi, vi VIVIVI is the editor of The Beast !
[17:15] <vila> bpierre: I've seen rms in flesh as St IGNUcis for the first time recently, the guy has a strong sense of auto-derision ;)   http://stallman.org/saint.html
[17:18] <bpierre> yeah
[17:37] <vila> bpierre: A *good* way to understand what my patch fix: with an older bzr version: add a line in a file, try to shelve it.
[17:38] <vila> bpierre: and watch your added line still present 8-)
[17:38] <AuroraBorealis> should i report a bug if bzr ran out of memory doing something?
[17:39] <vila> bpierre: you just type 'y\n' and shelve sees 'y' '\n' (default n) '\n' (default n) and think you don't want to shelve it finally :)
[17:41] <vila> AuroraBorealis: es, that would be helpful and awesome! Especially if you mentioned your hardware config ( mem size, proc, etc) and the software one (bzr version, plugin versions, etc) and of course the data (urls, formats, revision ids, etc) so we can reproduce and compare
[17:42] <vila> AuroraBorealis: we may need time to fix it but we'll know how close we get along the way ;)
[17:42] <AuroraBorealis> k
[17:42] <AuroraBorealis> i was trying to...convert the git repo for the linux kernel
[17:42] <AuroraBorealis> and first i ran out of memory, then i ran into this bug =P https://bugs.launchpad.net/bzr/+bug/541626
[17:46] <vila> AuroraBorealis: <cough> 2.1.0 ??
[17:47] <AuroraBorealis> do you mean thats the bzr version i'm using?
[17:47] <AuroraBorealis> i'm using 2.4.0
[17:47] <vila> AuroraBorealis: You'd really get better performance and memory consumption with 2.4 which is stable or 2.5b1 which is beta
[17:47] <vila> oh, known bug ! Sorry, let me finish reading
[17:47] <AuroraBorealis> xD
[17:49] <AuroraBorealis> i also have 8 gb of memory, but i guess the version of python bzr uses is 32 bit
[17:49] <vila> AuroraBorealis: sry, gtg, metoo the bug and subscribe
[17:50] <AuroraBorealis> kk!
[17:50] <vila> AuroraBorealis: and the informations mentioned above (and check the comments ?)
[21:06] <udp> so I have a recipe set up for my project, and the source is being imported from a git repository by launchpad
[21:06] <udp> I need to add a tag "upstream-0.2.4t"
[21:06] <udp> I don't know anything about bzr, but I assume that's to tag a particular revision as 0.2.4?
[21:07] <udp> since the debian packaging info says it's building 0.2.4
[21:09] <udp> I'm not sure how I'd do this since the branch is coming from git
[21:16] <jelmer> udp: hi
[21:16] <jelmer> udp: still there?
[21:16] <udp> Hi jelmer, yeah I am
[21:17] <jelmer> udp: git imports should import tags as well, so if you create one in Git it should create a matching tag in bzr
[21:17] <jelmer> udp: that said, why do you need that particular tag? It shouldn't be necessary for the recipe.
[21:17] <udp> ah, I didn't realise it did
[21:17] <udp> thanks - well, I'm getting "bzr: ERROR: No such tag: upstream-0.2.4t hooks - Stage 5/5"
[21:18] <jelmer> udp: try building with --allow-fallback-to-native
[21:18] <udp> I guess it'd be building HEAD if I did that?
[21:20] <jelmer> udp: well, this is about how it determines the upstream source
[21:21] <jelmer> udp: if you specify --allow-fallback-to-native then it will simply create a "native" debian package if it can't find the upstream source
[21:23] <udp> OK, I don't get the error if I use --allow-fallback-to-native
[21:24] <jelmer> I'm fixing the error message to be a bit clearer.
[21:27] <udp> can I add --allow-fallback-to-native to the recipe itself?
[21:27] <jelmer> udp: no, but launchpad has it enabled already
[21:30] <udp> ah ok - cheers
[21:41] <udp> odd, there's a *_source.changes file being generated in the working directory when I run dailydeb - it includes an incorrect Changed-By email address which is causing lintian to fail (it uses my local hostname)
[21:42] <udp> it's not the address from `bzr whoami`
[21:44] <jelmer> udp: I'm not entirely sure what the logic behind that is
[21:57] <AuroraBorealis> jelmer i posted my bzr version to that MemoryError bug
[21:59] <udp> never mind, starting a new terminal solved it - I tried to build on launchpad again, but it failed with "bzr: ERROR: Failed to apply quilt patches"
[22:00] <udp> there aren't any patches
[22:00] <jelmer> udp: is there a debian/patches/series file?
[22:00] <udp> yes, it's blank
[22:00] <jelmer> udp: launchpad is still running a fairly old bzr-builder which has problems with that
[22:02] <jelmer> udp: if you remove debian/patches it should work
[22:11] <wgz> AuroraBorealis: ha, I should have refreshed the bug page
[22:11] <jelmer> AuroraBorealis: thanks
[22:11] <AuroraBorealis> i have 8 gb of memory, so i would think that it shouldn't..run out o.o
[22:12] <jelmer> AuroraBorealis: I'm not sure about bzr-fastimport, but I remember importing linux with bzr-git at some point
[22:12] <wgz> you need to install it youself from parts if you want that to be true.
[22:12] <jelmer> auroraborealis: I'm also pretty sure the Launchpad vcs-imports don't have that much memory
[22:12] <AuroraBorealis> yeah i would think not
[22:12] <wgz> because bzr only provides 32-bit windows installers
[22:13] <AuroraBorealis> it seems that the importing was fine
[22:13] <AuroraBorealis> but repacking it caused it to run out of memory
[22:13] <wgz> jelmer: launchpad doesn't run on widnows.
[22:13] <wgz> ...or windows
[22:13] <jelmer> true
[22:13] <jelmer> maybe John will have something useful to say about this on Monday
[22:13] <wgz> I posted some observations to the bug.
[22:14] <wgz> there are like, three things we could fix that I can see, but I don't know which are important without actual memory measurements
[22:15] <AuroraBorealis> is there a way to do memory measurements?
[22:15] <AuroraBorealis> is that what lp:meliae is?
[22:15] <udp> jelmer: It built successfully on launchpad - thanks for your help  :-)
[22:15] <jelmer> AuroraBorealis: yep, meliae can indeed help with memory usage analysis
[22:15] <wgz> yup, if you have that when you OOM it does a dump.
[22:16] <jelmer> udp: cool, glad I could help
[22:16] <AuroraBorealis> ok i shall try this out
[22:16] <AuroraBorealis> i might run out of disk space though haha
[22:16] <AuroraBorealis> the fast export file is 20 gigs >.>
[22:16] <wgz> AuroraBorealis: I'd really like if you tried a 64-bit bzr if you're okay with building python things yourself
[22:16] <AuroraBorealis> yeah i can try that
[22:16] <AuroraBorealis> not sure how i do that on windows
[22:17] <wgz> you need a 64 bit python and the compiler it built with for starts...
[22:17] <jelmer> wgz: ah, you're Martin!
[22:18] <AuroraBorealis> which compiler is that?
[22:18] <jelmer> wgz: What made your "m" go upside down?
[22:18] <wgz> weekend!
[22:18] <wgz> ...I didn't quite stick to irc hours discipline
[22:18] <jelmer> yeah, it's hard on all of us :)
[22:20] <wgz> AuroraBorealis: let me check, I'm slightly concerned that the old free beer MSVCs were 32 bit only
[22:20] <AuroraBorealis> i *should* have access to all of the microsoft visual studio stuff, just need to ask my school
[22:21] <wgz> ..I've typed "54 bit" like, three times now
[22:22] <wgz> okay, this is the first thing I've turned up on google that looks even vaguely useful: <http://mattptr.net/2010/07/28/building-python-extensions-in-a-modern-windows-environment/>
[22:22] <wgz> as with all such things, some of what it says is probably out of date
[22:23] <AuroraBorealis> ive heard that vs2008 is the correct one too
[22:23] <wgz> this no doubt still stands though  "Visual C++ express works, as long as it’s 2008."
[22:23] <wgz> so, you should be able to get it to work.
[22:24] <AuroraBorealis> ok
[22:24] <AuroraBorealis> so then, i just download bzr from source
[22:24] <AuroraBorealis> and then what do i compile?
[22:25] <wgz> hm, jelmer, do you know if the C-from-pyrex sources in the tarball can be used straight up?
[22:26] <jelmer> wgz: I think so; the ugliness of the generated code is in part due to it trying to support all possible compilers
[22:26] <wgz> if so, you should just then be able to do `...Python2.7/python.exe setup.py` for Bazaar... then you'll need to do a similar thing for the two fastimport packages
[22:27] <wgz> and meliae... anything else?
[22:27] <wgz> *`python setup.py install`
[22:28] <wgz> ask in here if you get stuck at any point or need more help.
[22:28] <AuroraBorealis> haha
[22:28] <AuroraBorealis> which fast import packages do i need?
[22:28] <AuroraBorealis> or are those included in the bazaar source
[22:29] <wgz> lp:bzr-fastimport and lp:python-fastimport
[22:29] <AuroraBorealis> k, and do i need VS2008?
[22:30] <wgz> yup.
[22:30] <AuroraBorealis> so what exactly do i build with vs2008
[22:30] <AuroraBorealis> i know i run setup.py for most everything
[22:31] <wgz> setup.py will call the compiler for you, for the modules that need compiling
[22:31] <wgz> (*should, see that blog post if it doesn't work)
[22:32] <AuroraBorealis> yay!
[22:33]  * AuroraBorealis starts the download
[22:56] <lifeless> wgz: mgz by another nick?
[22:59] <wgz> lifeless: otherwise I'd forget to logout and be ghosting come Monday all the time
[22:59] <lifeless> wgz: welcome to Canonical!
[23:00] <AuroraBorealis> i can't seem to branch lp:bzr
[23:00] <AuroraBorealis> it just sits there at "starting" =/
[23:00] <wgz> AuroraBorealis: I suggest you get the tarball, will save you needing cythong
[23:00] <lifeless> AuroraBorealis: are you behind a proxy perhaps ?
[23:00] <AuroraBorealis> i'm not
[23:01] <wgz> lifeless: and welcome to not being able to stay logged out over the weekend? :)
[23:01] <lifeless> wgz: working on something we're passionate about, from home, tends to lead to blurred lines ;)

[23:01] <wgz> you have <http://www.python.org/ftp/python/2.7.2/python-2.7.2.amd64.msi> already right?
[23:02] <AuroraBorealis> yeah
[23:02] <lifeless> wgz: for instance, I've just triaged a hundred or so stale LP bugs
[23:03] <wgz> lifeless - he's passionate about stale bugs
[23:03] <wgz> they eat funny things in nz...
[23:03] <AuroraBorealis> bzr seems to be trying to open the repo with subversion or something
[23:03] <lifeless> wgz: :P I'm passionate about LP
[23:03] <wgz> :P
[23:04] <wgz> !pastebin the log quickly AuroraBorealis?
[23:04] <wgz> !pastebin
[23:06] <AuroraBorealis> this is unrelated to the memory error thing, its just not branching lp:bzr and creating a repo has weird output o.o  http://paste.ubuntu.com/700769/
[23:06] <wgz> yup.
[23:06] <wgz> ugh, yeah, that's not pretty.
[23:07] <AuroraBorealis> no idea why its doing it, i'm just creating a new repo >.>
[23:08] <AuroraBorealis> it also seems to be denying my public key
[23:11] <AuroraBorealis> back to what i was doing, its saying that no cython or pyrex is installed. do i need those?
[23:12] <wgz> shouldn't say that if you went with the tarball?
[23:12] <wgz> otherwise yeah, you'll need one
[23:12] <AuroraBorealis> yeah its with the tarball
[23:13] <AuroraBorealis> just did python27_64 setup.py and its saying "no cython, trying pyrex...pyrex is not available"
[23:13] <wgz> http://www.lfd.uci.edu/~gohlke/pythonlibs/#cython
[23:13] <wgz> did it then fail?
[23:13]  * wgz checks the setup.py logic
[23:14] <AuroraBorealis> i was just checking the arguments
[23:14] <AuroraBorealis> it said that then printed the usage
[23:14] <wgz> ah, it looks like it'll say that
[23:14] <wgz> but then build anyway
[23:14] <wgz> so, don't worry
[23:14] <AuroraBorealis> now its saying cython is there
[23:14] <AuroraBorealis> so yay
[23:15] <AuroraBorealis> booooo
[23:15] <AuroraBorealis> "valueerror"
[23:15] <fullermd_> Obviously, it thinks you have questionable values.
[23:16] <wgz> pastebin traceback?
[23:16] <wgz> did you get the windows 7 sdk?
[23:16] <AuroraBorealis> http://paste.ubuntu.com/700774/
[23:16] <AuroraBorealis> no i didn't
[23:17]  * AuroraBorealis installs that
 is what you want I think
[23:17] <wgz> ^that error might be one of the ones the blog post from earlier had a workaround for
[23:18] <AuroraBorealis> yeah i'm installing it now
[23:18] <wgz> see the "Trick distutils" section
[23:18] <wgz> which comes after "Install the Windows 7 Platform SDK"
[23:19]  * wgz hugs fullermd and his underscore
[23:19] <AuroraBorealis> annnnd installation failed on the sdk
[23:20]  * AuroraBorealis cries
[23:20]  * wgz offers emotional support
[23:21] <AuroraBorealis> the error was "see the config html page for more information"
[23:21] <AuroraBorealis> thanks microsfot
[23:21] <AuroraBorealis> soft*
[23:25] <wgz> did it dump a html log anywhere obvious?
[23:25] <AuroraBorealis> i have the log
[23:25] <AuroraBorealis> no idea what its actually doing
[23:26] <AuroraBorealis> http://paste.ubuntu.com/700777/
[23:26] <fullermd_> Aiee!  There's an underscore on my back??    Get it off!!
[23:27]  * wgz swats at it
[23:27]  * fullermd_ spins around barking and biting as his tail.
[23:27] <AuroraBorealis> found something promising on google, one se
[23:27] <AuroraBorealis> c
[23:28] <wgz> http://blogs.msdn.com/b/windowssdk/archive/2009/09/16/windows-7-sdk-setup-common-installation-issues-and-fixes.aspx
[23:28] <wgz> the list of errors there is amusing
[23:28] <AuroraBorealis> the fix is diving deeep into the registry
[23:34] <AuroraBorealis> and now i apparently need to reboot


[01:48] <ScottK> stgraber: Yes.
[01:49] <stgraber>  ScottK ok. Can you say so in the<EMAIL_ADDRESS>thread?
[01:49] <ScottK> stgraber: Riddell already did.
[01:50] <stgraber> ScottK: ah? https://lists.ubuntu.com/archives/ubuntu-release/2012-November/ and https://lists.ubuntu.com/archives/ubuntu-release/2012-December/ don't seem to agree
[01:51] <stgraber> and there's nothing in the moderation queue
[01:51] <cjohnston> stgraber: do you know where the code is for http://reqorts.qa.ubuntu.com/reports/boot-speed/ by chance?
[01:52] <ScottK> OK.  Done.
[01:52] <stgraber> cjohnston: nope
[01:52] <stgraber> ScottK: thanks
[01:52] <ScottK> Seems I mis-remembered.
[01:52] <ScottK> No problem.
[01:52] <cjohnston> thanks stgraber
[01:54] <infinity> ScottK: APAC woke up, rocs is building belatedly on armhf/quantal-proposed now.
[01:55] <ScottK> infinity: Thanks.
[02:31] <infinity> ScottK: When you get a moment, can you review and let the above hugetlbfs into lucid-backports?
[02:31] <ScottK> Is it tested?
[02:31] <infinity> Yeahp.  stokachu had it tested.
[02:31] <infinity> (So says the bug log)
[02:35] <infinity> Do backports uploads auto-close bugs, or do I need to do it manually?
[02:35]  * infinity goes to look.
[02:35] <ScottK> No.  They don't, but I already did it.
[02:35] <infinity> Ahh, thanks.
[02:36] <ScottK> It wasn't actually even filed against backports.  Fixed that too.
[02:36] <infinity> Oh, yeah.  The backport bug tracking is a bit odd to me.  The lack of per-pocket bugs targeting makes it sketchy, I guess.
[02:38] <ScottK> Each release is a separate project in LP.
[02:38] <Riddell> hmm I'm sure I e-mailed ubuntu-release
[02:38]  * ScottK thought so too, but didn't see it.
[02:39]  * ScottK did a backup mail and covered it though.
[02:39] <Riddell> my sent-mail says I sent it to stgraber directly, silly me
[02:39] <Riddell> doesn't explain why he hasn't seen it but
[02:40] <infinity> I dunno about him, but I spam filter all mail with Scottish accents.
[02:40] <stgraber> Riddell: well, I've had e-mail problems on Friday and likely lost an hour or so of e-mails. I re-checked all my mailing-lists manually for anything I'd missed, but there's not much I could do for private e-mails
[02:41] <Riddell> jings and crivvens
[02:41] <infinity> Great, now I need to start filtering IRC.
[02:42] <infinity> Also, http://en.wiktionary.org/wiki/crivvens is brilliant: "See also: cripes and crikey".
[11:05] <cjwatson> Grr, getting live-build to install linux-generic-lts-quantal correctly is unexpectedly difficult
[13:24]  * ogra-cb wonders if the chinese images are built using a different build system ... bug 1085918 shows the same timestamp i use for nexus7 images but thats set only based on the subarch
[13:24] <ubot2> Launchpad bug 1085918 in ubiquity (Ubuntu) "Chinese raring desktop images have different format of media-info to that of standard desktop images" [Undecided,New] https://launchpad.net/bugs/1085918
[13:28] <xnox> ogra-cb: i'd like to know where the chinese images are...
[13:29] <ogra-cb> the bug points to them
[13:29] <ogra-cb> http://china-images.ubuntu.com/raring/daily-live/current/
[13:30] <ogra-cb> its likely only a conicidence that they use the same timestamp format. but its irritating
[13:31] <cjwatson> The Chinese images use ubuntu-defaults-builder.
[13:31] <cjwatson> Which is based on live-build / livecd-rootfs, but another layer.
[13:42] <ogra-cb> xnox, i would also see a bug in utah here ... it should eb able to handle such stamps too
[13:43] <ogra-cb> (specifically because all arm images and images will have it)
[13:43] <ogra-cb> (well, all preinstallled ones at least)
[13:46] <xnox> ogra-cb: sure, but ideally we standartise on some kind of parsable format.
[13:48] <ogra-cb> yes, for preinstalled where the stamp is created on the live builder we cant know if it is yyyymmdd.n or just yyyymmdd
[13:48] <ogra-cb> so there must be another format that still makes it possible ot have more than a build per day
[13:49] <ogra-cb> if the stamp is added during post processing you code can check whats in the www dir alreday, cant do that from a live builder easily
[13:49] <ogra-cb> *your
[13:58] <xnox> ogra-cb: or the stamp can be yyyymmdd.HHMM
[13:58] <ogra-cb> oh, sure
[13:58] <xnox> and that has ~ same machine parsability.
[13:59] <ogra-cb> but that will require code changes all over the place if you want consistency
[13:59] <ogra-cb> i.e. to make the download dirs use that
[14:00] <ogra-cb> and i'm not sure we would want that (breaks likely lots of download scripts out there)
[14:02] <ogra-cb> i think we should rather determine the version string at the very beginning of the build and export it to the live builder
[14:03] <ogra-cb> (and to all other scripts indeed, but these are on teh same machine anyway)
[14:07] <psivaa> xnox: i am seeing bug 1085961 when i do side by side installations
[14:07] <ubot2> Launchpad bug 1085961 in ubiquity (Ubuntu) "Unable to install two raring desktops side-by-side" [Undecided,New] https://launchpad.net/bugs/1085961
[14:10] <xnox> ogra-cb: I am not talking about urls, I am only talking about the format/regexp of the image/iso diskid.
[14:10] <xnox> ogra-cb: which we can use in ubiquity & utah etc.
[14:11] <ogra-cb> xnox, usually that corresponds to the url
[14:11] <xnox> ogra-cb: no. all urls use current/ symlink.
[14:11] <xnox> ogra-cb: and that's the canonical url, the rest may or may not exist as we rotate them a lot & images may not be build today.
[14:12] <ogra-cb> i.e. an iso from  cdimage.u.c/daily/20121201.1 will have exactly that timestamp insiuude too
[14:12] <ogra-cb> and i think thats wanted
[14:12] <ogra-cb> current is just a link to the latest of these timestamped dirs
[14:13] <xnox> ogra-cb: apart from that url -> file mapping is not always true (e.g. as we see in preinstalled & chinese images), while current->latest symlink is correct across all of them.
[14:14] <ogra-cb> preinstalled just got that added two weeks ago ... and simply because i couldnt come up with anything better
[14:14] <xnox> ogra-cb: that gives me confidence that url != file is ok, but file having a different format within image is / can be a problem.
[14:14] <ogra-cb> chinese looks more like a bug
[14:14] <xnox> ack.
[14:15] <ogra-cb> url != file is not ok, it is there because i introduced it lacking a better implementation
[14:16] <ogra-cb> the proper implementation would be as i said above, figure out the stamp at the very beginning and hand them to the respective scripts ... currently the stamp is only used in post processing
[14:16] <ogra-cb> which we dont do for preinstalled
[14:16] <xnox> ogra-cb: ack.
[14:17] <xnox> ogra-cb: and ubuntu-defaults builder should be fixed to generate more similarish timestamps.
[14:17] <ogra-cb> i simply didnt want to hack up the whole code of cdimage ... introducing yyymmdd-hhmm was just the way of least resistance for an unsupported image
[14:17] <ogra-cb> i dont mind replacing the dash with a dot for now ... but effectively it wont fix the bug
[14:18] <ogra-cb> that can only be done by a bit of redesign
[14:19] <ogra-cb> i might even drop the whole thing again if we decide to switch to xz for nexus7 which means we would re-pack the tarball on nusakan anyway
[14:34] <ScottK> It would be nice if someone in SRU (I uploaded it, so I can't) would review ^^^ so we don't end up hold all of KDE 4.9.3 up for it.
[15:54] <cjwatson> infinity,slangasek: ^- livecd-rootfs 2.65.4 - YA in the secure boot saga
[15:54] <cjwatson> This time I've actually tested the image build (which is currently failing in precise :-/)
[16:01] <ScottK> stgraber: Now that I created the Alpha 1 milestone in the tracker, is everything going to get added automatically?
[16:02] <ScottK> It'd be nice to only have the Kubuntu stuff in there so people don't get confused.
[16:02] <stgraber> ScottK: yeah, I still need to setup some scripts to avoid that ^
[16:02] <stgraber> was planning on doing that this afternoon :)
[16:03] <ScottK> Excellent.
[16:03] <ScottK> IIRC, that's not far off.
[16:07] <cjwatson> Has anyone decided on whether a partial britney freeze is needed, and if so of what package(set)s?
[16:08] <stgraber> ScottK: alright, I removed everything from the alpha-1 milestone. I'll add the Kubuntu desktop products to the manifest so that they'll auto-publish when we start building at 21:00 UTC today
[16:08] <stgraber> cjwatson: I didn't get any request so far, so I'm hoping not
[16:10] <ScottK> stgraber: Can we have the current images in there manually?
[16:10] <ScottK> (for Kubuntu)
[16:11] <ScottK> I added them manually when I set up the milestone.
[16:11] <stgraber> ScottK: ok, added.
[16:11] <ScottK> Thanks.
[16:12] <stgraber> ScottK: you added them with an invalid version number (.0), so that's why I removed them earlier
[16:12] <ScottK> Yes.  I messed that bit up.  I wasn't sure what to put in.  Thanks for fixing.
[16:13] <stgraber> btw, we may end up having an Edubuntu alpha-1 after all. Seems like highvoltage will have enough time to take care of it all by himself.
[16:13] <stgraber> we'll have the final decision by 21:00 UTC
[16:17] <ScottK> Cool.
[17:15] <stgraber> highvoltage: edubuntu added to the alpha-1 manifest, first builds will show up a bit after 21:00 UTC
[17:18] <slangasek> cjwatson: livecd-rootfs accepted
[17:18] <xnox> stgraber: yeah, so ubiquity-gtk frontend will be exercised ;-)
[17:28] <cjwatson> slangasek: thanks
[17:35] <infinity> cjwatson: Oh, FWIW, verified over the weekend that the britney hack for d-i/udeb block/pass works fine.  So, that takes some pressure off d-i upload timing.
[17:35] <slangasek> block/pass/pick/fumble/touchdown
[17:35] <infinity> I don't understand, that's not hockey.
[17:36] <cjwatson> Good good, thanks.  (Not that I was feeling the pressure anyway, I must say; the worst case was NBS.  The difficult sync is between d-i and seeds ...)
[17:38] <infinity> cjwatson: Yeah, seeds are a bit sketchy still.  I've been trying to time my seed updates to when d-i hits disk on ftpmaster, which isn't an ideal thing for normal mortals to try to do. :P
[17:39] <infinity> cjwatson: Maybe that could do with some rethinking.  I was going to use the word "automation", but I don't really want automated commits to seed branches.
[18:01] <cjwatson> infinity: Quite.
[18:01] <cjwatson> infinity,slangasek: I've fixed britney to require at least one up-to-date binary on at least one architecture before promotion, regardless of any exceptions for slow architectures.
[18:02] <infinity> cjwatson: That should do.  Thanks.
[18:03] <slangasek> sounds good
[18:17] <ScottK> heka had a chroot problem failure, but it must have been gremlins/cosmic rays because the retry hit heka again and worked fine.
[18:19] <infinity> When we finally get decent ARM buildds, I intend to send a Panda from the DC to every member of ~launchpad-buildd-admins and ~ubuntu-release to mutilate as they please.
[18:19] <micahg> infinity: can I get on the list for one please :)
[18:20] <infinity> Heh.
[18:21] <infinity> micahg: I see your firefox finally built. :P
[18:21] <micahg> infinity: yeah, last time it muttered about a \37....
[18:21]  * micahg didn't ask it to fnid Amelia Earhart, just to build firefox...
[18:35] <slangasek> infinity: mutilating machines that contain no spinning parts is way less fun
[18:36]  * ScottK looks around for some spare dynamite.
[18:36] <ScottK> Depends on how you do it.
[18:36] <sbeattie> slangasek: the point is to make the parts that are not spinning spin.
[18:36] <sbeattie> or at least, that's what I go for.
[18:36] <sbeattie> YMMV and all that.
[18:40] <ogra-cb> its pandaboards, you can just make them spin completely with pretty low effort
[19:38] <ScottK> This proposed thing is handy when a package update gets uploaded to the archive instead of a PPA by mistake ...
[19:39] <slangasek> heh
[20:24] <ScottK> Which package owns the first startup screen in the installer (the one that Ubuntu doesn't show by default, where you, for example, set up an OEM install)?
[20:26] <infinity> Sounds like ubiquity.
[20:27] <infinity> Do you have a string from said screen?
[20:27] <ScottK> "Boot from first hard disk"
[20:27] <ScottK> That one is particularly relevant because it's trying to boot from my USB stick again.
[20:27] <infinity> Oh, pre-boot?
[20:27] <ScottK> Yes.
[20:28] <ScottK> The one that you have to hold shift down in Ubuntu to see.
[20:28] <infinity> That would be syslinuxish, though the actual menus don't come from syslinux.
[20:28] <ScottK> So in the case of picking the wrong thing to boot from, what package do I blame?
[20:28] <infinity> I'm trying to sort that out...
[20:29] <ScottK> Thanks.
[20:29] <slangasek> your bios? :)
[20:29] <infinity> debian-cd writes the menus.
[20:29] <infinity> label hd
[20:29] <infinity>   menu label ^Boot from first hard disk
[20:29] <infinity>   localboot 0x80
[20:29] <slangasek> "Boot from first hard disk" is done via BIOS calls; if the "first hard disk" it's booting isn't the one you want, that's a BIOS issue
[20:29] <infinity> And yeah, that's just booting 0x80, so if your BIOS is remapping your stick, that's correct.
[20:30] <infinity> And it's arguably correct for your BIOS to remap your stick when you select it as the boot device.
[20:30] <ScottK> Hmmm.
[20:30] <infinity> (Though this behavious varies wildly between machines)
[20:30] <slangasek> solution: upgrade your firmware to UEFI
[20:30] <infinity> behaviour, too.
[20:30] <slangasek> then you can't run syslinux at all, problem solved
[20:30] <infinity> Hahaha.
[20:30] <infinity> "solved".
[20:30] <ScottK> So does this option actually do any good?
[20:31] <infinity> ScottK: It made a lot more sense on CDs, which were never remapped.
[20:31] <ScottK> Right.
[20:31] <infinity> ScottK: And it makes sense for people who burn our images to DVDs (same argument).
[20:31] <slangasek> right, if the issue is that you're booted *from* the USB stick, it should probably detect that and translate it to 0x81 instead
[20:31] <infinity> That's probably still more common than USB sticks, except for serial reinstallers.
[20:32] <ScottK> slangasek: That sounds sensible.
[20:32] <infinity> slangasek: That's a fair chunk of extra magic to ask of syslinux.
[20:32] <slangasek> IIRC the same el-torito boot image is used for both CD and hybrid USB booting, so this magic would have to be in syslinux
[20:33] <slangasek> infinity: it doesn't hurt to ask
[20:33] <ScottK> Also it doesn't have to detect it's a USB, it would have to detect that the device it's about to try to boot from is the same one it's already booted from.
[20:33] <infinity> But yeah, one could do an "if current device = 0x80, shift all menu lookups by 1" or something.  I guess.
[20:33] <infinity> I'm not sure if it can even reliably know this.
[20:33] <ScottK> From the discussion, it seems like that would do it.
[20:34] <infinity> Not without more code than it has room to run.
[20:34] <infinity> Still, yeah, a mildly annoying buglet.
[20:37] <ScottK> I'll file it and then it will be what it will be.
[20:39] <ScottK> Turns out there is an existing bug.
[20:42] <infinity> Hrm.
[20:42] <infinity> Looks like "localboot -1" triggers int 18h, which should force your BIOS to try the next boot device.
[20:43] <infinity> Of course, that's likely wildly buggy from machine to machine as well.
[20:44] <infinity>                 cmp ax,-1
[20:44] <infinity>                 je .int18
[20:44] <infinity> .int18:
[20:44] <infinity>                 int 18h                         ; Hope this does the right thing...
[20:44] <infinity>                 jmp kaboom                      ; If we returned, oh boy...
[20:45] <infinity> Such faith in his own code there...
[20:45] <ScottK> Heh.
[20:45] <ScottK> Bug #1066387 in case you want some place to document findings.
[20:45] <ubot2> Launchpad bug 1066387 in syslinux (Ubuntu) "D-I install menu, select "Boot from first hard disk" and it goes back to Language selection" [Medium,Triaged] https://launchpad.net/bugs/1066387
[20:51] <ScottK> BTW, the continuous quality push seems to be showing.  I got through all the Kubuntu test cases for i386 with  no failures.
[20:51] <infinity> \o/
[20:55] <ScottK> The syslinux thing was the 2nd most annoying bug I found.
[20:57] <infinity> That bug's been around forever, so hardly counts.  What was the first most annoying bug?
[20:59] <ScottK> http://launchpad.net/bugs/1086047
[20:59] <ubot2> Launchpad bug 1086047 in qapt (Ubuntu) "Firefox installer fails in raring" [High,Fix released]
[20:59] <ScottK> The Kubuntu package install mechanism was broken.
[21:00] <ScottK> (for adding specific packages)
[21:00] <infinity> Ahh.
[21:00] <ScottK> qapt-batch
[21:00]  * infinity nods.
[21:24] <persia> re: bug 1066387 : what problem is the "boot from first HD" option attempting to solve
[21:24] <ubot2> Launchpad bug 1066387 in syslinux (Ubuntu) "D-I install menu, select "Boot from first hard disk" and it goes back to Language selection" [Medium,Triaged] https://launchpad.net/bugs/1066387
[21:25] <slangasek> persia: to let you boot from the hard drive if you've accidentally left the CD in the drive
[21:26] <slangasek> without having to reboot and/or fiddle
[21:26] <persia> Given that it won't work with any machines that have a preinstall of Windows 8 or OS X > 10.6, how much longer should this remain relevant?
[21:27] <persia> (plus we did tell the user to remove the CD in order to perform the reboot, although some hardware lets one ignore this)
[21:28] <slangasek> persia: any machines that have a preinstall of Windows 8 won't see syslinux at all
[21:29] <slangasek> I don't know that this bug is anything we're going to invest time in fixing
[21:29] <slangasek> but I think it's true that it's a bug
[21:32] <persia> Makes sense: rather than trim syslinux to just not show this for the dwindling use case, leave it as a known issue, and let it expire as BIOS becomes irrelevant.
[21:33]  * ScottK doesn't have a strong opinion about fixing/removing, but thinks one of them should happen.
[21:38] <cjwatson> Ultimately the boot menu needs to move to GRUB for all architectures, but it's a non-trivial chunk of work to migrate the menu interface over.
[21:38] <cjwatson> Something I've tried to push up the hill before.  It may get higher-priority as UEFI becomes more common.
[21:39] <cjwatson> If we do it for UEFI then we can ditch syslinux across the board and rejoice.
[21:39] <cjwatson> Longish-term plan though.
[21:39] <persia> What produces txt.cfg?  I don't see it in the syslinux source.
[21:41] <slangasek> I believe that's in the debian-cd branch
[21:43] <cjwatson> Either that or debian-installer.
[21:48] <stgraber> ScottK: so I'm assuming you don't want your 21:00 UTC respin?
[21:48] <ScottK> stgraber: We do.  I want the newer qapt in.
[21:49] <ScottK> The qapt-batch bug didn't cause the test case to fail, but it's still a significant bug.
[21:49] <stgraber> ScottK: ok, so should I kick a respin now?
[21:50]  * ScottK is lost in TZ math.
[21:50] <stgraber> it's 21:48 UTC :)
[21:50] <stgraber> or :50 even
[21:50] <ScottK> Right.
[21:50] <ScottK> So if the 2100 respin is out of date for qapt, yes.  Please.
[21:50] <persia> It is in debian-cd, although in the branch, and not the package.  From infinity's suggestions, I get the impression that the bug should be retargeted, but I'm not sure of the semantics of that, as it's not in the debian-cd ubuntu package, nor in the debian-cd trunk branch on LP.  Can we do specific branch-targeting of bugs?
[21:51] <persia> (unless someone believes it to actually be a bug in syslinux code)
[21:52] <slangasek> it's a limitation of syslinux code
[21:52] <slangasek> well, or there's that -1 option, isn't there
[21:53] <slangasek> so I'm actually not sure how that works when you've got a mapped eltorito image
[21:53] <persia> What's the limitation in syslinux?  If it's being told to boot 0x80, and it does, why is this wrong?
[21:55] <slangasek> because 0x80 is the disk you just booted from
[21:55] <slangasek> so boot 0x80 is a loop
[21:56] <slangasek> I'm not sure you can properly solve this is a hybrid-friendly manner in bios
[21:57] <persia> Sure.  I agree it's a bug.  I'm just not convinced it's a syslinux bug, but rather a debian-cd bug.
[21:57] <persia> I'm not sure why syslinux shouldn't boot from BIOS-mapped first hard drive when instructed to "localboot 0x80"
[21:58] <slangasek> persia: er, show me how you can tell syslinux to dtrt
[21:58] <slangasek> it's a debian-cd bug iff there's already a way to express this to syslinux
[21:59] <slangasek> anyway, the place to target would be the ubuntu-cdimage project
[22:00] <persia> Ah, OK.  Not having hardware that does such BIOS mapping, I'll leave that alone then (as I can't test the -1 option).
[22:00] <infinity> I think the word "bug" is a bit harsh in this case.  Misfeature, perhaps. :P
[22:01] <infinity> The (potential) problem with switching to -1 is that some BIOSes, upon remap, may remove your HDD entirely from the boot list, so 18h would trigger floppy, then fail.
[22:01] <infinity> But that's theoretical, since I have no idea what any one person's weird BIOS will do. :/
[22:02] <ScottK> But that's at least no worse off.
[22:02] <infinity> Barring that potential strange behaviour, though, 18h is probably what one actually expects to happen, since it's just the generic "this boot device sucks, fall through to the next" call.
[22:03] <infinity> 18h being what, for instance, PXE firmware will do when it fails to get a BOOTP server, etc.
[22:03] <cjwatson> persia: bugs on our debian-cd branch go on the ubuntu-cdimage project
[22:04] <cjwatson> oh, slangasek said that
[22:04] <persia> But you also saying it changes my mind to actually do the retarget, as opposed to wait longer for someone to test the -1 thing with appropriate hardware before retargeting.  It can always come back, if it turns out to really be a syslinux thing.
[22:04] <infinity> cjwatson: We could switch to -1, call it "Attempt to boot from next device..." and call it good. :P
[22:05] <cjwatson> We could.  I'm not much interested, TBH :-)
[22:05] <cjwatson> I suspect that'll attract a different set of bugs.
[22:05] <infinity> Yeah, I don't really care deeply either way.  The obvious solution to "it doesn't work" is "remove the USB stick, doofus".
[22:06] <infinity> cjwatson: In the known-working case (CDs), -1/18h should work just as well.
[22:06] <cjwatson> Assuming sane BIOS ...
[22:06] <infinity> cjwatson: In the USB case, it'll likely just break in a different set of weird BIOS cases.
[22:08]  * infinity doesn't care terribly if it just stays kinda broken anyway, given that "I left the disk in the drive, oops" is a time-honored "I own a PC, and did a stilly thing" deal.
[22:08] <persia> Added an ubuntu-cdimage task: someone should set it to wontfix or switch to -1, and set it to fixreleased (and be willing to argue with folk about which is the right thing for follow-on reports).
[22:09] <infinity> Note that this isn't remotely a "new" bug.  Well, as new as the ability to boot USB thumb drives.
[22:09] <infinity> I don't see that dealing with it suddenly became urgent. :P
[22:11] <slangasek> that doesn't seem to be stopping anybody from talking it to death though :P
[22:14] <ScottK> slangasek: We could talk about systemd instead, if you'd prefer.
[22:14] <ScottK> ;-)
[22:14] <slangasek> doesn't bother me none
[22:15] <ScottK> It seems to be the recent driver for most extensive flogging of a dead horse I've seen lately.


[00:28] -kubuntu-ci:#kubuntu-devel- Project disco_unstable_akonadi build #45: STILL FAILING in 58 min: https://kci.pangea.pub/job/disco_unstable_akonadi/45/
[03:38] -kubuntu-ci:#kubuntu-devel- Project disco_stable_calligra build #26: STILL FAILING in 1 min 2 sec: https://kci.pangea.pub/job/disco_stable_calligra/26/
[08:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #2871: SUCCESS in 56 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/2871/
[08:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #2871: SUCCESS in 1 min 31 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/2871/
[08:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #2871: SUCCESS in 4 min 17 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/2871/
[10:53] <mparillo> Now that the DD beta is out, I am planning on reverting the wiki page (https://wiki.ubuntu.com/DiscoDingo/Beta/Kubuntu) link from the daily image back to the released image: http://cdimage.ubuntu.com/kubuntu/releases/disco/beta/ unless somebody objects.
[10:53] <mparillo> At least that was what we did for CC
 @valorie, That's not it valorie
[14:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #2872: SUCCESS in 55 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/2872/
[14:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #2872: SUCCESS in 1 min 12 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/2872/
 You mean it should be one listing with an install deb and snap buttons?
[14:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #2872: SUCCESS in 4 min 21 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/2872/
 Yes similar to how I believe the Ubuntu Software app does.
[17:54] <ahoneybun> mparillo: sounds good.
[20:26] <valorie> mparillo: I thought I already did that?
[20:26] <valorie> err, maybe not
[20:27] <valorie> ahoneybun: that would be OK too
[20:27] <valorie> as long as both choices are equally seen
[23:43] <mparillo> The ISO is not available under http://cdimage.ubuntu.com/kubuntu/releases/disco/beta/ *DURING* our testing; only after it is released. That is why you changed the wiki to point to the daily builds, but once the Beta is released, then the daily builds re-start. And in the past, we wanted the wiki page to point to the released beta. In fact, we might have written it that way from the beginning and only publicized the wiki
[23:43] <mparillo> outside this channel after the beta was announced.


[00:47] <ScottK> slangasek: If my publisher cycle math is right, it's about time to kick off some Kubuntu Live CD rebuilds so I can hunt down some testers.
[00:50] <slangasek> well, antimony pings but isn't letting me ssh in; I guess it's still fscking
[01:03] <slangasek> up now - build kicked off
[01:12] <ScottK> Thanks.
[01:13] <ScottK> I'll be away for a while, but will check in later.
[01:46] <slangasek> (built now)
[02:00]  * ScottK looks
[02:10] <ScottK> Call for testing sent out.  thanks.
[05:07] <ScottK> slangasek: Would you please do a binary reject of lazr.enum and then remove the source.  I swear I clicked on reject, but apparently not.
[05:07] <ScottK> As an added bonus, I get permissions errors if I try to do the binary reject.
[05:08] <slangasek> rejecting
[05:09] <slangasek> and removed
[05:15] <ScottK> Thanks.
[05:16] <ScottK> slangasek: Will you be around for a few minutes?  I have another one to reject.  I'd like to try it again just to confirm if I hit the wrong button.
[05:17] <ScottK> Meh.  Here I go.
[05:18] <ScottK> Rejecting worked  that time.  I must have hit the wrong button.
[05:18] <ScottK> Thanks again.
[05:25] <ScottK> dholbach is 0 of 2 for tonight.
[05:45] <slangasek> ScottK: still around, tho intermittently
[05:45] <ScottK> Thanks.  It worked the second time, so I must have hit the wrong button.
[05:46] <ScottK> I'm pretty well to the point of feeling like I've done about enough damage for one night.
[05:46] <slangasek> :)
[05:46] <ScottK> (didn't find a new package to accept yet)
[05:46] <slangasek> you could merge lp:~vorlon/kubuntu-default-settings/lp-557102, that shouldn't be much damage
[05:46] <slangasek> (OTOH, I haven't actually tested that the plymouth theme looks right with those changes)
[05:47]  * ScottK looks.
[06:01] <ScottK> I guess if it doesn't, we'll hear about it soon.
[06:09] <ScottK> slangasek: Uploaded and pushed.  Thank you for your contribution to Kubuntu.
[06:09] <slangasek> cheers :)
[06:09]  * ScottK goes and collapses.
[06:09] <slangasek> 'night!
[06:09] <ScottK> Good night.
[13:39] <Laney> Is there a particular syntax that would make processing a lot of binary removals easy for an AA?
[13:39] <Laney> (on a single arch only)
[21:53] <slangasek> Laney: ${package_name} ${binary_version_to_remove} probably does it
[21:56] <sistpoty> hey slangasek
[21:56]  * slangasek waves
[21:56] <sistpoty> slangasek: the sync queue is getting quite large... :/
[21:57] <slangasek> sistpoty: oh, perhaps I can help with that this weekend... if not, definitely will on Monday
[21:57] <slangasek> sistpoty: thanks for your work on the FFe processing today, btw
[21:57] <sistpoty> slangasek: that would be super! (maybe you can even delegate *g*)
[21:57] <sistpoty> slangasek: still at it, didn't manage to finish the list yet :(
[21:57] <slangasek> ScottK: so bug #557930 is turning out to be quite interesting; it seems that failsafe-X doesn't work so well if zenity isn't installed, which it isn't on Kubuntu
[21:59] <slangasek> /etc/gdm/failsafeXinit is provided by x11-common, but needs zenity to actually run and do anything useful
[22:00] <slangasek> ScottK: the script also tries to start gdm at the end... so maybe this is not the right place for kdm to be integrating with failsafe-X?
[22:12] <slangasek> sistpoty: delegate> for syncs?  all the other archive admins are already empowered to do those syncs, but they're all short on round tuits... :)
[22:13] <sistpoty> slangasek: thought you have some power to make the other aa's not short on time for handling syncs :P
[22:14] <slangasek> heh :)
[23:28] <sistpoty> woohooo, I've managed a complete run through ubuntu-release/+subscribedbugs :)
[23:32] <stgraber> congrats :)
[23:38] <stgraber> slangasek: seems like Edubuntu dailies aren't happening at the moment. Is there something wrong with the cronjob ?


[00:23] <a1fa> flocculant:
[00:23] <a1fa> yellow
[11:29] <bluesabre> flocculant, bumped the importance up
[11:58] <flocculant> bluesabre: cheers :)
[12:00] <flocculant> akxwi-dave: just so you are aware - .2 has apparently slid a bit - not sure when to atm
[12:00] <akxwi-dave> cheers mate
[17:09] <flocculant> knome: seems oem install fails globally - which I guessed would be the case
[18:32] <knome> flocculant, yep
[18:33] <flocculant> I guess the conversation needs to happen at some point - maybe next meeting ...
[18:35] <knome> ywah
[18:35] <knome> is that scheduled and if not, who should do that?
[18:35] <knome> apparently Unit193
[18:38] <flocculant> perhaps something to sensibly work towards for 18.04?
[18:38] <knome> yes
[18:38] <flocculant> oem - not Unit193's meeting ...
[18:39] <knome> well...


[01:34] <Slick666> Hello all, I've opened up a bug a couple days ago and I was wondering if There is anything more I need to add before it can be triaged
[01:34] <Slick666> https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/379055
[01:34] <ubot4> Launchpad bug 379055 in evolution "Evolution Exchange Proxy miss-match with system" [Undecided,New]
[03:24] <scream> I don't see the builds at
[03:24] <scream> http://iso.qa.ubuntu.com/qatracker/info/2707
[03:24] <scream> for example
[03:31] <Hobbsee> scream: they probably don't exist anymore
[03:32] <Hobbsee> hrm
[03:34] <Hobbsee> or never existed.  either way
[03:36] <Hobbsee> no, they must have existed.  how strange.
[03:37] <scream> I want to test and report bugs.
[03:37] <Hobbsee> scream: I think those are on a cron-job, and dailies get deleted every friday, or something
[03:37] <scream> Can you point me in the right direction. :)
[03:37] <Hobbsee> http://cdimage.ubuntu.com/ubuntu-server/daily/current/ always points to the latest server installation
[03:37] <Hobbsee> but, may not actually install
[03:38] <Hobbsee> the other option is to install a fresh copy of jaunty and dist-upgrade, or to install alpha 1 of karmic,and upgrade from there
[03:39] <JonCharge> So that is the desired iso for testing and reporting?
[03:39] <Hobbsee> if it works, sure
[03:39] <JonCharge> Are there specific things that need to be tested (perhaps another web page I need to read)?
[03:39] <Hobbsee> the most sensible option is to use the latest alpha, and upgrade off that
[03:40] <Hobbsee> seeing as that's actually been tested
[03:40] <Hobbsee> or at least, bits of it have
[03:40] <Hobbsee> which are at http://cdimage.ubuntu.com/releases/karmic/alpha-1/
[03:41] <Hobbsee> test anything and everything, i think
[04:01] <JonCharge> bug 379879 does not look like a bug, seems already installed from the dmesg upload, double check me before I invalidate it?
[04:01] <ubot4> Launchpad bug 379879 in ubuntu "package ltrace failed to install or upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/379879
[04:15] <Hobbsee> JonCharge: i'd ask mvo about that - dpkg shouldn't throw up it's hands for random reasons like that
[04:16] <JonCharge> Ok.
[05:13] <micahg> I'm not sure about this: bug 374398
[05:13] <ubot4> Launchpad bug 374398 in firefox "Glitches around checkboxes in Firefox" [Undecided,Incomplete] https://launchpad.net/bugs/374398
[05:13] <micahg> Graphics card issue or compiz?
[06:31] <micahg1> Hew: can you mark something triaged for me?
[06:32] <Hew> micahg1: Depends what it is. If you are not in ubuntu-bugcontrol usually marking as confirmed is good enough.
[06:33] <micahg1> bug 135066
[06:33] <ubot4> Launchpad bug 135066 in thunderbird "Thunderbird doesn't use Ubuntu icon theme" [Wishlist,New] https://launchpad.net/bugs/135066
[06:33] <micahg1> I thought the goal was to have stuff set as traiged that no longer needs attention unless someone will start working on it
[06:35] <micahg1> are you in bug-control?
[06:38] <Hew> Ideally yes, see https://wiki.ubuntu.com/Bugs/Status . Yes I am in bug-control. With this particular bug it is quite old, I would set it to incomplete and ask the reporter if they still consider this a bug with the latest release. Personally I don't consider that one a bug.
[06:38] <micahg> it's a wishlist
[06:38] <Hew> yes I know
[06:38] <Hew> they seem to be suggesting to change all email program icons to envelopes
[06:38] <Hew> just as firefox has the firefox logo, it seems appropriate that thunderbird has the thunderbird logo
[06:39] <Hew> this is my opinion of the report
[06:40] <Hobbsee> i doubt mozilla would let us even use a different logo, and distrubute it as 'thunderbird'
[06:40] <Hew> Hobbsee: very true!
[06:40] <micahg> it's not for the logo Hew, Hobbsee
[06:40] <micahg> It's about the mail icons
[06:40]  * Hobbsee waits for the bug to load
[06:40] <micahg> the mail icons do not have the TB logo
[06:40] <micahg> but there are themes available
[06:41] <micahg> this user just thinks that an ubuntu icon theme should be an option
[06:41] <Hew> ah ok, my mistake
[06:41] <micahg> which seems like more of an integration request
[06:42] <Hobbsee> again, i doubt mozilla would allow us that in our stock theme.  However, i think other themes do have a more fitting icon
[06:42] <Hobbsee> maybe i'm reading the bug wrong
[06:42] <micahg> but we could offer a package that would change the theme to an ubuntu icon theme
[06:43] <Hobbsee> this is true
[06:45] <Hobbsee> the question would hten be if it's worth it, or if it's more worthwhile to fix higher user effecting bugs
[06:45] <Hobbsee> i think
[06:46] <micahg> of course
[06:47] <micahg> but that's up to whoever wants to do it
[06:47] <micahg> that's why I think wishlist->triaged makes sense
[06:47]  * Hobbsee would be willing to hedge a bet that no one ever will, by the time they have to make the package, then get it thru REVU and into the archive, but whatever ;)
[06:48] <Hobbsee> for anyone who *is* wanting the icon to be different, i'd expect them to hack in and change the icon, tbh
[06:48] <micahg> Hobbsee: you're probably right, but it's not up to bug control whether an issue is taken care of or not, just to make sure there is enough info
[06:49] <Hobbsee> micahg: oh right.  so this is a hint for a developer to come and close it?
[06:49] <micahg> lol
[06:49] <Hobbsee> i can smack it down if you like
[06:49] <micahg> I'd rather just have it mark triaged
[06:50] <Hobbsee> but i think bugsquad can judge feasibility of things, ifthey're able to
[06:50] <Hobbsee> (iirc)
[06:51] <micahg> under won't fix, it says: controversial, not targeted for this version, feature developer won't implement
[06:51] <micahg> I don't think it falls into any of them
[06:52] <Hobbsee> probably the latter on there
[06:53]  * Hobbsee prods the bug
[06:53] <micahg> it's not an unreasonable request to have an app blend in, is it?
[06:54] <Hobbsee> this is a good question
[06:55] <micahg> Requests are exactly that, they don't have to be fulfilled
[06:56] <Hobbsee> Right, so this is then the debate of "do we leave bugtracker full of any and every request, or do we close stuff which we think won't get implemented, and have a saner bugtracker as a result"
[06:56] <micahg> well, if it's set to wishlist, then the devleopers can decide what to implement
[06:56] <micahg> they can sort by importance, can't they?
[06:57]  * Hobbsee wore her developer hat to modify that bug, fwiw
[06:57] <Hobbsee> i don't think I was initially clear on that, sorry
[06:57] <Hobbsee> and even things like sorting by importance get difficult when there are more than a couple of hundred bugs on a package
[06:57] <micahg> sorry Hobbsee, I don't see that as being a problem as they allow theming
[06:58] <Hobbsee> oh, do they?
[06:58] <micahg> I know, I'm trying to clear out the bug tracker for the old thunderbird package
[06:58] <micahg> yes, mozilla, allows theming for FF and TB
[06:59] <micahg> and I was suggesting it be a package for ubuntu purists
[06:59] <micahg> not even the default
[06:59] <Hobbsee> ah.  feel free to reopen it then
[06:59] <Hobbsee> hrm, gnomefreak's not here.  He could answer as part of the mozilla team
[07:00] <micahg> Yeah, I can check with him later
[07:01] <micahg> I added it to my ask file
[12:16] <xteejx> afternoon guys
[12:34] <xteejx> tell me about sane
[12:34] <xteejx> ubot4
[13:30] <skullhacks> In how many chats am I?
[14:07] <askand> What debug packages do I need to get debugsymbols to trace a segfault for firefox?
[14:33] <xteejx> !search firefox
[14:33] <ubot4> Found: ff3, ftp, firefox, kde firefox, autoscroll, fffc, thunderbird, ff@firefox, flash64bit, firefox-kde@kde firefox
[14:33] <xteejx> askand, firefox-3.5-dbg
[14:47] <yofel> askand: for ffx-3.5 beta use the package xteejx said, for the stable firefox (3.0) add the repository from https://wiki.ubuntu.com/DebuggingProgramCrash and install firefox-3.0-dbgsym
[15:17] <xteejx> !search qt4
[15:17] <ubot4> Found: qt
[15:17] <xteejx> !info qt
[15:17] <ubot4> xteejx: Package qt does not exist in jaunty
[15:17] <xteejx> !qt
[15:17] <ubot4> Qt is the Qt (pronounced "cute") toolkit, which forms the base of KDE and is used by many applications to provide a !GUI. Install the libqt3-mt-dev package to compile Qt 3 applications or libqt4-dev for Qt 4 applications. Qt 4.4 is available from hardy-backports
[15:25] <BUGabundo> guud day
[15:34] <askand> yofel: I still get (no debugging symbols found)
[15:35] <askand> after installing firefox-3.0-dbgsym
[15:36] <BUGabundo> askand: please pastebin a trace
[15:36] <BUGabundo> from the lines where it lacks gdb
[15:36] <BUGabundo> you can dpgk -S /path/to/that/lib
[15:36] <BUGabundo> and install the proper debug libs
[15:37]  * BUGabundo has more gdbsym libs then regular packages installed
[15:38] <xteejx> lol i'm not surprised bugabundo
[15:38] <xteejx> how is everyone today anyway?
[15:39] <askand> BUGabundo: http://pastebin.com/m3c98986d
[15:39] <BUGabundo> xteejx: going fine
[15:39] <xteejx> BUGabundo, good good :)
[15:40] <BUGabundo> askand: what's this? bt full'[K
[15:40] <BUGabundo> This GDB was configured as  "i486-linux-gnu"...
[15:40] <BUGabundo> very strange!!!
[15:41] <BUGabundo> why do you have it set for 486?
[15:42] <askand> BUGabundo: I have no idea :O but I wrote bt full
[15:43] <BUGabundo> askand: https://wiki.ubuntu.com/MozillaTeam/Bugs/Triage/Responses
[15:43] <BUGabundo> apt-get install firefox-dbg
[15:43] <BUGabundo> apt-get install libgtk2.0-0-dbg libnss3-0d-dbg libnspr4-0d-dbg libpango1.0-0-dbg libc6-dbg
[15:43] <BUGabundo> askand: https://wiki.ubuntu.com/MozillaTeam/Bugs/  too
[15:44] <askand> BUGabundo: Hm, i've got no libnss3-0d-dbg
[15:44] <BUGabundo> and all the others
[15:44] <BUGabundo> ?
[15:45] <askand> I have the others but libnss is not in my repos
[15:45] <BUGabundo> do you have te debug repo ?
[15:45] <askand> yep
[15:45] <BUGabundo> some need to be updated to the correct verions
[15:46] <BUGabundo> the wiki is outdate
[15:46] <BUGabundo> a good job for a new bug triager
[15:46] <BUGabundo> isn't micahg around '
[15:47] <micahg> BUGabundo: I'm here
[15:47] <micahg> what's up?
[15:47] <BUGabundo> another guy that never sleeps
[15:47] <BUGabundo> eheh
[15:48] <BUGabundo> micahg: wanna help update the mozillateam wiki page?
[15:48] <micahg> It's 9:45AM in Chicago :)
[15:48] <BUGabundo> its very outdated
[15:48] <BUGabundo> Sun May 24 15:48:15 WEST 2009
[15:48] <micahg> Yeah, I already was going to do some of that
[15:48] <BUGabundo> great
[15:48] <micahg> but mainly regarding flash
[15:48] <BUGabundo>  https://wiki.ubuntu.com/MozillaTeam/Bugs/  and
[15:48] <BUGabundo>  https://wiki.ubuntu.com/MozillaTeam/Bugs/Triage/Responses
[15:48] <BUGabundo> most debug libs and nss ave wrong version
[15:49] <micahg> This is the latest updated mozilla page
[15:49] <micahg> https://wiki.ubuntu.com/MozillaTeam/Bugs/TriagersHandbook
[15:49] <BUGabundo> no sure we should go with JJ or KK
[15:49] <BUGabundo> haa nice
[15:49] <BUGabundo> time to bookmark it
[15:49] <BUGabundo> all other should refer to that then
[15:49] <micahg> but  the other ones need updates as well
[15:49] <xteejx> !search update-notifier
[15:49] <ubot4> None found
[15:49] <xteejx> hmmmm
[15:49] <xteejx> !update
[15:49] <BUGabundo> ohh it's a poor page
[15:49] <ubot4> For upgrading, see the instructions at https://help.ubuntu.com/community/UpgradeNotes - see also http://www.ubuntu.com/getubuntu/upgrading
[15:50] <micahg> xteejx: what are you looking for?
[15:50] <BUGabundo> micahg: xteejx is looking to flood us
[15:50] <xteejx> trying to debug why update-notifier never kicks in when there are updates
[15:50] <xteejx> i dont flood :)
[15:50] <BUGabundo> xteejx: that would be bug 332945
[15:50] <ubot4> Launchpad bug 332945 in null "[Jaunty] Update Notifier icon would provide useful status information" [Low,Fix released] https://launchpad.net/bugs/332945
[15:51] <xteejx> BUGabundo, bug 126775 - problem since Feisty
[15:51]  * BUGabundo loves the "null" project
[15:51] <ubot4> Launchpad bug 126775 in update-notifier "Update Notifier does not work" [Medium,Confirmed] https://launchpad.net/bugs/126775
[15:51] <BUGabundo> brb... need to go to a wind machine to update my GPS maps
[15:51] <micahg> BUGabundo: I'll have to update it when asac is around, so maybe next week
[15:52] <BUGabundo> why do you need him?
[15:52] <BUGabundo> its just a case of looking for updated lib versions
[15:52] <BUGabundo> and change the text
[15:52] <micahg> well, I don't think that it's even necessary anymore
[15:52] <micahg> I think apport might take care of it
[15:52] <micahg> but I have to check
[15:53] <BUGabundo> micahg: apport doesn't generate backtracks on call
[15:53] <BUGabundo> just for crashes
[15:53] <micahg> right
[15:54] <micahg> but there's a whole section on crashes that might be able to be removed and replaced with a one line command
[15:59] <micahg> askand: libnss3-1d-dbg in Jaunty
[16:00] <askand> micahg: yes thanks, i have that installed but still get no debugging symbols found
[16:00] <BUGabundo> micahg: I would agree ... using apport is a good solution!!!
[16:00] <micahg> askand: is it a crash?
[16:00] <BUGabundo> but *remember* apport is only for II and latter
[16:00] <micahg> II?
[16:00] <askand> micahg: yes
[16:00] <BUGabundo> you still support GG
[16:00] <BUGabundo> II = interpid
[16:00] <micahg> no, we don't support GG
[16:00] <micahg> HH on
[16:00] <micahg> and apport is in HH
[16:01] <micahg> askand: what Ubuntu version?
[16:01] <askand> im on jaunty
[16:01]  * BUGabundo starts to mess actively supported versions
[16:02] <micahg> askand: sudo force_start=1 /etc/init.d/apport restart
[16:02] <micahg> then crash firefox
[16:03] <BUGabundo> that's one way
[16:03] <micahg> :)
[16:03] <BUGabundo> but how easy is it to crashe FF?
[16:03] <BUGabundo> ohh nevermind! stupid Q
[19:38] <xteejx> guys, is there a russian ubuntu irc room?
[19:39] <micahg> #ubuntu-ru
[19:39] <xteejx> micahg, just done /list , either theres no room or nno-one in it
[19:41] <kklimonda> !ru
[19:41] <ubot4> Пожалуйста посетите #ubuntu-ru для получения помощи на русском языке  / Pozhalujsta posetite #ubuntu-ru dlya polucheniya pomoshi na russkom yazyke
[19:41] <kklimonda> so, channel exists..
[19:41] <xteejx> i'm not russian, neither do i speak it lol
[19:41] <xteejx> it wasn't in /list, just joined it anyway and its there no worries
[19:41] <xteejx> :)
[20:17] <xteejx> !date
[20:17] <ubot4> Factoid 'date' not found
[20:18] <BUGabundo> Sun May 24 20:18:34 WEST 2009
[20:18]  * BUGabundo as usual, BUGabundo acts like a bot
[20:19] <xteejx> wrong window :)
[20:19] <BUGabundo> oh
[20:19] <BUGabundo> hey ogra
[20:19] <BUGabundo> long time no see
[20:22] <bcurtiswx> BUGabundo: i reinstalled ubuntu on my computer.. how to I take the GPG key stored on launchpad and put it on my current computer?
[20:22] <BUGabundo> you can't!
[20:23] <bcurtiswx> oh boo
[20:23] <BUGabundo> you should have made BACKUPS
[20:23] <BUGabundo> never never delete your GPG private key
[20:23] <micahg> Do you have a backup of your home directory?
[20:23] <BUGabundo> without backups
[20:23] <BUGabundo> now u need a new one
[20:23] <bcurtiswx> micahg, yes :D
[20:23] <BUGabundo> ohh then you are safe
[20:23] <BUGabundo> uff
[20:24] <micahg> restore the files in .gnupg
[20:24] <bcurtiswx> but, in case.. wheres a good tutorial on creating a new one
[20:24] <micahg> LP
[20:24] <bcurtiswx> ok
[20:24] <micahg> where your key is listed are the instructions for creating a new one
[20:25] <BUGabundo> bcurtiswx: use seahorse!
[20:25] <BUGabundo> its the easiest way with GUI
[20:26] <BUGabundo> or the LP help via CLI for *fast*
[20:32] <bcurtiswx> seems the ubuntu keyservers a little slow today
[20:42] <bcurtiswx> you guys use jabber a lot?
[20:42] <BUGabundo> bcurtiswx: somewhat
[20:42] <BUGabundo> depends on who I want to talk to
[20:43] <bcurtiswx> its it the main Im client for Ubuntu members
[20:43] <BUGabundo> but I have many conctacts there! I even use several MUC
[20:43] <BUGabundo> Pidgin
[20:43] <BUGabundo> bcurtiswx: ahah?? Ubuntu Members what?
[20:44] <bcurtiswx> well launchpad has a jabber id section for my profile.. makes me think that to contact other launchpad people they use jabber a lot
[20:44] <bcurtiswx> considering i've never heard of it until joining the ubuntu community
[20:45] <BUGabundo> ehehe
[20:45] <BUGabundo> its just a contact... like email
[20:45] <BUGabundo> surelly in the near future it will have µblog section
[20:45] <BUGabundo> LOLOL
[20:45]  * BUGabundo thinks of filing a wishbug
[20:45] <bcurtiswx> haha
[20:46] <BUGabundo> I really do
[20:46] <BUGabundo> of course it will be closed won't fix, since we can add it to the profile page
[20:46] <bcurtiswx> it seems jabber and its VV support is good with empathy
[20:49] <BUGabundo> nice
[20:56] <kklimonda> I can't get notifications to work with empathy :/
[20:57] <BUGabundo> I think a recent update mess them up
[20:57] <kklimonda> do you have a bug?
[20:57] <BUGabundo> nope
[21:11] <elena09> hello
[21:13] <BUGabundo> elena09: hi. long time no see
[21:13] <BUGabundo> what's you ?
[21:13] <BUGabundo> *up?
[21:13] <elena09> you fired me...
[21:14] <BUGabundo> hey andresmujica
[21:14] <andresmujica> hey Bugabundo!!! where are u?
[21:14] <BUGabundo> on the sofa
[21:14] <BUGabundo> at home
[21:14] <elena09> dropbox doesn't start when I choose applications-Internet-Dropbox
[21:15] <andresmujica> :)
[21:15] <BUGabundo> elena09: new version? if so, $ dropbox status
[21:15] <BUGabundo> and let me know
[21:15] <BUGabundo> but this is WAY off topic for this room
[21:15] <BUGabundo> pvt me please
[21:15] <kklimonda> you people still use dropbox? is so yesterday ;}
[21:15] <kklimonda> it's* ;)
[21:15] <BUGabundo> don't want to get anyone angry at us
[21:15] <kklimonda> :}
[21:15] <kklimonda> hehe
[21:15] <BUGabundo> kklimonda: ehehe I use both DB and U1
[21:15] <BUGabundo> and that is DropBox and UbuntuOne
[21:16] <BUGabundo> in case you don't know that those acronims are :))
[21:16] <andresmujica> which one is best for u?
[21:16] <elena09> hmmmm it says "idle" but the icon of Dropbox doesn't appear anymore in the upper right
[21:16] <kklimonda> BUGabundo: I've moved all my files from DB to U1 (and now it doesn't work :D)
[21:17] <BUGabundo> andresmujica: up until now DB by a lot
[21:17] <BUGabundo> elena09: $ dropbox stop
[21:17] <BUGabundo> and then
[21:17] <BUGabundo> elena09: $ dropbox start
[21:17] <BUGabundo> kklimonda: LOL
[21:17] <elena09> I did it and it says "dropbox already running"
[21:18] <BUGabundo> andresmujica: maybe when all the new features dobey (can't public) say there will be
[21:18] <elena09> the icon is missing from the upper right
[21:18] <BUGabundo> come out, it will be better, but until then DB is better
[21:18] <elena09> ok
[21:18] <BUGabundo> faster, share (that works), versoning, photo gallery, multi OS, mobile
[21:19] <BUGabundo> elena09: $ dropbox stop
[21:19] <elena09> Dropbox daemon stopped.
[21:21] <elena09> ok it works now
[21:21] <elena09> I started it again and it works. Thank you a lot.
[21:22] <elena09> :)
[21:23] <BUGabundo> np
[21:23] <BUGabundo> glad I could help
[21:23] <elena09> good night
[21:23]  * BUGabundo being *everywhere* has its advantages lol
[21:29] <xteejx> anyone have a RAID setup??
[21:29] <xteejx> Ref bug 129012, need some help.
[21:29] <ubot4> Launchpad bug 129012 in debian-installer "when setting up RAID, the installer appears to stall at a blue screen for 10 minutes. Suggest "watch cat /proc/mdstat"" [Medium,Incomplete] https://launchpad.net/bugs/129012
[21:32] <xteejx> Bug 129012 - can someone have a look at this for me please?
[21:32] <ubot4> Launchpad bug 129012 in debian-installer "when setting up RAID, the installer appears to stall at a blue screen for 10 minutes. Suggest "watch cat /proc/mdstat"" [Medium,Incomplete] https://launchpad.net/bugs/129012
[21:53] <Notch-1> hi all, please check this out: https://bugs.launchpad.net/ubuntu/+source/loop-aes-source/+bug/342902
[21:53] <Notch-1> this CONFIG_BLK_DEV_LOOP=y new setting is a huge problem for somebody, are there any chances to get back to CONFIG_BLK_DEV_LOOP=m ?
[21:54] <ubot4> Launchpad bug 342902 in loop-aes-source "Build error: ‘struct bio’ has no member named ‘bi_hw_front_size’" [Undecided,New]
[22:13] <bcurtiswx> does debian have an online bug submission form?
[22:14] <bcurtiswx> i see things for e-mail submission
[22:14] <kklimonda> bcurtiswx: it has a reportbug terminal tool
[22:15] <bcurtiswx> kklimonda: is that the main way I should push bugs upstream with debian?
[22:16] <kklimonda> bcurtiswx: that's the way I use.
[22:17] <kklimonda> bcurtiswx: beats writing email :)
[22:17] <BUGabundo> bcurtiswx: and it beats the hell of our tools
[22:17] <kklimonda> BUGabundo: why?
[22:17] <kklimonda> well, true - we could use similar tool..
[22:17] <BUGabundo> its that great
[22:17] <BUGabundo> isn't it ?
[22:17] <kklimonda> hmm, maybe i'll write something like that..
[22:17] <bcurtiswx> apport is our "tool"
[22:17] <BUGabundo> you have... its called LP
[22:17] <kklimonda> bcurtiswx: it uses browser
[22:18] <bcurtiswx> so here in ubuntu i type reportbug ?
[22:18] <kklimonda> reportbus i great because it's completely text based and fast..
[22:18] <BUGabundo> kklimonda: lp works on e-lynks!
[22:18] <BUGabundo> I filed a bug once with it
[22:18] <BUGabundo> FF wasn't opening
[22:18] <BUGabundo> lol
[22:18] <BUGabundo> Geek points for me
[22:18] <kklimonda> bcurtiswx: if you want to report bug to debian you use reportbug, if to ubuntu use ubuntu-bug
[22:20] <bcurtiswx> bcurtis@Weather:~$ reportbug
[22:20] <bcurtiswx> *** ERROR: "Ubuntu" BTS is currently unsupported.
[22:20] <micahg1> kklimonda: reportbug only works on a debian os
[22:20] <kklimonda> bcurtiswx: you have to add -B debian
[22:21] <kklimonda> micahg: I've used reportbug few times so it works just fine.
[22:21] <micahg> kklimonda: yeah, but don;t they get upset that you're reporting about a debian package based on the ubuntu version?
[22:22] <micahg> maybe the debian version doesn't have the issue
[22:22] <kklimonda> micahg: Well, I report only bugs that are present in debian (mostly packaging issues)
[22:22] <BUGabundo> micahg: we have no idea what bcurtiswx is trying to repport
[22:22] <kklimonda> micahg: sure - it doesn't make any sense to report bugs with ubuntu system to debian bts.
[22:22] <bcurtiswx> haha, im pushing bug #351369 upstream
[22:22] <ubot4> Launchpad bug 351369 in update-notifier "Preferences should allow for custom "check for updates" frequency" [Wishlist,New] https://launchpad.net/bugs/351369
[22:23] <BUGabundo> bcurtiswx: is debian the upstream project?
[22:23] <bcurtiswx> yup
[22:23] <BUGabundo> really?
[22:23] <bcurtiswx> i looked in gnome.. nope
[22:23] <bcurtiswx> googled it
[22:23] <bcurtiswx> only thing came up was debian
[22:24] <kklimonda> bcurtiswx: nope - it's ubuntu
[22:24] <BUGabundo> its upstream is resgitered  as a LP project
[22:24] <BUGabundo> to MVO
[22:24] <BUGabundo> bcurtiswx: https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/351369/+choose-affected-product
[22:24] <bcurtiswx> where can i find this _valuable_ information
[22:24] <ubot4> Launchpad bug 351369 in update-notifier "Preferences should allow for custom "check for updates" frequency" [Wishlist,New]
[22:24] <BUGabundo> so don't bother
[22:25] <kklimonda> bcurtiswx: apt-cache show update-notifier
[22:25] <BUGabundo> mvo will be notified of the bug anyway
[22:25] <kklimonda> bcurtiswx: check Maintainer field and package version
[22:25] <bcurtiswx> ahhh, ok
[22:25] <bcurtiswx> much thanks all!
[22:25] <kklimonda> bcurtiswx: Ubuntu packages has Maintainer who use @ubuntu.com email and don't have Original-Maintainer:
[22:26] <BUGabundo> who the heck wants to check hourly for updates?
[22:26] <BUGabundo> its going to hammer the server for nothing
[22:26] <BUGabundo> smells to me like wontfix
[22:27] <BUGabundo> there was this little apt-cron to do that btw
[22:27] <BUGabundo>  !package cron-apt
[22:27] <ubot4> BUGabundo: Error: I am only a bot, please don't think I'm intelligent :)
[22:27] <BUGabundo>  !info cron-apt
[22:28]  * BUGabundo kicks the bot
[22:28] <BUGabundo> !info cron-apt
[22:28] <ubot4> BUGabundo: cron-apt (source: cron-apt): automatic update of packages using apt-get. In component universe, is optional. Version 0.6.7 (jaunty), package size 24 kB, installed size 220 kB
[22:28] <BUGabundo> nothing like a little kick
[22:28] <bcurtiswx> did the space fool it ?
[22:28] <kklimonda> BUGabundo: is it just me or there are no X drivers for virtualbox guest in repository?
[22:28] <BUGabundo> bcurtiswx: I'm closing it
[22:29] <BUGabundo> ohhh I can't set it wontfix!
[22:29] <BUGabundo> hggdh: can you ?
[22:29] <kklimonda> :)
[22:29] <bcurtiswx> BUGabundo: i think the idea was just to have a custom time for users to choose
[22:29]  * BUGabundo needs to apply for bug control
[22:29] <BUGabundo> bcurtiswx: there's already a tool for that
[22:30] <bcurtiswx> i can set to wont fix
[22:30] <bcurtiswx> whats the tool for that?
[22:31] <BUGabundo> bcurtiswx: I just commented on it
[22:32] <bcurtiswx> i don't think thats what he was looking for though
[22:32] <bcurtiswx> i think he wanted it to be built into the program update-notifier and its settings
[22:32] <BUGabundo> its built into it, sort tha
[22:33] <BUGabundo> once it gets updates, and freshens the DB cache
[22:33] <BUGabundo> UN should fire up like usual
[22:33] <BUGabundo> at least it did for me on older version
[22:33] <BUGabundo> but with all this changes to UM who knows
[22:33] <BUGabundo> then again... AppCenter
[22:34] <BUGabundo> ohh how wonderful! an all new world of Bugs to be filled
[22:34] <bcurtiswx> i don't think won't fix is the right way to go though.  I'm going to set it back as triaged
[22:34] <BUGabundo> Invalid?
[22:36] <bcurtiswx> no, its a valid wishlist bug.  I think at this point MVO should take over. if he sees it triaged hes going to act on it.. if we keep changing the status, hes going to ignore it longer
[22:36] <BUGabundo> just got to catch him online and ask
[22:36] <BUGabundo> but he hasn't been coming in for a while
[22:37] <micahg> who is mvo?
[22:37] <bcurtiswx> yup, i will do that too.  marking as triaged tho
[22:37] <BUGabundo> hope everything is okay
[22:37] <BUGabundo> micahg: Michael Vogh
[22:37] <bcurtiswx> Michael Vogt (maintainer for update-notifier)
[22:37] <micahg> ah ok, still learning who all the players are here
[22:37] <BUGabundo> bcurtiswx: UM, synaptic, compiz, etc
[22:37] <BUGabundo> micahg: eheh
[22:37] <bcurtiswx> micahg: you will be for life :P
[22:37] <BUGabundo> micahg: checking devs LP page helps
[22:37] <bcurtiswx> BUGabundo: yeah. thx
[22:38] <BUGabundo> you can see what bug mail they get and what packages they upload
[22:38]  * micahg is pretty much sticking with Mozilla stuff for now
[22:40] <bcurtiswx> hi ogasawara
[22:41] <BUGabundo> hey ogasawara torkiano
[22:41] <kklimonda> why are virtualbox additions closed source? :/
[22:41] <torkiano> hello BUGabundo
[22:41] <kklimonda> that's sad..
[22:42] <BUGabundo> kklimonda: OSE or Suns closed one?
[22:42] <hggdh> er
[22:42] <hggdh> what is it I should do?
[22:42] <kklimonda> BUGabundo: dunno - i've installed virtualbox-ose and chosed Install Guest Additions from menu..
[22:43] <bcurtiswx> hggdh: nothing
[22:43] <hggdh> ah, OK ;-)
[22:43] <BUGabundo> hggdh: sorry to bother.. fixed
[22:55] <micahg> Debian planet just posted about debian bug #530000
[22:55] <ubot4> Debian bug 530000 in dbus "upgrading dbus and hal at the same time can break hal's init script" [Grave,Open] http://bugs.debian.org/530000
[22:55] <micahg> and that it takes them about 2 months for 10k bugs
[22:55] <micahg> we do that many in less than a month
[22:55] <micahg> so I"m wondering, when will LP bug # overtake Debian bug #s
[22:55] <BUGabundo> ehehehe
[22:55] <yoasif> micahg: soon?
[22:55] <yoasif> :)
[22:56] <BUGabundo> yep we do
[22:56] <BUGabundo> but micahg don't mistake LP bugs for Ubuntu bugs
[22:56] <BUGabundo> there are _many_ other projs there too
[22:58] <micahg> well, Ubuntu is at like 286k
[22:59] <micahg> LP's at close to 380k
[22:59] <BUGabundo> how do you know?
[23:00] <BUGabundo> those specific for ubuntu I mean
[23:00] <kklimonda> http://bugs.launchpad.net/ubuntu
[23:01] <kklimonda> All bugs ever reported   	283883
[23:02] <micahg> yeah
[23:02] <micahg> that's weird, last week we only added 1500 bugs
[23:02] <micahg> according to the newletter
[23:02] <micahg> *newsletter
[23:03] <BUGabundo> we are still lagging behing debian by a lot
[23:03] <micahg> well, as the user base expands, so will the bug reports
[23:04] <micahg> kklimonda: in 2 minutes, 20 bugs were reported :)
[23:04] <micahg> All bugs ever reported       reported                 283903
[23:09] <BUGabundo> damn... and none mine
[23:18] <BUGabundo> I find this very strange
[23:18] <BUGabundo> apport-crash                  15295
[23:18] <BUGabundo> apport-bug                  7433
[23:18] <BUGabundo> apport-package                  5375
[23:18] <BUGabundo> needs-packaging                  1675
[23:18] <ubot4> Launchpad bug 7433 in rsync "rsync: directory traversal in daemon mode" [High,Fix released] https://launchpad.net/bugs/7433
[23:20] <BUGabundo> and what the heck is this arch cft-2.6.27                  1405 ?
[23:22] <BUGabundo> wow dapper has more tagged bugs then JJ
[23:22] <micahg> BUGabundo: why does that surprise you?
[23:23] <micahg> dapper's been out for 3 years and JJ for 1 month
[23:23] <BUGabundo> well some one said the other day tat most bugs was from apport crash and I had an hard time beliving it
[23:23] <BUGabundo> but seems true
[23:23] <BUGabundo> but those 1765 needs packaging is A LOT
[23:27] <micahg> well, there are new software projects all the time and debian doesn't include all of them