[00:03] <LordMetroid> Is Canonical doing most of the dev work themselves?
[00:03] <calc> LordMetroid: dev work for what?
[00:03] <LordMetroid> Assembling the distribution...
[00:04] <calc> LordMetroid: some is done by canonical and some by community
[00:04] <calc> LordMetroid: there are many more community people than canonical people though
[00:04] <calc> LordMetroid: canonical people have the benefit of being able to work on it full time though
[00:04] <LordMetroid> Yes, but I can't seem to figure out where the main work is being done
[00:04] <pwnguin> its a little tough to tell; im given to understand canonical occasionaly contracts community members to do some work
[00:04] <directhex> depending on which news sources you believe, i'm apparently an evil microsoft plant
[00:05] <calc> and yes directhex is an evil Novell-Microsoftie ;-)
[00:05] <directhex> oh yeah, i love me some microsofts
[00:05] <calc> my OOo build worked, yipee
[00:05] <directhex> is it called OOOo yet?
[00:05] <pwnguin> LordMetroid: in one sense, the vast majority of Ubuntu is written by non-ubuntu people be it canonical or otherwise
[00:06] <calc> now to forward port all my OOo 3.0 patches to 3.1
[00:06] <directhex> pwnguin, debian!
[00:06] <Amaranth> directhex: throw some of that microsoft cash my way :)
[00:06] <pwnguin> directhex: and the people who write the programs debian packages
[00:06] <LordMetroid> So I've tried to figure out where the decisions are being made now for a good 4 month but I can't seem to grasp it
[00:06] <directhex> ah, your question is a governance question
[00:06] <LordMetroid> yes, I think so
[00:07] <calc> maybe he means UDS decisions?
[00:07] <pwnguin> ubuntu is divided into "members" "developers" and "core developers"
[00:07] <directhex> and "annoying hanger-ons"
[00:07] <pwnguin> theoretically there isn't supposed to be a hierarchy like this
[00:08] <LordMetroid> UDS's where the decision are being made?
[00:08] <LordMetroid> I was thinking of going down to UDS in Barcelona
[00:08] <Amaranth> LordMetroid: UDS is where things are planned
[00:08] <pwnguin> UDS is one place where decisions are made
[00:08] <calc> most of them happen at UDS
[00:08] <Amaranth> LordMetroid: but the people doing the work make the decisions, basically
[00:08]  * directhex remembers to pack his ice beam & missiles
[00:09] <LordMetroid> lol
[00:09] <pwnguin> LordMetroid: basically, anyone in core developers can upload to main/restricted
[00:09] <Amaranth> LordMetroid: So just because some people at UDS decide we're going to rewrite nautilus in scheme doesn't mean it'll get done
[00:10] <directhex> Amaranth, thank $EXPLETIVE
[00:10] <calc> directhex: instead you are going to rewrite it in mono, eh? ;-)
[00:10] <directhex> calc, damn straight!
[00:10] <LordMetroid> *facepalm*
[00:10] <ajmitch> calc: he's probably going to unveil that at UDS
[00:10] <directhex> calc, with winforms!
[00:10]  * Amaranth remembers when we almost decided to use xgl for FUSA
[00:11] <pwnguin> LordMetroid: the CoC directs people to be collaborative, so they shouldnt really be abusing the powers to override any consensus
[00:11] <directhex> unless they're sabdfl
[00:11] <LordMetroid> CoC?
[00:11] <ajmitch> calc: don't forget, directhex's a fan of VB.NET as well :)
[00:11] <Amaranth> one Xserver with multiple xgl servers under it for each user and OpenGL effects for user switching
[00:11] <directhex> ajmitch, "fan of"? never written a line of it matey!
[00:11] <ajmitch> directhex: you try & hide it now...
[00:11] <Amaranth> then everyone would get compiz and we could do awesome transitions for user switching, logging out, etc
[00:11] <directhex> ajmitch, which sorta breaks the first rule of packaging... :/
[00:11] <pwnguin> LordMetroid: in the event that no obvious consensus can be found, the technical board exists to handle things
[00:12] <LordMetroid> ok
[00:12] <Amaranth> I had that one specced and most people either saying it was a good idea or they weren't sure
[00:12] <pwnguin> !coc
[00:12] <Amaranth> thank goodness that didn't happen :P
[00:12] <RAOF> Amaranth: That would've been *awesome*.  Apart from the death of upstream, of course.
[00:12] <Amaranth> RAOF: yeah, that was before upstream completely died
[00:12] <Amaranth> RAOF: we were going to get input redirection too!
[00:13] <directhex> know what i want?
[00:13] <ajmitch> a pony?
[00:13] <directhex> i want mouse sensitivity settings that can cope with mice >1000dpi
[00:13] <pwnguin> a gnome-panel that does intelligent layout?
[00:13] <directhex> and a pony
[00:13] <Amaranth> I want sharks with fricken laser beans
[00:13] <pwnguin> directhex: wacom has some ridiculusly high input resolution
[00:13] <Amaranth> err, beams
[00:13] <directhex> but i'm both allergic to horse hair and french, so if i could have that with chips...
[00:13] <LordMetroid> Death of Upstream, that seems really horrible!
[00:13] <Amaranth> who put those two keys so close together?
[00:13] <RAOF> Mmmm... laser beans.
[00:13] <ajmitch> pwnguin: I won't mention my hassles with gnome-panel & multiple displays then, I may break the CoC :)
[00:14] <directhex> pwnguin, the highest resolution consumer-grade mouse on the market is 5600dpi
[00:14] <LordMetroid> 5600dpi is nothing, I can move way less distance than that!
[00:14] <directhex> pwnguin, my mouse does 4000, and i need to lower it to 1500 for it to be remotely usable on ubuntu
[00:14] <LordMetroid> I move one pixel at a time!
[00:15]  * Amaranth spends $10 on a mouse
[00:15] <Amaranth> so I doubt it does that :P
[00:15] <pwnguin> directhex: maybe its time to gift some x developers with high resolution mice ;)
[00:15] <directhex> Amaranth, the 5600dpi mouse is $130
[00:15] <directhex> so... no
[00:16] <directhex> pwnguin, if i knew which specific person would guaranteed produce results, then i'd donate a reasonable high-dpi mouse
[00:16] <pwnguin> LordMetroid: wacom input resolution is like 20000x20000
[00:16] <directhex> pwnguin, tablets != mice though
[00:16] <pwnguin> indeed
[00:16] <LordMetroid> I have a wacom from the 90s
[00:18] <pwnguin> anyways, i hope you have a better understanding of how decisions are made
[00:18] <pwnguin> locally, with the backing of consensus and oversight of community and technical boards
[00:19] <LordMetroid> Hmm, maybe one should find a place to stay in Barcelona before it is too late
[00:20] <LordMetroid> Yes, I have thank you very much pwnguin
[00:20] <directhex> i really don't remember where i put my euros
[00:21] <LordMetroid> euros chemrous, just use the plastic
[00:21] <directhex> aha, here on my desk
[00:22] <LordMetroid> Remember, do not drink the tap water, it does not contain your bacteria culture and from my experience of Spain, it is highly chlorated as well so you will become quite quizzy
[00:24] <directhex> i never drink the tap water when abroad. who knows what those funny foreigners have done to it
[00:26] <james_w> luckily the beer is fine
[00:27] <LordMetroid> All these people attending the UDS, they are like diehardcore distro developers?
[00:27] <directhex> and/or microsoft plants
[00:27] <LordMetroid> >_>
[00:27] <directhex> james_w, what's drinkable beerwise though? i'm used to nice local ale!
[00:28] <james_w> we'll be short on ale unfortunately
[00:28] <directhex> well, never mind. i hopefully have enough euros that i won't taste it by the end
[00:29] <james_w> there's plenty of good lager and wine though
[00:32] <Amaranth> directhex: Do a couple shots first, you won't taste any of it :)
[00:32] <directhex> hm, i wonder if anyplace sells my favourite rum. i'm almost out!
[00:33] <directhex> is james_w going?
[00:33] <james_w> directhex: where?
[00:34] <directhex> james_w, uds!
[00:34] <james_w> of course!
[00:34] <james_w> UDS in Barcelona? I wouldn't miss that
[00:36] <LordMetroid> You think a general user of Ubuntu which merely is reporting bugs when he sees them has anything to contribute at the UDS?
[00:37] <LaserJock> I'd think it'd at least be nice to have some non-developer feedback for some things
[00:37] <Amaranth> LordMetroid: You may have some ideas or input that is useful
[00:38] <LordMetroid> I develop my own software projects. Mainly concerned about usability...
[00:38] <LaserJock> usability is always a hot topic
[00:39] <pace_t_zulu> anyone here familiar with building Chromium on Ubuntu?
[00:39] <dtchen> pace_t_zulu: fta does; he maintains the ppa.
[00:39] <pace_t_zulu> dtchen: i don't see fta in here
[00:40] <directhex> #ubuntu-mozillateam
[00:42] <dtchen> pace_t_zulu: https://launchpad.net/~chromium-daily/+archive/ppa
[00:43] <pace_t_zulu> dtchen: i am trying to figure out why my builds fail on stock Ubuntu systems
[00:43] <pace_t_zulu> dtchen: if there are any steps particular to Ubuntu that are necessary
[00:44] <dtchen> contrast w/ his generated source packages.
[00:54] <calc> is there a way to view a diff of a git commit without having to give the commit name of the previous commit?
[00:54] <james_w> git show
[00:55] <james_w> or "git diff name^..name"
[00:58] <LaserJock> james_w: btw, do you know if people have been testing the bzr git plugin on the gnome repos?
[00:58] <james_w> yes, they have
[00:59] <LaserJock> james_w: and it's been working pretty good?
[00:59] <james_w> I've no idea
[01:00] <LaserJock> pretty much every upstream and Debian project I've worked with has gone git now
[01:00] <james_w> 100% success record for the feedback I've heard
[01:00] <LaserJock> awesome
[01:00] <LaserJock> do you imagine it might be LP ready pretty soon?
[01:00] <james_w> you didn't ask what the sample size was though ;-)
[01:00] <LaserJock> heh
[01:01] <james_w> I don't know when LP will be ready, you're better off asking them
[01:30] <pace_t_zulu> asac: are you around?
[01:34] <RAOF> LaserJock: I've been playing with Banshee, and the initial branch works just fine (now that it no longer consumes multiple GB of memory), but subsequent pulls seem to die, but only in the particular repository I have.  I'm trying to track it down to something easily reproducible before filing a bug.
[01:34] <Ademan> this is somewhat offtopic I suppose, but it relates to a jaunty package (ushare)
[01:34] <Ademan> does anyone know why the pid stored in a pid file would consistently be two less than the actual pid of the daemon?  (the daemon is being started by start-stop-daemon)  If I had to guess I'd say the pid is from the bash instance that starts start-stop-daemon, rather than the instance of the daemon itself.  Can anyone confirm this?
[01:42] <Ademan> WAIT, duh, the process is daemonizing itself by forking twice...
[01:43] <Ademan> and that was my own addition/mistake
[01:43] <Ademan> please disregard anything i've said :-p
[02:34] <billisnice> my intel and 9.04 is slow
[02:39] <wgrant> billisnice: You might want to read the release notes.
[02:40] <LaserJock> luckily all my intel problems have been fixed in -proposed
[02:40]  * wgrant is using the x-updates PPA plus bits of Karmic.
[02:40] <wgrant> KMS is nice.
[03:10] <billisnice> does 9.04 update to x-updates PPA auto when you update?
[03:15] <maco> huh, hey guys, there's no jaunty directory under http://cdimage.ubuntu.com/ ...who should be told about that?
[03:15] <ajmitch> maco: there is one under /releases/
[03:16] <maco> and http://cdimage.ubuntu.com/releases/jaunty/release/ only has DVDs
[03:16] <ajmitch> as far as I know, releasse.ubuntu.com is the main site
[03:16] <calc> maco: cd's are available at http://releases.ubuntu.com/9.04/
[03:17] <wgrant> Right, most images will be on releases.ubuntu.com or ports.ubuntu.com
[03:17]  * ajmitch cannot spell either :)
[03:17] <maco> ah, so then what's cdimage?
[03:17] <directhex> unofficial portrs
[03:17] <directhex> e.g. ps3 port
[03:17] <directhex> plus other general non-standard cruft
[03:18] <wgrant> And the pre-release images.
[03:18] <wgrant> Only RC and final are ever on releases.u.c, IIRC.
[03:24] <maco> i give up on quassel for tonight
[05:17] <pace_t_zulu> is there a python-tlslite package available in the repos? i can't seem to find one
[06:36] <pitti> Good morning
[06:36] <StevenK> Morning pitti
[06:36] <pitti> directhex: dh_clistrip> URL?
[06:36] <pitti> calc: hi
[06:37] <pitti> apw: no, the default "lp:apport" is trunk, which isn't wrong
[06:37] <pitti> Riddell: will look ASAP
[06:38] <pitti> doko: tsconf> is there a MIR bug?
[06:38] <pitti> hey StevenK, how are you?
[06:38] <StevenK> pitti: Great, you? :-)
[06:43] <NCommander> morning pitti and StevenK
[06:44] <StevenK> And that's an early morning
[06:52] <TheMuso> Morning pitti
[06:52] <pitti> hey TheMuso
[06:52] <TheMuso> Yay, chroot problem. :)
[07:01] <pitti> Riddell: oh, I take it this was invalidly closed as "fix released" then?
[07:02]  * pitti boggles
[07:02] <pitti> "You are not the bug assignee nor the maintainer of xmlrpc-c (Ubuntu), and therefore cannot edit this bug's status. "
[07:02] <pitti> WTH?
[07:02] <pitti> it's an Ubuntu bug
[07:11] <NCommander> pitti, which bug?
[07:15] <dholbach> good morning
[07:25] <pitti> NCommander: sorted out already, I wasn't logged in
[07:25] <pitti> NCommander: filed as bug 371517
[07:26] <NCommander> Launchpad being buggy
[07:34] <stooj> Hi folks
[07:41] <dholbach> pitti: do you know what the deal with libpango/libthai is atm?
[07:41] <dholbach> (karmic amd64)
[07:42] <pitti> dholbach: might be what doko meant with tsconf promotion
[07:44] <dholbach> pitti: hm, not sure I get it - in any case it makes pbuildering / sponsoring anything to do with pango a bit tough :-)
[07:45] <pitti> right, it's uninstallable right now
[07:45] <pitti> doko: hm, tsconf is in main; what did you mean?
[07:45] <pitti> dholbach: what is the error?
[07:46] <persia> dholbach, If you're on amd64, you ought to be able to construct an i386 or lpia pbuilder environment, which might get around some of that class of issue (assuming it's arch-specific).
[07:46] <dholbach> persia: I dunno
[07:46] <dholbach> pitti: it tries to deinstall everything to do with pango :)
[07:48] <dholbach> ah
[07:48] <dholbach> it seems to need a newer libdatrie0
[07:49] <dholbach> libdatrie0 0.1.3-2 is in the archive right now, libthai0 conflicts with libdatrie << 0.1.4
[07:50] <dholbach> ah, maybe pango needs a rebuild against libdatrie
[07:50]  * dholbach will try that
[07:51] <pitti> hm, this morning's dist-upgrade killed f-spot
[07:51] <pitti> ah, seems to be some mono transition
[07:51]  * pitti eyes directhex
[07:52] <StevenK> dholbach: 0.1.3-2 is the latest in Debian, too
[07:52] <dholbach> StevenK: libdatrie0 -> libdatrie1 - I'm just trying a quick pango rebuild
[07:52] <StevenK> Ah!
[07:53]  * StevenK checks other rdepends
[07:54] <StevenK> Right, m17n-lib and libthai need a rebuild too
[07:54] <StevenK> dholbach: &
[07:55] <StevenK> s/&/^/
[07:55] <dholbach> StevenK: will you take care of them or shall I do it?
[07:55] <StevenK> dholbach: I'll look at them when my machine finishes it's current build run
[07:55] <dholbach> StevenK: gracias
[08:00] <StevenK> pitti: Oh, is the NBS checker pointing at karmic yet?
[08:00] <pitti> StevenK: yes
[08:00] <StevenK> \o/
[08:34] <dholbach> StevenK: I'm just taking care of m17n-lib and libthai - don't worry
[08:35] <dholbach> libthai does not seem to need the rebuild anyway
[09:48] <doko> pitti: james_w did promote it yesterday
[09:48] <pitti> ah, ok
[10:02] <pitti> StevenK, kirkland, jdstrand, james_w: warning, I just ran new-binary-debian-universe, and the output has some bogus (packages which are and should be in main)
[10:02] <pitti> so please don't use that right now
[10:04] <pitti> ah, ignore me, it's just harmless noise
[10:05] <olmari> cjwatson_: in case you bear any interest on the issue, I coudn't repeat the dreaded apt "racing condition" bug anymore...
[10:10] <olmari> cjwatson_: as suggested on the bugreport, would there be any way to get some ubuntu "installation server" to be available basically with mirror of 23th of april, as with that day this bug happened every time no matter which other way I tried to install ubuntu-desktop with mini-installer :)
[10:22] <Omahn> Is it normal for the build servers to have over 5000 packages queue or is it just the recent opening of Karmic that's had such an affect?
[10:30] <maxb> Omahn: The buildds are still churning through the initial surge of autosynced packages that happens when the archive opens again after a release
[10:30] <Omahn> maxb: I'm guessing it normally settles after a week or so then?
[10:31] <maxb> lpia's already settled. At the current rate of progress amd64 and i386 should have caught up in another day or so
[10:32] <maxb> The other architectures are, I presume, building on slower hardware.
[10:32] <Omahn> I'm guessing all the build servers are internal to Canonical?
[10:32] <maxb> yes
[10:33] <Omahn> Seems sensible. Shame though, we have some fairly beefy boxes sitting at our place that could certainly help.
[10:44] <ebroder> Anybody backporters around willing to sign off on bug #216761?
[11:08] <scapor> Could someone tell me where the data in the user's home of a persistent live usb (created with usb-creator) is stored? there's no other partition created, no /home on the usb stick's one partition
[11:09] <scapor> and an empty /home in the sqaushfs
[11:10] <soren> scapor: There's a file on the usb stick that holds the filesystem overlay.
[11:10] <soren> I forget what it's called. casper-rw, perhaps.
[11:10] <tdmackey> yeah, casper-rw
[11:11] <tdmackey> in the root directory
[11:11] <scapor> I see. And that's sqaushfs too, then ? :)
[11:11] <tdmackey> tells how much reserved space there is for persitent storage
[11:12] <scapor> oh it's a ext3 partition I see
[11:12] <scapor> tdmackey: soren: thank's very much :)
[11:15] <tkamppeter> pitti, can you pass through the SRU package of bug 365329? Thanks.
[11:26] <soren> scapor: Sure.
[11:33] <pitti> tkamppeter: please reupload with correctly wrapped changelog (too long line)
[11:35] <maxb> What is the official line length, ooi? /me can't find an exact statement in debian-policy
[11:37] <pitti> lintian uses 79 or so
[11:38] <soren> I tend to wrap at 72. It be pleasin' to me eyes.
[11:40]  * soren doesn't know why he got all piratey all of a sudden
[11:41] <slangasek> a vitamin C deficiency?
[11:41] <dholbach> must be scurvy :)
[11:43] <bigon> is the procedure to request package remove written somewhere?
[11:43] <slangasek> create a bug on the package, give a reason, subscribe ubuntu-archive
[11:43] <slangasek> bigon: ^^ written there ;)
[11:44] <bigon> :)
[11:44] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing%20Packages
[11:44]  * dholbach makes sure it's linked from https://wiki.ubuntu.com/UbuntuDevelopment/KnowledgeBase
[12:19] <kumarabhi> hey people
[12:19] <kumarabhi> is there any bounty programme from ubuntu for  studen developers
[12:19] <kumarabhi> student developers
[12:21] <tkamppeter> pitti, can I use the same version number or do I have to bump it?
[12:21] <pitti> tkamppeter: same number is fine
[12:28] <slangasek> StevenK: you haven't killed hildon-fm-l10n yet... :)
[12:28] <StevenK> Hm. I'll do that now.
[12:29] <tkamppeter> pitti, s-c-p reuploaded.
[12:51] <dpm> hi pitti, I've got a question on langpacks when you've got a minute
[12:51] <dpm> I'm trying to find out the status of a translation not from Rosetta but from the langpack sources.
[12:51] <pitti> dpm: hi! just ask
[12:51] <dpm> I have tried to find the language-pack-gnome-mk-base from here -> https://edge.launchpad.net/~ubuntu-langpack/+archive/ppa?field.name_filter=mk&field.status_filter=published&field.series_filter=hardy , but they don't seem to be there. Is there a location where I can find those -base packages?
[12:52] <pitti> dpm: what do you mean by "find the packages"?
[12:52] <pitti> apt-get source?
[12:52] <pitti> dpm: what are you trying to do?
[13:00] <dpm> pitti: I'm trying to find out the status of a given translation for Hardy in a more or less accurate way. Therefore, I'm not looking at the Rosetta stats, but at the data from the last released langpacks. I've first gone the apt-get source way, but I noticed that depending on the language, a given translation had less strings than others, and in any case they seemed to differ from the Rosetta template. Then danilo told me that there is some
[13:00] <dpm>  post-processing going on after the PO files are extracted from Rosetta (such as removal of duplicate strings) ...
[13:01] <pitti> dpm: apt-get source will give you the exact data that is shipped in a release
[13:01] <pitti> dpm: we don't do any post-processing _in_ the source packages' build process
[13:01] <pitti> just some to create these source packages
[13:02]  * pitti -> lunch, bbl
[13:03] <dpm> pitti: ok, I'll ask you some more later, enjoy your meal!
[13:03] <slangasek> dpm: if you need answers sooner, there may be others in the channel who can help answer
[13:03] <slangasek> (I know a bit about langpacks, though I'm not an expert)
[13:04] <ogra> god, when did the ArchiveAdministration wikipage grow so much
[13:04] <dpm> slangasek: thanks, I can wait. I think in the case of langpacks pitti and ArneGoetje are the experts, though
[13:05] <slangasek> they are
[13:05] <slangasek> but you needn't treat them as a bottleneck for everything :)
[13:06] <ogra> slangasek, so its your day today, could you take care for bug 369159 ? seems that slipped through the recent syncs
[13:06] <ogra> pfft
[13:06] <slangasek> ogra: it did not...
[13:06] <ogra> hmm, why dont i see it on any ML
[13:07] <slangasek> at a guess, because StevenK accidentally included in a NOMAIL flush-syncs batch
[13:07] <ogra> ah
[13:07] <ogra> we have that ?
[13:07] <ogra> ok
[13:08] <slangasek> yes, it's what's supposed to be used for all autosyncs
[13:08]  * ogra wonders how he missed the bugmail ... at least i have that
[13:09] <ogra> why are you up already btw ? :)
[13:10] <slangasek> so that I can get my archive day done before Europe has a chance to fill the queue with even more stuff. >:)
[13:10] <ogra> heh
[13:18] <mdke> pitti: re your last comment on bug 366098, do you mean "jaunty" instead of "karmic"?
[13:19] <slangasek> no, he means karmic
[13:20] <slangasek> of questionable import in the case of ubuntu-docs, but it was copied nonetheless :)
[13:21] <mdke> slangasek: karmic already has a package with a higher version number, though
[13:21] <calc> hi
[13:21] <mdke> slangasek: does that not matter?
[13:21] <slangasek> mdke: in that case, the copy presumably failed ;)
[13:22] <mdke> slangasek: I don't know how it works. The bug isn't fixed in the karmic package with the higher version number, because it's not a bug in karmic
[13:22] <slangasek> correct
[13:22] <mdke> as long as it hasn't superceded the existing karmic package, I'm happy
[13:23]  * calc hugs slangasek for syncing all his packages :)
[13:23] <slangasek> it hasn't; I guess pitti overlooked the error message (as well as overlooking that it wasn't a karmic bug, of course)
[13:23] <mdke> ok, no worries then
[13:23] <mdke> thanks slangasek
[13:23] <slangasek> calc: get _rene_ to upload those to unstable, please, so we don't have to do that manually again :)
[13:26] <calc> slangasek: ok... he is going to once he decides to actually upload OOo 3.1.0 to unstable :\
[13:26]  * slangasek nods
[13:34] <TheMuso> Are any build admins able to kick the amd64 build of alsa-lib back into gear? Its a chroot problem, but appears to be due to locking issues which don't seem to be a problem for other builds now.
[13:35] <mdz> pitti: I'm trying to work up a patch for bug 316215.  can you point me to some information about access_control.* and how it works?
[13:35] <mdz> what I want is to make the path in linux.device_file read/writable by the user
[13:36] <mterry> slangasek: Thanks for the pm-utils patch fixups!
[13:38] <slangasek> mterry: sure thing :)
[13:55] <pitti> dpm: re
[13:56] <pitti> mdke: I copied it from jaunty-proposed to jaunty-updates and karmic
[13:56] <pitti> mdke: ah, I remember (sorry, too much SRU stuff this morning); this should be reopened, of course
[13:57] <slangasek> pitti: no, it shouldn't, it wasn't a bug in karmic at all
[13:57] <slangasek> the bug was "document includes an 'unreleased' watermark", and karmic isn't released... :)
[13:58] <pitti> slangasek: right, but it should be kept as a RC bug as a reminder to do it *before* karmic's release this time
[13:58] <dpm> pitti: thanks. Going back to the question: I'm trying to compare the status of the translation of e.g. gnome-terminal in two different languages. I see that in Rosetta the template has got 483 strings, and both translations are 100% complete. However, when I apt-get source the langpack for each language, one PO file has got 472 strings and the other 467. In any case, none of them has got the 483 strings from the original template.
[13:59] <dpm> pitti: 1) Why do the 100% translated PO files have a different number of strings and also differ in number from the Rosetta template? (I know that this does not pose any kind of problem, I'm just trying to understand why)
[13:59] <slangasek> pitti: I don't think a bug is the right way to track things that are supposed to be part of the release process
[13:59] <pitti> slangasek: if we move it there, that works for me as well
[13:59] <pitti> aside from the fact that I question the entire idea of this watermarking in the first place
[14:00] <pitti> after all, everything in karmic is a "draft" until we release
[14:00] <slangasek> I was rather surprised that this wasn't in the process checklists already
[14:00] <pitti> dpm: are you getting the ones from hardy-proposed, hardy-updates, or hardy final?
[14:02] <dpm> pitti: hardy-updates
[14:04] <pitti> mdz: http://people.freedesktop.org/~david/hal-spec/hal-spec.html#access-control is the initial documentation
[14:04] <geser> doko: do you know why python-distutils.mk from cdbs (karmic) renames dist-packages to site-packages?
[14:05] <pitti> mdz: there is an existing patch which adds ACLs for smartcard readers: http://bazaar.launchpad.net/%7Eubuntu-core-dev/hal/ubuntu/annotate/head%3A/debian/patches/02_smart_card_readers_acl.patch
[14:06] <doko> geser: what is python-distutils.mk?
[14:07] <geser> doko: /usr/share/cdbs/1/class/python-distutils.mk
[14:08] <doko> geser: see above, answered to pitti as well. packaging *.install files expect these in site-packages
[14:09] <mdz> pitti: thanks
[14:10] <mdz> pitti: what defines the meaning of access_control.type=smart-card-reader?
[14:11] <pitti> mdz: it's just a human readable identifier which binds together the policy (who has access) in the .policy file with the subject (device file, in the fdi)
[14:12] <geser> doko: do we still need to modify packages for the python2.6 transition with all this automatic renaming done by the different packaging helpers?
[14:13] <mdz> pitti: ah, and "active" and "inactive" in the .policy refer to active user and inactive user?
[14:13] <pitti> mdz: console session, but that by and large maps to user, yes
[14:13] <mdz> pitti: so access_control.type=foo maps to org.freedesktop.hal.device-access.foo ?
[14:13] <pitti> mdz: right
[14:14] <mdz> pitti: can you give me a hint as to whether I should create a new type or if an existing one is appropriate?
[14:14] <pitti> mdz: looking at /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
[14:15] <DnaX> please fix bug #340718! I've post a patch before final release.
[14:15] <doko> geser: if a package ftbfs, yes
[14:15] <pitti> mdz: well, portable_audio_player wouldn't be entirely wrong
[14:15] <pitti> or camera
[14:16] <pitti> mdz: ah, hang on, there's "PDA"
[14:16] <DnaX> this package fail to install and irda do not work automatically
[14:16] <mdz> pitti: that reminds me of another bug which i haven't looked for / filed yet...when I plug in the G1, I get multiple popups (music player, camera).  technically correct, but not very helpful
[14:17] <mdz> pitti: PDA seems to imply a palm-like sync interface though
[14:17] <pitti> mdz: I noticed that, too; I just didn't see an obvious way to fix it
[14:18] <mdz> this stuff is closest:
[14:18] <mdz>     <!-- support for Linux USB stack where linux.device_file is set (e.g. device node is on the main usb device) -->
[14:18] <pitti> mdz: not necessarily, that's just there for the Pam/pocketpc ones
[14:19] <pitti> mdz: in that block, portable_audio_player is closest then
[14:20] <mdke> pitti: we use the watermark for the doc.ubuntu.com website too. But I agree with slangasek that a bug is not the right way to remember this, since it will happen in releases after karmic too. I think the best way is to include it on a -doc specific release process list
[14:20] <mdz> pitti: the text in org.freedesktop.hal.device-access.policy wouldn't really be accurate though.  I don't know how big a problem that is
[14:20] <DnaX> pitti: have you see irda-utils bug?
[14:20] <mdz> "System policy prevents access to audio players"
[14:21] <pitti> mdke: works for me
[14:21] <DnaX> pitti: can you triage it?
[14:21] <mdke> pitti: ok, I'll do that then
[14:22] <pitti> mdz: that string is displayed if the admin sets the PK policy to "auth_admin"
[14:22] <pitti> mdke: it's not shown for "yes" or "no"
[14:22] <pitti> erm, mdz: ^
[14:22] <pitti> DnaX: I don't have any IR devices, and I'm quite busy ATM, sorry
[14:22] <mdz> pitti: then why are there so many entries with the same defaults (yes and no)
[14:23] <pitti> mdz: it's the upstream default, and we never cleaned it up
[14:23] <DnaX> pitti: I have it... and i've post a working patch for it!
[14:23] <pitti> mdz: basically, that allows an admin to say "my users can access a music player, but not an USB stick"
[14:23] <mdz> pitti: ok, just tell me what you recommend and I will submit a patch
[14:23] <pitti> DnaX: please subscribe ubuntu-main-sponsors then
[14:23] <DnaX> done
[14:24] <pitti> mdz: string-wise, PDA still sounds closest to me
[14:24] <pitti> DnaX: thanks
[14:36]  * zhxk wants know if there are any ready made pakages in depo to ubuntu
[14:37]  * zhxk wants know if there are any ready made pakages in depo to ubuntu about arm cross-build-chains
[14:38] <ikonia> zhxk: you'll have to build your own tool chain to cros-compile
[14:40] <zhxk> ikonia:well, i encontered a problem to it  http://pastebin.ca/1412096
[14:40] <zhxk> its logs to (export,config,make)
[14:41] <zhxk> to e2fsprogs
[14:43] <ikonia> zhxk: that's nothing to do with ubuntu development
[14:59] <zhxk> ikonia:which channel should i ask?
[14:59] <ikonia> zhxk: no idea, but it's nothing to do with ubuntu
[15:00] <pitti> dpm: the hardy-updates are from January, perhaps the mk translations weren't that complete at that time?
[15:02] <zhxk> ikonia:thanks all the same
[15:02] <ikonia> no problem
[15:02] <persia> zhxk, You may want to ask in #ubuntu-arm, while we don't do cross-compilation, someone there may have more useful information.
[15:02] <zhxk> persia:thanks a lot
[15:05] <dpm> pitti: If I understand it correctly, the mk translation was complete at the time, the only thing I cannot understand is the difference in the number of actual strings (msgid) in the template (Rosetta) and in the PO file (langpack source package). The PO file in the langpack tarballs seem to have the same number of strings as the Rosetta templat, though. In any case, I think I'll try to follow this up in an e-mail and I'll provide the links
[15:05] <dpm> to the exact files I'm looking at, which will be easier
[15:06] <tkamppeter> pitti, did you see my s-c-p re-upload?
[15:06] <pitti> tkamppeter: yes, I did
[15:07] <pitti> dpm: okay
[15:08] <kirkland> pitti: okay, thanks for the headsup
[15:13] <directhex> it's an ikonia!
[15:28] <dholbach> al-maisan_: congratulations to your upload to Ubuntu :)
[15:28] <al-maisan_> dholbach: thanks :) it's a pleasure to contribute :)
[15:28] <dholbach> :-)
[15:39] <ogra> slangasek, when do you plan the first dailies again ?
[15:39] <slangasek> ogra: tomorrow
[15:40] <slangasek> (but they'll probably fail to build, the installer's not merged up yet)
[15:40] <ogra> good (i just got the responsibility for alpha1 mobile images assigned)
[15:40] <ogra> yeah, i wouldnt expect them to build yet
[15:41] <ogra> mako, you dont happen to be around, do you ?
[15:54] <dholbach> tjaalton, bryce: anything Andreas can do to make bug 352708 more useful?
[16:07] <kirkland> cjwatson_: hey, one more ssh auth question ... i assume that the message the client signs to verify its identity is some randomly generated different signature every time, right?  (else replays would be possible)
[16:25] <soren> kirkland: It's a blob of data consisting of the session id and some other tidbits, yes.
[16:39] <dholbach> can somebody please shove ibus through binary new? :)
[16:41] <james_w> dholbach: it's not built has it?
[16:42] <dholbach> ah, so it's through new, but not built yet, ok :)
[16:42] <dholbach> thanks james
[16:42] <kirkland> pitti: hey
[16:42] <james_w> dholbach: binary NEW after building I think
[16:42] <kirkland> pitti: am i correct in remembering you being the person who is anti-/etc/groups ?  :-)
[16:43] <kirkland> pitti: i was thinking about for Karmic making /sbin/mount.ecryptfs_private perm'd 4750, and adding an ecryptfs group
[16:43] <pitti> kirkland: I am, yes :)
[16:43] <kirkland> pitti: currently, any user can created an encrypted-private dir
[16:43] <kirkland> pitti: which means that users could, say, "hide" data from the sysadmin, perhaps
[16:43] <dholbach> james_w: ok, I'll shut up and wait then :)
[16:44] <pitti> kirkland: I thought that was the point? :-)
[16:44] <kirkland> pitti: fedora is shipping ecryptfs with a patchset that restricts this to users the admin puts in the ecryptfs group
[16:44] <kirkland> pitti: yeah, well, RHEL got some customer complaints, evidently!
[16:45] <kirkland> pitti: users in the ecryptfs group can continue to "hide" data from root, but not everyone, necessarily
[16:46] <kirkland> pitti: i guess my question to you is, how would i solve this without a group?
[16:46] <kirkland> pitti: is this something that PolicyKit is cut out to do?
[16:46] <pitti> kirkland: you can add a PK check to ecryptfs.mount if you wanted to
[16:47] <kirkland> pitti: what does that look like?
[16:47] <pitti> kirkland: my main crusade was to stop people from using groups for device access
[16:47] <kirkland> pitti: ah!
[16:47] <pitti> kirkland: for your use case, a group is less evil
[16:47] <kirkland> pitti: so a group might actually be "okay" for this?
[16:47] <pitti> kirkland: but I don't think you'd want to deny it by default, do you?
[16:47] <kirkland> pitti: less evil, heh :-)
[16:47] <pitti> kirkland: well, adding a group is still an excuse for us to push work to an admin
[16:47] <kirkland> pitti: right, this is going to be a really tough one, particularly for upgrades
[16:48] <pitti> kirkland: upgrades> don't even think about it
[16:48] <pitti> kirkland: you can't add users to groups on upgrades
[16:48] <kirkland> pitti: ideally, there would be an existing group that we already use, that I could piggy back onto
[16:49] <kirkland> pitti: i think 'admin' is not the right one, though
[16:49] <kirkland> pitti: i think i might make it a really, really low priority debconf question
[16:50] <kirkland> pitti: "Do you want to restrict eCryptfs use to members of 'ecryptfs' only?"
[16:50] <kirkland> pitti: default in Ubuntu is "no"
[16:50] <pitti> kirkland: that wouldn't help us, though
[16:50] <kirkland> pitti: but fascist sysadmins can preseed that "yes", or change it later
[16:50] <pitti> kirkland: since you can't have a group "no-ecryptfs"
[16:51] <kirkland> pitti: well, i worded that question poorly
[16:51] <pitti> kirkland: seriously, a fascist sysadmin could just dpkg-statoverride mount.ecryptfs
[16:51] <kirkland> pitti: really, it's just about the setuid binary
[16:51] <kirkland> pitti: which is mount.ecryptfs_private
[16:51] <pitti> kirkland: no, but you want users who currently run ecryptsfs to continue to do so after an upgrade
[16:51] <kirkland> pitti: not the generic mount.ecryptfs
[16:51] <kirkland> pitti: right, which is why the question would be low priority, and the default value would be our current policy
[16:52] <kirkland> pitti: which would keep that setuid binary 4755
[16:52] <kirkland> pitti: the fascists can make it 4750
[16:52]  * kirkland decides that 'fascist' isn't particularly accurate, when describing this class of sysadmin
[16:53] <pitti> kirkland: ah, I see
[16:53] <pitti> kirkland: but those kind of sysadmin can probably also use statoverride themselves
[16:53] <kirkland> pitti: it's really just about the encrypted-private, encrypted-home
[16:53] <pitti> kirkland: but well, your call
[16:53] <pitti> kirkland: as long as it doesn't involve putting users into that group _by default_, it's okay with me
[16:53] <kirkland> pitti: well, i didn't know that -stateoverride existed, or what it did, until i just manpaged it
[16:54] <kirkland> pitti: yeah, i don't think we add any users in that group by default
[16:54] <kirkland> pitti: if the admin chooses to go with mount.ecryptfs_private at 4750, then it's up to them to add users to that group
[16:55]  * slangasek envisions a nanog logo involving a fasces
[16:55] <kirkland> ||)
[16:55] <kirkland> ||*
[16:56] <kirkland> slangasek: i like the asterisk one better ;-)
[16:56] <slangasek> heh
[16:57] <kirkland> pitti: cool, thanks for your ideas
[16:57] <kirkland> pitti: i think i know how we're going with this
[16:58] <pitti> kirkland: great, thanks for the discussion
[17:07] <kirkland> cjwatson_: i'm curious what you think about https://bugs.launchpad.net/bugs/371719, if this might be acceptable for Karmic
[17:58] <savvas> pitti: here? do you think I should file a bug at debian about libmtp package still using a link? and for the proper prefix?
[17:58] <pitti> savvas: Debian is moving towards udev rules in /lib/ as well, so they should just do that
[18:00] <savvas> pitti: sorry I'm confused :) you mean I shouldn't and just keep the patch as it is in ubuntu, right?
[18:04] <pitti> savvas: oh, Debian should by all means fix their package as well
[18:04] <pitti> savvas: but we shuold keep the ubuntu one as it is for now, yes
[18:05] <pitti> savvas: basically, debian could take our patch (and update the version numbers in the comparison adequately)
[18:05] <savvas> ok trying right now then, I'll let you know if a few minutes
[18:05] <pitti> savvas: no hurry; I need to leave in 30 mins, I won't get to sponsoring it today anyway
[18:06] <savvas> ok then :)
[18:19] <savvas> those preinst / postinst are really twisted scripts, but gooooood :) I got the hang of it, no changes required, conf files and packages will be properly upgraded
[18:21] <savvas> (I mean no changes required on my behalf)
[18:31] <pitti> savvas: no; the main point of the merge is to send the patch to Debian, so that eventually we can sync again
[18:32] <pitti> savvas: also, would you have time to integrate the other patch I mentioned?
[18:32] <pitti> good night everyone, see you all tomorrow
[18:33] <savvas> pitti: I'll check that out as well, I'll let you know through the bug report
[18:38] <rtg> kees: I've updated the kernel flavours blueprint https://wiki.ubuntu.com/KernelTeam/Specs/KarmicKernelFlavours and referenced one that you wrote a year ago.
[18:43] <kees> rtg: ah-ha, cool.
[18:43] <kees> rtg: instead of the current one?
[18:43] <rtg> kees: I'm not sure what you mean.
[18:44] <kees> https://blueprints.edge.launchpad.net/ubuntu/+spec/security-karmic-pae-desktop instead of the other one since the other was already scheduled for the last UDS
[18:44] <geser> doko: any idea how to resolve the FTBFS of cerealizer in karmic? the problem is that cdbs renames the dist-packages back to site-packages, but the testscript adds get_python_lib() prefixed with debian/cerealizer to find the modules which fails as the files are at this point in site-packages and not dist-packages
[18:44] <geser> doko: http://launchpadlibrarian.net/26117036/buildlog_ubuntu-karmic-i386.cerealizer_0.7-3_FAILEDTOBUILD.txt.gz
[18:45] <rtg> kees: I just referenced yours since it was apropo wrt PAE, but my spec also covers other topics.
[18:45] <kees> rtg: also, why do lpia and armel get -$arch instead of -generic
[18:45] <kees> rtg: okay, but I'd like to make sure that the cs-limit nx-emulation stuff gets in too.
[18:45] <rtg> actually, they $flavour
[18:45] <rtg> they get $flavour
[18:46] <kees> rtg: and why "generic-pae" instead of just "pae"
[18:46] <rtg> kees: the names are open for discussion. perhaps 3gb is more appropriate.
[18:47]  * kees nods
[18:47] <kees> "-allyourRAMisbelongtous"
[18:47] <elmo> I thought the cutoff for non-PAE was 2Gb? :-P
[18:47] <rtg> kees: my goal is to have the minimum difference between -generic and -generic-pae
[18:48] <kees> rtg: I don't know what the conventions are for UDS scheduling, but you might want to check if using +spec/use-pae-when-possible is correct (since it was last UDS)
[18:48] <elmo> umm, 4, rather
[18:48] <rtg> elmo: 1GB is reserved for mem mapped I/O stuff
[18:48] <kees> elmo: iiuc, it's only 3 because of how the kernel maps virtual memory.
[18:48] <maswan> elmo: minus whatever pci etc wants, and then kernel/userland split
[18:48] <maswan> elmo: We got 3.5GB on our machines, back in the days before real pointers
[18:49] <kees> rtg: -generic vs -generic-pae> yeah, I'm all for it being just a single CONFIG difference.  :)
[18:49] <maswan> but anyway, 32-bit stuff has been obsolete for close to 5 years now anyway. ;)
[18:49] <elmo> maswan: haha
[18:50] <kees> rtg: and what're your current thoughts on cs-limit?
[18:51] <rtg> kees: um, ambivalent. Its an ugly patch but I'm probably gonna add it. I _would_ like to see some evidence that it might have prevented past abuses.
[18:51] <kees> rtg: I can certainly go find some example exploits that don't work as a result of cs-limit nx-emulation.
[18:52] <rtg> kees: that would certainly help bolster credibility for the patch
[18:52] <kareem> hello
[18:52] <kees> rtg: if it helps, nearly all security vulnerability research starts with "and if we turn off NX, [example]".
[18:52] <kees> rtg: all the stuff about how to avoid ASLR, stack canaries, etc, all depend on NX being non-functional.
[18:53] <kareem> Would this qualify as a Q for here?  I'm trying to make an Ubuntu package for FreeSWITCH, and when I test it, I keep getting: "E: Internal Error, Could not perform immediate configuration (2) on g++-4.2"  No one in any other Ubuntu channels I've been in can figure it out.
[18:53] <kees> rtg: shall I send it to the kernel-team thread?
[18:53] <rtg> kees: I've got no problem with NX, its just that the cs-limit emulation is a bit of a hack (but understandable given HW limits)
[18:53] <rtg> kees: yes- the k-t list is appropriate
[18:54] <kees> rtg: well, cs-limit == NX for people lacking NX hardware, so basically, all exploits that work when NX is missing are protected by cs-limit nx-emu
[18:54] <rtg> kees: true, it is page granular.
[18:55] <kees> rtg: do you still want examples?  it's an entire class of vulnerabilities, so I thought it'd be an obvious protection.
[18:55] <ogra_> heh ... that abbreviation is used way to often /me just thought of nx-server/client
[18:55] <rtg> kees: it may be obvious to you, but a list of examples wouldn't hurt.
[18:55] <kees> rtg: okay
[19:18] <cody-somerville> My ssh-agent seems to have been replaced with one that has an icon of a weird looking fish
[19:18] <cody-somerville> I thought I remember reading about this in a changelog
[19:18] <cody-somerville> Can anyone jot my memory?
[19:23] <Pici> cody-somerville: seahorse?
[19:23] <cody-somerville> I'd like to use seahorse
[19:30]  * zhxk runs away
[19:44] <LaserJock> is there an easy way to determine what the default python version is for a given release?
[19:44] <geofft> packages.ubuntu.com/python
[19:45] <LaserJock> geofft: thanks, that was easy :-)
[19:48] <geser> LaserJock: you can also run "python --version" (assuming a supported setup)
[19:48] <LaserJock> yeah, I just didn't have chroots available for the releases I wanted
[19:52] <LordMetroid> Does the launchpad automatically forward bug reports upstream?
[19:53] <geser> LordMetroid: no
[19:54] <LordMetroid> Damn, why not? It ought to, it is so convenient to report bugs for anything in one place
[19:56] <geser> one reason is that the bug might be due to Ubuntu changes, another reason that not every bug is really a bug but an user-error and upstream won't be happy if we auto-forward those bugs too
[19:56] <geser> I guess there are more reasons against it
[19:56] <LordMetroid> So what do I do with this:  https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/371819 ?
[19:56] <LaserJock> upstreams not wanting automatic bugs from LP comes to mind
[20:02] <geser> LordMetroid: forward the bug to the gimp bugtracker yourself and add a bugwatch to the bug in LP
[20:02] <LordMetroid> ok... I'll try to do that
[20:03] <geser> I guess some upstream prefer to have a human contact to a bug instead of some script (another reason against automatic bug-forwarding)
[20:15] <LordMetroid> Bugwatching is more intersting then birdwatching...
[20:23] <mrooney> Would anyone be kind enough to whitelist me on the ubuntu-devel list?
[20:24] <cody-somerville> mrooney, Are you a Ubuntu developer?
[20:25] <mrooney> cody-somerville: I am not familiar with the official definition of that :)
[20:25] <cody-somerville> mrooney, Are you a member of the ubuntu-dev or ubuntu-core-dev teams on launchpad?
[20:25] <mrooney> As I understand it anyone can be whitelisted if they have a history of reasonable posts
[20:25] <mrooney> cody-somerville: nope
[20:26] <cody-somerville> mrooney, You might try e-mailing an administrator of the list
[20:26] <cody-somerville> mrooney, Or try your luck and see if the right people see your message above
[20:27] <mrooney> cody-somerville: yeah I have seen someone successfully ask here so I thought I'd try as well :)
[20:35] <kirkland> jcastro: yo
[20:35] <kirkland> jcastro: got your email about ec2+screen
[20:35] <kirkland> jcastro: try the new screenbin
[20:35] <kirkland> jcastro: i put everything you need in there
[20:35] <jcastro> ok
[20:35] <kirkland> jcastro: you'll need to install Karmic's deb on your Jaunty system
[20:35] <kirkland> jcastro: give that a try, and let me know how it works for you
[20:36] <jcastro> likely tomorrow before I prep for a talk on s-p
[20:36] <kirkland> jcastro: neat
[20:36] <kirkland> jcastro: who are you talking to?
[20:37] <kirkland> jcastro: btw ... kees patched screen itself to fix one annoyance, where someone trying to type in their read-only session will cause a 'bell' or ding-message to all other users
[20:38] <kirkland> jcastro: i built that in the screen-profiles ppa for hardy/intrepid/karmic
[20:38] <kirkland> jcastro: you'd probably want that package on your host :-)
[21:08] <thebloggu> my network manager applet is taking too long (like 2-3 min) to recognize my wireless card (not even connect to network, just recognize the card only) on boot. it is possible it is a bug or maybe i am missing something. using openbox if it is relevant
[21:17] <pace_t_zulu> can someone help me will pbuilder?
[21:17] <pace_t_zulu> i have a problem with unmet dependencies on a build
[21:18] <pace_t_zulu> i have read https://wiki.ubuntu.com/PbuilderHowto
[21:18] <pace_t_zulu> but i can't find a way to resolve the issue
[21:27] <pace_t_zulu> can someone help me figure out how to fix unresolved dependencies in debuild and/or pdebuild?
[21:32] <pwnguin> pace_t_zulu: unresolved dependencies?
[21:33] <pwnguin> as in, the build deps aren't installable?
[21:33] <pace_t_zulu> pwnguin: yeah i figured pbuilder would handle it better
[21:33] <pace_t_zulu> pwnguin: no, the build can't happen
[21:33] <pace_t_zulu> pwnguin: i think it is specific to this package
[21:33] <pace_t_zulu> pwnguin: i am trying to put together a patch
[21:34] <pwnguin> if you have an error log, that might help to pastebin. but right now i have to run the vacuum =(
[21:37] <maco> thebloggu: see if it's showing up in hal during that 2-3 minute wait
[21:38] <thebloggu> maco, how can i do that ?
[21:38] <maco> lshal...
[21:38] <pace_t_zulu> pwnguin: http://pastebin.ubuntu.com/164447/
[21:39] <maco> (by the way, #ubuntu-bugs might be a good place for debugging...or #nm for that matter)
[21:39] <thebloggu> maco, wow enourmous :P it will be difficult to test it because it is on boot
[21:39] <thebloggu> right after start
[21:40] <maco> thebloggu: log in, run "lshal >> lshal.out" and then read through at your leisure to see if your wirless card is listed
[21:40] <maco> (it'll put the output in a file called lshal.out)
[21:42] <thebloggu> maco, ok, i'll test it and i'll bring the results here
[21:43] <maco> #nm would be better
[21:43] <maco> since they know how this stuff all works and all i know "it gets info from hal" ;)
[21:46] <pace_t_zulu> pwnguin: did you get that pastebin?
[21:48] <pwnguin> yea
[21:49] <pwnguin> pace_t_zulu: so it's complaining that ipython isn't installable
[21:49] <pwnguin> pace_t_zulu: by chance, is this a patch for a package in universe?
[21:51] <pace_t_zulu> pwnguin: let me check
[21:52] <pace_t_zulu> pwnguin: indeed it is
[21:52] <pwnguin> then #ubunt-devel isn't the right place to chat about the patch :)
[21:53] <pwnguin> #ubuntu-motu handles universe packages
[21:53] <pwnguin> lets move the conversation to there, and stop bothering core developers :)
[22:46] <pace_t_zulu> pwnguin: you here?
[23:26] <tkamppeter> pitti, hi