[02:13] <weirdbro> has anyone thought of integrating the Application Launcher menu with other programs that need to choose applications?
[02:14] <weirdbro> Its just seems really silly to me that for Sessions, to add a new startup program, users need to find the binary file/terminal command
[02:14] <weirdbro> when there's already a menu to do what they most likely want
[02:40] <diogo> I really want to know why FGLRX 8.7 has better performance on blender when using ubuntu than on other distros... is this because of xorg... of patches...
[02:41] <diogo> ?
[02:43] <RAOF> diogo: We can't patch the driver, obviously (barring totally crazy binary patching).
[02:44] <RAOF> diogo: apt-get source on the various components will get you the source package that the binaries are built from; I don't know of any specific "make fglrx magically faster" patches we apply, though.
[02:45] <diogo> its just that it seems as fast as windows... and the other distros don't have this "fastness"
[02:46] <diogo> its weird... I really like conary for example but rpath and foresight1s has not been so fast as ubuntu's xorg
[02:46] <LaserJock> anybody know of a bug about audio "crackling" in Intrepid, even if volumes are muted?
[02:47] <RAOF> LaserJock: No, but that sounds pretty cool.
[02:48] <LaserJock> RAOF: rather annoying is more like it ;-)
[02:49] <LaserJock> everybody looks at me funny when I start up Intrepid
[02:49] <diogo> this is radio intererence I had it on my pc too... some sound cards has the "ability" of crackling when a frequency passes through it... this is a hardware thing... at least my case were
[02:49] <RAOF> Oh, you mean on _startup_?
[02:50] <RAOF> Yeah, I hear that.
[02:50] <LaserJock> RAOF: well, it starts at the gdm login
[02:50] <RAOF> On alsa init.
[02:50] <RAOF> Ah, no, not than.
[02:50] <RAOF> s/n./t./
[02:50] <LaserJock> RAOF: and then thereafter any sound event get's a crackle
[02:50] <LaserJock> it's over the top of the intended sound
[02:51] <LaserJock> but when I mute the device I still get the crackle
[02:51] <RAOF> Wicked.  How are you muting the device?
[02:52] <LaserJock> just in the gnome volume control
[02:53] <RAOF> I wonder if: (a) You've accidentally set the 'combine sinks to create one big virtual sink' option, then (b) pulseaudio is picking up pcspk, and (c) the default sink has somehow been set to the virtual combined sink?
[02:57] <LaserJock> RAOF: well, this is off a fresh install of Alpha2 I believe
[02:57] <LaserJock> so I'm fairly certain it's not something I did intentionally
[02:57] <LaserJock> but I can perhaps look around to see if something like that has happened
[03:16] <pwnguin> is there a built in mic on the computer running intrepid?
[03:29] <tanath> anyone else get nothing on display when booting?
[03:30] <Hobbsee> boot without splash?
[03:30] <tanath> yeah
[03:30] <tanath> at first i had no video output at all. now i just get a blank screen, until GDM
[03:31] <tanath> and VTs don't work. get a corrupt display
[03:31] <RAOF> I thought that got fixed in usplash; mine's working.
[03:31] <tanath> hm
[03:32] <tanath> i was wondering what intrepid would look like booting up, but didn't get to see. that was a while ago. still haven't seen what it looks like :P
[03:32] <RAOF> Looks exactly like hardy, once you've got the fixed usplash.
[03:32] <tanath> ah
[03:33] <tanath> well the 'fixed' usplash may be what got me the blank screen as opposed to no output
[04:27] <Fjodor> tanath: Your problem also sounds like what I used to see when the wrong framebuffer console driver got loaded. To test, you might want to compile your own kernel, either without framebuffer console support, or with just vesa or the one you should be using...
[04:27] <Fjodor> And then report back
[06:55] <pitti> Good morning
[06:55] <emgent> moin pitti :)
[06:56] <RAOF> Howbitie.
[06:58] <RAOF> If you're up, maybe it's time to ping again about gnome-python-extras.
[06:59] <RAOF> Debian's source package builds a couple of binary packages we don't, and I'm wondering whether that's a deliberate divergence or what.
[07:03] <pitti> ScottK: sauerbraten-data seems fine to me? same version in hardy-backports as sauerbraten
[07:04] <pitti> ScottK: (and intrepid)
[07:04] <pitti> Hobbsee: yes, most probably
[07:04] <Hobbsee> pitti: cool
[07:04] <pitti> Hobbsee: promoted
[07:04] <Hobbsee> thanks :)
[07:04] <pitti> Hobbsee: (oh, that was about libltdl7-dev)
[07:05] <Hobbsee> pitti: i figured, seein gas i only poked you about one thing :)
[07:22] <tkamppeter> pitti, hi
[07:24] <nxvl> hi all!
[07:33] <pitti> hi tkamppeter
[07:39] <tkamppeter> pitti, I have succeeded now to get the hal-cups-utils work with and without usblp now.
[07:39] <pitti> tkamppeter: rocking! did you patch hal, or just h-c-u?
[07:39] <pitti> tkamppeter: btw, I got your mails, but didn't catch up with them yet
[07:39] <tkamppeter> There is only one small problem:
[07:39] <tkamppeter> I patched only h-c-u.
[07:41] <tkamppeter> When there is no usblp I trigger the script by the USB interface entry. With interface class 7 and subclass 1 I have a printer,
[07:42] <tkamppeter> There is no device ID in the HAL DB then. So I poll the ID from the printer using libusb.
[07:42] <ogra> no way to get it out of sysfs ?
[07:43] <tkamppeter> This makes creating queues with the correct PPD, recognizing that there is already a queue, and re-enabling queues working as well as before.
[07:44] <tkamppeter> pitti, problem is on turning off the printer. From a printer turned off I cannot poll the ID. I must use what got into the HAL database while the printer was on.
[07:46] <tkamppeter> Here I can at best get manufacturer and model name as shown by lsusb (which is not as perfect as from the device ID) and the serial number (which is not reported by all printers).
[07:46] <pitti> tkamppeter: hm, that sounds odd; even with usblp, the device disappears from hal once you turn your printer off
[07:46] <pitti> tkamppeter: frankly, if the user turns off the printer while autodetection is in progress, I'd just silently exit
[07:48] <tkamppeter> pitti, but with usblp the HAL database contains the device ID and it seems that the complete HAL database entry is sent to the scripts (as env variables) which a removal event happens.
[07:48] <tkamppeter> pitti, I am not treating queue setup here but disabling the queue when the printer is turned off.
[07:49] <pitti> tkamppeter: hm, doesn't cups care about this already?
[07:49] <pitti> tkamppeter: also, why does the queue need to be disabled?
[07:49] <pitti> if the printer is off, documents should just be kept in the spooler until it is turned on again?
[07:49] <tkamppeter> pitti, no, CUPS does not disable queues on turning off printers.
[07:51] <Mithrandir> why would you care about disabling the queue?  CUPS notices it can't send anything to the printer and waits.
[07:51] <tkamppeter> pitti, many backends, like the usb backend of CUPS retry every 30 seconds, once using resources (filtering and rendering the complete job) and second popping up a tray message that the printer is not connected.
[07:52] <pitti> tkamppeter: I still think that'd be the correct thing to do, but independently from that, how did it work in the past? you can't get info about hal nodes any more after they disappeared (when the printer is turned off)
[07:52] <pitti> that seems pretty independent to the usblp issue to me?
[07:54] <tkamppeter> pitti, with usblp you had the full device ID also on a printer removal event, as it was in the HAL DB and before HAL discards a DB entry on removal of a device it starts the removal callout supplying the complete DB entry to it as env variables.
[07:54] <pitti> ah, I see
[07:54] <pitti> tkamppeter: right, so ideally hal could still have the device ID without usblp
[07:55] <pitti> s/could/would/
[07:56] <tkamppeter> Without usblp the hal_lpadmin script is triggered from another HAL DB entry which does not contain the device ID.
[07:56] <pitti> right, I understand
[07:56] <tkamppeter> So I would like to know if I could do the following:
[07:57] <tkamppeter> Printer turned on: hal_lpadmin script polls the device ID from the printer and WRITES it into the HAL database entry
[07:57] <tkamppeter> Printer turned off: HAL database entry contains device ID and so printer can be identified as well as on turn-on event.
[07:58] <pitti> tkamppeter: yes, you can use hal-set-property to add a property to a hal node; you need to be root for that, though
[07:59] <tkamppeter> pitti, as hal_lpadmin is called by HAL, it runs as root.
[07:59] <pitti> tkamppeter: so either hald itself detects the device id (if that's possible without much code), or you use hal-set-property
[07:59] <pitti> oh, it's a python script, handy
[08:00] <pitti> tkamppeter: /usr/lib/hal/scripts/hal-system-power-set-power-save uses hal-set-property (example)
[08:00] <tkamppeter> pitti, as hal-set-property is a command line utility, one can call it from any language.
[08:01] <pitti> exactly
[08:01] <tkamppeter> Or are there python bindings for HAL
[08:01] <pitti> tkamppeter: no, there aren't; from python you usually use straight d-bus calls to hal
[08:02] <ogra> there are dbus bindings, hal understabds them
[08:05] <tkamppeter> pitti, I have tried hal-set-property directly from the command line and it does exactly what I want. I can add properties to HAL DB entries now.
[08:05] <pitti> great
[08:07] <tkamppeter> Thank you for your help, pitti
[08:07] <pitti> tkamppeter: no problem, I didn't do much :)
[08:08] <pitti> tkamppeter: thanks for fixing it
[09:07] <Hobbsee> pitti: what about libltdl7?
[09:08] <pitti> Hobbsee: promoted, thanks
[09:08] <Hobbsee> pitti: np
[09:09] <Hobbsee> oh, sigh.  buildd.py's broken again
[09:09]  * Hobbsee tries to remember how to redo the cookie
[09:11] <jpds> ./cookies-sql2txt ~/.mozilla/firefox/*/cookies.sqlite launchpad.net > ~/.lpcookie
[09:13] <Hobbsee> jpds: done that.  it still blows up
[09:13] <jpds> Hobbsee: No error?
[09:13] <Hobbsee> urllib2.HTTPError: HTTP Error 500: Internal Server Error
[09:14] <jpds> Hobbsee: What are you trying to do?
[09:14] <Hobbsee> retry imlib2 builds
[09:15] <jpds> Yep, I get that error too.
[09:15] <Hobbsee> pitti: remind me, how did this get fixed last time?  :)
[09:17] <seb128> Hobbsee: previous time you were using the wrong cookie because you had several mozilla directories around
[09:18] <Hobbsee> seb128: that's what i thought.  i checked that, and there's no more there.
[09:18] <seb128> Hobbsee: ls .mozilla/*/*/cookies.txt?
[09:18] <Hobbsee> .mozilla/firefox/4usr3i1j.default/cookies.txt
[09:19] <seb128> Hobbsee: cp .lpcookie .mozilla/firefox/4usr3i1j.default/cookies.txt
[09:19] <seb128> Hobbsee: and try again
[09:19]  * pitti hugs seb128, bonjour
[09:19] <Hobbsee> seb128: still dies.
[09:19]  * seb128 hugs pitti, guten tag
[09:19] <seb128> Hobbsee: suck to be you then ;-)
[09:19] <Hobbsee> oh, ffs!
[09:20]  * Hobbsee mutters at stub
[09:20] <seb128> Hobbsee: maybe strace -e open -f buildd.py ... and see what cookie it opens
[09:20] <Hobbsee> seb128: i've found the problem.
[09:20] <seb128> ah?
[09:20] <Hobbsee> looks like they've logged everyone out *again* today.
[09:20]  * Hobbsee already got logged out earlier today.
[09:21] <seb128> ah, yes, I did have to enter my login and password again this morning too
[09:21] <Hobbsee> there we are.  now it's working
[09:21] <seb128> good
[09:21] <Hobbsee> seb128: thanks :)
[09:21] <seb128> doh, I was looking to NEW apport-crash bugs this weekend
[09:22] <seb128> there is around 3000 of those
[09:22] <seb128> we should try to clean old ones or failed retracings
[09:23] <seb128> the retracing success rate is also pretty low
[09:23] <seb128> not sure of why though
[09:24] <Hobbsee> hm, somehow i forgot that promotions aren't immediate.
[09:24] <seb128> pitti: I'm wondering if we should not remove the dump and close automatically using a stock reply the bugs where retracing doesn't work correctly
[09:24] <pitti> seb128: tricky question; in a lot of cases the retracers are broken
[09:25] <pitti> but right, we'll hardly keep up with the flood anyway
[09:25] <askand> Hi, how do one get blueprints approved?
[09:27] <cjwatson> don't get overly obsessed with the status of blueprints. If it's something that you're capable of doing, then just go ahead and do it. (If it's not something that you're capable of doing yourself, then you probably shouldn't have registered a blueprint for it; they're detailed software design documents, not wish-lists.)
[09:28] <cjwatson> if you're a developer, then the question you should be asking is how to get peer review for your design, rather than how to get the blueprint approved; and in that case the answer is to find a group of like-minded interested developers and talk to them about it
[09:41] <askand> cjwatson:  ah thanks, in fact I am not asking about a blueprint I have made, but one that I do like the sound of. The creator of that blueprint asked in the forums how do get blueprints approved, I will forward your message :)
[09:48] <cjwatson> askand: for non-developers, it's much better to use brainstorm.ubuntu.com than to use blueprints
[09:48] <cjwatson> we have a problem at the moment that we have hundreds or probably even thousands of blueprints that weren't created by developers, aren't plausible software design documents, and can essentially never be approved
[09:50] <askand> cjwatson:  I have indeed seen that problem arising too
[09:52] <askand> However this wasnt a complex blueprint (at least it does not sound so to me as a non-developer), it was simply a blueprint about changing the default screensaver from black to something else to avoid confuse new users when the screensaver starts during installation
[09:54] <cjwatson> so why is that a blueprint rather than a wishlist bug?
[09:54] <cjwatson> it makes no sense for trivial things to be blueprints
[09:55] <cjwatson> there has been a trend for people to follow up to all wishlist bugs and say that they should be blueprints, and it's completely wrong - complex things that require careful design work sometimes merit being blueprints, but simple enhancements don't
[09:56] <cjwatson> anyway, the person involved should talk to the desktop team
[09:57] <askand> cjwatson: hm, that make sense..here is the link to the forumdiscussion in case you want to write something there :) http://ubuntuforums.org/showthread.php?t=854500
[09:58] <cjwatson> I don't
[09:59] <cjwatson> I don't want to get involved in this, just offering general advice
[10:55] <tkamppeter> pitti, applied changes to hal-cups-utils upstream, Ubuntu package will follow.
[11:09] <norsetto> pitti: I have f*d up bug 249355, can we override the previous upload to hardy-proposed?
[11:27] <pitti> norsetto: no, we can't; we can only do a followup upload
[11:27] <pitti> norsetto: so you'd need a -8build2 which is in fact -7, if you want to revert
[11:27] <pitti> norsetto: however, the changes in -8 don't actually look scary or intrepid specific
[11:35] <askand1> Hi,  I talked to cjwatson about blueprints earlier and the problem with blueprints created by non-developers thinking that is the best way to get their ideas and wishes fullfilled. I begun to look and there are a lot of blueprints out there, many which only contains a link to a brainstorm-idea. Perhaps a sticky in the Intrepidsection in the forums would be good?
[11:36] <askand1> A sticky about not creating blueprints of things you are not capable of doing yourself
[11:36] <cjwatson> sounds good but the forums guys would have to do that
[11:37] <askand1> Ok, I forward it to them
[11:43] <norsetto> pitti: ok, you are right, the new dependancies dragged in are not hurting, quite the contrary
[11:45] <tkamppeter> pitti, new hal-cups-utils uploaded
[11:45] <pitti> yay
[11:47] <AlexCONRAD> tseliot: hello ! I wanted to know if you were able to compile the latest ati drivers ?
[11:49] <tseliot> ﻿AlexCONRAD: what's the problem?
[11:50] <AlexCONRAD> tseliot: there's no problem, I just wanted to know if were about to release the new ATI drivers that came out a few days ago... :)
[11:51] <AlexCONRAD> I was looking at the xorg-driver-fglrx's version number. I have 1:7.1.0-8-3+2.4.24.13-19.45. Would this mean we're running the 8.3 version of ATI's drivers ?
[11:53] <tseliot> ﻿AlexCONRAD: yes, however the -envy flavour is 8.6.
[11:53] <AlexCONRAD> tseliot: aah, good to know
[12:15] <wgrant> Why does new GNOME feel that I need to be notified about the ability to change my screen resolution?
[12:17]  * pitti joins the complaint
[12:18] <james_w> through a libnotify popup?
[12:18] <pitti> now I have this tray icon all the time
[12:18] <wgrant> pitti: Right.
[12:18] <pitti> which I don't want, and just wastes space
[12:18] <wgrant> I would expect GNOME folks to get it right, of all people.'
[12:18] <pitti> supposedly it only happens if you have more than one screen?
[12:18] <wgrant> Not here.
[12:18] <pitti> (I'm working in docked mode, with an external TTF on my laptop)
[12:18] <wgrant> Well, I only have LVDS connected, but there are two other outputs...
[12:19] <james_w> the randr capplet was merged upstream, I haven't seen what changes were made yet, it's perhaps related to that.
[12:20] <wgrant> Anyway, it shouldn't be there. Like NM.
[12:21] <wgrant> Except this has no reason to be here at all.
[12:25] <seb128> re
[12:25] <seb128> wgrant, pitti: calm down, the changes just landed upstream and it's still early in the unstable cycle
[12:26] <pitti> seb128: oh, I'm not furious at all, just agreeing :)
[12:26] <seb128> comment about GNOME not getting it right are not really useful there
[12:26]  * pitti hugs seb128
[12:26]  * seb128 hugs pitti
[12:26] <seb128> well, having a rant on new changes because they are not perfect is not really constructive
[12:27] <pitti> it's not exactly a bug, this looks like a deliberate decision
[12:27] <pitti> but yeah, we'll figure it out soon enough
[12:28] <seb128> pitti: http://bugzilla.gnome.org/show_bug.cgi?id=542822
[12:28] <seb128> pitti: no, it's a bug
[12:28] <james_w> from the code: http://paste.ubuntu.com/31247/
[12:28] <seb128> james_w: right, that's mentionned in the bug too ;-)
[12:29] <james_w> just seen it :-)
[12:29]  * wgrant didn't see a rant.
[12:29] <seb128> wgrant: your comments about expecting GNOME to get such things right are annoying and not constructive
[12:30] <james_w> seb128: would you be ok with filing an Ubuntu bug milestoned for intrepid, or are you fine tracking it yourself?
[12:30] <seb128> wgrant: the code is just new and needs some tweaking, that doesn't tell anything on GNOME choices
[12:30] <seb128> james_w: feel free to open a bug but I'm already tracking it
[12:30] <james_w> seb128: and thanks for forwarding all the other bugs to do with this.
[12:30] <seb128> we will get bugs anyway so you can as well open one now ;-)
[12:30] <james_w> heh :-)
[12:31] <seb128> my please for the forwarding, having bugs upstreamed is good ;-)
[12:31]  * pitti comments and subscribes
[12:31] <pitti> seb128: thanks for the gnome #
[12:32] <seb128> james_w: upstream did take the "don't apply changes immediatly" patch apparently, I noticed after the upload, I opened a bug upstream about the issue
[12:32] <james_w> seb128: that's interesting, I wonder if they ended up doing it the same way.
[12:33] <seb128> doh
[12:33] <seb128> james_w: "didn't"
[12:33] <pitti> I used the dialog this morning, and it felt pretty much the same as always
[12:33]  * pitti agrees that "don't apply immediately" makes sense there
[12:33] <seb128> that's basically the same code
[12:34] <james_w> seb128: ah
[12:34] <seb128> james_w: http://bugzilla.gnome.org/show_bug.cgi?id=545115
[12:42] <zul> morning
[12:58] <glock> If i wanted to start contributing to ubuntu - would you guys recommend I start with bugs or look at something like the MOTU?    I have no experience with building debs, but could learn..
[13:00] <cjwatson> I always recommend that people start by doing something they find interesting and that fixes something that annoys them personally
[13:00] <cjwatson> https://wiki.ubuntu.com/ContributeToUbuntu may help - there are all sorts of avenues
[13:05] <glock> The MOTU stuff seems nice with the sponsorship / mentoring kinda approach.  I can fix and work out bugs, just never know if im fixing things correctly according to the procedures. I guess the idea would be to work in as many teams as possible to gain an overall understanding, so was just looking where to start which would give me a good understanding
[13:13] <pitti> seb128: FYI, I tried the upstream patch for gnome-keyring, didn't work; I reopened the upstream bug
[13:24] <seb128> pitti: right I noticed the comment and it doesn't work for me either
[13:47] <norsetto> glock: if you want a good overview about ubuntu development, you should look at this wiki page: https://wiki.ubuntu.com/UbuntuDevelopment
[14:11] <saispo> any ftp maintainer in this room ? : )
[14:11] <Hobbsee> wrong distro?
[14:12] <saispo> Hobbsee: i think there is a "shitty" link on archive.ubuntu.com for a packages
[14:12] <Pici> No need for the language.
[14:14] <Lightkey> indeed, let us all switch to latin. english is so outdated
[14:14] <ScottK> pitti: RE sauerbraten-data, Riddell took care of it over the weekend.
[14:14] <Pici> Quod? Er, saispo can you provide an example?
[14:15] <saispo> Pici: ie example
[14:15] <saispo> lftp archive.ubuntu.com:/ubuntu/pool/universe/libn> ls -al libnet
[14:15] <saispo> drwxr-sr-x    2 1001     1001         4096 Oct 30  2007 .
[14:15] <saispo> drwxrwsr-x  135 1001     1001         4096 May 30 08:04 ..
[14:15] <saispo> lrwxrwxrwx    1 1001     1001           63 Oct 30  2007 libnet1-dev_1.1.2.1-2build1_amd64.deb -> ../../../main/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb
[14:15] <saispo> excuse me for the flood...
[14:15] <saispo> i think one must be deleted or removed...
[14:16] <\sh> saispo: no...it's correct...it was demoted to universe
[14:16] <\sh> in hardy...
[14:16] <saispo> drwxrwsr-x    2 1001     1001         4096 Jul 02 08:04 .
[14:16] <saispo> drwxrwsr-x  135 1001     1001         4096 May 30 08:04 ..
[14:16] <saispo> lrwxrwxrwx    1 1001     1001           63 Jul 02 08:55 libnet-ip-perl_1.25-2.diff.gz -> ../../../main/libn/libnet-ip-perl/libnet-ip-perl_1.25-2.diff.gz
[14:16] <saispo> same for this ?
[14:17] <saispo> i get some error when i try to build custom Ubuntu Cd with this links, but if you say it's ok...
[14:18] <\sh> saispo: yes...it was moved from universe to main in intrepid...
[14:18] <\sh> saispo: but the wonder is why do you have links?
[14:19] <\sh> ah ok...you showed the source files
[14:19] <saispo> yes
[14:19] <saispo> i thinl dangling symlink is not a good idea to me
[14:20] <saispo> s/thinl/think/
[14:20] <\sh> saispo: how did you do the mirror?
[14:20] <saispo> with rsync on an .de mirror
[14:20] <\sh> use debmirror and everything is good :)
[14:20] <cjwatson> it's not a dangling symlink.
[14:21] <saispo> cjwatson: when you use COPYMODE in Ubuntu-CD it's a dangling symlink :)
[14:21] <\sh> saispo: afaics there are no links on the webserver of the archive...if there are it's wrong imho
[14:21] <cjwatson> saispo: that's a mirroring problem. it's not dangling on the master archive system.
[14:21] <cjwatson> \sh: you're wrong on both counts, I'm afraid
[14:21] <cjwatson> there are symlinks, and they're correct
[14:22] <cjwatson> lp_archive@drescher:~$ ls -l ubuntu/pool/universe/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb
[14:22] <saispo> cjwatson: hmmm, see my copy/paste
[14:22] <cjwatson> lrwxrwxrwx 1 lp_publish lp_publish 63 Oct 30  2007 ubuntu/pool/universe/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb -> ../../../main/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb
[14:22] <cjwatson> lp_archive@drescher:~$ ls -l ubuntu/pool/main/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb
[14:22] <cjwatson> -rw-r--r-- 1 lp_publish lp_publish 339158 Jul 31  2007 ubuntu/pool/main/libn/libnet/libnet1-dev_1.1.2.1-2build1_amd64.deb
[14:22] <cjwatson> saispo: your mirroring setup is wrong. fix it ...
[14:22] <devfil> pitti: there?
[14:22] <saispo> cjwatson: hum, as you wish but...
[14:22] <cjwatson> I've checked both the examples you gave and they are not dangling symlinks in the master archive
[14:23] <saispo> cjwatson: must remove --links and --hard-links in rsync can be a solution ?
[14:23] <\sh> cjwatson: well, it's not shown on the directory index of the archive
[14:24] <cjwatson> \sh: that doesn't prove anything
[14:24] <cjwatson> \sh: rsync archive.ubuntu.com:: shows the symlinks
[14:25] <saispo> cjwatson: for example
[14:25] <saispo> Copy: /home/eole/mirror/cdimage/scratch/eole/daily/tmp/hardy-i386/CD1/pool/universe/libn/libnet-ip-perl/libnet-ip-perl_1.25-2_all.deb => /home/eole/mirror/cdimage/ftp/pool/universe/libn/libnet-ip-perl/../../../main/libn/libnet-ip-pe+rl/libnet-ip-perl_1.25-2_all.deb
[14:25] <saispo> cp: not writing through dangling symlink `/home/eole/mirror/cdimage/scratch/eole/daily/tmp/hardy-i386/CD1/pool/universe/libn/libnet-ip-perl/libnet-ip-perl_1.25-2_all.deb'
[14:25] <cjwatson> saispo: the anonftpsync script included in cdimage already uses --copy-links to avoid this problem
[14:25] <saispo> ok, thanks, will see it
[14:26] <\sh> cjwatson: well...rsync is too slow from me here..that's why I'm using debmirror and http...and it doesn't show it to me using http..and avoids those problems.
[14:26] <pitti> hi devfil
[14:26] <cjwatson> \sh: sure
[14:27] <saispo> thanks \sh and cjwatson
[14:28] <devfil> pitti: you've worked at libgphoto2 in the past, so you probability know it, can you please take a look at bug #252408 ?
[14:28] <cjwatson> and the reason that they're symlinks is that, as \sh said, e.g. libnet1-dev was moved from main to universe between gutsy and hardy, but is at the same version in both, so we need the same file in the pool; symlinks save a good deal of disk space here
[14:28] <cjwatson> same file in two locations in the pool, I mean
[14:29] <pitti> devfil: thanks! I'll sponsor this (not right now, but today or tomorrow)
[14:29] <devfil> pitti: thanks to you
[14:29] <\sh> cjwatson: but that means, source one time in main, it's always symlinked to universe? regarding libnet-ip-perl it was in main (dapper) then demoted to universe and since intrepid again in main....
[14:30] <devfil> pitti: I hope it is ok
[14:30] <pitti> devfil: I'll follow up on the bug report if there are problems
[14:30] <cjwatson> \sh: only if the same version is in main and universe in two different releases
[14:30] <devfil> pitti: thanks
[14:30] <cjwatson> \sh: in this case dapper is irrelevant because it's a different version, but the same version (1.25-2) is in feisty/gutsy/hardy universe and intrepid main
[14:31] <cjwatson> \sh: this means that dists/feisty, dists/gutsy, and dists/hardy refer to it as pool/universe and expect it to be there, while dists/intrepid refers to it as pool/main
[14:31] <cjwatson> \sh: so we move the file itself to main but put a symlink in universe
[14:32] <\sh> cjwatson: ok
[14:57] <tkamppeter> Whom should I as if I want to get admin of the ubuntu-printing Launchpad group?
[14:59] <cjwatson> tkamppeter: the current administrator
[15:00] <tkamppeter> cjwatson, thanks.
[15:00] <tkamppeter> doko, ping
[15:03] <doko> tkamppeter: done
[15:08] <tkamppeter> doko, thanks, as I am doing all the printing stuff now and you do not do printing stuff any more, should perhaps the team ownership be transfered to me?
[15:09] <doko> tkamppeter: sure, please do
[15:33] <kirkland> cjwatson: hiya, I was wondering what you thought of the usplash patch attached to https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/251656
[15:37] <cjwatson> kirkland: looks fine
[15:37] <kirkland> cjwatson: could I trouble you to sponsor the upload?
[15:37] <cjwatson> kirkland: oh, except this is C so use /* */ comments rather than //. (Yes, I know C99 allows // ...)
[15:37] <cjwatson> kirkland: sure, I'll make the comment change and upload
[15:37] <kirkland> cjwatson: ;-)  i'll update the patch
[15:37] <cjwatson> kirkland: do you have a bzr branch for it?
[15:37] <cjwatson> kirkland: also, version number -> 0.5.23
[15:38] <kirkland> cjwatson: I do not have a bzr branch
[15:38] <kirkland> cjwatson: i'll pull one
[15:39] <NCommander> seb128, morning
[15:41] <kirkland> cjwatson: help me understand the bzr work flow ....
[15:41] <kirkland> cjwatson: i should register a branch here?  https://code.launchpad.net/usplash
[15:41] <cjwatson> no, create the branch locally then push it to the right place
[15:42] <cjwatson> bzr branch bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/ name-of-your-new-branch
[15:42] <cjwatson> cd name-of-your-new-branch
[15:42] <cjwatson> hack commit hack commit hack commit
[15:42] <cjwatson> bzr push bzr+ssh://bazaar.launchpad.net/~kirkland/usplash/name-of-your-new-branch/
[15:43] <kirkland> cjwatson: and the difference between https://code.launchpad.net/usplash and http://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu is upstream vs. ubuntu's?
[15:44] <cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu is a single branch associated with the upstream project https://code.launchpad.net/usplash
[15:44] <cjwatson> the namespace on bazaar.launchpad.net is ~OWNER/PROJECT/BRANCHNAME
[15:44] <cjwatson> in this case 'ubuntu' is just a conventional name rather than having any database-level association with Ubuntu
[15:46] <cjwatson> put UNRELEASED in the changelog when committing; generally the uploader should be the one to set that to intrepid
[15:47] <bryce> morning
[15:47] <seb128> NCommander: hey
[15:47] <kirkland> cjwatson: okay, so I've made the change to the C code...  do I update the changelog too, or not?
[15:47] <kirkland> cjwatson: ah, make the changelog entry, but set to UNRELEASED
[15:48] <cjwatson> yes
[15:48] <NCommander> seb128, how are things going for you this morning?
[15:49] <kirkland> cjwatson: okay, so my bzr diff looks like http://pastebin.ubuntu.com/31295/
[15:49] <seb128> NCommander: busy as usual after the weekend but good otherwise, how are things going for you?
[15:49] <NCommander> seb128, Eh, driving over the state of NY. Watching people play with the ne and improved REVU
[15:49] <kirkland> cjwatson: adding link to LP #
[15:49] <tkamppeter> doko, I cannot move team ownership. Can you look whether you are able to do so?
[15:50] <seb128> NCommander: and people like the new REVU then? ;-)
[15:50] <NCommander> seb128, it's not brown, which I think has shocked some people into submission
[15:50] <seb128> lol
[15:50] <NCommander> seb128, http://revu.tauware.de/
[15:56] <dmishd>  Hello all.  Wanted to check on the process for getting a new upstream version of mypasswordsafe uploaded for intrepid.  I've packaged it in my ppa, registered it as a bug in launchpad, nominated it for release and subscribed the ubuntu-universe-sponsors.  Did that a few weeks ago and have heard nothing since.  Is it usual to wait for several weeks or is there something else I should do?
[15:56] <dmishd>  The bug url is https://bugs.launchpad.net/ubuntu/+source/mypasswordsafe/+bug/221893
[16:01] <kirkland> cjwatson: okay, try this: bzr+ssh://bazaar.launchpad.net/~kirkland/usplash/usplash.251656
[16:11] <cjwatson> kirkland: looks good, uploaded, thanks
[16:12] <kirkland> cjwatson: cool, thanks for the bzr workflow details, i've added them to my process documents ;-)
[16:12] <cjwatson> kirkland: you could just add a link to https://wiki.ubuntu.com/BzrContributorHowto :)
[16:13] <kirkland> cjwatson: will do ;-)
[16:39] <tkamppeter> doko, still there?
[16:42] <doko> tkamppeter: yes
[17:03] <tkamppeter> doko, I did not succeed to move ownership of theb ubuntu-printer group. Probably only you can do so. Can you check?
[17:12] <mario_limonciell> pitti, i got a hold of some more broadcom hardware, but unfortunately LRM appears to be broke in hardy-proposed for the wl driver.  There wasn't an SRU bug opened for it's last upload, so what's the proper way to indicate regression in hardy-proposed?
[17:13] <pitti> mario_limonciell: can you please open a new one and subscribe timg-tpi and ubuntu-sru?
[17:13] <mario_limonciell> yup
[17:14] <pitti> thanks!
[17:33] <kees> tedg: okay, I'm sold on pulseaudio.  :)
[17:33] <tedg> kees: What did it do for you?
[17:33] <kees> tedg: though I think the volume control is a bit wonky, so I left my volume management attached to the ALSA output.
[17:34] <kees> tedg: being able to move streams live... that's just bad-ass.
[17:34] <kees> tedg: and the knowledge that when I feel like it, I can code up a "to-disk" sink like mplayer's --dumpaudio :)
[17:34] <tedg> kees: Heh, yeah.  I think there's some great infrastructure there now, we just need to get apps using the power of it more.
[17:35] <tedg> kees: I'd really like to see apps like pidgin have a volume control in their preferences.
[17:35] <kees> there's some broken logic in libflashsupport that causes it to not select the correct pulse output (it seems to ignore the default), but after I sorted that out, I was golden.
[17:36] <tedg> kees: Oh, cool.  A lot of people will be happy for you for fixing that :)
[17:36] <tedg> kees: See, everything we do on the desktop is to make you happy.  You just have to trust us, and give us all your passwords.
[17:37] <kees> tedg: I didn't fix it -- I just moved the stream to the right place.
[17:37]  * kees cries quietly
[17:44] <tedg> kees: Don't worry, it's flash, I'm sure that Adobe will submit a patch in just a few hours, or days, or decades...
[18:05] <Laney> In CDBS, how can I pass options to my make target? I want it to be "make VERBOSE=1"
[18:09] <pitti> Laney: DEB_MAKE_ENVVARS (real environment files) or just use CFLAGS
[18:09] <pitti> Laney: see /usr/share/cdbs/1/class/makefile-vars.mk
[18:09] <Laney> Oh whoops, I meant to say that in -motu
[18:09] <Laney> but thanks pitti, will look into it
[18:10] <slangasek> well, not CFLAGS in this case, CFLAGS="VERBOSE=1" doesn't sound like what you want :)
[18:10] <pitti> Laney: erm, what did I say; s/environment files/environment vars/, of course
[18:21] <Laney> That works great, thanks pitti and slangasek
[18:34] <RichW> What channel do I use for Ubuntu PPA/Package Building?
[18:38] <crimsun> RichW: #ubuntu-motu generally.
[18:41] <totopalma> Riddell: can you please take a look at bug #250579
[18:57] <Riddell> totopalma: looks good
[18:57] <Riddell> totopalma: ah, bug "dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[18:58] <Riddell> totopalma: uploading
[19:01]  * totopalma hugs Riddell :)
[21:26] <kees> lamont: when you get a moment, can you look at bug 252675?
[21:31] <lamont> kees: muppets
[21:31] <lamont> I'll go look at it
[21:32] <lamont> kees: ah.  yeah, when ISC releases the real (better performing) patch, we want it
[21:32] <kees> lamont: okidoky
[21:33] <lamont> generally, if ISC calls it -Pn, uh, we want it./
[21:33] <lamont> whether for -security or -updates, that varies
[21:33] <kees> :)
[21:33] <lamont> but they don't do -P releases trivially
[21:37] <mathiaz> slangasek: I'm about to send an updated cn=config patch to pkg-openldap
[21:37] <slangasek> mathiaz: ok, cool
[21:49]  * calc hopes he doesn't blow up his repo
[21:50]  * calc is going to try to branch his 2.4.1 into 3.0.0 then merge debian into it, heh
[21:51] <lamont> kees: likewise, I'm not going to release it before ISC. :-)
[21:51] <lamont> and make that "they don't do -P releases without great care"
[21:51] <lamont> s/trivially/frivously/
[21:52] <lamont> or however that's spelled
[21:52]  * lamont wanders afk for a while
[22:06] <jdstrand> I find it curious that mk-sbuild-lv did not install apt for my intrepid chroot
[22:08]  * slangasek looks at apt askance for pulling in wcatalan to satisfy the pam build-dep
[22:13] <calc> wow OOo 3.0 source is big 314,704,496 for m28
[22:13] <calc> not including diff.gz
[22:15] <calc> they also have the source split up into bits but not buildable separately yet
[22:16] <calc> at least its a step in the right direction
[22:17] <asac> TheMuso, are you there?
[22:19] <rubikcube> hi, do can someone please tell me where dpkg-reconfigure linux-image-${version} takes the modules from to compile into?  Only from /etc/initramfs-tools/modules or from other sources as well?
[22:21] <NCommander> seb128, hola
[22:23] <seb128> hello NCommander
[22:23] <NCommander> seb128, got any more updates for me to tackle?
[22:24] <seb128> NCommander: still don't want to do the glibmm, gtkmm, etc?
[22:24] <jdstrand> dpkg: dependency problems prevent configuration of apt:
[22:24] <jdstrand>  dpkg (1.14.20ubuntu3) breaks apt (<< 0.7.7) and is installed.
[22:24] <jdstrand>   Version of apt to be configured is 0.7.6ubuntu14.1.
[22:24] <jdstrand> well, I guess that answers that...
[22:25] <NCommander> seb128, libglibmm-2.4-dev - I get these weird packages, and I can't pull a source package for them ...
[22:26] <seb128> NCommander: did you try again?
[22:26] <NCommander> yeah
[22:26] <seb128> that's weird, those work just fine for me, what error do you get?
[22:26] <NCommander> Right now, I'm updated to intrepid, but I couldn't get them in my chroot either
[22:26] <NCommander> "Unable to locate source package for ..."
[22:27] <seb128> NCommander: apt-get source glibmm2.4?
[22:27] <NCommander> that works
[22:27] <seb128> so what is the issue?
[22:27] <NCommander> human error on my part :-P
[22:28] <seb128> ;-)
[22:36] <seb128> james_w: around?
[22:36] <james_w> hey seb128
[22:37] <seb128> james_w: hello, I don't get your comment on bug #252564
[22:37] <seb128> ah, you need somebody to approve the request you mean
[22:37] <james_w> requeststnc by default assumes you have permission to upload the package, and so confirms the bug and subscribes the archive admin. I need sponsorship, so I unconfirmed and subscribed the sponsors.
[22:38] <seb128> I was going to do sync the new version and just looked at the bug list and found your bugs there
[22:38] <james_w> seb128: exactly.
[22:38] <seb128> I'll ack it and sync then
[22:38] <jdstrand> hmm, I grabbed the wrong dpkg up above, but still curious why apt wasn't pulled in be debootstrap...
[22:38] <jdstrand> s/dpkg/apt/
[22:38] <james_w> thanks seb128
[22:38] <seb128> you're welcome ;-)
[22:39] <seb128> james_w: oh, btw they undoed the bug #251508 changes
[22:40] <james_w> seb128: eh? the -2 upload was in response to me filing that in Debian, did the make a mistake with the upload?
[22:40] <seb128> james_w: debian doesn't split python-desktop the way we do, the current package was not installable on debian
[22:40] <seb128> python-gnome-desktop I mean
[22:41] <james_w> seb128: oh really? oops, that's my fault.
[22:41] <seb128> they just uploaded a -3 to fix those depends
[22:41] <james_w> ah, I didn't see that.
[22:42] <james_w> we can still sync -2 and we get what we want though right? :-)
[22:42] <seb128> james_w: I just read the change on the debian -changes list
[22:43] <seb128> james_w: the maintainer did an another typo, and we don't need those changes, python-gnome2 depends on python-gconf already
[22:43] <seb128> james_w: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492767 for the record about the issue
[22:45] <norsetto> ubuntuism? lol
[22:46] <james_w> seb128: so are we able to sync that version?
[22:46] <seb128> yes
[22:47] <james_w> seb128: great, thanks for your help
[22:48] <seb128> np, thanks for working on reducing the debian,ubuntu delta for desktop packages ;-)
[23:01] <seb128> enough for today, see you tomorrow
[23:31] <TheMuso> asac: I'm around now.
[23:32] <TheMuso> kirkland: If you have finished your work with those initramfs-tools/mdadm patches, is it ok if I look at them today, and merge the changes I need to make into initramfs-tools and upload both our changes?
[23:32] <TheMuso> kirkland: I've noticed that you have made some nice improvements.
[23:32] <kirkland> TheMuso: hiya!
[23:33] <kirkland> TheMuso: well, actually, Kees just committed them today
[23:33] <kirkland> TheMuso: we debated pinging you about it, but Kees got comfortable with the commit
[23:33] <TheMuso> Fair enough.
[23:33] <kirkland> TheMuso: I'd appreciate any feedback, though, even if in retrospect
[23:33] <asac> TheMuso, great. would you mind to upload and push crimsun's alsa-lib branch?
[23:33] <TheMuso> asac: I'd rather wait till we have 1.0.17 in the kernel.
[23:33] <kirkland> TheMuso: the work isn't entirely done yet, either mind you, but we're at an incremental point where the commit makes sense and stands on its own
[23:33] <asac> TheMuso, whats the point of waiting?
[23:33] <TheMuso> asac: I've asked the kernel guys to look into that.
[23:34] <TheMuso> asac: Mismatch/breakage between library and kernel space?
[23:34] <asac> TheMuso, the branch just adds a single patch
[23:34] <TheMuso> kirkland: Alright then, I'll just do the change I want to make then.
[23:34] <TheMuso> asac: Oh its not to update to 1.0.17? Right, I can do that.
[23:34] <TheMuso> asac: Will look at it this morning.
[23:34] <kirkland> TheMuso: cool, there was one bug in there that I stumbled upon, in case you're interested
[23:35] <TheMuso> kirkland: Sure, fire away.
[23:35] <asac> TheMuso, its adding the pulse plugin by default so flash 10 works nicely for all
[23:35] <kirkland> TheMuso: bit me for a while, until I figured it out ;-)
[23:35] <TheMuso> asac: That wil affect KDE users.
[23:35] <asac> crimsun, ^^ whats the idea for that?
[23:36] <kirkland> in the local script, i had to initialize FSTYPE="unknown", if unset
[23:37] <kirkland> TheMuso: in the case where $(fstype) runs, but doesn't find anything meaningful, it doesn't set FSTYPE="unknown"
[23:37] <TheMuso> kirkland: Right.
[23:37] <TheMuso> asac: I'll have a look at how he has done it anyway.
[23:37] <asac> TheMuso, any idea if kde will adapt pulse at some point in the future?
[23:37] <TheMuso> asac: I doubt it, Riddell would be abel to answer that better than I.
[23:38] <asac> TheMuso, http://bazaar.launchpad.net/~crimsun/alsa-lib/ubuntu.new/annotate/9?file_id=use_pulse_pcmctl_by_-20080607184226-whgrt66pie4ls67q-1
[23:38] <kirkland> TheMuso: anyway, minor item, but kept me bemused for a bit, why [ ! -e "${ROOT}" ] || ! $(get_fstype "${ROOT}" >/dev/null) || ! /sbin/udevadm settle wasn't doing what I wanted
[23:38] <kirkland> TheMuso: and it was because $(get_fstype) was malfunctioning ;-)
[23:38] <asac> TheMuso, i think if kde really doesnt use pulse, we need to have different configs for kde and gnome
[23:38] <TheMuso> kirkland: Right,a fair Keybuk said that udevadm settle doesn't do what one sthinks it should.
[23:39] <kirkland> TheMuso: anyway, I have to shift my focus this week to iSCSI, but I'm going to return and finish the RAID stuff thereafter
[23:39] <kirkland> TheMuso: I have some bootloader changes to make, and want to add a deconf bit to mdadm
[23:39] <kirkland> TheMuso: i think i'm probably mostly done with initramfs-tools, though
[23:39] <TheMuso> kirkland: Ok.
[23:40] <calc> ok i don't know if i screwed up or if lp is just slow
[23:40] <asac> crimsun, will the config make alsa fallback to something if there is no pulse on the system?
[23:40] <calc> i merged debian's ooo into my branch resolved the conflicts then bzr commit the change
[23:40] <calc> but its not showing up on launchpad and a bzr update elsewhere isn't getting the revision i committed
[23:41] <calc> do i have to push it?
[23:41] <cjwatson> if it isn't a bound branch (bzr checkout, or bzr branch; bzr bind) then you have to push it manually
[23:42] <cjwatson> you can use 'bzr bind' to convert an ordinary branch into a bound branch so that it gets autopushed
[23:42] <calc> oh crap i committed it to the wrong branch somehow
[23:43] <TheMuso> asac: It doesn't look like it.
[23:43] <calc> is there a way to rollback cleanly like it didn't happen?
[23:44] <cjwatson> bzr uncommit
[23:45] <calc> yipee, thanks :)
[23:46] <calc> so now i have it ready where i could push it but it says there is nothing to push
[23:46] <calc> Checkout (format: pack-0.92)
[23:46] <calc> Location:
[23:46] <calc>        checkout root: .
[23:46] <calc>   checkout of branch: bzr+ssh://ccheney@bazaar.launchpad.net/%7Eopenoffice-pkgs/openoffice/2.4.1-intrepid/
[23:46] <calc> Related branches:
[23:46] <calc>     push branch: bzr+ssh://ccheney@bazaar.launchpad.net/%7Eopenoffice-pkgs/openoffice/3.0-intrepid/
[23:46] <calc>   submit branch: bzr+ssh://ccheney@bzr.debian.org/srv/bzr.debian.org/bzr/pkg-openoffice/packages/openofficeorg/3.0/experimental/
[23:46] <calc> i probably branched 2.4.1 to 3.0 incorrectly but it mostly worked, heh
[23:47] <calc> do i need to redo the merge since it was a checkout of the wrong branch?
[23:49] <asac> calc, if you uncommitted the merge then you probably have to redo
[23:50] <calc> ok
[23:51] <asac> calc, if you have a checkout you will auto-push. so your changes might end up in the checkout branch. not sure if that is what you want to do
[23:51] <calc> i think i can make it redo it pretty easily by copying the conflict fixed files over to the new checkout after attempting a merge
[23:52] <asac> calc, i'd suggest to use a full branch so you can decide when and where to push ;).
[23:56] <cjwatson> calc: 'bzr unbind', or 'bzr bind bzr+ssh://ccheney@bazaar.launchpad.net/%7Eopenoffice-pkgs/openoffice/3.0-intrepid/', before doing anything with that
[23:56] <cjwatson> calc: otherwise you'll be committing directly to ~openoffice-pkgs/openoffice/2.4.1-intrepid on LP
[23:57] <cjwatson> calc: looks like maybe you branched with 'cp -a' rather than with 'bzr branch'
[23:57] <asac> cjwatson, why binding at all instead of branching and then pushing?
[23:59]  * asac wonders if checkout gives any real performance improvements nowadays