=== dendro-afk is now known as dendrobates
[00:27] <Drakeson> is there a guideline or some such that explains what the client-side-decorations patch (against libgtk2.0) does and what APIs have changed?
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
[02:16] <SoftwareExplorer> I bzr get'ed the softwareproperties source and fixed two depreciation warnings. Then I did a commit, but now I'm a little confused how I would publish my branch to launchpad. My launchpad username is erik-b-andersen.
=== jtechidna is now known as JontheEchidna
[02:31] <CynthiaG> SoftwareExplorer: Do you have a branch?
[02:32] <CynthiaG> Registered for yourself on Launchpad, I mean.
[02:32] <wgrant> SoftwareExplorer: You can just say 'bzr push lp:~erik-b-andersen/softwareproperties/SOME-DESCRIPTIVE-NAME'
[02:34] <SoftwareExplorer> I do have a launchpad account. I think I figured out how to do the bzr push thing. (Thanks wgrant for the advice though) Now I'm wondering what the official process is to get my branch merged.
[02:35] <CynthiaG> go to your branch page and hit "propose for merge", then link it to the bug reports it's meant to fix
[02:36] <SoftwareExplorer> CynthiaG: I didn't report a bug, I just noticed the bug and thought I might be able to fix it since it was in python, got the source and fixed it. Should I try to find a bug or file one?
[02:37] <CynthiaG> for such things as warnings, I don't know if you should file a bug or just propose the merge
[02:38] <CynthiaG> post about it on ubuntu-devel-discuss or wait here ~7 hours for someone at Canonical to be there (Euro timezone and start of the work week)
[02:39] <SoftwareExplorer> CynthiaG: What would happen if I propose a merge. Then if I find a bug can't I just mark my branch as fixing it?
[02:40] <CynthiaG> you could do that
[02:40] <CynthiaG> in the bug report, there's also a "link to a branch" option, so you would hit that and add a comment saying "the linked branch fixes this bug"
[02:40] <SoftwareExplorer> CynthiaG: Ok, thanks. I think that's what I'll do then.
[02:41] <CynthiaG> SoftwareExplorer: mk :)
[02:41] <CynthiaG> Wait a minute
[02:42] <CynthiaG> Do you mean "if I find a bug" about the DeprecationWarning, or "if I find a bug" about anything related to softwareproperties?
[02:42] <SoftwareExplorer> CynthiaG:I meant if I find a bug about the two depreciation warnings.
[02:43] <CynthiaG> ok, good - that was just me getting confused a bit
[05:09] <andersk> Are new Debian packages being synced into Maverick automatically, or only updated existing packages?
[05:10] <ScottK> andersk: New ones too, but it's a seperate process that is done less frequently.
[06:43] <hagabaka> Is anyone associated with x-edgers? I am trying to enable r300 gallium on ubuntu using https://launchpad.net/~xorg-edgers/+archive/ppa/ , but after installing the packages and restarting, glxinfo still doesn't say anything about gallium.
[06:48] <Sarvatt> hagabaka: #ubuntu-x
[06:50] <Sarvatt> i run the ppa, will help you out over in that channel
[07:49] <CynthiaG> I just tried the Maverick daily from 2010-06-11 to speed-test it, and the laptop won't boot it :(
[08:00] <mneptok> CynthiaG: #ubuntu+1 please
[08:00] <CynthiaG> Well, this was on-continuous-topic from my prior development on the LiveCD optimisations
[08:00] <CynthiaG> Sorry though
[08:07] <mneptok> CynthiaG: are you looking for support, or to debug it yourself and submit a fix?
[08:08] <CynthiaG> I'm not looking to do anything, because in the time it took me between downloading the daily and trying it out, things may have changed
[08:08] <lifeless> mneptok: CynthiaG is doing dev
[08:08] <lifeless> mneptok: for all that it sounded a bit +1ish :P
[08:08] <CynthiaG> if you want to take a look at what I'm doing, see bug 589629 :)
[08:08] <ubottu> Launchpad bug 589629 in debian-cd (Debian) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629
[08:09] <CynthiaG> cjwatson gave the daily builds the bootchart package, and I was starting Maverick-20100611 to see that
[08:09] <CynthiaG> unfortunately it didn't start
[08:09] <mneptok> CynthiaG: there's no need for that. your initial comment is precisely the kind of support questions -devel gets, and shouldn't.
[08:09] <CynthiaG> Am I off to a bad start in here then?
[08:10] <mneptok> CynthiaG: not in the least.
[08:10] <CynthiaG> Cool :)
[08:11] <mneptok> CynthiaG: there's coffee, donuts, and some half-baked x86 assembly on the table in the corner. help yourself. ;)
[08:11] <CynthiaG> And now re-reading the mksquashfs order file, I see that I have a gnome-specific entry in there; I ideally want this optimisation to work equally well in gnome, kde and xfce :\
[08:11] <pitti> Good morning
[08:12] <CynthiaG> I'm not that fond of coffee :) Thanks for the donuts and the x86 assembly, though! Careful, however, because I might want to optimise it with SSE2 :P
[08:12] <CynthiaG> Good morning pitti
[08:13] <pitti> lifeless: because we switched over to lp:ubuntu/pm-utils-powersave-policy and dropped the custom branch
=== mpt_ is now known as mpt
[08:13] <mneptok> CynthiaG: pfffft ... all the cool kids use PNI
[08:14] <dholbach> good morning
[08:15] <CynthiaG> mneptok: then I must not be a cool kid :) and AcronymFinder isn't helping much with this one
=== hrw|gone|lt is now known as hrw
[08:26] <hrw> morning
[08:35] <lifeless> pitti: so the vcs-bzr line should say lp:ubuntu/pm-utils-powersave-policy
[08:35] <lifeless> pitti: it *still has* a vcs location, doesn't it ?
[08:35] <pitti> lifeless: but that's the implied default anyway?
[08:36] <lifeless> pitti: not AFAIK
[08:36] <lifeless> pitti: apt-get source looks at the header
[08:36] <pitti> all packages are supposed to be available like that
[08:36] <pitti> well, many aren't, but that's a bug, not by design
[08:37] <lifeless> pitti: I know, but partner etc won't be
[08:37] <pitti> right
[08:37] <lifeless> pitti: was dropping the header discussed at UDS? I think this needs more thought if it wasn't.
[08:37] <pitti> I don't think it was
[08:38] <pitti> but for packages where we never had a custom branch and just started using the canonoical one we didn't add it either
[08:38] <lifeless> pitti: I'm quite sure our toolchain doesn't default to lp:ubuntu
[08:38] <pitti> apt-get source doesn't, right
[08:38] <lifeless> pitti: could you raise this on ubuntu-devel/u-d-d, or would you like me to ?
[08:39] <pitti> OTOH modifying all packages with a valid import to have a vcs-bzr: seems like a huge effort
[08:40] <pitti> lifeless: sure, go ahead
[08:40] <pitti> but there must be a better way than adding a canonical vcs-bzr everywhere
[08:40] <pitti> unmodified packages have vcs-* from Debian, etc.
[08:41] <pitti> it'd probably be more elegant if a branch could somehow be marked as "valid" or "being used" by a developer, and apt-get source could check that
[08:41] <pitti> a lot of auto-imports are obsolete/broken, those wouldn't be marked then
[08:41] <pitti> OTOH this could be automated as well
[08:41] <pitti> debian/changelog first line -> match version on LP
[08:43] <pitti> lifeless: FYI, for the particular case of pm-utils-p-p it doesn't really matter, the pacakge will be obsoleted by the next pm-utils upload
[08:56] <pitti> cjwatson: WDYT about http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/casper/maverick/revision/817 ? please feel free to revert if you don't like it
[08:57] <lifeless> pitti: well we can look at a script ;)
[08:58] <lifeless> pitti: checkout; commit; done, for branch in lp:ubuntu/
[08:58] <lifeless> pitti: and the unmodified vcs-bzr from Debian is a really interesting thing to consider.
[09:00] <CynthiaG> not much improvement. should a 6-second improvement on boot over 2 minutes be pursued?
=== almaisan-away is now known as al-maisan
[09:18] <pitti> CynthiaG: two minute boot time sounds like a bug on itself
[09:19] <pitti> CynthiaG: I have the slowest possible hard disk on earth and it takes 50s for me (including logging into gdm and ecryptfs)
[09:19] <CynthiaG> pitti: even despite the commonly-known weakness ... oh wait
[09:19] <CynthiaG> you're talking about hard drives
[09:19] <CynthiaG> I'm talking about the LiveCD itself
[09:19] <pitti> ah, I see
[09:19] <CynthiaG> "even despite the commonly-known weakness ... of CD drives when it comes to seeking"
[09:20] <CynthiaG> boot is very noisy, even after changing the order of files around
[09:21] <pitti> CynthiaG: 6 s> I'd say it depends on how much effort it is; a two-minute fix in one package sounds like worth it; reengineering 30 packages for it doesn't
[09:22] <CynthiaG> pitti: it's about bug 589629, which I've been testing lately. It affects one file in livecd-rootfs, plus cjwatson's reordering of the squash file within the ISO so it falls to the end (edge) of the disc
[09:22] <ubottu> Launchpad bug 589629 in debian-cd (Debian) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629
[09:24] <mneptok> CynthiaG: PNI = Prescott New Instructions = SSE3
[09:25] <CynthiaG> mneptok: Ah :) I knew SSE3, but not PNI
[09:25] <mneptok> :)
=== lucas_ is now known as lucas
=== tkamppeter_ is now known as tkamppeter
[10:08] <lool> doko_: Around?
[10:22] <cjwatson> pitti: casper change is fine by me - wasn't there a bug report asking for that, in fact?
[10:24] <pitti> cjwatson: I tried to look at https://edge.launchpad.net/ubuntu/+source/casper/+bugs?batch=300 but didn't spot it
=== smb is now known as smb-afk
[11:31] <apw> can someone remind me which package had the volume key 'sticky-ness' work arounds in it
[11:34] <ScottK> pitti: Would you please rescore kdebase-workspace kdeedu (only affects ia64)?
[11:39] <cjwatson> apw: does the omap support in linux/maverick supersede the linux-ti-omap source package?  should we be removing linux-ti-omap from maverick, and rebuilding d-i against the omap flavour of linux?
[11:41] <apw> cjwatson, i believe that to be correct yes, let me confirm with ogra
[11:49] <pitti> ScottK: done
=== MacSlow is now known as MacSlow|lunch
[12:03] <apw> cjwatson, yes we should be dropping the separate omap source package in maverick
[12:17] <Q-FUNK> doko_: so you feel that the real issue is with the eglibc build scripts then?
[12:18] <Q-FUNK> doko_: the discussion on the FC bugzilla is convoluted, but did I uderstand this right that eglicb's build scripts are simply more efficient than average at passing optimization flags all the way down to GAS than most other libraries?
[12:36] <pitti> cjwatson: ok, new langpack-locales with using archive and updated scripts uploaded; works fine here, let's see what breaks :)
[12:40] <cjwatson> pitti: cool, thanks!
[13:02] <buxy> cjwatson, seb128: http://lists.debian.org/1276511250.4912.18.camel@seb128-laptop
[13:02] <seb128> buxy, ?
[13:02] <buxy> do you know what kind changes are needed and if/when they can be done?
[13:03] <seb128> buxy, the cdbs changes we have?
[13:03] <buxy> you make it sound like a big blocker
[13:03] <seb128> well, a reason for having diff over debian at least
[13:03] <seb128> right know if works well with cdbs when gnome.mk is used
[13:03] <seb128> because we modify the cdbs gnome.mk in ubuntu for what we need
[13:03] <seb128> which means no source change to do
[13:03] <seb128> but we can't do that with dh7
[13:04] <seb128> there is no standard include we can change this way
[13:04] <seb128> the code there basically do a few things like adding gettext domain to desktop entries
[13:04] <seb128> or cleaning gconf schemas
[13:05] <buxy> seb128: can you open some official launchpad bug and make sure someone is going to offer a solution for dh7 too?
[13:06] <seb128> buxy, we have a workitems from UDS for this already
[13:06] <seb128> so it's tracked
[13:06] <seb128> I'm just not sure how we can solve that in an elegant way though
[13:07] <buxy> "dh --with gnome"
[13:07] <seb128> buxy, one issue I've there is that changing the packaging system is not required when you take something packaged from Ubuntu and upload to Debian
[13:07] <seb128> buxy, well that would require having a sort of "gnome" debian would use for something yes
[13:07] <seb128> then to modify that rules in ubuntu
[13:07] <seb128> or to add a diff in ubuntu "--with gnome"
[13:08] <buxy> seb128: even if only an empty placeholder in debian for a start, I think it's fine
[13:09] <buxy> also I have submitted wishlist bugs against dh to be able to add new sequences without modifying the rules (just modifying the environment)
[13:09] <seb128> ok
[13:09] <buxy> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570935
[13:09] <ubottu> Debian bug 570935 in debhelper "debhelper: possibility to enable an addon with an environment variable" [Wishlist,Open]
[13:10] <buxy> seb128: can you give me a pointer to the work item in question?
[13:16] <seb128> buxy, I don't find it now, I think it was in the desktop team workflow changes for maverick discussion we had which didn't get converted in a proper spec, I will have it filed today and give you the bug number
[13:16] <buxy> seb128: thanks
=== dendrobates is now known as dendro-afk
[13:51] <mdeslaur> hmm...while running lucid, "update-manager -d" doesn't give me the update to maverick button...does anyone know why that is?
=== zul_ is now known as zul
[13:56] <soren> win 8
[13:56] <zul> mdeslaur: did you talk nicely to it?
[13:57] <mdeslaur> soren: win 9, I win
[13:57] <mdeslaur> zul: I whispered into it's ear
[14:01] <pitti> hm, doesn't work here either
[14:02] <pitti> I bet it's because mvo is on holiday
[14:04] <cjwatson> I imagine it needs somebody to create an entry in the meta-release file
[14:05] <cjwatson> (on changelogs.ubuntu.com)
=== dendro-afk is now known as dendrobates
=== dendrobates is now known as dendro-afk
=== sconklin-gone is now known as sconklin
=== ericm|ubuntu is now known as ericm-Zzz
[15:28] <ogra> Keybuk, hey ... i recently get ureadahead OOM messages on boot with omap beagleboards (it boots fine otherwise and there isnt anything out of ram post-boot) any idea what that could be ?
[15:33] <smoser> hi. i'm looking to pull in a new package 'ebsmount'.  it comes from turnkey linux, it has a (easily removable) dependency on "turnkey-pylib".
[15:33] <smoser> i'd like to remove that dependency and have support from the upstream to do it (replacing it with code in ebsmount itself)
[15:34] <smoser> mostly i just don't want to pull the package in. i'm wondering how dirty that seems to other people and if i should just bite the bullet and pull in both, and file both MIR eventually (as I want them into cloud utils)
[15:34] <smoser> s/cloud utils/cloud images/
=== mathiaz_ is now known as mathiaz
=== dendro-afk is now known as dendrobates
=== dendrobates is now known as dendro-afk
[16:18] <Keybuk> ogra: yeah, the kernel picks on ureadahead sometimes
[16:40] <hrw> hi
=== dendro-afk is now known as dendrobates
=== beuno is now known as beuno-lunch
=== hrw is now known as hrw|gone
=== ogra__ is now known as ogra
=== beuno-lunch is now known as beuno
=== dendrobates is now known as dendro-afk
[17:49] <qense> directhex: Could you take a look at bug #592706, if you have some spare time?
[17:49] <ubottu> Launchpad bug 592706 in indicator-application (Ubuntu) "apps using the mono bindings fail to load" [High,Triaged] https://launchpad.net/bugs/592706
[17:55] <directhex> qense, without looking in detail, it looks like the indicator-application C ABI has changed
[17:56] <seif_> tedg, u there?
[17:56] <seif_> i need u with indicator appler
[17:56] <seif_> applet
[17:56] <tedg> seif_, Yup.  What's up?
[17:56] <seif_> hmmmmm
[17:56] <seif_>  i need a custom applet
[17:56] <pitti> mr_pouit: I'd like to package the current xfce4-power-manager (with upower support), and alongside this https://edge.launchpad.net/libxfce4ui (new requirement; I understand this supersedes the old libxfce4gui)
[17:56] <tedg> seif_, Perhaps #ayatana is a better channel for that though.
[17:56] <seif_> how do i do that
[17:56] <seif_> ok
[17:57] <pitti> mr_pouit: whom should I coordinate with for this?
[18:06] <kees> pitti: I think 587055's eglibc version is going to collide with -security
[18:08] <kees> pitti: or... i am confused and the bug title confused me
=== dendro-afk is now known as dendrobates
[18:14] <mr_pouit> pitti: you want to package it for maverick?
[18:32] <mr_pouit> pitti: anyway, there's already a package in the xubuntu-dev ppa. But it requires libxfce4ui, which is still a development release, so I would rather not put it in an ubuntu release
=== dendrobates is now known as dendro-afk
=== pgraner is now known as pgraner-afk
[19:04] <akheron> I'm using cowbuilder-dist on karmic and trying to build a lucid package; the builder cannot install debhelper, what's wrong?
[19:04] <akheron> is it not possible to build for newer ubuntu versions with cow/pbuilder-dist?
[19:08] <Chipzz> smoser: I just googled ebsmount and looked at its page
[19:09] <Chipzz> now while I don't know the implementation details
[19:09] <Chipzz> that configfile is just... it smells like an fstab line, it quacks like an fstab line, but it's a configfile?
[19:09] <Chipzz> pls tell me I shouldn't facepalm? :P
[19:10] <smoser> config file ?
[19:10] <smoser> ebsmount.conf is not a fstab entry, no.
[19:10] <Chipzz> http://www.turnkeylinux.org/blog/ebsmount , Default configuration
[19:10] <Chipzz> I know it's not
[19:11] <Chipzz> but from how that config file looks, it sounds like it should be?
[19:11] <smoser> the basic intent of the package is to take action on attach or detach of a volume
[19:12] <smoser> its udev rules and then something that implements the hook.
[19:12] <Chipzz> I know I should look at the source code first, but when I see sth like that I pre-emptively take out my biggest cluebat :P
[19:12] <Chipzz> that just looks... horribly misguided
[19:13] <smoser> thats reasonable, yeah.  but it is intended to provide "autorun" like function for EBS devices.
[19:15] <smoser> i'm working with the upstream folks to  make it better.  and we're not opposed to input.
[19:19] <Chipzz> wait, what?
[19:19] <Chipzz> I looked over the biggest SNAFU it appears
[19:19] <Chipzz> "Once a filesystem is mounted, EBSmount will execute scripts located in MOUNTPOINT/.ebsmount in alpha-numeric ordering."
[19:20] <Chipzz> now I REALLY am going to facepalm
[19:20] <Chipzz> "This provides a very powerful mechanism. In its simplest form, the user might want to symlink the mountpoint to a more accessible path, for example:"
[19:20]  * Chipzz facepalms moar
[19:21] <ion> Haha
[19:21] <Chipzz> is. that. not. what. udev. is. supposed. to. do.
[19:21] <Chipzz> ???????
=== JayFo is now known as JFo
[19:21] <Chipzz> this makes me want to shoot ppl, and I haven't even looked at the source code yet
[19:22] <Chipzz> so basically anyone with write-access to the root of that fs can root your system on the next reboot
[19:22] <Chipzz> congrats, you just made yourself one hell of a security hole
[19:23] <kees> that's ... not in Ubuntu, right?
[19:24] <Chipzz> no, but smoser was proposing it
[19:26] <Chipzz> smoser: pls note that having write access to the root of the fs is not unlikely (I'm guessing)
[19:27] <Chipzz> since we're talking about EBS, it's very like you'll want to mount the partition as, say, /srv for your ftp daemon or apache
[19:27] <cjwatson> kees: if you have a chance to review bug 582189, I'd really appreciate it; I'm pretty close to being blocked on it
[19:27] <ubottu> Launchpad bug 582189 in libisofs (Ubuntu) "MIR: libisoburn, libisofs, libburn" [Undecided,New] https://launchpad.net/bugs/582189
[19:27] <Chipzz> now assume your ftp daemon has a bug, you have sloppy permissions, ftp daemon gets exploited and dumps a file in that special dir
[19:28] <Chipzz> next reboot you're rooted
[19:28] <Chipzz> privilege escalation
[19:28] <kees> cjwatson: yup, was going to do an MIR pass today
[19:29] <cjwatson> thanks
[19:35] <smoser> Chipzz, i had realized that that should be disabled by default.
[19:37] <smoser> we'll have to address that somehow.
[19:38] <smoser> regarding "thats what udev is for".. yes, there are udev rules that invoke the mount behavior. the package installs them.
[19:39] <smoser> i completely understand your concerns. i'm interested in suggestions on how to make things safer, yet still provide some of that functionality.
[19:42] <Chipzz> smoser: udev can create symlinks so you have stable device nodes to mount
[19:42] <Chipzz> not sure how exactly ebs works, but it seems that's what should be done
[19:43] <smoser> you're suggesting via udev ?
[19:43] <smoser> the intent is largly to simplify that, and do something with no effort from the user.
[19:43] <Chipzz> like I said, I don't know the exact implementation, but yes
[19:44] <Chipzz> are you serious?
[19:44] <Chipzz> you're proposing opening up a gigantic security hole for the sake of user convenience?
[19:44] <Chipzz> this software is supposed to be installed on a server
[19:45] <Chipzz> if you're administering a server, you're supposed to have some amount of clue
[19:45] <Chipzz> "convenience" should be a non-issue
[19:45] <smoser> i absolutely dont want to open a huge security hole.
[19:45] <smoser> and agree, that as it is, it is open to exploit.
[19:46] <ion> Personally, i’d rather have Upstart run the arbitrary set of commands i want to happen when a certain partition is mounted.
[19:46] <smoser> that said the argument of "this is for a server, some things are difficult" is not valid.
[19:47] <Chipzz> I'm not a udev expert, but may I suggest you talk to Keybuk? He can probably help you beat this piece of missoftware into a usable shape
[19:47] <ion> start on mounted MOUNTPOINT=/foo, task, exec touch /foo/bar
[19:47] <Chipzz> although from what I read on that page, you're probably better off starting from scratch
[19:48] <Chipzz> not much to salvage I figure
[19:51] <smoser> Chipzz, thanks for your input
[19:51] <Chipzz> smoser: really, mount/fstab/udev provide all the pieces of the puzzle
[19:52] <qense> upower detects brightness keys?
[19:52] <smoser> i agree completely.
[19:52] <Chipzz> it just seems upstream lacked the necessary insight and made a kludge of it
[19:52] <smoser> there really isn't much there.  except a bit of config and udev rules written to call something.
[19:53] <smoser> but saying the pieces provide all the functionality doesn't mean that its obvious how to put them together, and the upstream package intent is to put them together for easier use.
[19:53] <smoser> ie, awk, ls, find provide all the functionality for 'du'.
[19:53] <smoser> "upstream" is using those tools.
[19:54] <Chipzz> and opening a gigantic security hole, and depending on python which probably isn't necessary at all, in the progress
[19:55] <smoser> i hardly find "depending on python" to be a concern.
[19:55] <Chipzz> it may be for debian
[19:55] <Chipzz> where you can have a very minimal install without a lot of packages
[19:56] <Chipzz> in case you would ever want to get this functionality into debian
[19:57] <smoser> i find the security concerns more than reasonable, but i'm not teribly concerned aobut a python dependency.
[19:57] <smoser> apt-cache show ubuntu-minimal | grep python
[19:58] <smoser> i'm being serious, though, thank you for your input.
[19:58] <Chipzz> yw
[19:59] <Chipzz> (if depending on python is not a concern to you, maybe the extra package is. but you already mentioned it is :))
[20:00] <ScottK> smoser: python isn't in minimal in Debian, so it is more of a concern there.
[20:00] <Chipzz> btw, I think your comparison to du is the wrong way around :)
[20:01] <Chipzz> smoser: that's exactly what what upstream is doing - implementing du on top of awk, ls, etc...
[20:01] <smoser> thats what i was saying.
[20:02] <smoser> that you were arguing "you have the tools to write 'du', why would you want to include that package itself"
[20:02] <Chipzz> it should just depend on coreutils instead
[20:03] <Chipzz> nevermind, enoughof this conversation already :)
[20:03] <Chipzz> it's 9PM and I'm tired :)
[20:03] <Janey0305> Do Yall know ubuntu?
[20:04] <Chipzz> I think there's room for one last facepalm though ;P
[20:04] <ion> Never heard.
[20:04] <Janey0305> ubuntu/linux
[20:04] <Janey0305> Nobody knows
[20:04] <Janey0305> ?
[20:04] <Chipzz> don't you mean gnu/ubuntu? :)
[20:04] <ion> I don’t think so.
[20:04]  * Chipzz runs :)
[20:04] <Janey0305> Well does anybody know a computer expert
[20:05] <Janey0305> I can chat with
[20:05] <Janey0305> FOR FREE!
[20:05] <Janey0305> lol.
[20:05] <Janey0305> cause I have a issue with sims 2
[20:05] <Janey0305> and i really wanna play it
[20:05] <Chipzz> yes, they're in #windows ;P
[20:05] <Janey0305> but I cant
[20:05] <Janey0305> where do I find that?
[20:06] <Janey0305> im new on here
[20:07] <Chipzz> Janey0305: this channel is about the development of ubuntu, it's not for user support
[20:07] <Chipzz> for user support, if your question is even related to ubuntu, pls join #ubuntu
[20:10] <dobey> anyone around that can do a quick REVU uh, review?
[20:15]  * lamont needs the name of a package uploaded/synced to maverick in the last 2 hours, and doesn't want to dig through his email... anyone got a name?
[20:16] <ion> Does http://blog.gmane.org/gmane.linux.ubuntu.devel.changes.maverick help?
[20:17] <ScottK> lamont: https://launchpad.net/ubuntu/maverick/+source/userconfig/0.9.0-0ubuntu5
[20:17] <lamont> yep. thanks all
[20:50] <pygi> cjwatson, I would have really appreciated at least a poke on bugs like this:
[20:50] <pygi> https://bugs.launchpad.net/ubuntu/+source/libisoburn/+bug/582189
[20:50] <ubottu> Launchpad bug 582189 in libisofs (Ubuntu) "MIR: libisoburn, libisofs, libburn" [High,In progress]
[20:50] <pygi> I know that you all laughed when I recommend those a few years ago, but yea....
[20:52] <pygi> *sigh*
[20:52] <pygi> I'd recommend communicating with upstream in the future if possible :-/
[21:00] <JanC> pygi: that's not really a bug, but just a task/proposal to move those packages from universe to main inside ubuntu?
[21:00] <pygi> JanC, yes, whatever you call it
[21:01] <antonpiatek> Anyone know if there is a way to extract a single file from a source package (without unpacking the entire archive)?
[21:03] <james_w> antonpiatek: there isn't really, as you may have to patch the file, overwrite it with one from elsewhere etc.
[21:04] <james_w> it's not as easy as just poking inside an archive
=== al-maisan is now known as almaisan-away
[21:04] <antonpiatek> james_w, thanks - thought it might be like that
[21:04] <JanC> well, you can extract the unpatched file of course
[21:10] <mathiaz> jcastro: hi!
[21:10] <mathiaz> jcastro: working on bug 471468
[21:10] <ubottu> Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/471468)
[21:11] <mathiaz> jcastro: I've created and linked the bug to the upstream bug tracker
[21:11] <mathiaz> jcastro: what do you recommend to set the Ubuntu bug status to?
[21:11] <mathiaz> jcastro: Fix committed?
[21:12] <jcastro> mathiaz: I would just leave it triaged until you sync next
[21:12] <jcastro> you haven't really committed it to ubuntu per se
[21:13] <mathiaz> jcastro: right - in that case it wouldn't be a sync since it's not reported to Debian, but rather the upstream tracker
[21:13] <mathiaz> jcastro: right - i seem to recall that the desktop team was doing something similar
[21:13] <jcastro> do you get it directly from upstream or from debian?
[21:13] <mathiaz> jcastro: hm - what do you refer to by *it* ?
[21:14] <jcastro> nagios I mean
[21:14] <mathiaz> jcastro: ah - nagios is a package in debian
[21:14] <mathiaz> jcastro: (is that what you meant?)
[21:14] <jcastro> Do you get nagios from debian or do we package it directly from upstream?
[21:15] <mathiaz> jcastro: we get nagios from Debian
[21:16] <jcastro> right, so I think leaving the Ubuntu task "triaged" until the next time it gets synced from Debian that includes that fix makes the most sense
[21:18] <jcastro> mathiaz: basically, how you have it now
=== pgraner-afk is now known as pgraner
[21:23] <mathiaz> jcastro: ok - how do you unsubscribe the review team?
[21:23] <mathiaz> jcastro: (since the patch has been reviewed)
[21:24] <jcastro> mathiaz: I think only someone from the review team can unsub them
[21:24] <mathiaz> jcastro: https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
[21:25] <mathiaz> jcastro: ^^ says to not unsubscribe the team
[21:25] <jcastro> nigelb: what do we do now?
[21:25] <jcastro> mathiaz: let's just ask him, heh
[21:29] <mathiaz> jcastro: I've read https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
[21:29] <mathiaz> jcastro: It seems clear to me what needs to be done
[21:52] <mathiaz> bdmurray: hi
[21:53] <mathiaz> bdmurray: is there an API in LP that lists the packages for which a team is a bug contact for?
[21:54] <bdmurray> mathiaz: could you give me an example of a bug contact for a package?
[21:54] <mathiaz> bdmurray: or screen scraping https://bugs.launchpad.net/~ubuntu-server/+packagebugs is still the only option?
[21:55] <mathiaz> bdmurray: ubuntu-server is a bug contact for the apache2 (src) package
[21:55] <mathiaz> bdmurray: I'm working on the following WI: Write script to automatically match ubuntu-server bug contact packagelist with ubuntu-server package set
[21:56] <mathiaz> bdmurray: from https://blueprints.launchpad.net/ubuntu/+spec/server-maverick-uds-seed-review
[21:56] <mathiaz> bdmurray: the goal is to use the packagesset list as the list of bugs the ubuntu-server team should be a bug contact for
[21:57] <mathiaz> bdmurray: may be (or may be not) LP should do that automatically
[21:57] <mathiaz> bdmurray: but for now I'd like to write a script that does that semi-automatically
[21:59] <bdmurray> mathiaz: if you had a list of packages I believe you could just use addBugSubscription for all of them and it would do the right thing wrt to subscribing you to new ones
[22:00] <mathiaz> bdmurray: I can already get a list of packages (using the packagesets API)
[22:00] <mathiaz> bdmurray: however I'd also like to prune the list
[22:00] <mathiaz> bdmurray: ie remove packages that are *not* in the package set
[22:00] <mathiaz> bdmurray: to do that I'd like to have the list of packages the ubuntu-server team is currently a bug contact for
[22:00] <bdmurray> mathiaz: right, well you can't yet move from people to all of their subscriptions
[22:01] <mathiaz> bdmurray: ok - I'll keep screen scraping https://bugs.launchpad.net/~ubuntu-server/+packagebugs
[22:01] <mathiaz> bdmurray: is there a bug filed about adding such an API call?
[22:01] <mathiaz> bdmurray: if not - where should I filed it?
[22:01] <bdmurray> mathiaz: I'm looking
[22:02] <bdmurray> mathiaz: I'm pretty sure bug 331039 covers it
[22:02] <ubottu> Launchpad bug 331039 in Launchpad Bugs "packagebugs not being exposed through API" [Medium,Triaged] https://launchpad.net/bugs/331039
[22:02] <mathiaz> bdmurray: agreed - thanks for the info!
[22:11] <mathiaz> bdmurray: I've looked at https://bugs.edge.launchpad.net/~ubuntu-server/+patches
[22:11] <mathiaz> bdmurray: this is really cool!
[22:11] <mathiaz> bdmurray: how do you select the list of bugs?
[22:12] <mathiaz> bdmurray: are you using the list of packages to which the team is a bug contact?
[22:12] <bdmurray> mathiaz: yes
[22:12] <mathiaz> bdmurray: \o/
[22:12] <mathiaz> bdmurray: another reason to get the packageset synced with the bug contact packages
[22:13] <ajmitch> hopefully exposing IPerson.getBugSubscriberPackages() is enough
[22:14] <bdmurray> mathiaz: I'm not sure where the term 'bug contact' comes from.  I think of it a subscription to bugs about that package.
[22:16] <CynthiaG> The bug contact for a package is the person or team which is automatically marked as subscribed to all bug mail about the package
[22:16] <CynthiaG> Other people may be subscribed to bug mail, but the bug contact is always subscribed
[22:16] <bdmurray> I don't believe there is a singular bug contact though
[22:17] <CynthiaG> Well, different packages and Launchpad projects are going to have different bug contacts yeah
[22:17] <bdmurray> For example https://edge.launchpad.net/ubuntu/+source/apache2 contains multiple bug subscriptions
[22:18] <CynthiaG> None of those are the bug contact
[22:19] <CynthiaG> Oh. Perhaps "bug supervisor" is meant here.
[22:19] <CynthiaG> And "security contact", the person or team notified of private security-related bugs for the package
[22:19] <CynthiaG> bdmurray, mathiaz: ^
[22:25] <CynthiaG> Never mind, bug 331039 *is* about all subscribers to bugs for a certain package, not the "bug contact"
[22:25] <ubottu> Launchpad bug 331039 in Launchpad Bugs "packagebugs not being exposed through API" [Medium,Triaged] https://launchpad.net/bugs/331039
[22:25] <CynthiaG> +packagebugs, etc.
[22:26] <CynthiaG> so for https://launchpad.net/ubuntu/+source/apache2 you would be scraping https://bugs.launchpad.net/ubuntu/+source/apache2/+packagebugs , since the API has nothing about this
[22:26] <CynthiaG> no, wait. you'd be scraping /~USERNAME/+packagebugs
[22:30] <ajmitch> the fix is to extend the API for it :)
[22:31] <CynthiaG> I think there was just confusion over the term 'bug contact' though
[22:31] <ajmitch> this started off at where we are, asking if there was an API equivalent of +packagebugs
=== sconklin is now known as sconklin-gone
=== bjf is now known as bjf[afk]
[23:48] <mathiaz> kees: hi!
[23:49] <mathiaz> kees: do you have script or know of a lP page that given a source package gives the list of binary packages with their component (main, universe,...)?
[23:50] <kees> mathiaz: I feel like you asked me this in the past.  :)
[23:54] <kees> mathiaz: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/annotate/head:/security-tools/bin-details
[23:54] <mathiaz> kees: great - thanks!
[23:54] <kees> mathiaz: np :
[23:54] <kees> )
[23:55] <mneptok> the question so nice you ask it twice.
[23:55] <kees> mneptok: heh.
[23:56] <ajmitch> mathiaz: btw, I found there was a branch for that +packagebugs API issue created a few hours ago, so it might get into LP sometime :)
[23:56] <mathiaz> ajmitch: right - I noticed that as well
[23:56] <mathiaz> ajmitch: thanks for linking the branch to the bug
[23:57] <ajmitch> np, I stumbled across it when figuring out how to implement it myself