[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 2.4.2.3+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_2.4.2.3+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 5.12.2.1.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 174.129.129.26: 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