[00:11] <Darxus> Is this an appropriate place to ask for help on azureus from karmic giving me an error on "debuild -S" of: "You must specify a valid JAVA_HOME or JAVACMD!"?  Google hasn't helped.
[00:22] <tormod> Darxus, try #ubuntu-motu (did you install all build-deps?)
[00:27] <Darxus> I tried #ubuntu-motu first.  They took 7 minutes to respond.  And it looks like the answer here was better.
[00:28] <cjwatson> seven minutes is a quick answer on IRC
[00:30] <Darxus> Wow, you typed out "seven".  And didn't capitalize it.  Weird.
[00:31] <slangasek> yes, that also happens on IRC
[00:32] <Darxus> Heh.
[00:32] <james_w> read(2) states that EAGAIN means that a non-blocking descriptor doesn't have any data for reading right now
[00:33] <slangasek> james_w: ?
[00:33] <james_w> damn, you noticed!
[00:33] <james_w> I was going to slink away quietly as I realised the stupidity of my question
[00:34] <slangasek> oh :)
[00:34] <james_w> it was how that could happen after poll said the fd was ready
[00:34] <james_w> I forgot about the successful read() in the middle
[00:59] <jono> just tried running
[01:00] <jono> ubuntu-bug  xsplash
[01:00] <jono> but I get:
[01:00] <jono> (gnome-open:5110): GLib-CRITICAL **: g_path_get_basename: assertion `file_name != NULL' failed
[01:00] <jono> Error showing url: Failed to execute child process "https://bugs.launchpad.net/ubuntu/+source/xsplash/+filebug/mqbjc344L61q7b3EzVB5nHO0IIs?" (No such file or directory)
[01:00] <jono> does that mean xsplash is not set up to work with ubuntu-bug?
[01:00] <seb128> jono, does it work on other sources?
[01:01] <jono> trying seb128 nope
[01:01] <jono> just tried with empathy
[01:01] <seb128> ok, what it looked like from the error
[01:01] <jono> jono@forge:~$ ubuntu-bug empathy
[01:01] <jono> (gnome-open:5225): GLib-CRITICAL **: g_path_get_basename: assertion `file_name != NULL' failed
[01:01] <jono> Error showing url: Failed to execute child process "https://bugs.launchpad.net/ubuntu/+source/empathy/+filebug/lBjafLHE35UK0YZyKBUrzd8xqDj?" (No such file or directory)
[01:01] <james_w> jono: System->Preferences->Preferred Applications
[01:01] <seb128> do you have a prefer browser configured and set to working binary?
[01:01] <james_w> what do you have as web-browser there?
[01:02] <jono> interesting
[01:02] <jono> it was custom
[01:02] <jono> let me try with firefox
[01:02] <jono> jono@forge:~$
[01:02] <jono> Gdk-ERROR **: The program 'firefox' received an X Window System error.
[01:02] <jono> This probably reflects a bug in the program.
[01:02] <jono> The error was 'BadWindow (invalid Window parameter)'.
[01:02] <jono>   (Details: serial 680 error_code 3 request_code 20 minor_code 0)
[01:02] <jono>   (Note to programmers: normally, X errors are reported asynchronously;
[01:03] <jono>    that is, you will receive the error a while after causing it.
[01:03] <jono>    To debug your program, run it with the --sync command line
[01:03] <jono>    option to change this behavior. You can then get a meaningful
[01:03] <seb128> that's a known firefox bug
[01:03] <jono>    backtrace from your debugger if you break on the gdk_x_error() function.)
[01:03] <jono> aborting...
[01:03] <jono> intereting
[01:03] <jono> interesting
[01:03] <seb128> try again ;-)
[01:03] <jono> ok will try chromium
[01:03] <maco> !pastebin
[01:03] <seb128> well it doesn't do it every time
[01:03] <seb128> jono, when they say that filing bugs will be harder they mean it ;-)
[01:03] <jono> maco, I know, it was short enough of a paste
[01:03] <jono> seb128, lol
[01:04] <jono> ok works in chromium :)
[01:34] <Darxus> The build-deps fixed my problem.
[01:34] <Darxus> Uploaded my first debdiff and subscribed ubuntu-universe-sponsors!
[02:59] <bluefoxicy> き
[02:59] <bluefoxicy> this glyph... the curve at the bottom should not connect with the leftward serif off the top segment
[03:00] <bluefoxicy> http://dic.academic.ru/pictures/enwiki/74/Japanese_Hiragana_kyokashotai_KI.png
[03:45] <Darxus> bluefoxicy: Submit a bug at https://bugs.launchpad.net/ubuntu/
[04:02] <TheMuso> cd
[04:02] <TheMuso> woops wrong tab
[04:03] <poningru> heh
[04:19] <glick> has anyone here heard/use MPC to build software?
[06:39] <dholbach> good morning
[06:41] <nixternal> good morning to you dholbach
[06:41] <nixternal> you've got mail btw
[06:41] <nixternal> I left MOTU :/
[06:42] <dholbach> hiya nixternal
[06:42] <dholbach> err
[06:42] <nixternal> it wasn't my fault though, GMail ate up the email about me expiring :)
[06:42] <dholbach> bah
[06:42] <nixternal> haha
[06:42]  * dholbach slaps nixternal around with a BIG trout
[06:42] <dholbach> man
[06:42] <dholbach> !
[06:42] <dholbach> not so early in the morning
[06:42] <nixternal> gotcha!
[06:42] <highvoltage> heh
[06:42] <nixternal> big trout? that is some mIRC there man
[06:42] <dholbach> you know what...
[06:43] <dholbach> find somebody else to re-add you to the team
[06:43] <nixternal> I can't unexpire myself
[06:43] <nixternal> I already asked the others :)
[06:43] <TheMuso> hehehehe
[06:43] <nixternal> I can't add myself, but I can remove you ;p
[06:43] <nixternal> so you will be in this same boat as well :)
[06:43] <nixternal> I expired in June too, just found out about it :)
[06:44] <nixternal> gotta keep an eye on it, cuz my ubuntu membership expired last month and ate up a weeks worth of email before I figured out what was wrong
[06:44] <dholbach> :)
[06:44] <nixternal> it was cool, because instead of 1,000 emails a day, I was getting about 5 a week :)
[06:56] <glick> hey does anyone here use SCONS or MPC as a build system?
[06:56] <glick> and which one is better/easier
[06:59] <dholbach> robert_ancell: could you hop into #ubuntu-reviews ?
[07:09] <TheMuso> glick: Never used mpc, but I've had to deal with projects usinc scons, and I would personally stay away from scons at all costs.
[07:16] <pitti> Good morning
[07:41] <glick> why TheMuso it looks pretty decent from reading about it on the website
[07:41] <glick> whats so horrible about it
[07:50] <TheMuso> glick: For one, scons has caused issues when package have been building on the Ubuntu  ubild servers for Ubuntu. Then there is the difficulty in passing CFLAGS etc to a project when the SConstruct files haven't been written properly.
[07:51] <TheMuso> glick: Granted autoconf is the same, but I have had too many bad experiences to recommend it to anyone. I also know that other devs around here stear well clear of it.
[07:52] <glick> can you recommend anything else? i have a project that needs to compile on windows, linux/unix, and vxworks, and integrity
[07:52] <glick> maintaining 5 build files is a nightmare, and MPC the current system is a pain
[07:54] <TheMuso> glick: I know that people manage to use autoconf/automake on windows using cygwin/mingw, but I am not sure how much more work that is. Since I have no experience with realy cross platform projects like that, I can't really suggest anything. My personal choice for a linux project is autoconf/automake.
[08:05] <wrapster> apt-sastisfydepends --> command not found
[08:05] <wrapster> devscripts have been installed
[08:20] <wrapster> can anyone help me?
[08:20] <wrapster> Im a newbie to packaging
[08:20] <pitti> wrapster: command-not-found doesn't know it either; what do you want to do?
[08:20] <pitti> wrapster: perhaps sudo apt-get build-dep <srcpackage> ?
[08:24] <wrapster> pitti: ive described everything here http://pastie.org/625614
[08:26] <dholbach> sudo apt-get build-dep gcc-4.4 (or gcc-4.3 if you want to modify that one) will be a good start
[08:26] <dholbach> you need gcc to compile gcc, there's no way around that
[08:27] <wrapster> dholbach: but wont it generate errors complaining that its already installed?
[08:28] <dholbach> no, because if you build the package using debuild or dpkg-buildpackage, it uses fakeroot(1)
[08:29] <ogra> pitti, bug 434210 ... you might want to close it if you feel like
[08:29] <pitti> ogra: oh, indeed; thanks
[08:30] <wrapster> dholbach: ok thanks will do it and see
[08:30] <dholbach> rock on!
[08:35] <wrapster> dholbach: cooool built it.. But i have an issue here.. i had already downloaded the gcc source so I used it as well.. But there are other pkgs (like gcc-4.3, gcc-4.3-dev and so on) how do i know in which pkg i should modify the rules file
[08:36] <dholbach> gcc (from gcc-defaults source package) is just a meta-package
[08:36] <dholbach> the actual gcc, comes from gcc-4.3 and gcc-4.4
[08:36] <dholbach> I don't know what you want to change, so I can't tell you which source package you should be modifying :)
[08:37] <dholbach> and for gcc, I'm really not the best person to talk to :)
[08:43] <wrapster> dholbach: i want to add a few symlinks to /usr/bin/gcc pointing to /usr/sfw/bin/gcc
[08:45] <Appiah> http://packages.ubuntu.com/ <- anyone else having problems reaching this page atm?
[08:45] <wrapster> i added that in the source of gcc. and it worked..
[08:45] <wrapster> i now have a symlink but not very sure if i am adderssing the right pkg
[08:46] <dholbach> wrapster: I'm not sure that's a good fix, but unfortunately I can't help you there
[09:09] <nubae|work> hi there... I work for Guadalinex-edu, and we are looking for a way to add the exit (logout options) button to the top panel via gconf... but cannot seem to find that option anywhere... can someone guide me as to where/how to do that (has to be done on a large scale, so can't do it via right click, etc)?
[09:11] <lool> pitti: Around?
[09:11] <lool> pitti: I'd like to discuss apport's hookutils with you
[09:12] <lool> pitti: I'd like to use the attach_gconf() utility for various packages but the settings are overwritten by each run since the section has a static name
[09:12] <lool> pitti: Would it be possible to use a dict in report['GConfNonDefault'] instead of a string?
[09:13] <lool> Otherwise I'm thinking of passing the section name as argument (name = 'GConfNonDefault') by default but can be overriden, or of moving the section around in the caller
[09:13] <pitti> hi
[09:13] <pitti> lool: the latter will work
[09:13] <pitti> lool: dictionaries as values aren't supported right now
[09:14] <lool> pitti: What about passing the name of the section as argument?
[09:14] <pitti> that would require writing marshalling and unmarshalling for the various file formats (RFC822, multipart-mime)
[09:14] <pitti> lool: right, that would be fine
[09:14] <lool> (Ok wasn't sure which "latter" you meant)
[09:15] <lool> pitti: Ok; another option is to always append to report['GConfNonDefault'] if it exists
[09:15] <lool> pitti: I can do any of these two (variable section or always appending)
[09:15] <pitti> lool: that sounds fine as well
[09:15] <lool> pitti: Ok I have a preference for always appending because in desktop-switcher I'd like to call other packages' hooks
[09:15] <pitti> seb128: ^ what would you prefer in bug reports?
[09:15] <lool> And I dont want to rename GConfNonDefault in each package
[09:15]  * ccheney can't sleep :-\
[09:16] <pitti> seb128: GconfNonDefaults having all changed settings from all packages in one field?
[09:16]  * ccheney so he is working instead, heh
[09:16]  * pitti counts sheep for ccheney
[09:16] <pitti> seb128: or separate fields per package?
[09:16] <seb128> pitti, I think I missed part of the discussion to understand the question
[09:16] <lool> pitti: I dont think it touches any package right now though
[09:16] <seb128> oh, apport
[09:16] <seb128> I was thinking gconf schemas
[09:17] <lool> seb128: So if apports utility to collect gconf non-default settings is called on two different packages, the last one wins; the question is whether you'd like the various settings to go in different sections or can they be aggregated in the same setting
[09:18] <seb128> I've no strong opinion either way, whatever is the easiest
[09:18] <seb128> as far as the datas are there
[09:18] <seb128> as long as
[09:18] <seb128> brb another quick session restart
[09:20] <lool> sebner: Ok thanks
[09:20] <lool> err sorry sebner
[09:24] <seb128> re
[09:24] <seb128> pitti, yeah, so no strong opinion there for the gconf dump as long as we have the datas
[09:24] <seb128> I think it's a corner case anyway
[09:25] <pitti> seb128: *nod*
[09:25] <lool> ok thanks
[09:25] <pitti> lool: so, same field and append seems most robust to me
[09:25] <pitti> then hooks don't need to care
[09:25] <lool> pitti: Yes exactly
[09:25] <seb128> +1
[09:25] <lool> that's what I was implementing
[09:34] <sladen> what's the deal with this ~60 seconds of ultimate pure blackness on boot now, with not even the black light turned on?
[09:34] <pitti> sladen: bug 431812
[09:37] <sladen> pitti: wondering whether to bump it to critical, it kills (recovery mode)
[09:39] <pitti> done
[10:00] <geser> pitti: Hi, I've looked at the cause of http://launchpadlibrarian.net/31948454/buildlog_ubuntu-karmic-i386.kde-l10n-sr_4%3A4.3.0-0ubuntu1_FAILEDTOBUILD.txt.gz (from the rebuild test) and it failed because both the sed expression in pkgstriptranslations and the locale name use an @:
[10:00] <geser> sed -i 's@^[[:alnum:]]\+  usr/share/locale/sr@latin/entry.desktop$@c7ff2ad283d1914db2c7797ce8789719  usr/share/locale/sr@latin/entry.desktop@' DEBIAN/md5sums
[10:01] <geser> I've replaced the @ in the sed expression with an # but wonder if there is a better delimiter
[10:02] <dholbach> ttx is doing patch/package reviews in #ubuntu-reviews
[10:03] <pitti> geser: hi
[10:03] <pitti> geser: oh, good catch; # should be fine, it's not a valid part of a locale
[10:09] <ogra> hrm, no Keybuk ...
[10:10] <pitti> ogra: he's on a conference
[10:10] <ogra> does anyone know how i'm supposed to start services if i boot with init=/bin/bash
[10:10] <ogra> now that we dont have any initscripts anymore
[10:11] <geser> have you tried: service - run a System V init script
[10:11] <ogra> it needs upstart :)
[10:11] <ogra> afaik
[10:11] <ogra> i'll try it
[10:19] <directhex> okay, mono <IP_ADDRESS>+dfsg-2 has definitely evaporated. i know it was "fix released"ed
[10:19] <directhex> Bug 426759, synced by seb128 weeks ago
[10:20] <seb128> directhex, you might have opened the sync request when the new revision was not on mirrors yet
[10:20] <geser> pitti: bug 434544 when you have some time for review and sponsoring
[10:21] <seb128> directhex, and I've overlooked the revision in the title
[10:21] <directhex>  - <mono_<IP_ADDRESS>+dfsg-2.dsc: downloading from http://ftp.debian.org/debian/>
[10:22] <sebner> directhex: pitti acked my sync request. seb128 mind syncing again?
[10:22] <sebner> seb128: bug #433070
[10:22] <pitti> geser: thanks! I'm currently doing sponsoring anyway, will grab this
[10:22] <seb128> directhex, dunno what happened
[10:22] <directhex> sebner, i wish i knew what had happened to it. eaten by gremlins!
[10:22] <sebner> directhex: lost in the nirvana :\
[10:22] <directhex> seb128, uploaded to debian 2 days before you ran the sync, so it can't be a timing issue :/
[10:23] <directhex> seb128, launchpad be eatin' packages!
[10:23] <seb128> I might have forgotten to flush and somebody cleaned the cache dir
[10:23] <seb128> doing that now
[10:27] <cjwatson> maybe we should invent an upstart mode that starts upstart but then just drops into a shell task and blocks everything else until you explicitly ask for them
[10:27] <cjwatson> like init=/bin/bash except you get to use initctl
[10:27] <ogra> yeah
[10:28] <ogra> well, that doesnt help me either though ...
[10:29] <bdrung> do i need a ffe for bug 430658?
[10:29] <ogra> in rootstock i use debootstrap first stage on an image, put a setup script in place (called /sbin/installer), then fire up a vm and call that with init=/sbin7installer
[10:29] <directhex> cjwatson, was i imagining over the weekend that fsck happens after modesetting but before any splashing, so you just get a black screen for an unknown and scary length of time?
[10:29] <cjwatson> directhex: there are known bugs getting fbcon up at the right time
[10:29] <cjwatson> directhex: bug 431812
[10:29] <ogra>  /sbin/installer being a shellscript, upstart would have to act like an interpreter here
[10:29] <directhex> just checking
[10:30] <cjwatson> ogra: the kernel is perfectly good at spawning interpreters where necessary, even for init=
[10:30] <cjwatson> or for anything started via execve in any way
[10:30] <ogra> oh, wait, /sbin/installer could be an upstart job i assume :) ... a little more work for me but likely a lot more elegant
[10:31] <ogra> and i wouldnt need init= at all
[10:31] <seb128> pitti, any idea on bug #430494?
[10:31] <seb128> I'm not sure how to debug upstart scripts
[10:31] <cjwatson> ogra: that is certainly a better replacement
[10:31] <ogra> cjwatson, yeah, i just fear the amount of changes i have to do that late in the cycle
[10:32] <ogra> seems more risky than having something that already is proven to work fine since a while
[10:32] <cjwatson> *shrug* goes for the whole boot sequence
[10:32] <ogra> heh, yeah
[10:33] <lool> pitti: Mind reviewing/merging lp:~lool/apport/gconf-non-defaults-append ?
[10:34] <lool> Didn't send a merge request yet
[10:34] <pitti> lool: sure
[10:34] <lool> This worked in my trivial testing
[10:35] <lool> With a nice split between the settings when reading the report
[10:35] <ogra> hmm, no, that wouldnt work, in debootstrap's second stage upstart isnt available, is it ?
[10:36] <pitti> lool: hm, why does your branch also contain kees' changes to parse_segv?
[10:37] <lool> pitti: I branched lp:apport
[10:38] <pitti> oops, forgot to pull first, my bad
[10:38] <pitti> lool: but now you added attach_conffiles(), which doesn't belong into trunk
[10:38] <pitti> lool: without that, it looks fine
[10:39] <lool> pitti: Oh crap
[10:39]  * pitti drops it and merges
[10:39] <pitti> lool: don't worry
[10:39] <lool> pitti: I'm stupid I started on the wrong branch and copied the file over instead of the diff
[10:39] <pitti> lool: conffiles aren't an upstream concept, so I can't have that in trunk
[10:39] <lool> pitti: So I didn't quite get how the stacks were layered; I saw the ubuntu branch but though that was packaging
[10:40] <lool> but actually it's not
[10:40] <pitti> done
[10:40] <pitti> thanks!
[10:40] <bdrung> pitti: do i need a ffe for bug 430658?
[10:40] <lool> pitti: So I just pull upstream into ubuntu branch?
[10:40] <lool> pitti: I mean do you mind the changes going to the .diff?
[10:41] <pitti> lool: I do that now; there's a fair share of trunk changes, I do a new upstream release and then upload
[10:41] <lool> pitti: Thanks
[10:41] <pitti> lool: I don't mind changes in the diff, but it's time for a new usptream relelase
[10:41] <pitti> bah, my typing sucks today
[10:41] <pitti> bdrung: I'll have a look, but lintian shouldn't cause problems
[10:42] <bdrung> pitti: thanks
[10:42] <bdrung> TheMuso: ping
[10:47] <bdrung> pitti: can you add "discuss UnitsPolicy" to the TB agenda?
[10:48] <pitti> bdrung: feel free to add it yourself; do you want to be present?
[10:48] <bdrung> yes
[10:49] <bdrung> pitti: according to the wiki: "in which case they will add it to this page. " so i thought i should ask
[10:50] <pitti> bdrung: right, I'm fine with discussing it
[10:59] <lool> pitti: Ah I might have found a bug in the gconf handling in apport with gnome-panel
[10:59] <Appiah> is there no openvz kernel in karmic?
[10:59] <lool> pitti: hook is http://paste.ubuntu.com/275760/
[10:59] <lool> pitti: traceback http://paste.ubuntu.com/275761/
[11:00] <soren> Appiah: Not since Intrepid.
[11:00] <soren> Appiah: Last one to have it was hardy.
[11:00] <pitti> lool: hm, I thought I fixed that a while ago
[11:01] <pitti> lool: but it might have been a similar crash (also in the xml parser)
[11:01] <lool> pitti: If you copy that hook in source_gnome-panel.py in /usr/share/apport/package-hooks and run ubuntu-bug gnome-panel, can you trigger it?
[11:02] <pitti> lool: hm, no, I can't
[11:03] <pitti> lool: ah, I fixed the crash for the "default" tag
[11:03] <pitti> but not for <applyto>
[11:04] <lool> pitti: I have the issue with /usr/share/gconf/schemas/panel-compatibility.schemas
[11:04] <lool> Which has no applyto
[11:04] <pitti> right, no applyto here
[11:04] <lool> pitti: but I dont get why you dont reproduce
[11:05] <pitti> lool: ah, I do actually; sorry, it scrolled off due to some firefox spewage
[11:06] <pitti> hm, without an <applyto>, how does gconf behave?
[11:06] <lool> I have no idea
[11:06] <pitti> I think I just fall back to the <key> value
[11:06] <pitti> it will have the /schemas/ prefix, but it should be clear enough
[11:06] <lool> pitti: Hey did you consider creating a dh_apport?
[11:06] <lool> I'm adding a debian/source_foo.py to a bunch of packages and realize it's not ideal
[11:07] <pitti> I didn't so far
[11:07] <pitti> I usually put them into debian/local and just add them to .install
[11:07] <lool> pitti: I also wonder whether it wouldn't make sense to simply collect gconf settings systematically
[11:07] <pitti> lool: I'm a bit hesitant of that
[11:07] <pitti> lool: for example, ekiga stores passwords unencrypted in gconf
[11:07] <lool> pitti: I add them to debian/ and add them to .install; it's trivial but it's also the perfect usage for dh_  :-)
[11:08] <lool> pitti: Aha good point
[11:08] <pitti> arguably that's an ekiga bug (it should use gnome-keyring)
[11:08] <lool> It's probably a bug in ekiga but there might be a bunch
[11:08] <pitti> but I don't know what other bits also store sensitive bits in gconf
[11:08] <lool> Yeah we're n the same page
[11:08] <pitti> heh
[11:11] <lool> pitti: I've added the hook to gnome-panel now (in bzr only) and wont upload; I understand you'll likely fix this apport issue soon and upload, or should I explicitely disable the hook for now and wait for the actual apport upload?
[11:12] <pitti> lool: http://bazaar.launchpad.net/%7Eapport-hackers/apport/trunk/revision/1605
[11:12] <pitti> lool: please go ahead and upload; a crashing hook doesn't crash apport, it's just ignored
[11:12] <pitti> lool: yes, I'll put that into the 1.9.1 release and upload
[11:12] <lool> Cool thanks
[11:13] <lool> pitti: Bah I dont want to cause people to be wondering about the ubuntu-bug stracktrace in terminal or reports to miss dependencies etc.
[11:13] <lool> Or pedro is going to come and beat me
[11:16] <pitti> lool: it's just for two hours or so :)
[11:17] <lool> that's what I wanted to confirm; thanks
[11:47] <doko> pitti: would you mind a python-tz sync from unstable?
[11:48] <pitti> doko: 2009l-1 ?
[11:49] <doko> pitti: yes
[11:50] <pitti> doko: done
[12:32] <dholbach> pitti, seb128: what do you think we should with bug 63412? it's been on the sponsoring list for a while and set upstream
[12:32] <dholbach> sent
[12:32] <seb128> dholbach, +do?
[12:32] <cjwatson> does it need to be uploaded, or should it just be taken off the sponsorship list since it's been upstreamed
[12:32] <seb128> dholbach, I've been looking at it, the patch is some hundred lines and not trivial to review I don't want to upload it
[12:33] <seb128> well let's say I didn't find the time to review it properly
[12:33] <cjwatson> so shall we unsubscribe the sponsors team so we don't have to keep on looking at it, in that case?
[12:33] <seb128> and I'm not wanting to spend half an hour on that, I've higher todo items on my list
[12:33] <dholbach> it looks a bit like tsclient is dead upstream?`:)
[12:33] <seb128> well, there is a patch so it would be nice to have somebody to review it
[12:36] <pitti> hm, the patch hasn't even been sent to upstream
[12:36] <seb128> it has if that's the bug I'm thinking about
[12:36] <james_w> dholbach: 'tis not
[12:37] <seb128> oh, there is 2 tsclient sponsoring requests
[12:37] <seb128> right that's the other one who got sent upstream
[12:37] <seb128> I think debian pkg-gnome guys were discussing replacing tsclient with something active upstream recently
[12:37] <dholbach> http://sourceforge.net/tracker/index.php?func=detail&aid=1689142&group_id=192483&atid=941574 links to http://sourceforge.net/tracker/?func=detail&aid=2799711&group_id=192483&atid=941576
[12:37] <seb128> and maybe vinagre will have the features next cycle
[12:38] <dholbach> james_w, pitti: ^
[12:38] <dholbach> sf's tracker is a pain in the arse
[12:38] <seb128> meanwhile I'm not sure what to do with the "should be reviewed but everybody is too busy or doesn't care about the software" bugs
[12:38] <pitti> seb128: there's an upstream bug with about zero details, and no patch attached
[12:38] <seb128> they sit there for ages right now
[12:39] <seb128> pitti, the patch is there IIRC they ui just sucks
[12:39] <pitti> "No attachments", hm
[12:39] <dholbach> aha: "Launchpad couldn't import bug #1689142 from SourceForge.net Tracker."
[12:39] <pitti> ah, it has a link to the patch in a comment
[12:39] <dholbach> pitti: try the second link I gave above
[12:39] <dholbach> *nod*
[12:40] <pitti> seb128: it's mainly "I don't want to take responsibility for the patch"
[12:40] <pitti> it's a major patch, and I don't use tsclient, and it's not a major bug
[12:40] <pitti> and there's no upstream feedback
[12:40] <seb128> right, same here
[12:40] <pitti> and I guess it's the same for everyone else
[12:41] <seb128> that's why I've been ignoring it and waiting that somebody who cares to spend the efforts take it
[12:41] <pitti> so, anyone objects if we are honest and I just unsub sponsors with a comment that it should go upstream first?
[12:42] <seb128> it's upstream, they don't reply
[12:42] <seb128> I can understand how it's frustrating for the user
[12:42] <dholbach> pitti: no, I'll also ping Efrain to ping upstream again
[12:42] <seb128> I don't have a good reply though
[12:44] <pitti> done
[12:44]  * pitti sees the bullets come
[12:45] <mvo> davmor2: could you please file a bug about the missing entires in software-store on the live-cd?
[12:46] <davmor2> mvo: will do I'm just double checking that it works as expected once the system is installed
[12:46] <mvo> davmor2: cool, thanks
[12:48] <cjwatson> ogra: bug 129769: the patch provided there is correct, but do you think xscreensaver (or xscreensaver-data?) should recommend screensaver-default-images as well?
[12:48] <ogra> screensaver-default-images should simply go away imho
[12:48] <cjwatson> maybe that would be over the top, I'm not sure
[12:48] <cjwatson> oh
[12:48] <cjwatson> huh, ok - in that case I'll just sponsor the patch provided to fix the error
[12:49] <ogra> its marks personal image collection
[12:49] <ogra> was supposed to be taken over by the art team with new and shiny images for each release
[12:49] <cjwatson> right
[12:49] <ogra> that never happened, so we could as well save the CD space
[12:56] <seb128> cjwatson, developer-membership-board invitation to join ubuntu-desktop pending now
[12:56] <seb128> cjwatson, ie somebody needs to accept it
[12:57] <cjwatson> seb128: done
[12:58] <seb128> cjwatson, thanks, set as admin too now
[13:05] <ogra> does anyone know if upstart is supposed to work without initramfs ?
[13:06] <lool> ogra: yes it should
[13:06] <ogra> thanks
[13:06] <lool> ogra: I have that from an email of scott from this morning or yesterday evening
[13:06] <ogra> i dont get why my VM gets quiet then
[13:06] <lool> s/of/from
[13:06] <ogra> i dont get any boot messages at all
[13:07] <lool> ogra: How can I easily reproduce?
[13:07] <ogra> i can put my rootstock script on people.u.c and you need to install qemu-arm-static
[13:08] <lool> Ok
[13:08] <ogra> gimme one sec until the next test finishes
[13:08] <ogra> i dropped all serial redirection, lets see if i see output in grapical mode of qemu-system-arm
[13:09] <ogra> hmm, no, doesnt look like
[13:09] <ogra> and the VM doesnt even use any CPU
[13:10] <ogra> just sits there
[13:12] <ogra> lool, http://people.canonical.com/~ogra/rootstock
[13:15] <wrapster> how to i use the debchange -i to change the version number?
[13:16] <pitti> wrapster: dch -v <version number>
[13:17] <wrapster> pitti: what Im doing is actually modifying an existing pkg and i need to change the version number thats all..
[13:17] <wrapster> pitti: i should use -v aye?
[13:18] <pitti> wrapster: you shouldn't change an existing version number
[13:18] <pitti> usually you add a new changelog entry with a new one?
[13:18] <wrapster> pitti: yes thats what  I want to do
[13:18] <ogra> dch -i ... in the tree of your unpacked source package
[13:19] <ogra> that should fire up an editor with the changelog and incremented version number
[13:19] <wrapster> yeah it did.. then
[13:19] <wrapster> im a newbie so pls help
[13:20] <ogra> well, you add your changelog entry after * (usually thats where your cirsor stands too at that point)
[13:20] <ogra> *cursor
[13:21] <ogra> soren, do you have to jump through any hoops to make upstart work in VMs ?
[13:22]  * ogra doesnt seem to get qemu starting a basic deboostrapped image
[13:22] <soren> ogra: Not really.
[13:22] <ogra> weird
[13:23] <ogra> i get zero output ... VM just sits there ... upstart doesnt seem to exec any jobs
[13:26] <lool> ogra: Which package is the static qemu in?!?
[13:26] <ogra> qemu-arm-static
[13:26] <ogra> only i386 though
[13:26] <lool> Why?
[13:26] <lool> (I'm running amd64)
[13:27] <ogra> because i had reports that people had additional syscall probs there ... i386 runs reliable
[13:27] <ogra> though that wasnt actually with qemu-arm-static but with my former version
[13:27] <ogra> i should enable amd64 again
[13:27] <lool> As in it cant work due to a technical impossibility or really hard to fix problem, or it's a bit buggy?
[13:28] <ogra> my former version surely was buggy
[13:28] <ogra> the one in the package might not, i went the safe path and didnt enable amd64
[13:28] <ogra> i probably should swithc it on again
[13:29] <lool> ogra: uploadin
[13:29] <lool> g
[13:29] <ogra> what ?
[13:29] <lool> With amd64 and lpia enabled
[13:29] <ogra> ugh, lpia ?
[13:29] <lool> yeah do you care?
[13:29] <ogra> remember its all syscall translations :)
[13:29] <ogra> not really
[13:29] <ogra> apart from the bugreports i might get
[13:30] <lool> on lpia?
[13:30] <ogra> well, who knows
[13:30] <lool> ogra: I just changed control; I think that's all what was needed
[13:31] <ogra> yep
[13:31] <ogra> but i dont know if it will work :)
[13:31] <ogra> we'll see
[13:31] <lool> Did you see qemu ftbfs on armel?
[13:32] <lool> and ia64 and powerpc, for three different reasons
[13:33] <ogra> yes, we talked about it before
[13:33] <ogra> to be honest i dont really care
[13:35] <ogra> hmm
[13:35] <ogra> so: qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel qemu-vmlinuz -hda qemu-armel-200909221415.img -m 256M -append "root=/dev/sda rw"
[13:35] <ogra> gets me buffer I/O errors on sda
[13:35] <ogra> thats new
[13:36] <lool> that's what I was getting all the time when used as a buildd
[13:36] <ogra> oh, because i just stopped the VM before
[13:36] <lool> and infinity too
[13:36] <ogra> i didnt
[13:37] <ogra> and it works if i start with init=/bin/bash
[13:37] <ogra> but then i'm missing the handfull of services i need
[13:37] <lool> then it's something else
[13:37] <ogra> its pretty clearly upstart
[13:37] <lool> I'm speaking of the sda errors
[13:37] <ogra> which i would be fine living without ...
[13:37] <ogra> but there is no chance to exec initscripts without it anymore
[13:54] <wrapster> ogra: and just write the version no there? like say * 1.6.2
[13:56] <ogra> no
[13:56] <wrapster> ogra: http://pastie.org/625551 have a look at this.. is it a makefile issue or because i've not updated the changelog properly?
[13:56] <ogra> the version should already be in the top line
[13:57] <ogra> that has nothing to do with dch -i
[13:58] <wrapster> hmm a broken makefile you say?
[14:00] <ogra> no, probably a codepiece that generates changelog from another file that hasnt been run or something
[14:00] <ogra> in any case debian/cpp/usr/share/doc/cpp/changelog doesnt exist
[14:00] <ogra> try to find out why
[14:01] <ogra> shouldnt be caused by you using dch -i
[14:01] <wrapster> yeah its been written in the rules...
[14:02] <wrapster> anyway http://pastie.org/625551 i landed up with this.. is it normal to have warnings?
[14:09] <james_w> yay pitti!
[14:09] <pitti> james_w: what did I break?
[14:09] <james_w> do you have bzr branches you would like me to push to bzr.debian.org?
[14:09] <james_w> nothing (I hope) :-)
[14:09] <james_w> you uploaded bzr et. al.
[14:09] <pitti> james_w: no, I didn't; those were two syncs and two trivial package updates
[14:09] <pitti> most of the time was testing and running "make check", etc.
[14:10] <pitti> well, bzr itself has some path changes
[14:10] <james_w> well, I was pulling my hair out on Friday about the bzr.install change
[14:10] <pitti> james_w: for the doc translations?
[14:10] <james_w> yeah
[14:10] <pitti> I just updated it in the .install file
[14:10] <james_w> I changed the paths in that file and it FTBFS
[14:11] <james_w> I was blaming CDBS
[14:11] <james_w> it wasn't running "setup.py install" before dh_install
[14:11] <james_w> but at least it is done now
[14:11] <pitti> weird, built fine here
[14:11] <pitti> and on the buildds too
[14:12] <james_w> yeah
[14:12] <james_w> ah, that was it, I was doing the PPA packages first, which have a -doc package split
[14:12] <pitti> james_w: ah, perhaps it's not run on -B ?
[14:12] <wrapster> pitti: are you referring to me?
[14:13] <james_w> it was running "setup.py install" after dh_install for arch-all packages but before arch-any
[14:13] <james_w> no, I'd only got as far as my local pbuilder
[14:13] <pitti> wrapster: no, I wasn't actually; what do you mean?
[14:13] <james_w> I should have focused on the Debian/Ubuntu packages first
[14:13] <james_w> anyway, thanks again
[14:13] <pitti> my pleasure
[14:13] <wrapster> pitti: anyway.. so did you go through the pastie?
[14:14] <pitti> well, it was a mail in my ubuntu folder, and they are pestering me :)
[14:14] <pitti> wrapster: http://pastie.org/625551 ? that looks very complicated; you usually don't call -genchanges manually
[14:15] <pitti> just do debuild or dpkg-buildpackage
[14:15] <wrapster> hmm
[14:17] <pitti> seb128: FYI, current retracer crash is due to chroot upgrade failure; fixing
[14:18] <seb128> pitti, thanks
[14:23] <wrapster> pitti: its all about understanding makefiles.. but im not very good at it.. i only know a little basics.. do you happen to know any links that i can refer?
[14:23] <wrapster> for understanding makefiles
[14:25] <pitti> wrapster: I think there should be plenty of tutorials on the web
[14:26] <StevenK> The info page for make has a good overview, but that means reading info pages. :-/
[14:32] <dholbach> seb128: hum... got any reports that gdm is not starting properly?
[14:32] <seb128> dholbach, no
[14:32] <seb128> or some
[14:33] <seb128> but usually those are xorg driver issues or the xorg server crashing or upstart
[14:33] <dholbach> seb128: I just started the machine and just had the black login screen (up-to-date from around 10 UTC), then dist-upgraded to the newest versions, rebooted, same resulted
[14:33] <dholbach> sudo restart gdm    started gdm
[14:33] <dholbach> now I'll try booting it again
[14:34] <seb128> I didn't update today yet
[14:34] <seb128> and didn't read about those
[14:34] <seb128> but you might be an earlier upgrader, I will keep an eye for bugs about that
[14:35] <dholbach> ah... ctrl-alt-f7 gets me to gdm too
[14:35] <dholbach> just the regular boot doesn't get me there
[14:35] <dholbach> *shrug*
[14:35] <ogra> buy more consoles ...
[14:35] <seb128> maybe pitti knows better about those sort of issues
[14:35] <ogra> we sell them cheap in the ubuntu shop ;)
[14:35] <dholbach> ogra: I need to wait for my pay cheque, I guess :)
[14:36] <ogra> heh
[14:37] <dholbach> ogra: do you have an idea about bug 129769?
[14:37] <ogra> dholbach, i think cjwatson just uploaded/sponsored a fix
[14:37] <dholbach> oh ok
[14:37] <dholbach> nm
[14:37] <dholbach> lalala :)
[14:37] <ogra> :)
[14:49] <uni4dfx> hello, my karmic doesn't wanna boot anymore
[14:49] <uni4dfx> dmesg complains about some "Firmware Bug"
[14:50] <tormod> uni4dfx: like not fatal. how far does it boot?
[14:50] <tormod> likely not fatal
[14:50] <uni4dfx> i can login
[14:50] <uni4dfx> but there's no X
[14:50] <uni4dfx> and most of the modules aren't loaded
[14:51] <tormod> uni4dfx: fully updated?
[14:52] <uni4dfx> probably not, last time i updated was 2 days ago
[14:52] <uni4dfx> and it didn't wanna update anyway since it got into some errors
[14:52] <tormod> uni4dfx: ubuntu+1 is a better channel for this
[14:52] <sandy|lurk> Hi, there appears to be some ancient automatic import from Tomboy SVN (we moved to git six months ago) to Launchpad here: https://code.launchpad.net/~vcs-imports/tomboy/head
[14:52] <uni4dfx> good point
[14:52] <sandy|lurk> I'm not sure if I should file a bug or what
[14:53] <sandy|lurk> but what I'd like is to either get rid of it (it's misleading) or have it pull from git master
[14:53] <Laney> sandy|lurk: you should talk to someone in #launchpad about it
[14:53] <sandy|lurk> Laney: will do, thanks
[14:54] <cjwatson> sandy|lurk: https://answers.launchpad.net/launchpad-bazaar is the way we ask for changes there
[14:54] <jelmer> pitti: thanks for updating bzr-svn for karmic!
[14:55] <pitti> jelmer: no problem; it was mainly testing that the Debian experimental package works :)
[14:55] <sandy|lurk> cjwatson: ok, take care folks
[15:00] <uni4dfx> any idea what module the ULi 1689,1573 integrated ethernet device uses?
[15:17] <jjardon> pitti, good news, evolution doesn't depends on HAL now: http://git.gnome.org/cgit/evolution/commit/?id=5a80f92d37e7e8a814f70f826b7b33f5d21b0f72 :)
[15:19] <pitti> jjardon: cool!
[15:19] <pitti> jjardon: did that land in 2.28.x still? or just trunk?
[15:21] <jjardon> I think only trunk, 2.28 will be released in few days ;). Also in  https://bugzilla.gnome.org/show_bug.cgi?id=594006 said 2.29
[15:22] <jjardon> but maybe could be backported to 2.28
[15:22] <pitti> jjardon: right; should be fine then, there's no real hurry; we need hal for X in karmic anyway
[15:24] <jjardon> pitti, Xorg devels added the bug I reported to the xorg 7.6 blocker list: http://bugs.freedesktop.org/show_bug.cgi?id=23462
[15:24] <pitti> jjardon: oh, *phew*; the upstream bug didn't move very far recently
[15:26] <jjardon> nope :(, I'd like to help but I'm not a xorg expert ;)
[15:37] <lool> kirkland: Hey do you mind if I do some relatively large cleanups to qemu-kvm's rules?
[15:51] <ttx> slangasek: what's the status on publication of ec2-version-query to a more appropriate place ?
[16:04] <LaserJock> james_w: what'd the difference between the DMB and MC?
[16:04] <maco> dmb?
[16:04] <james_w> as I understand it the DMB and the MC are likely to merge under archive-reorg
[16:04] <james_w> maco: developer membership board
[16:04] <maco> ah
[16:04] <james_w> the TB is splitting off their developer approval role from their technical oversight role
[16:04] <james_w> much as the CC did
[16:05] <LaserJock> james_w: ah, OK, I wondered with the reorg what the difference would be, makes sense that they'd merge
[16:05] <james_w> I don't think it's decided, but to many people I believe it is the logical step
[16:06] <pitti> cjwatson, dholbach, james_w: also, DMB would only approve "core" developers and other generalists (what MOTU are today), but many contributors will probably just stay in one particular team like mythbuntu, right?
[16:06] <pitti> IOW, the number of applicants should actually go down?
[16:06] <james_w> that's my understanding
[16:06] <pitti> for DMB?
[16:07] <james_w> well, the absolute number might go up :-)
[16:07] <LaserJock> is "core" developer defined under the new scheme?
[16:07] <maco> james_w: and that might be a good thing
[16:07] <LaserJock> my understanding was more along the lines of Core Dev getting split up into team upload rights and MOTU largely becoming generalists
[16:08] <maco> i thought there could be per-package-uploaders that werent also motu in the new thing.  but then, im rather confused by the archive reorg stuff
[16:08] <cjwatson> LaserJock: generalist is just a new word (which personally I don't like) for core-dev
[16:09] <cjwatson> (I can't see people going around proudly wearing a badge saying "Ubuntu Generalist Developer")
[16:09] <cjwatson> (well, not sure I can see that for core either, but it seems a bit more likely :-) )
[16:09] <maco> haha
[16:09] <LaserJock> yes
[16:10] <LaserJock> so then MOTU either get "promoted" or get upload-access through a specific team?
[16:10] <maco> cjwatson: i think a core dev badge would just make random people off the street yelling at you about their pet bug more likely :P
[16:10] <highvoltage> hi LaserJock
[16:10] <cjwatson> LaserJock: something like that, over time, yes
[16:10] <cjwatson> LaserJock: we've started mail conversations with all current MOTU already
[16:11] <cjwatson> though need to do a bit more with the results :)
[16:11] <LaserJock> right
[16:11] <LaserJock> although not a lot has been said to Core Devs
[16:11] <LaserJock> presumably the status doesn't change much
[16:12] <LaserJock> although our available set of packages we have upload access gets smaller?
[16:13]  * LaserJock never remembers if "generalist" access is lower or higher "priority" than team access
[16:13] <geser> LaserJock: only if you're interested in some special packages, like kernel or eglibc (don't know which packages end in the restricted set)
[16:14] <soren> pitti: Hey. About https://bugs.edge.launchpad.net/ubuntu/+source/redhat-cluster/+bug/429834
[16:14] <soren> pitti: I'm wondering why you approved it, but didn't sync it?
[16:14] <pitti> soren: it needs manual uploading, didn't get to it
[16:14] <pitti> i just acked the FFE
[16:15] <soren> pitti: Oh, ok. should I subscribe ubuntu-archive?
[16:15] <soren> Or can't it be synced?
[16:15] <pitti> oh, I don't know
[16:15] <soren> I thought we could sync from anywhere.
[16:15] <pitti> I'd just upload it
[16:15] <geser> LaserJock: the current core-dev keep upload right to everything (modulo the restricted set), some MOTU get "promoted" to generalist, which give them the same upload rights as core-dev, team upload rights are completely new
[16:15] <soren> pitti: Alright. I'll do so.
[16:15] <soren> pitti:  Thanks.
[16:15] <pitti> soren: copy-package.py might be able to do it, didn't check
[16:16] <cjwatson> hmm, so the new initramfs-tools means that we expose an X bug again, where it sits munching CPU unless intel_agp was loaded first
[16:16] <cjwatson> or possibly unless KMS was brought up first
[16:16] <soren> pitti: I wouldn't know. The powers of ubuntu-archive have not been bestowed upon me, so I know little of the syntax copy-package would accept.
[16:16] <cjwatson> weird, though, I thought that had been fixed a while back
[16:16] <pitti> soren: I was just thinking aloud :)
[16:16] <soren> pitti: :)
[16:16] <sebner> geser: I have good news and bad news regarding libjgraph0.6-java. What do you want to hear first? ^^
[16:17] <cjwatson> LaserJock: not sure what priority mean
[16:17] <cjwatson> s
[16:17] <cjwatson> LaserJock: core-dev's available set should remain (very nearly) the entire archive
[16:17] <LaserJock> cjwatson: right, that's what I was getting at
[16:18] <cjwatson> LaserJock: while we've talked about "restricted sets", I expect their use to be very limited
[16:18] <LaserJock> I was wondering if generalists were going to be sort of in-between where they uploaded to everything *but* seeded packages
[16:18] <cjwatson> LaserJock: there's a restricted set for language packs, on the grounds that if you upload them then your upload will get automatically overwritten later anyway, and this has always been the case
[16:18] <Laney> is the switch on this going to be thrown soonish?
[16:18] <cjwatson> people talk about making the kernel and libc restricted, but personally I don't see the need
[16:18] <cjwatson> LaserJock: #define generalist ubuntu-core-dev
[16:19] <cjwatson> Laney: it actually sort of has been and nobody noticed ;-)
[16:19] <Laney> heh
[16:19] <cjwatson> Laney: Launchpad now has package set data and can grant upload access to packages in those sets
[16:20] <Laney> I mean the dissolving of universe
[16:20] <cjwatson> Laney: we're gradually talking about the basics like getting ~ubuntu-desktop upload rights to the desktop set, which is mostly a process thing
[16:20] <cjwatson> Laney: changing the component structure of the archive is still some way off
[16:20] <cjwatson> and there are still some design things to solve there
[16:21] <mdz> cjwatson, the server seed is part of ubuntu, while most other derivatives are separate, no?
[16:21] <mdz> is that still the right setup?
[16:27] <wrapster> supposing the rule file contains only the include directive and no command set.. how do i make changes to the existing pkg?
[16:27] <wrapster> http://pastie.org/626056
[16:27] <wrapster> have a look at that..its the rule file of grep.. I need some mods to be done there.. How should i approach it now?
[16:31] <mdz> soren, the current manifests are machine parseable
[16:31] <cjwatson> mdz: I've thought about splitting it out a few times, which probably ought to happen, but I don't think it's all that important or urgent
[16:32] <soren> mdz: That's exactly why I'm not sure how to include this information in there.
[16:32] <soren> mdz: The command line to build the image doesn't naturally fit into a "packagename version" sort of format :)
[16:32] <cjwatson> wrapster: you'll have to look at what is laughingly referred to as CDBS's documentation
[16:32] <soren> mdz: I'll work something out..
[16:32] <soren> Hahah!
[16:32] <cjwatson> wrapster: there's some stuff in /usr/share/doc/cdbs/
[16:33] <mdz> cjwatson, soren is looking for a sensible way to record which version of vmbuilder was used to create each UEC image
[16:33] <cjwatson> wrapster: you should familiarise yourself with debhelper first ('man debhelper', and chase references), since in many cases changes can be made by editing debhelper files
[16:34] <wrapster> cjwatson: ok.. but i dont have cdbs under the dir you specified
[16:34] <geser> sebner: start with the bad news
[16:34] <soren> Well... Not just the VMBuilder version. That's reasonably easy (although slightly misleading if put in the manifest next to everything else), but more the command line used to build the image.
[16:34] <cjwatson> wrapster: how do you normally install packages? :-)
[16:34] <sebner> geser: ok, the bad news are now strange news xD
[16:34] <wrapster> dpkg -i <pkg>
[16:34] <cjwatson> wrapster: consider installing cdbs ... ;-)
[16:34] <cjwatson> wrapster: that would normally be a prerequisite for reading its documentation
[16:35] <wrapster> ok
[16:35] <james_w> soren: just "# vmbuilder ..." ?
[16:35] <cjwatson> soren: how parseable does it need to be?
[16:35] <soren> cjwatson: You tell me.
[16:35] <cjwatson> soren: could you just spit it out in the log, and save that somewhere?
[16:35] <geser> sebner: then start with the strange news before they change again
[16:35] <soren> cjwatson: I've never really used these manifests for much.
[16:35] <cjwatson> soren: *shrug* *I* won't be using it
[16:35] <cjwatson> what manifests are these?
[16:35] <cjwatson> (url)
[16:36] <sebner> geser: synced new package, removed old one. Replace b-d and cdk FTBFS. Then I used libjgraph0.6-java-link as b-d and this works now. And it also pulls in libjgraph-java but version <IP_ADDRESS>.dfsg-1 , seems to be a different package xD
[16:36] <soren> cjwatson: http://uec-images.ubuntu.com/karmic/20090922/ubuntu-uec-karmic-i386.manifest [+]
[16:36] <soren> -[+]
[16:36] <cjwatson> so that's a derivative of the live filesystem manifest
[16:37] <cjwatson> which is automatically parsed in a way that may or may not handle comments, I don't remember
[16:37] <cjwatson> although the UEC one is not automatically parsed, it's purely informational
[16:37] <cjwatson> if it's useful to put comments in the manifest, I don't see a reason not to
[16:37] <cjwatson> ah yes, the only code that parses manifests (ubiquity) handles comments, so *shrug*
[16:38] <soren> automatically parsed by what?
[16:38] <geser> sebner: you didn't miss the 't'? there is libgraph-java and libjgraph*t*-java
[16:38] <soren> Oh, ubiquity.
[16:38] <cjwatson> yeah, not that it parses UEC manifests, as I say
[16:38] <soren> Right, right.
[16:38] <soren> Obviously :)
[16:39] <sebner> geser: ah, just noticed! xD I'm sorry. But anyways. Replace libjgrapht-java with libjgrapht0.6-java didn't work. I had to use the -link package (which pulls in 0.6-java also)
[16:39] <cjwatson> but if you're borrowing its format anyway ...
[16:39] <soren> cjwatson: Alright, I'll use a comment. That makes sense.
[16:39] <cjwatson> the only real alternative would be to put it in a file inside the image somehow
[16:39] <cjwatson> that sounds harder to inspect though
[16:39] <geser> sebner: and what are the good news then?
[16:39] <soren> It's already there, actually.
[16:40] <soren> I put the build log inside the images.
[16:40] <soren> Well, as much as I can, since part of the magic happens after the filesystem is finalised, but still.
[16:40] <sebner> geser: New package sycned over and old one finally removed ^^
[16:45] <sebner> geser: I'm sorry, this all sounds a little bit stupid xD , As I said cdk built locally but I uploaded to my PPA (start time 1 hour :( ) to be really sure the problem is solved now
[17:00] <mdz> smoser, what's the EC2_URL used for EC2 itself (with euca2ools)?
[17:01] <smoser> EC2_URL=https://ec2.amazonaws.com
[17:02] <smoser> the environment you have to set for amazon use is:
[17:02] <smoser> EC2_SECRET_KEY=${aws_secret_key} EC2_ACCESS_KEY=${aws_access_key} EC2_URL=https://ec2.amazonaws.com
[17:02] <mdz> smoser, thanks
[17:03] <smoser> one thingto note, i could be under-informed on this, is that euca2ools require exporting your aws access key and aws secret key
[17:03] <mdz> smoser, I think I have everything set up correctly now, but euca-describe-instances is hanging for a long time
[17:03] <smoser> the ec2 tools require exporting a path to certificate file and path to private key.
[17:03] <mdz> smoser, yes, I noticed that, but I don't understand why
[17:03] <mdz> smoser, could you ask nurmi_ to join here so we can discuss?
[17:04] <smoser> just did
[17:06] <smoser> there is nurmi_ .
[17:06] <smoser> above, i had said
[17:06] <smoser> the environment you have to set for amazon use is: EC2_SECRET_KEY=${aws_secret_key} EC2_ACCESS_KEY=${aws_access_key} EC2_URL=https://ec2.amazonaws.com
[17:06] <smoser> one thingto note, i could be under-informed on this, is that euca2ools require exporting your aws access key and aws secret key
[17:07] <smoser> mdz, i just verified that
[17:07] <smoser> EC2_SECRET_KEY=${aws_secret_key} EC2_ACCESS_KEY=${aws_access_key} EC2_URL=https://ec2.amazonaws.com euca-describe-instances
[17:07] <smoser> is working for me.
[17:07] <smoser> nurmi_, do you know why that difference ?
[17:08] <soren> Sorry, what's the difference?
[17:08] <smoser> between environment for euca- versus ec2-
[17:08] <smoser> euca2ools require exporting aws access key and secret key. the ec2 tools require exporting a path to certificate file and path to private key.
[17:09] <nurmi_> smoser: the ec2 tools use the SOAP interface (x509 credentials)
[17:09] <nurmi_> smoser; the eucatools use the REST interface (secret/query key)
[17:09] <soren> So they're not CLI compatible?
[17:10] <soren> People who've set their environment variables according to ec2-api-tools will not be able to use euca-tools without changing stuff.
[17:10] <soren> Right?
[17:10] <smoser> so choice of rest over soap dictated the difference in credentials being needed.
[17:10] <kirkland> cjwatson: so vmbuilder doesn't really support preseeding
[17:10] <nurmi_> soren: it depends on how you use the tools
[17:11] <soren> nurmi_: How so?
[17:11] <nurmi_> soren: for example, the AMI tools from amazon use the REST stuff
[17:11] <soren> nurmi_: Ok..
[17:11] <nurmi_> soren: so, if you have your environment set up to use both EC2 API and EC2 AMI tools, then there is no change to use eucatools
[17:11] <nurmi_> if you ONLY use EC2 tools, then you environment might not be sufficient for eucatools, as we need the REST crednetials (as does AMI tools)
[17:12] <soren> I see.
[17:15] <Laney> I think I am stuck in a redirect loop after submitting my UDS sponsorship
[17:15] <Laney> can someone check if it worked?
[17:16] <cjwatson> kirkland: ...
[17:17] <kirkland> cjwatson: sorry, too many pots on the stove right now
[17:18] <kirkland> cjwatson: the moodle package has a series of "critical" debconf questions in its config
[17:19] <kirkland> cjwatson: i'd like to create a PPA package that set these values to something "sane", and depend on moodle, such that it gets installed
[17:19] <kirkland> cjwatson: call it "moodle-appliance" or something
[17:20] <kirkland> cjwatson: but "depends" means that moodle would get installed first
[17:20] <cjwatson> I would recommend against attempting to do preseeding from a package
[17:20] <cjwatson> everyone I've ever seen trying to do this ran up against lots of roadblocks and ended up wasting lots of time
[17:20] <kirkland> cjwatson: yes, that's where i am
[17:20] <cjwatson> preseeding is intended for admins and as such it doesn't work well when you try to do it from a package
[17:20] <kirkland> cjwatson: i've wasted several days on this
[17:20] <cjwatson> why not just have vmbuilder preseed stuff itself?
[17:21] <kirkland> cjwatson: feature request for vmbuilder
[17:21] <LaserJock> kirkland: you're just stuck on moodle or are there others?
[17:21] <kirkland> cjwatson: i think there's a bug alreay
[17:21] <cjwatson> understood, but it's the only sane approach
[17:21] <kirkland> cjwatson: okay, thanks for the feedback
[17:21] <soren> Laney: url?
[17:22] <Laney> soren: url to what? http://summit.ubuntu.com/
[17:23] <soren> Laney: Oh, never mind. I don't have access to that, i think.
[17:23] <lool> kirkland: Heym I need to butcher the qemu-kvm rules heavily to fix the static build
[17:23] <lool> kirkland: Hope you dont mind
[17:23] <kirkland> lool: please, and thank you!
[17:24] <lool> kirkland: Do you mind if I do further cleanups after that?
[17:24] <kirkland> lool: go for it
[17:24] <lool> Ok thanks
[17:24] <ion> !summon Keybuk
[17:24] <kirkland> lool: i'll review all of them afterward
[17:24] <lool> Ok
[17:25] <ogra> ion ++
[17:28] <mdz> smoser, nurmi_, I'm trying to set everything up from scratch for EC2 using only euca2ools
[17:28] <mdz> basically following the starter's guide with s/ec2/euca/
[17:29] <smoser> mdz, http://wiki.debian.org/euca2ools got me going on euca2ools.
[17:30] <mdz> smoser, I'm able to create an instance, but I'm not able to login
[17:31] <soren> mdz: You've created a keypair and specified it on the euca-run-instances command line?
[17:32] <mdz> soren,    83  euca-run-instances ami-fa658593 --key ${EC2_KEYPAIR} --instance-type m1.small
[17:32] <mdz> atomicity:[~/ec2] euca-describe-instances |grep keypair
[17:32] <mdz> INSTANCE	i-ef0fdb87	ami-fa658593	ec2-174-129-129-26.compute-1.amazonaws.com	domU-12-31-39-04-35-05.compute-1.internal	running 	ec2-keypair 	0 	m1.small 	2009-09-22T16:20:38.000Z 	us-east-1a 	aki-841efeed 	ari-9a1efef3
[17:32] <soren> mdz: Looks accurate enough to me. And you're connecting as "ubuntu"?
[17:33] <smoser> mdz, and EC2_KEYPAIR is the name associated ?
[17:33] <mdz> smoser, EC2_KEYPAIR=ec2-keypair
[17:33] <mdz> atomicity:[~/ec2] ssh -i ec2-keypair.pem ec2-174-129-129-26.compute-1.amazonaws.com
[17:33] <mdz> Received disconnect from <IP_ADDRESS>: 2: Too many authentication failures for mdz
[17:34] <smoser> well, you can't get in as mdz
[17:34] <mdz> (which is trying all keys from my ssh-agent)
[17:34] <mdz> smoser, ah, of course, heh
[17:34] <mdz> it would be nice if keypairs had a username associated
[17:36] <smoser> hm... can you do that in a .ssh/config ?
[17:36] <smoser> obviously you could set up all connections to *.compute.amazonaws.com to be ubuntu@
[17:36] <mdz> smoser, that's a good idea
[17:38] <jpds> Laney: It worked, and that's a known problem.
[17:40] <jpds> Laney: Check http://summit.ubuntu.com/uds-l/sponsorship/ - or chase jcastro.
[17:40] <jcastro> Laney: you're in the system
[17:44] <lool> smoser: Sure, username
[17:44] <lool> e.g. I have:
[17:44] <lool> Host git.videolan.org User git
[17:44] <lool> Argh, on two lines but you get hte idea
[17:45] <smoser> lool, i knew you could do it by host. i was wondering if you could tie a key to a username
[17:45] <smoser> but i dont think so. it'd be strange.
[17:46] <mdz> smoser, I'm still seeing bug 427288 in the alpha 6 AMI
[17:46] <mdz> smoser, judging by the comments, I thought it was fixed
[17:47] <smoser> mdz, you're seeing (i think) bug 432718
[17:48] <cjwatson> smoser: you can't, because ssh can present several keys or none, and it doesn't start presenting them - and therefore know which one will work - until after it's already made the initial auth request including the username
[17:48] <smoser> and soren was going to upload vmbuilder so i could make the emulation bug fixed-released.
[17:48] <smoser> cjwatson, yeah, i didn't think so. it didn't make a lot of sense.
[17:49] <smoser> mdz, does that look right ? ie you're seeing complaint about dbus ?
[17:53] <mdz> pitti, is it possible to have apport-cli print out the URL rather than launching w3m in server installs?
[17:54] <pitti> mdz: there's a wishlist bug for that; for now it is only possible to save the report and copy it to another machine
[17:54] <cjwatson> does it follow the BROWSER environment variable spec?
[17:54] <cjwatson> (or use sensible-browser)
[17:54] <pitti> cjwatson: xdg-open, it should
[17:54] <cjwatson> BROWSER=echo apport-cli? :-)
[17:56] <mvo> dear network-manager, please keep your hands off my /etc/resolv.conf
[17:57] <pitti> cjwatson: hm, doesn't seem to work :-(
[17:57] <Amaranth> mvo: agreed
[17:57] <Amaranth> Or at least don't add these stupid search lines
[17:59] <mvo> yeah
[18:00] <mdz> cjwatson, heh, that's probably worth a try
[18:00] <mdz> oh, pitti tried
[18:00] <mdz> I end up just suspending w3m and copy/pasting the URL from ps
[18:00] <cjwatson> or hit u in w3m?
[18:00] <mdz> if we want to strongly encourage ubuntu-bug for servers (and we do), I think we should do something about this
[18:00] <cjwatson> or do you need to get it before redirection?
[18:01] <mdz> cjwatson, screen size defeats me often when doing that
[18:01] <cjwatson> = then
[18:01] <mdz> the url is the correct one, but doesn't fit
[18:01] <mdz> didn't know about =
[18:01] <mdz> smoser, FYI I filed bug 434755 about some kernel dependency changes which are needed for ec2
[18:03] <smoser> grub ?
[18:04] <smoser> thanks mdz.
[18:07] <sebner> Who has archive admins duties currently?
[18:10] <ScottK> Today is Riddell's day.
[18:10] <Riddelll> it's my very special day
[18:10] <sebner> Riddell: you remember libjgraph0.6-java right?
[18:10] <mdz> smoser, maybe a better solution, rather than trying to provide ec2-* names for euca2ools, would be to add those higher level CLI tools we've been talking about
[18:11] <mdz> e.g. "start an instance using the current stable Ubuntu AMI"
[18:11] <Riddelll> sebner: mm hmm
[18:11] <mdz> those would wrap euca2ools and wouldn't need to worry about CLI compatibility
[18:11] <mdz> nurmi_, ^^
[18:11] <smoser> which would still require setting up *some* environment that could then provide other tools with the needed data.
[18:12] <mdz> smoser, I'd like to work on minimizing the environment setup as well
[18:12] <mdz> there are a lot of steps
[18:12] <sebner> Riddelll: The synced source (by jdstrand) went to multiverse (again) which is the reason why we removed the old libjgraph-java package. Will move it to universe. Something went totally wrong
[18:12] <smoser> erichammond's largest issue is with existing code that already works.
[18:12] <mdz> a standardized configuration file would be much friendlier than a bunch of environment variable settings
[18:12] <smoser> mdz, i agree.
[18:12] <mdz> sane defaults would be even better
[18:12] <Riddelll> sebner: what do you want me to do?
[18:13] <smoser> the xc2 that i've pointed you at has a config file that it reads
[18:13] <sebner> Riddell: move it from multiverse to universe
[18:13] <smoser> i dont really know how you'd come up with a sane default for your amazon secret key... :)
[18:14] <Riddelll> sebner: move libjgrapht-java?  I just deleted it
[18:14] <smoser> but some of the others could be done
[18:14] <sebner> Riddelll: no, you missunderstood. move libjgrapht0.6-java
[18:15] <sebner> Riddell: libjgrapht-java was the old package (split over multiverse and universe) so I synced the new package and let you remove the old one. But the new one moved to multiverse instead of universe (don't know what went wrong)
[18:19] <Riddelll> sebner: done
[18:20] <ScottK> Riddelll: I just accepted moodbar back into the archive (the reason it was removed is no longer applicable).  I expect it's on the sync blacklist and should be removed.  Would you mind looking into it?
[18:20] <sebner> Riddelll: Thank you very much =)
[18:21] <pitti> ScottK, Riddelll: moodbar unblacklisted
[18:21] <ScottK> pitti: Thanks.
[18:21] <Riddelll> that explains why I can't see it in there :)
[18:21] <ogra> could someone sync ltsp-docs from debian ?
[18:21] <ogra> its new and holds the upstream documentation, no deps afaik
[18:22] <Riddelll> ogra: ok
[18:22] <ogra> thanks :)
[18:22] <Riddelll> ogra: all done
[18:23]  * ogra hugs Riddelll
[18:23] <ogra> when did you earn the third l btw ?
[18:23] <Riddelll> when the server I used got moved but then the old one came back to life, so there are two of me now :(
[18:23] <ogra> meh
[18:24]  * Riddelll eyes up sladen
[18:26] <LaserJock> everybody always knew that more Riddell's would be a good thing :-)
[18:27] <ogra> if he only could delegate more work to the others ;)
[18:27] <asomething> ScottK: Thanks accepting moodbar
[18:28] <ScottK> asomething: No problem.  We only had it removed because it didn't appear useful anymore.
[18:29] <ogra> "udevd[392]: specified group 'fuse' unknown" ... why do i see that in a VM installing ubuntu-desktop but not in a chroot doing the exact same
[22:03] <tormod> what is running hdparm (twice?) at boot (I have disabled acpi-support)
[22:43] <kees> james_w: I've attached a patch to bug 307019 for gnome-about-me; should be easy to call that now.
[23:02] <james_w> kees: neat, thanks
[23:04] <seb128> kees, his, feel free to commit and upload your gnome-control-center change
[23:56] <ian_brasil> just got a django debug output from an error on http://summit.ubuntu.com/uds-l
[23:57] <ian_brasil> change DEBUG = False in settings.py ..that info should not be available to all


[00:00] <tonyyarusso> I'd imagine simple quoting would work for }, but certainly a \ escape would.
[00:00] <tonyyarusso> Too bad he left.
[04:57] <tonyyarusso> Hey, who wants to help work on wording for a resolution regarding mandating open standard document format usage for government publications in MN?
[05:04] <sparklehistory> tonyyarusso: I'll read a draft and critique or offer suggestions but I'm not up for actually writing it.
[05:05] <sparklehistory> tonyyarusso: Also, don't you have a resolution from the SD convention?
[05:06] <tonyyarusso> sparklehistory: yeah, but it was written on the spot and could probably be better
[05:07] <tonyyarusso> I started a gobby session on ubuntu-minnesota.org:6522
[05:08]  * tonyyarusso pokes h00k
[05:09] <h00k> tonyyarusso: ohai
[05:09] <h00k> tonyyarusso: in a second, I'm working on a few things here
[05:10] <sparklehistory> tonyyarusso: I've got to download/install so it'll be a few mintues
[05:12] <tonyyarusso> of course
[05:12]  * tonyyarusso can wait, he just microwaved some bacon
[05:15] <sparklehistory> hehe...a tonyyarusso with bacon is a happy tonyyarusso
[05:49] <Obsidian1723> Anyone know where I can can a wall-mounted 16 U 4-Post Open Server Rack?
[05:50] <tonyyarusso> Uh, wall-mounted *and* 4-post?
[05:58] <tonyyarusso> h00k: Does OOXML meet the "royalty-free" requirement?
[06:01] <Obsidian1723> 2 post if wall mounted
[06:54]  * tonyyarusso wonders how h00k's work is coming along
[06:54] <tonyyarusso> hey ripps
[07:27] <tonyyarusso> sparklehistory: take a look at what I have now
[07:29] <sparklehistory> tonyyarusso: Are you sure that you want to tie the State using open formats with the DFL using open formats?
[07:29] <tonyyarusso> sparklehistory: sure, why not?
[07:32] <sparklehistory> Just wondering if you would get some resistance from whoever at the DFL is responsible for record maintenece if they didn't totally understand or weren't contacted and consulted before this resolution comes up on the floor.
[07:33] <tonyyarusso> meh
[07:33] <tonyyarusso> All the better to make them listen :)
[07:33] <sparklehistory> And if they're offended or not on board for some reason, that could derail the broader policy which is the most important thing.
[07:33] <tonyyarusso> And they can always propose an amendment removing that line.
[07:33] <tonyyarusso> (It'd be really really stupid to demand that the state do something we can't do ourselves)
[07:35] <sparklehistory> (I don't think it's a matter of it being something the DFL can't do, just that I'm not sure this is the best way to get the DFL to do it nor do I think it helps the cause of requiring government documents in free software)
[07:36] <sparklehistory> Especially at a convention where emotions can run high and people are under a lot of stress, I would just be particularly careful not to appear disrespectful or indifferent of someone's territory (so to speak) if I didn't have to.  They might be completely cool and on board with it, but they might not and I think that's a risk.
[07:37] <sparklehistory> It might not matter at all and maybe I'm being paranoid, but it just sort of rubbed me the wrong way.
[07:39] <tonyyarusso> Well, the other two ways to make the DFL do it would be to get elected to the state standing Rules committee and try to put it in the Call, or propose it as an amendment to the party constitution, which would be actually binding, whereas a resolution is not.
[07:40] <tonyyarusso> Wording has a been changed a bit over the last few minutes.
[07:41] <sparklehistory> Well then this seems like the least aggressive official way to do it.  I assume you could also accomplish it unofficially by convincing the records manager/office staff themselves simply to change the way they work with documents.  It doesn't seem like something so critical that it would actually have to be an official, convention approved change.
[07:41] <tonyyarusso> yup
[07:42] <tonyyarusso> If I were only doing it for the DFL it wouldn't be a resolution, but as long as the definition is all spelled out it may as well come up.
[07:42] <sparklehistory> I like that wording better
[08:05]  * tonyyarusso is going to bed - ping me if you have thoughts later h00k
[23:04]  * Obsidian1723 Gotta love how McAfee thinks Windowsw is a virus and then reboots the PC.. I don't know what took it so long. Heck, I knew Windows was a virus long ago. /snark
[23:55] <tonyyarusso> h00k: pastebin.ca appears to be down, so http://pastebin.com/aDtkfp2M if you want to look
[23:56] <h00k> tonyyarusso: that is excellent.
[23:58] <tonyyarusso> anything you'd change?


[00:01] <dark_soul> bzr whoami 'your info'
[00:01] <dark_soul> in case someone is interested
[01:22] <Boobek> bye
[06:03] <l0de> The l0de radio hour is now online! stream up at www.klulz.com , call in live at<PHONE_NUMBER>!  Upgrade the repositories to the same format for better performance.
[07:24] <bignose> but when I attempt to upgrade it, Bazaar asserts there's nothing to do:
[07:24] <bignose> $ bzr upgrade --format 2a bzr+ssh://bzr.debian.org/bzr/collab-maint/python-daemon/python-daemon.debian/
[07:24] <bignose> bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format.
[07:24] <lifeless> bignose: are you upgradeing a branch perhaps
[07:24] <lifeless> oh
[07:24] <lifeless> bignose: the remote repository is 21
[07:24] <lifeless> bignose: the *local* one isn't
[07:24] <lifeless> s/21/2a/
[07:25] <bignose> hmm, checking
[07:25] <lifeless> thats the the mesage indicates
[07:25] <bignose> well spotted. but how did you spot that?
[07:26] <lifeless> the error string: RemoteRepositoryFormat(_network_name=...) - thats what repositories using a proxy object over bzr:// protocols show as
[07:27] <bignose> thanks.
[08:53] <lelit> hi all
[08:55] <lelit> I'm still in the process of converting a bunch of svn repo to bzr. The standalone repos seems in good shape, and I am now trying to group them with the "externals" plugin
[08:56] <lelit> I have a "metarepo" containing just external refs to a few repo
[08:58] <lelit> the test I did some days ago worked great, but now "suddenly" cloning such metarepo gives me a desolately empty repo, with 0 revision in it... it completely misses any ref to the externals
[09:01] <lifeless> lelit: your terminology is confusing me
[09:01] <lifeless> you can't clone repos in bzr
[09:03] <lelit> uhm, sorry lifeless, I'm still learning the new terminology :)
[09:03] <lelit> isn't "clone" an alias of "branch"?
[09:03] <lifeless> yes
[09:03] <lelit> this is my migration script: http://pastebin.com/vd7KBEmG
[09:03] <lifeless> a repository is just a database
[09:04] <lifeless> it can't be pushed/branched/cloned/anything
[09:04] <lelit> ah, so what I call "repository" is a "branch" instead?
[09:05] <lelit> you know, I'm coming from darcs, where there isn't such distinction
[09:05] <lifeless> I would guess; you're the one that knows what you mean :)
[09:05] <lelit> :)
[09:05] <lelit> ok
[09:07] <lelit> the script above will create a "metarepo", containing .bzrmeta/externals pointing to the bzr-based branches of my svn repos
[09:07] <lelit> but when I "cd /tmp; bzr branch .../metarepo" I don't get those
[09:11] <lelit> I'm just blind :)
[09:11] <lelit> I need to commit, after all those eadds! :-)
[09:11] <lelit> sorry, caffeine is not circulating yet
[09:17] <lelit> gosh, this works ok on bzr 2.1.1, but fails with 2.0.1
[09:31] <lifeless> ok
[09:31] <lifeless> well 2.1.1 is nice ;)
[09:41] <lelit> http://pastebin.com/DK73EFtY
[09:42] <lelit> eh! unfortunately on debian/lenny there is 2.0.3 in backports
[10:11] <thumper> lifeless: the config object passed into Commit.commit is ignored
[10:11] <thumper> lifeless: is that right?
[10:14] <lifeless> thumper: no; but you should be calling tree.commit, not Commit.commit
[10:15] <thumper> lifeless: I am
[10:15] <thumper> but I'm following the path through
[10:15] <thumper> MutableTree.commit calls Comit().commit(...
[10:15] <thumper> the Commit object __init__ method can set self.commit
[10:16] <thumper> the config object passed in to the commit method of Mutable tree seems to be ignored to me
[10:16] <thumper> ...
[10:16] <thumper> not mutable tree
[10:16] <thumper> the Commit._commit method
[10:17] <thumper> I'm wanting to set the committer of the revision to be wikkid, but the author to be the author
[10:17] <lifeless> thumper: its a regression
[10:17] <lifeless> added by spivs run_cleanups stuff
[10:18] <thumper> hmm...
[10:18] <thumper> lifeless: how can I set the signing policy for a branch?
[10:19] <lifeless> thumper: well, I say regression
[10:19] <lifeless> its an ambiguous interface
[10:19] <lifeless> :q
[10:19] <thumper> it should use the passed in config like the reporter several lines above
[10:19] <lifeless> no
[10:19] <lifeless> ambiguous like I say
[10:19] <thumper> why not?
[10:19] <lifeless> hang a sec
[10:20] <thumper> I'm thinking line 347 of bzrlib/commit.py
[10:20] <lifeless> http://pastebin.com/hxtjLNp0
[10:20] <lifeless> apply that patch
[10:21] <thumper> I'll work around it for now, hopefully by setting the branch signing policy
[10:21] <lifeless> please don't
[10:21] <lifeless> its a regression, I'm just submitting the fix
[10:22] <thumper> funny, yesterday you were saying don't override the config
[10:22] <lifeless> I still say that
[10:22] <lifeless> but my point is to honour what the user has configured
[10:22] <thumper> if it is operating as a webapp, that is a very bad idea
[10:22] <lifeless> if you are going to override it, passing in a new object is the cleanest way IMO
[10:23] <lifeless> thumper: sysadmins are users too
[10:23] <thumper> I don't get the reference
[10:23] <lifeless> if its running as a webapp
[10:23] <lifeless> then the configuring person is the sysadmin
[10:23] <thumper> right
[10:23] <lifeless> who may well want commits on the server to be signed
[10:23] <thumper> but you don't want it prompting for a password
[10:23] <lifeless> *I* would
[10:24] <lifeless> why would it prompt in such a setup
[10:24] <thumper> fair call
[10:24] <thumper> I've added a TODO in the init method to allow using the users signing policy
[10:24] <thumper> I intend to honour it
[10:24] <thumper> just not right now
[10:25] <lifeless> see, it seems to me you are adding code you don't need to
[10:25] <lifeless> thats my whole point here
[10:25] <thumper> well, right now I don't want to change my default config
[10:25] <thumper> I have signing on
[10:25] <lifeless> don't change it
[10:25] <lifeless> you can override for your test wikis in 2 lines in ~/.bazaar/locations.conf
[10:25] <thumper> which is way I said before, how do I set the signing policy for a branch
[10:26] <lifeless> or in branch.conf
[10:26] <lifeless> review wanted: https://code.edge.launchpad.net/~lifeless/bzr/commit/+merge/23150
[10:26] <thumper> does branch.conf go with the branch?
[10:26] <thumper> on push?
[10:26] <lifeless> no
[10:26] <lifeless> but I'm not sure how that affects your dev environment
[10:27] <thumper> it doesn't
[10:27] <thumper> I was just wondering
[10:27] <lifeless> I'd like to have some stuff propogate
[10:27] <lifeless> currently nothign does
[10:28] <lifeless> what would you need to be happy with its behaviour for you ?
[10:28] <lifeless> no signing for wikki branches?
[10:29] <lifeless> thumper: ^
[10:30] <thumper> I'd like it to work as people expect
[10:30] <lifeless> ok, me too :)
[10:30] <lifeless> *I* expect things using bzr to honour my bzr settings.
[10:30] <thumper> I found it surprising that it asked me to sign my commit when I hit save on the webpage
[10:31] <lifeless> but you seem to be annoyed that you're getting signing prompts
[10:31] <lifeless> so I'd like to teach you how to turn that off, for your wikis.
[10:31] <thumper> just in locations.conf?
[10:31] <lifeless> thats what I
[10:31] <lifeless> thats what I'd reach for first in this case, I think.
[10:31] <thumper> I'll go with that for now
[10:32] <thumper> I agree that in a server setting it would make sense to use the config settings
[10:32] <lifeless> [file:///tmp]
[10:32] <lifeless> create_signatures = never
[10:32] <thumper> I'll go with honouring bzr expectations
[10:34] <lifeless> what bzrlib do you have installed btw
[10:34] <thumper> nightly ppa
[10:40] <abli> Hi! If I created a branch in a shared repository, do I need to do anything special when I want to delete it? or simply rm-ing the directory will do?
[10:46] <thumper> abli: that works
[10:46] <thumper> abli: it won't however remove the revisions from the repository
[10:47] <abli> where are the revisions actually stored? in the repo's .bzr, so the branch-directories' .bzr contains no revision data, only some metadata?
[10:48] <lifeless> right
[10:48] <lifeless> thumper: http://pqm.bazaar-vcs.org/
[10:49] <abli> Would deleting the branch now and later creating a branch with the same name be a problem? (Storing the revisions is not a problem in my case because they are quite small, so I won't care about the wasted space), but I want to avoid confusing people with old and obsolete branches
[10:49] <lifeless> thumper: have you seen the progress bar ? :)
[10:49] <lifeless> abli: no problem
[10:49] <thumper> lifeless: nice
[10:49] <lifeless> abli: or at least, no technical problems. *you* might get confused though
[10:49] <lifeless> thumper: subunit :)
[10:50] <abli> you mean if I create a branch with the same name, revisions from the old branch will come back?
[10:50] <lifeless> abli: no
[10:50] <lifeless> abli: I mean you might not remember if its the old or new branch, in a couple of weeks time :>
[10:50] <abli> oh. Ok, I'll remember to keep that straight then.
[10:51] <abli> Thanks everyone!
[11:07] <sipsniffa> testing the addition of files from within the current project directory and below using: bzr add --dry-run **/*.py
[11:07] <sipsniffa> none of *.py in the current directory get added. am i missing something?
[11:08] <lifeless> sipsniffa: your shell isn't matching them
[11:08] <sipsniffa> i understand ** to mean zero or more
[11:08] <lifeless> sipsniffa: any reason you don't just do 'bzr add' ?
[11:08] <lifeless> sipsniffa: and let bzr find all unignored files and add them for you
[11:08] <sipsniffa> i can drop the ** from **/*.py and get all the current directory py files
[11:09] <sipsniffa> probably the only reason is that i'm unfamiliar with bzr conventions and ways of working
[11:09] <lifeless> sipsniffa: the usual way is to setup bzr ignore rules for things you don't want to version
[11:10] <lifeless> and use 'bzr add' - just that - to add things automatically
[11:10] <sipsniffa> ok, will go that route
[11:10] <sipsniffa> still curious to know whether ** pattern matching is misbehaving
[11:10] <lifeless> check your shell's man page
[11:10] <lifeless> its outside bzr's control, unless you are on windows
[11:11] <sipsniffa> i've done bzr help patterns
[11:11] <lifeless> on windows bzr does the expansion
[11:11] <sipsniffa> linux
[11:11] <lifeless> right
[11:11] <lifeless> bzr doesn't see the **/*.py
[11:11] <lifeless> if you look in ~/.bzr.log
[11:11] <lifeless> you can see the command line bzr is being given
[11:12] <lifeless> your shell - e.g. bash, or zsh, or whatever - is expanding the **/*.py
[11:13] <sipsniffa> k, just tried quoting the pattern: bzr add --dry-run '**/*.py'
[11:14] <lifeless> bzr won't glob expand though :)
[11:14] <lifeless> that will add the file '**/*.py', if you had one
[11:14] <sipsniffa> gives an error!
[11:14] <lifeless> as I said, you need to check the documentation for your shell under 'GLOBBING'
[11:15] <sipsniffa> k
[11:15] <sipsniffa> thanks for the pointers, lifeless
[14:11] <bialix> igc: ping
[14:32] <igc> hi bialix
[14:33] <bialix> igc: what dependecies I should install?
[14:34] <igc> bialix: for the installer stuff?
[14:34] <bialix> yes, you have asked me to look at bzr-windows-installer script
[14:35] <igc> if you have the latest stuff, it will build the windows help but it expects ...
[14:35] <igc> sphinx 0.6 and make
[14:35] <bialix> I'm lacking the fresh info about bzr build dependencies
[14:36] <igc> http://wiki.bazaar.canonical.com/BzrWin32Installer is the place to start
[14:36] <igc> but you no longer need pycurl and cog
[14:37] <igc> and zlib gets installed for you
[14:38] <igc> bialix: any particular questions? I'm heading to sleep real soon now
[14:38] <bialix> that page is awfully outdate as I can see
[14:38] <igc> yes, I've been meaning to update it :-(
[14:38] <igc> next week hopefully
[14:39] <bialix> I don't have questions because I'm trying to figure out what I need to install
[14:39] <igc> do you have the old stuff installed still?
[14:39] <igc> the key bits are ...
[14:39] <bialix> no, for python 2.6 I have nothing
[14:40] <igc> python + pytqt + paramiko + sphinx + ms help compiler + innosetup
[14:40] <bialix> ms help compiler?
[14:40] <igc> for sphinx, start with setuptools, then easy_install it
[14:40] <bialix> C compiler?
[14:41] <igc> yes, you'll need one, either visual C or Mingw32
[14:41] <igc> also pyrex
[14:41] <bialix> can you put the dependencies version to simpleplain text file in the branch with script?
[14:42] <bialix> maybe tomorrow or the next week, maybe
[14:42] <igc> yes, that's the plan
[14:44] <igc> bialix: http://www.microsoft.com/downloads/details.aspx?familyid=00535334-c8a6-452f-9aa0-d597d16580cc&displaylang=en
[14:49] <bialix> igc: so perhaps we need to continue this odissey tomorrow or then next week, good night!
[14:50] <igc> bialix: I'll type something up tomorrow if I can
[14:50] <igc> bialix: night
[14:50] <bialix> that's ok, sleep well
[14:55]  * fullermd sure is glad to be on a *nix system   :p
[14:59] <bialix> fullermd: :-P
[15:06] <jml> I accidentally resolved a directory conflict by deleting the directory
[15:06] <jml> the commit that did that is way back in the history of my branc
[15:07] <jml> but it turns out that the project won't build without this (empty!) directory
[15:07] <jelmer> jml: can't you just re-add it with the same file id?
[15:07] <jml> jelmer, same file id? I didn't know you could do that
[15:08] <jml> jelmer, how would I do that?
[15:08] <jelmer> jml: you can't really specify a file id, but you can have 'bzr add' use the file id the same path has in another tree
[15:08] <jelmer> jml: so if you have an old copy of lp around you can use 'bzr add --file-ids-from=lp:launchpad/devel path/to/empty/dir'
[15:09] <fullermd> Easier to use revert.
[15:09] <fullermd> Just find a rev where it existed and revert -rwhatever dir
[15:13] <jelmer> fullermd: that won't readd the dir though right?
[15:13] <jelmer> fullermd: and if it's not added to the working tree, it won't have a file id
[15:13] <fullermd> Er, it certainly SHOULD.
[15:14] <fullermd> It works fine on FILES.  And dirs are just files in pink tutus.
[15:14] <fullermd> If it doesn't, that's a glaring bug that needs to be fixed.
[15:22] <sebi_`> what would be the reason for bzr not to upload certain files and/or directories when pushing a revision? I had to repush for the third time now. note that all files and directories are read and writable, and owned by my systemuser
[15:23] <bialix> sebi_`: bzr does not update remote working tree usually, only those on the local disk
[15:23] <sebi_`> okay
[15:24] <sebi_`> well, some of the files in the revision were empty, even though they aren't in the local source tree
[15:24] <jelmer> fullermd: you're right sorry. I never use revert with -r
[15:24] <sebi_`> ah well. if that's the only thing i'll have to live with, then i'll live with it. :P
[15:36] <bialix> sebi_`: if you need to upload files to remote location look at bzr-upload plugin
[15:37] <sebi_`> I was just talking about `bzr push $branch`, but i'll take a look at the bzr-upload plugin
[15:49] <bialix> there is also push-and-update plugin
[16:48] <MvG> FYI: I've just released version 1.1.0 of the bzr-bash-completion plugin, including completion for registry-based options.
[16:48] <jelmer> MvG: nice
[16:49] <MvG> I've also filed bug #560030 to get something done about the horribly outdated completion scripts included in the bzr source tree. If you want to discuss it, I'm all ears.
[16:51] <MvG> I'd be particularly interested in opinions as to whether bzr-bash-completion should be included with bzr itself, either now or in the forseeable future. I have no strong opinion either way, but it has been suggested to me by users, and I'd like to know what you think.
[16:52] <jelmer> doesn't bash itself also ship with some completion scripts?
[16:52] <jelmer> I think it should be shipped either with bzr or with bash
[16:54] <MvG> I assume that the bash progcomp api is far more stable and also a lot simpler than the bzr plugin and options api. Therefore I'd keep it with bzr.
[16:55] <MvG> I don't think bash ships anything related to bzr, but I'll check. I know zsh does ship a completion function.
[16:58] <MvG> Nope, neither bash 4.1 nor bash-completion 1.1 (from http://bash-completion.alioth.debian.org/ ) ship anything bzr-ish.
[17:00] <MvG> By the way: what are the steps turning a merge proposal at LP into an actual merge performed by PQM? And which of these steps are automatic? Do I need a certain number of approving comments, or approval by the right person, or either of these? Is there some document outlining this process?
[17:01] <jelmer> MvG: you need to approvals from bzr committers
[17:01] <jelmer> MvG: s/to/two/
[17:01] <jelmer> MvG: the merge is submitted manually by a pqm committer, usually through "bzr lp-land" or pqm-feed (from hydrazine)
[17:02] <MvG> Thanks!
[18:21] <RobOakes> Hi, I am getting a very strange error when I try and import from an SVN repository.  bzr: ERROR: Unable to convert Subversion path help/hits/LaTeX\docs because it contains characters invalid in Bazaar.
[18:21] <RobOakes> Does anyone know how I can by-pass this error?  The file it references is a documentation file and not really important to my merge.
[18:40] <jelmer> RobOakes: Bazaar doesn't allow backslashes in paths
[18:40] <RobOakes> Is there any way that I can exclude that one file?  Or can I update just the project src directory?
[18:41] <jelmer> RobOakes: I think the only real option is to use something like fastexport/fastimport that allows you to remove the backslash from the stream before importing it into bazaar
[18:42] <RobOakes> Do you know if there is a tutorial that explains how to do that?  (I'm a pretty novice bzr user.)
[18:42] <jelmer> I'm not aware of one, but that doesn't say a lot.
[18:44] <RobOakes> Any idea on how I could use fastexport/fastimport to do what you describe?
[18:44] <RobOakes> I'm trying to merge bugfixes made to an svn version of the bzr branch.
[18:55] <RobOakes> Thanks, I found a way around the problem.  There are only a few folders that I need to merge.  The merge works if I only update those selected folders.
[19:21] <sebi_`> okay, I think i've figured out why some files were missing when pusing a new revision; I forgot to add them. :P


[12:02] <brendand> pitti, is this resolvable? http://paste.ubuntu.com/11798706/
[12:39] <pitti> brendand: doesn't look like it :/ you have a package installed (in the r/o system image) which conflicts with your test dependencies
[12:40] <pitti> brendand: unless you actually cheat and do the ro-apt-update stuff, of course
[12:40] <brendand> pitti, afaik i am doing that
[12:41] <pitti> brendand: ah right, update, but not dist-upgrade
[12:41] <pitti> i. e. the current archive went through some transition, but the tested image didn't yet
[12:41] <pitti> brendand: are you in the "happy" position of having to test old images again? :-(
[12:42] <brendand> pitti, well it seems there will always be a period of time where the two are out of sync
[12:42] <brendand> i'll check for a new image
[13:05] <brendand> pitti, weird even after i updated the image it still fails :/
[14:51] <brendand> pitti, crazily that error still happens even with the just built image ???
[14:52] <pitti> brendand: oxideqt-codecs-extra already ought to be on the image, is it not?
[14:53] <pitti> which version is it?
[14:53] <pitti>  oxideqt-codecs-extra | 1.7.8-0ubuntu1 | wily | amd64, armhf, i386
[14:53] <pitti> that's the version we have in the archive, so I'm not sure what requires 1.7.9
[14:53] <pitti> oh, overlay PPA perhaps?
[14:54] <brendand> pitti, maybe, but the image i'm using should have been built with that
[14:54] <pitti> oxide-qt also doesn't seem to be in teh overlay
[14:55] <pitti> brendand: what is apt-cache policy oxideqt-codecs-extra ?
[14:56] <brendand> pitti, http://paste.ubuntu.com/11799522/
[14:56] <brendand> pitti, 1.7.9 is in -updates ???
[14:57] <pitti> brendand: erk, someone SRUed it without updating wily
[14:57] <pitti> sorry, I just looked at wily
[14:59] <pitti> brendand: so apparently we don't build the image with -updates/-security enabled, but do enable their apt sources
[15:00] <pitti> brendand: you should be able to work around this by commenting out the -updates/-security apt sources and running apt-get update
[15:00] <pitti> brendand: but congrats, you just found a rather major flaw in our image builds :)
[15:01] <brendand> pitti, will it be fixed?
[15:02] <pitti> brendand: I don't know; worth bringing up with ogra and sil2100 in #ubuntu-touch
[15:07] <brendand> pitti, ogra and sil seem to be in denial :)
[15:07] <brendand> pitti, well - they certainly are in sources.list, but why do you say they aren't used in the image build?
[15:07] <pitti> how do you mean? (I didn't see any recent discussion in #u-touch)
[15:07] <pitti> well, your apt-cache policy proves just that
[15:07] <brendand> pitti, sorry i'm talking on -ci-eng. maybe i shouldn't
[15:08] <pitti> if it was a recently built image
[15:09] <pitti> https://launchpad.net/ubuntu/+source/oxide-qt/1.7.9-0ubuntu<IP_ADDRESS> landed on June 23, so a week aog
[15:09] <pitti> any image younger than a week ought to have it
[15:51] <brendand> pitti, it says published 3-4 hours ago on that page ??
[15:52] <pitti> brendand: oh, I see -- so it was held in some staging area for a week; nevermind then
[15:52] <brendand> pitti, probably the ppa
[15:53] <brendand> pitti, i think it just missed the cutoff for the new image
[15:53] <brendand> pitti, so need to wait for the next one
[15:53] <pitti> the -security staging PPA, not the touch overlay PPA
[15:53] <brendand> pitti, ah ok
[15:53] <pitti> brendand: as a workaround, you could remove -updates/-security apt sources from your image
[15:54] <brendand> pitti, i did try that, there was another error
[15:54] <brendand> pitti, http://paste.ubuntu.com/11799786/
[15:55] <pitti> brendand: ah, meh -- so, "next image" it is :/
[15:55] <brendand> pitti, yeah eventually this will happen enough times we'll be compelled to do something about it...
[15:56] <brendand> pitti, might become more urgent once more people start using autopkgtest
[19:30] <cachio> brendand, do you know how to avoid this error http://paste.ubuntu.com/11800900/?
[19:31] <brendand> cachio, it could be there is a problem importing a sub-module
[19:32] <brendand> cachio, is this with a specific branch?
[19:32] <cachio> brendand, this happened when I install all the packages in the device manually
[19:32] <cachio> brendand, and then I run the test with adt-run
[19:32] <cachio> brendand, i.e. python3 -m ubuntu_system_tests.command_line --update-apt ubuntu_system_tests.tests.test_html5_application.HTML5ApplicationTest
[19:33] <cachio> brendand, it happens with any branch
[19:34] <brendand> cachio, ok. i'm not sure off the top of my head
[19:34] <brendand> cachio, if you edit the adt-run command in command_line.py and add -S to it then it will break after that failure inside the adt-run environment
[19:34] <brendand> cachio, then you can try the import ubuntu_system_tests and see if it gives you a more detailed error
[19:35] <cachio> brendand, ok
[19:36] <cachio> brendand, tx


[20:49] <John__> Hello, I bought a new laptop with amd gpu and i'm confused about the current state of amd drivers. Can someone explain what are all these drivers, fglrx, ati, amdgpu, amdgpu-pro? I want the best recommended driver for performance
[20:52] <lynorian> John__, which laptop gpu is it
[20:52] <lynorian> fglrx is the old propritary driver not supported anymore
[20:53] <lynorian> ati is a company that amd bought with that gave them their gpu technology
[20:53] <lynorian> amdgpu is the new driver for recent stuff
[20:54] <lynorian> amdgpu-pro is the proprietary amd extensions to the new amdgpu driver
[20:54] <John__> Dell Inspiron 15 5559 with AMD Radeon R5 M335
[20:55] <John__> lynorian, thank you very much
[20:56] <John__> lynorian, oibaf ppa has a driver called xserver-xorg-video-ati, what about that
[20:56] <lynorian> I honestly don't use obiaf
[20:57] <lynorian> Ok you should use amdgpu on that
[20:57] <lynorian> and then with amdgpu-pro if you need even more performance
[20:59] <John__> is there any ppa with pro driver?
[21:01] <lynorian> oh wait that is actually A rebadged old cpu
[21:01] <lynorian> hate when amd does that
[21:01] <lynorian> hoenstly just use raedon
[21:01] <lynorian> I have heard fglrx is very unstable
[21:02] <lynorian> and not supported with 16.04 or newer
[21:05] <John__> what driver is installed by default in ubuntu 16.10?
[21:37] <lynorian> it installs the open source ones by default but will load the one you need
[21:37] <lynorian> this allows you to say using the built in drivers to move disks around to different machines if say your laptop screen breaks and you need data off it
[23:49] <John__> my laptop has hybrid graphics, amd/intel and now uses intel, how to change it into amd