[00:47] <hicham> usb-creator doc is in ubuntu-docs package ?
[02:13] <GanonKiller> were gps drivers made for meerkat?
[02:15] <persia> There are usually some in the archive.  I'm unsure how heavily tested they are.  I would expect maverick to have slightly more coverage than lucid in that regard.
[02:15] <persia> I'd recommend either asking in #ubuntu for your specific hardware, or testing your specific hardware with a LiveCD, and if it doesn't work, filing a bug and following up in #ubuntu-bugs.
[02:18] <GanonKiller> #ubuntu aint helping.. too many people
[02:20] <GanonKiller> thats why i was asking if any were developed... i have a old PCMCIA GPS Card
[02:21] <RAOF> The easiest way to find out is to boot a 10.10 live cd, and see if it's detected.
[02:21] <persia> I don't know which GPS chipsets happen to be supported, and this isn't a support channel.  Really, your best bet is test with a LiveCD, and if it doesn't work, report a bug and use that as a place to discuss getting support working.
[02:22] <GanonKiller> am looking on support sites.. but no luck
[03:01] <ion> Hardy herons? http://4.bp.blogspot.com/_yu-22ZXfW0E/TKZtXqQ54SI/AAAAAAAAAnI/80V_hfVFN7c/s1600/herons.jpg
[06:16] <pitti> Good morning
[06:19] <ajmitch> morning pitti
[06:49] <micahg> python-numpy is FTBFS because it now use python-matlibplot to buildk the docs, is it better to make an MIR for matlibplot and its build-deps or to not build the docs (or another option)?
[07:05] <persia> micahg, if doing an MIR would increase the install-time set, it needs real thought.  If it's just the build-time set, it's worth looking through the MIR process, and if there's no obvious reason the package would fail, process the MIR.
[07:07] <micahg> persia: the doc is only suggests, so no install-time issue, but matlibplot has a lot of universe build-deps
[07:07] <persia> Worth a look.
[07:08] <persia> The MIR process is mostly so that we know anything in main has an acceptable level of maintenance effort and can sanely receive security support.
[07:08] <micahg> persia: so that means going through each of the build deps and looking if they require a lot of universe packages?  how much recursion is too much in this case?
[07:08] <persia> We, alas, don't have any process to *ensure* things stay that way, but that's different.
[07:09] <persia> And we probably need a new way to handle "code-review-passed" in the face of Archive Reorganisation anyway.
[07:09] <persia> micahg, recurse to the point of frustration.  If you're still motivated enough to keep doing it, you aren't doing too much.
[07:09] <persia> As soon as it feels like it's not worth it, it's probably not.
[07:11] <micahg> I guess 14 packages doesn't look so bad and some of them are probably from the same source
[07:13] <persia> Note that it's worth considering that all of them will need at least a code review and security review: it may take a while.
[07:54] <dholbach> Good morning!
[08:07] <lifeless> cjwatson: +1 on libpipeline
[08:29] <cjwatson> lifeless: :-)
[09:30] <mvk> how do we get into Ubuntu/Kubuntu development, we would like to add geolocation to the timezone screen for the installation
[09:30] <mvk> so we need to modify the 'setup', were do we start?
[09:30] <mvk> this here https://help.ubuntu.com/community/InstallCDCustomization says that its 'The process of customizing or "remastering" Ubuntu installation CDs is not especially complex, but it is a little tedious and finicky.'
[09:31] <mvk> but we need to create a production stable image after modification!
[09:40] <mvk> how does one commit patches for the ubuntu-installation?
[09:48] <apw> mvk, normally you need to find the package within which the changes are to be and add the patches to that package
[09:48] <mvk> hi
[09:48] <mvk> apw: what packages does the installer (screens) reside in?
[09:49] <apw> mvk, (not being an expert on that side I am guessing some) but that might be casper
[09:49] <mvk> do they even exist in the repos
[09:49] <mvk> or just on the cd images
[09:49] <apw> everything on the CD is in the archive in a package
[09:49] <mvk> (extracked, i doubt they are .deb packages)
[09:49] <apw> (as far as i know)
[09:50] <mvk> ow
[09:51] <apw> mvk, i would suspect the people who know are hanging out on #ubuntu-installer
[09:51] <mvk> now thats a nice pointer, thanks apw
[09:51] <apw> mvk we try
[09:53] <apw> mvk, one does sometimes have to be patient, the team may be US based for instance
[13:11] <TLE> pitti: Hey. David and I were discussing that we would like to create some guidelines for how language teams can request a manual language pack update. The actual requests should be probably be in the form of a bugreport and of course it requires that you get informed somehow.
[13:11] <TLE> pitti: so the questions is, against which package do you think these bug reports should be files?
[13:12] <TLE> pitti: and can we find one where you will automatically be subscribed?
[13:12] <TLE> s/be files/be filed/
[13:46] <rsFF> hello there
[13:46] <rsFF> where do the package dgbsyms for the kernel installs
[13:46] <rsFF> since the gdb is not automaticly loading the symbols
[13:46] <rsFF> i used to use vmlinux for that
[13:47] <rsFF> but after i found out that ddebs were provides i tried to use them
[13:47] <rsFF> but i cannot find it
[13:50] <kklimonda> rsFF: dpkg -L <package> will give you the list of packages. Debug symbols are installed in /usr/lib/debug/
[13:50] <persia> ddebs.ubuntu.com
[13:50] <rsFF> yeah i already installed
[13:50] <kklimonda> there is for example /usr/lib/debug/boot/vmlinux-2.6.35-22-generic and /usr/lib/debug/lib/modules/...
[13:51] <rsFF> hummm
[13:51] <rsFF> i think that should do it
[13:53] <rsFF> thanks
[13:54] <TLE> afk 20 min
[14:01] <pitti> TLE: you should assign "ubuntu-langpack" to the bug (or subscribe); the actual package isn't that important, it could be any language-pack-* or the langpack-o-matic project
[14:44] <jdstrand> pitti: hi! I was wondering if there was anything else needed from me re bug #660077
[14:45] <jdstrand> (it is still waiting for approval)
[14:45] <pitti> jdstrand: didn't get to review it yet; this makes me horribly nervous, though
[14:45] <pitti> so I don't just want to wave it through, but read the diff
[14:45] <pitti> this has such a huge regression potential
[14:45] <jdstrand> pitti: in terms of abstractions, it should be fine. I was very careful on those
[14:46] <pitti> right, but also for kernel<->userspace ABI or version expectancies, etc.
[14:47] <jdstrand> pitti: jj-afk can speak at length on all of that
[14:48] <jdstrand> pitti: but the upstream changes were very conservative to not break things like that. but certainly, I am not trying to rush you. I just want to make sure you have everything you need
[14:48] <pitti> yes, I think I do
[14:48] <pitti> (except enough time for the SRU queue.. :) )
[14:48] <jdstrand> heh
[14:48] <pitti> still have a couple of bugs for OEM which I need to get done this week
[14:48] <pitti> next week -> back to platform :)
[14:49] <jdstrand> pitti: (this is actually needed for an oem thing as well, since you mention it)
[14:49] <jdstrand> pitti: but please talk to jj-afk if you have questions. he is extrememly familiar with these patches, the hows/whys, etc, etc
[14:50] <pitti> okay, thanks
[15:06] <TLE> pitti: ok thanks
[15:19] <jdstrand> pitti: oh, one other thing. I plan to run the -proposed apparmor packages on several production systems and have committments from sbeattie and jj-afk on verifying the -proposed packages as well
[15:19] <jdstrand> (that is in addition to all the testing I said I would do in the bug)
[15:41] <avinashhm> hi, is there any tool or script to remove dos line endings for a patch ???
[15:42] <micahg> avinashhm: vi can do it, I don't remember the command offhand
[15:44] <avinashhm> micahg, yep tried :s/^M//g .. this worked .. thanks micahg
[15:45] <micahg> avinashhm: actually, vi can just modify the line endings, but as they say in the Perl world TMTOWTDI
[15:45] <avinashhm> whats TMTOWTDI ??
[15:45] <ogra_ac> GIYF
[15:46] <ogra_ac> :)
[15:46] <avinashhm> ogra_ac, yeah ... theres more than one way because of google :-)
[15:46] <ogra_ac> hehe
[15:47] <micahg> avinashhm: http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it
[15:47] <avinashhm> micahg, thanks .... got it ..:-)
[16:02] <mdeslaur> pitti: could you please release webkit for lucid and maverick so I can publish a USN? Thanks! (LP: #660075)
[16:07] <pitti> mdeslaur: will do, thanks for testing
[16:07] <mdeslaur> pitti: thanks!
[16:10] <pitti> mdeslaur: done
[16:14] <micahg> pitti: could you please accept gnome-shell in lucid-proposed?
[16:43] <ari-tczew> cjwatson: is it possible to create a special blacklist for merge-o-matic to prevent showing merges? e.g. it's necessary for chromium-browser
[16:49] <ximion_> Riddell: ping
[16:49] <ximion_> I created a Debian package for packagekit, which will be present in Debian soon.
[16:50] <ximion_> This package is a little bit different from the current one present in Ubuntu.
[16:51] <ximion_> I was asked by Michael Vogt to ask you about "joining forces" in PackageKit Debian/Ubuntu packaging
[16:51] <micahg> ari-tczew: why not fix the code to read teh archive blacklist file?
[16:51] <ari-tczew> micahg: I don't mind.
[16:52] <micahg> ari-tczew: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[17:02] <SpamapS> so, while merging cheetah, I find that its only building for python2.6 in natty.. but 2.7 is available right? So should we also add a build-dep on python2.7-dev to get the C extension part built for 2.7?
[17:03] <SpamapS> or is that what python-all-dev does eventually?
[17:04] <james_w> python-all-dev would be appropriate I think, but there may need to be debian/rules or debian/control tweaks to get it to build for 2.7
[17:04] <SpamapS> it loops through the pyversions already
[17:05] <tumbleweed> err, python2.7 isn't supported yet. It's there, but your package won't build for it until it's listed in pyversions -s
[17:06] <SpamapS> Ah, so basically.. just let it get rebuilt whenever python-all-dev is updated and it becomes a supported version?
[17:06] <tseliot> cjwatson: have you ever seen this error with quilt (note: it's not true that the patch was already applied)? http://pastebin.ubuntu.com/516334/
[17:06] <tumbleweed> SpamapS: yeah, that'll have to be done for many packages
[17:09] <ScottK> ximion_: Riddell is expecting to mostly be offline this week, so don't expect a quick answer.
[17:11] <ximion_> ScottK: Thanks for the info :) Okay, I don't need a fast reaction on this topic.
[17:39] <SpamapS> woooooooot mdadm v3 uploaded! :-D
[17:43]  * SpamapS would ^5 surbhi were she here. ;)
[18:06] <SpamapS> hrm, and now I see when I do a pbuilder build, it does pull in python 2.7 .. and, unfortunately, fails horribly because of it. :(
[18:07] <SpamapS> wow.. 2.6 all tests pass, 2.7, no tests pass. I'd say cheetah is not even capable of supporting python 2.7 yet.
[18:07] <SpamapS> AttributeError: attribute '__dict__' of 'type' objects is not writable
[19:24] <smoser> i have a debconf question that shows itself to debconf-get-selections as
[19:24] <smoser>   eucalyptus-nc   eucalyptus-nc/no_vmx    error
[19:24] <smoser> how can i seed it so i dont have to press 'Ok'
[19:30] <smoser> anyone ^
[19:35] <ScottK> SpamapS: barry has tons of advice for people fixing 2.7 stuff.
[19:40] <barry> SpamapS: what's up?
[19:47] <ScottK> barry: Do you have the backscroll where he talks about cheetah?
[19:48] <barry> ScottK: i do.  SpamapS, i'll take a look at cheetah and see what i get.
[19:48] <ScottK> Cool.  That's all I know.
[19:48] <ScottK> Python problem?  Dial 1-800-barry.
[19:49] <barry> or 1-800-flufl
[19:50] <ScottK> That would be more pythonic, you're right.
[19:50] <ScottK> It wouldn't work as well on IRC unless you highlight flufl too?
[19:50] <SpamapS> barry: I haven't tried 2.4.3 yet, but 2.4.1 has quite a few issues.
[19:51] <micahg> ScottK: 1-800-PEP3118 :)
[19:54] <barry> SpamapS: lp:ubuntu/cheetah is 2.0.1-2ubuntu7 yes?
[19:56] <SpamapS> barry: I just submitted a merge request with 2.4  bug 663343
[19:57] <barry> SpamapS: ack
[20:01] <barry> SpamapS: does the test suite run as part of the build?
[20:03] <SpamapS> barry: yes
[20:03] <SpamapS> barry: if you remove 2.7 from debian/pyversions you get a whole mess of failures
[20:03] <SpamapS> barry: or you can just run python2.7 /usr/bin/cheetah test
[20:04] <SpamapS> barry: definitely worth trying out a uupdate to 2.4.3
[20:08] <barry> SpamapS: ah, even 2.0.1 has test suite failures during the build, though the build apparently still succeeds
[20:08] <barry> lots of these:
[20:08] <barry> TypeError: importHook() takes at most 5 arguments (6 given)
[20:08] <barry> let me try to merge 2.4.3, and then i might have one more source of useful patches...
[20:23] <SpamapS> barry: I don't recall the end of the discussion about 2.7 in natty.. was the final call that it would be pushed for, but not set as default for some time?
[20:24] <barry> SpamapS: i don't think we've made a final decision.  for now, 2.7 is supported but 2.6 is still default.  i *hoping* we can go with 2.7 as default for natty, but we'll see
[20:25] <barry> SpamapS: i believe doko and ScottK agree with that plan
[20:27] <barry> SpamapS: 2.4.3 builds but i need to update the rules to run the test suite in its new location
[20:31] <barry> SpamapS: cheetah 2.4.3 + py27 + tests == fail
[20:33] <SpamapS> barry: wait
[20:33] <SpamapS> oh sorry n/m
[20:34] <SpamapS> barry: the failures all seem to be around 1 or 2 problems like overwriting __dict__ in Template
[20:36] <barry> SpamapS: i have one more trick up my sleeve...
[20:40] <ScottK> barry: I do (agree with that plan).
[20:44] <SpamapS> ScottK: hostname detection/setting.. I got mentioned in that conversation, but I wasn't sure what context it was under.
[20:45] <ScottK> SpamapS: General system context of we suck at doing it consistently and correctly and we should fix that.
[20:46] <SpamapS> ScottK: other than using the name fed to us via DHCP, I've never liked any of the other auto-detection methods. :-P
[20:47] <SpamapS> Of which I can only think of one.. reverse dns.
[20:47] <ScottK> SpamapS: We should look at what the various installers do, dhcp, anything else we can think of.
[20:48] <SpamapS> ScottK: I wonder if we can lump this in with the upstart improvements discussion, and call it "server bootup improvements" instead.
[20:48] <ScottK> SpamapS: No.  I think it's a different, but slightly related topic.
[20:48] <ScottK> It's not just server for a start.
[20:49] <SpamapS> Ah, good point. I don't ever think about the desktop. Desktops are just terminals for servers. ;)
[21:00] <barry> SpamapS: branch with successful 2.7 build+test on its way :)
[21:12] <barry> SpamapS: https://code.edge.launchpad.net/~barry/ubuntu/natty/cheetah/py27-compat/+merge/38883
[21:20] <SpamapS> barry: nice. :)
[21:26] <Riddell> ximion_: great, what's different?
[21:30] <barry> SpamapS: i can't upload it though, perhaps you can sponsor?
[21:31] <SpamapS> barry: nor can I. We're in the same boat that way. ;)
[21:32] <barry> SpamapS: :)  perhaps ScottK, or i will ping doko tomorrow
[21:32] <ximion_> Riddell: Nearly everything :P It produces some additional packages, has a few renamed to match the newest Debian policy and has a completely new copyright file.
[21:32] <ximion_> these are chages Ubuntu can easily take.
[21:33] <ximion_> the only thing you will want to change in Ubuntu is the vendor patch.
[21:33] <SpamapS> barry: I will ask one of my usual sponsors to take a look if its not uploaded by Thursday.
[21:33] <ScottK> barry or SpamapS: If someone presents me with an actual debdiff, I'll look at it.
[21:34] <ximion_> Riddell: I suggest one Bazaar-Branch "packagekit" and one "packagekit-debian" which belong to the PackageKit-Team at LP, where both packages are maintained.
[21:34] <barry> ScottK: https://bugs.edge.launchpad.net/ubuntu/+source/cheetah/+bug/663343/+attachment/1702084/+files/cheetah-663343.debdiff
[21:34] <ximion_> Riddell: This should make sharing patches and other changes between both distributions really easy.
[21:35]  * ximion_ is away for a short time
[21:35] <ScottK> barry: Looking
[21:36] <ScottK> barry: Is this a new upstream version?  If so, I need just the diff.gz.
[21:37] <barry> ScottK: it is.  hang on, i'll upload that
[21:38] <Riddell> ximion_: that sounds good
[21:41] <barry> ScottK: http://barry.warsaw.us/cheetah_2.4.3-0ubuntu1.diff.gz
[21:57]  * barry -> reboot
[22:01] <pwnguin> obviously sin city has warped bav
[22:04] <ximion_> Riddell: Is there an existing branch I should use for the Ubuntu packaging? Or should I create a new one?
[22:10] <Riddell> ximion_: there's an existing branch, don't have it to hand but it'll be in the debian/control of our existing package
[22:13] <ximion_> Diddell: The code assigned to the PK team only has a branch for maverick
[22:13] <ximion_> woops :D sorry, I mean Riddell :P
[22:14] <ximion_> Riddell: I would create a generic PK branch, which always contains the newest packaging version available in Ubuntu.
[22:15] <ximion_> (so if e.g. Maverick closes, the content goes to packagekit-maverick and packagekit ist the branch where the natty development takes pace)
[22:15] <maco> ordinarily the "trunk" branch refers to the devel version of ubuntu
[22:15] <ximion_> there's a PK branch for the current dev version, but only members of Ubuntu branches can upload to it.
[22:15] <maco> uh yeah that
[22:16] <ximion_> I'm not familiar with the branch management in Ubuntu, so I don't know the best practice there
[22:16] <maco> i think you just described it correctly
[22:16] <Riddell> ximion_: practice differs from package to package
[22:17] <ximion_> Riddell: What do you suggest?
[22:17] <Riddell> ximion_: well presumably we need a debian one and an ubuntu one, which would be branches of each other
[22:19] <ximion_> Riddell: The Debian packaging is currently in lp:~ximion/+junk/packagekit-debian, the Ubuntu packaging is in lp:~packagekit/packagekit/ubuntu-maverick
[22:19] <ximion_> cause maverick is reserved for maverick, i would suggest lp:~packagekit/packagekit/ubuntu for Ubuntu stuff and lp:~packagekit/packagekit/debian for the Debian packaging
[22:22] <ximion_> I would need to ask Sebastian to register the branches, as he is the maintainer of the PackageKit project at LP
[22:25] <ScottK> barry: Thanks.
[22:25] <Riddell> ximion_: I agree on the branch names, anyone with access to the team can push to them
[22:26] <Riddell> ximion_: looks like glatzor and mvo can add you to the launchpad team, I'd recommend we get them to do so
[22:27] <Riddell> ximion_: ah, you're Matthias Klumpp and have been a member for some hours
[22:28] <Riddell> ximion_: so you just need to bzr push lp:~packagekit/packagekit/debian
[22:30] <Riddell> ximion_: and we can see if we can manage without an ubuntu specific branch for now
[22:41] <ximion_> Riddell: You probably want to have a different vendor patch for Ubuntu
[22:43] <Riddell> ximion_: mm
[22:43] <ximion_> Riddell: Also, the pkg is new on Debian, so it might lack the transition stuff needed for the Ubuntu pkg
[22:45] <sladen> where is the Gtk+ menubar -> window manager integration done?  (My desktop theme has just reverted itself to defaults, as though something has crashed)
[22:45] <ScottK> ximion_: It isn't wrong to carry the additional transition stuff in Debian so we can sync.  You might consider it.
[22:46] <ximion_> ScottK: yep, I just need to figure out what exactly is needed for a Maverick -> Natty transition
[22:50] <ximion_> you can watch the Debian packaging at lp:~packagekit/packagekit/debian now
[22:50] <Riddell> ximion_: groovy, thanks
[22:52] <ximion_> Riddell: Tomorrow I'll try to merge the Debian changes to Ubuntu and vice versa and then create an ubuntu branch. Then you can take this branch to upload a new PK version to Natty instead of using MoM on the Debian pkg
[22:53] <sladen> ah... desk full wrecks Gtk+
[22:54] <debfx> ximion_: dh_install should be in its own override target
[22:55] <debfx> also you don't need to pass --list-missing to dh_install
[22:56] <debfx> --fail-missing implies listing
[22:56] <ximion_> debfx: Already changed this, but needs testing. The version in the repo represents the initial upload to the Debian archive
[22:56] <ximion_> debfx: Oo...
[22:57] <ximion_> you pointed me at a really bad regression I introduced
[22:59] <ximion_> debfx: Phew! It wasn't uploaded to the Debian archive. The archive received the correct version
[23:13] <ximion_> debfx: The call to dh_install was only for testing purposes, you can delete it if you want
[23:21] <ximion_> gn88
[23:21] <ximion_> whoops, I really need to sleep (this was typing error number fourteen in just twelve minutes!)
[23:21] <ximion_> night!
[23:47] <TheMuso> 6/c
[23:52] <barry> ScottK: thanks for uploading cheetah.  SpamapS it failed to build, even though it built fine locally on my natty chroot.  will investigate.
[23:52] <ScottK> barry: I did make some changes, so please review them for next time.
[23:52] <barry> ScottK: will do, thanks
[23:53] <ScottK> It built here too before I uploaded it.
[23:54] <ScottK> barry: There's .pyc shipped in the 2.7 stuff.
[23:55] <barry> ScottK: yikes
[23:55] <ScottK> So that's why.
[23:56]  * ScottK waits for a diff ....
[23:56] <barry> it looks like the 2.6 stuff also has pycs though
[23:57] <ScottK> barry: In my local build there's stuff in pyshared and python2.7/site-packages and only the latter has .pyc.
[23:58] <barry> ScottK: where can i see your changes?
[23:59] <ScottK> apt-get source the package and then diff it with yours.
[23:59] <ScottK> None of hte changes I made would have affected the current problem.
[23:59] <ScottK> (it was mostly changelog enhancement)