=== dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [00:47] usb-creator doc is in ubuntu-docs package ? === rsalveti` is now known as rsalveti === nogo_ is now known as nogo === superm1` is now known as superm1 [02:13] were gps drivers made for meerkat? [02:15] 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] 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] #ubuntu aint helping.. too many people [02:20] thats why i was asking if any were developed... i have a old PCMCIA GPS Card [02:21] The easiest way to find out is to boot a 10.10 live cd, and see if it's detected. [02:21] 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] am looking on support sites.. but no luck [03:01] Hardy herons? http://4.bp.blogspot.com/_yu-22ZXfW0E/TKZtXqQ54SI/AAAAAAAAAnI/80V_hfVFN7c/s1600/herons.jpg === GanonKiller is now known as Rikku [06:16] Good morning [06:19] morning pitti [06:49] 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] 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] persia: the doc is only suggests, so no install-time issue, but matlibplot has a lot of universe build-deps [07:07] Worth a look. [07:08] 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] 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] We, alas, don't have any process to *ensure* things stay that way, but that's different. [07:09] And we probably need a new way to handle "code-review-passed" in the face of Archive Reorganisation anyway. [07:09] 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] As soon as it feels like it's not worth it, it's probably not. [07:11] I guess 14 packages doesn't look so bad and some of them are probably from the same source [07:13] 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] Good morning! [08:07] cjwatson: +1 on libpipeline === jjohansen is now known as jj-afk === warp11 is now known as warp10 [08:29] lifeless: :-) === smb` is now known as smb === hunger_ is now known as hunger === almaisan-away is now known as al-maisan [09:30] how do we get into Ubuntu/Kubuntu development, we would like to add geolocation to the timezone screen for the installation [09:30] so we need to modify the 'setup', were do we start? [09:30] 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] but we need to create a production stable image after modification! [09:40] how does one commit patches for the ubuntu-installation? [09:48] mvk, normally you need to find the package within which the changes are to be and add the patches to that package [09:48] hi [09:48] apw: what packages does the installer (screens) reside in? [09:49] mvk, (not being an expert on that side I am guessing some) but that might be casper [09:49] do they even exist in the repos [09:49] or just on the cd images [09:49] everything on the CD is in the archive in a package [09:49] (extracked, i doubt they are .deb packages) [09:49] (as far as i know) [09:50] ow [09:51] mvk, i would suspect the people who know are hanging out on #ubuntu-installer [09:51] now thats a nice pointer, thanks apw [09:51] mvk we try [09:53] mvk, one does sometimes have to be patient, the team may be US based for instance === delan is now known as Guest29546 === Guest29546 is now known as delan_ === amitk is now known as amitk-afk === hanska is now known as dapal === diwic is now known as diwic_afk === amitk-afk is now known as amitk === seif_ is now known as seifloty === seifloty is now known as seiflotfy === dendro-afk is now known as dendrobates [13:11] 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] pitti: so the questions is, against which package do you think these bug reports should be files? [13:12] pitti: and can we find one where you will automatically be subscribed? [13:12] s/be files/be filed/ [13:46] hello there [13:46] where do the package dgbsyms for the kernel installs [13:46] since the gdb is not automaticly loading the symbols [13:46] i used to use vmlinux for that [13:47] but after i found out that ddebs were provides i tried to use them [13:47] but i cannot find it [13:50] rsFF: dpkg -L will give you the list of packages. Debug symbols are installed in /usr/lib/debug/ [13:50] ddebs.ubuntu.com [13:50] yeah i already installed [13:50] there is for example /usr/lib/debug/boot/vmlinux-2.6.35-22-generic and /usr/lib/debug/lib/modules/... [13:51] hummm [13:51] i think that should do it [13:53] thanks [13:54] afk 20 min [14:01] 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 === lan3y is now known as Laney [14:44] pitti: hi! I was wondering if there was anything else needed from me re bug #660077 [14:44] Launchpad bug 660077 in apparmor (Ubuntu Maverick) "update AppArmor to 2.5.1 (for upstream and backported maverick kernels)" [High,In progress] https://launchpad.net/bugs/660077 === dendrobates is now known as dendro-afk [14:45] (it is still waiting for approval) [14:45] jdstrand: didn't get to review it yet; this makes me horribly nervous, though [14:45] so I don't just want to wave it through, but read the diff [14:45] this has such a huge regression potential [14:45] pitti: in terms of abstractions, it should be fine. I was very careful on those [14:46] right, but also for kernel<->userspace ABI or version expectancies, etc. [14:47] pitti: jj-afk can speak at length on all of that [14:48] 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] yes, I think I do [14:48] (except enough time for the SRU queue.. :) ) [14:48] heh [14:48] still have a couple of bugs for OEM which I need to get done this week [14:48] next week -> back to platform :) [14:49] pitti: (this is actually needed for an oem thing as well, since you mention it) [14:49] 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] okay, thanks === dendro-afk is now known as dendrobates === tkamppeter_ is now known as tkamppeter [15:06] pitti: ok thanks [15:19] 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] (that is in addition to all the testing I said I would do in the bug) === bjf[afk] is now known as bjf [15:41] hi, is there any tool or script to remove dos line endings for a patch ??? [15:42] avinashhm: vi can do it, I don't remember the command offhand [15:44] micahg, yep tried :s/^M//g .. this worked .. thanks micahg [15:45] avinashhm: actually, vi can just modify the line endings, but as they say in the Perl world TMTOWTDI [15:45] whats TMTOWTDI ?? [15:45] GIYF [15:46] :) [15:46] ogra_ac, yeah ... theres more than one way because of google :-) [15:46] hehe [15:47] avinashhm: http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it [15:47] micahg, thanks .... got it ..:-) [16:02] pitti: could you please release webkit for lucid and maverick so I can publish a USN? Thanks! (LP: #660075) [16:07] mdeslaur: will do, thanks for testing [16:07] pitti: thanks! [16:10] mdeslaur: done [16:14] pitti: could you please accept gnome-shell in lucid-proposed? === deryck is now known as deryck[lunch] === mnepton is now known as mneptok [16:43] 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] Riddell: ping [16:49] I created a Debian package for packagekit, which will be present in Debian soon. [16:50] This package is a little bit different from the current one present in Ubuntu. [16:51] I was asked by Michael Vogt to ask you about "joining forces" in PackageKit Debian/Ubuntu packaging [16:51] ari-tczew: why not fix the code to read teh archive blacklist file? [16:51] micahg: I don't mind. [16:52] ari-tczew: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt === deryck[lunch] is now known as deryck === jj-afk is now known as jjohansen === beuno is now known as beuno-lunch [17:02] 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] or is that what python-all-dev does eventually? [17:04] 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] it loops through the pyversions already [17:05] 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 === cmagina is now known as cmagina-lunch [17:06] Ah, so basically.. just let it get rebuilt whenever python-all-dev is updated and it becomes a supported version? [17:06] 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] SpamapS: yeah, that'll have to be done for many packages [17:09] ximion_: Riddell is expecting to mostly be offline this week, so don't expect a quick answer. [17:11] ScottK: Thanks for the info :) Okay, I don't need a fast reaction on this topic. === Claudinux_ is now known as Claudinux [17:39] woooooooot mdadm v3 uploaded! :-D [17:43] * SpamapS would ^5 surbhi were she here. ;) === cmagina-lunch is now known as cmagina === beuno-lunch is now known as beuno-luncheso === beuno-luncheso is now known as beuno [18:06] 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] 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] AttributeError: attribute '__dict__' of 'type' objects is not writable [19:24] i have a debconf question that shows itself to debconf-get-selections as [19:24] eucalyptus-nc eucalyptus-nc/no_vmx error [19:24] how can i seed it so i dont have to press 'Ok' [19:30] anyone ^ [19:35] SpamapS: barry has tons of advice for people fixing 2.7 stuff. [19:40] SpamapS: what's up? [19:47] barry: Do you have the backscroll where he talks about cheetah? [19:48] ScottK: i do. SpamapS, i'll take a look at cheetah and see what i get. [19:48] Cool. That's all I know. [19:48] Python problem? Dial 1-800-barry. [19:49] or 1-800-flufl [19:50] That would be more pythonic, you're right. [19:50] It wouldn't work as well on IRC unless you highlight flufl too? [19:50] barry: I haven't tried 2.4.3 yet, but 2.4.1 has quite a few issues. [19:51] ScottK: 1-800-PEP3118 :) [19:54] SpamapS: lp:ubuntu/cheetah is 2.0.1-2ubuntu7 yes? [19:56] barry: I just submitted a merge request with 2.4 bug 663343 [19:56] Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/663343 [19:57] SpamapS: ack [20:01] SpamapS: does the test suite run as part of the build? [20:03] barry: yes [20:03] barry: if you remove 2.7 from debian/pyversions you get a whole mess of failures [20:03] barry: or you can just run python2.7 /usr/bin/cheetah test [20:04] barry: definitely worth trying out a uupdate to 2.4.3 [20:08] SpamapS: ah, even 2.0.1 has test suite failures during the build, though the build apparently still succeeds [20:08] lots of these: [20:08] TypeError: importHook() takes at most 5 arguments (6 given) [20:08] let me try to merge 2.4.3, and then i might have one more source of useful patches... [20:23] 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] 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] SpamapS: i believe doko and ScottK agree with that plan [20:27] SpamapS: 2.4.3 builds but i need to update the rules to run the test suite in its new location [20:31] SpamapS: cheetah 2.4.3 + py27 + tests == fail === al-maisan is now known as almaisan-away [20:33] barry: wait [20:33] oh sorry n/m [20:34] barry: the failures all seem to be around 1 or 2 problems like overwriting __dict__ in Template [20:36] SpamapS: i have one more trick up my sleeve... [20:40] barry: I do (agree with that plan). [20:44] ScottK: hostname detection/setting.. I got mentioned in that conversation, but I wasn't sure what context it was under. [20:45] SpamapS: General system context of we suck at doing it consistently and correctly and we should fix that. [20:46] 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] Of which I can only think of one.. reverse dns. [20:47] SpamapS: We should look at what the various installers do, dhcp, anything else we can think of. [20:48] ScottK: I wonder if we can lump this in with the upstart improvements discussion, and call it "server bootup improvements" instead. [20:48] SpamapS: No. I think it's a different, but slightly related topic. [20:48] It's not just server for a start. [20:49] Ah, good point. I don't ever think about the desktop. Desktops are just terminals for servers. ;) [21:00] SpamapS: branch with successful 2.7 build+test on its way :) [21:12] SpamapS: https://code.edge.launchpad.net/~barry/ubuntu/natty/cheetah/py27-compat/+merge/38883 [21:20] barry: nice. :) [21:26] ximion_: great, what's different? === dendrobates is now known as dendro-afk [21:30] SpamapS: i can't upload it though, perhaps you can sponsor? === dapal is now known as hanska === hanska is now known as dapal [21:31] barry: nor can I. We're in the same boat that way. ;) [21:32] SpamapS: :) perhaps ScottK, or i will ping doko tomorrow [21:32] 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] these are chages Ubuntu can easily take. [21:33] the only thing you will want to change in Ubuntu is the vendor patch. [21:33] barry: I will ask one of my usual sponsors to take a look if its not uploaded by Thursday. [21:33] barry or SpamapS: If someone presents me with an actual debdiff, I'll look at it. [21:34] 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] ScottK: https://bugs.edge.launchpad.net/ubuntu/+source/cheetah/+bug/663343/+attachment/1702084/+files/cheetah-663343.debdiff [21:34] Launchpad bug 663343 in cheetah (Ubuntu) "Please merge cheetah 2.4.2.1-1 (main) from Debian unstable (main)" [Undecided,Confirmed] [21:34] 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] barry: Looking === dendro-afk is now known as dendrobates [21:36] barry: Is this a new upstream version? If so, I need just the diff.gz. [21:37] ScottK: it is. hang on, i'll upload that [21:38] ximion_: that sounds good [21:41] ScottK: http://barry.warsaw.us/cheetah_2.4.3-0ubuntu1.diff.gz [21:57] * barry -> reboot [22:01] obviously sin city has warped bav [22:04] Riddell: Is there an existing branch I should use for the Ubuntu packaging? Or should I create a new one? [22:10] 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] Diddell: The code assigned to the PK team only has a branch for maverick [22:13] woops :D sorry, I mean Riddell :P [22:14] Riddell: I would create a generic PK branch, which always contains the newest packaging version available in Ubuntu. [22:15] (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] ordinarily the "trunk" branch refers to the devel version of ubuntu [22:15] there's a PK branch for the current dev version, but only members of Ubuntu branches can upload to it. [22:15] uh yeah that [22:16] I'm not familiar with the branch management in Ubuntu, so I don't know the best practice there [22:16] i think you just described it correctly [22:16] ximion_: practice differs from package to package [22:17] Riddell: What do you suggest? [22:17] ximion_: well presumably we need a debian one and an ubuntu one, which would be branches of each other [22:19] Riddell: The Debian packaging is currently in lp:~ximion/+junk/packagekit-debian, the Ubuntu packaging is in lp:~packagekit/packagekit/ubuntu-maverick [22:19] 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] I would need to ask Sebastian to register the branches, as he is the maintainer of the PackageKit project at LP [22:25] barry: Thanks. [22:25] ximion_: I agree on the branch names, anyone with access to the team can push to them [22:26] ximion_: looks like glatzor and mvo can add you to the launchpad team, I'd recommend we get them to do so [22:27] ximion_: ah, you're Matthias Klumpp and have been a member for some hours [22:28] ximion_: so you just need to bzr push lp:~packagekit/packagekit/debian [22:30] ximion_: and we can see if we can manage without an ubuntu specific branch for now [22:41] Riddell: You probably want to have a different vendor patch for Ubuntu [22:43] ximion_: mm [22:43] Riddell: Also, the pkg is new on Debian, so it might lack the transition stuff needed for the Ubuntu pkg [22:45] 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] ximion_: It isn't wrong to carry the additional transition stuff in Debian so we can sync. You might consider it. [22:46] ScottK: yep, I just need to figure out what exactly is needed for a Maverick -> Natty transition [22:50] you can watch the Debian packaging at lp:~packagekit/packagekit/debian now [22:50] ximion_: groovy, thanks [22:52] 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] ah... desk full wrecks Gtk+ [22:54] ximion_: dh_install should be in its own override target [22:55] also you don't need to pass --list-missing to dh_install [22:56] --fail-missing implies listing [22:56] debfx: Already changed this, but needs testing. The version in the repo represents the initial upload to the Debian archive [22:56] debfx: Oo... [22:57] you pointed me at a really bad regression I introduced [22:59] debfx: Phew! It wasn't uploaded to the Debian archive. The archive received the correct version === SolidLiq is now known as solid_liq [23:13] debfx: The call to dh_install was only for testing purposes, you can delete it if you want === bjf is now known as bjf[afk] [23:21] gn88 [23:21] whoops, I really need to sleep (this was typing error number fourteen in just twelve minutes!) [23:21] night! === drizztbsd_ is now known as drizztbsd [23:47] 6/c [23:52] ScottK: thanks for uploading cheetah. SpamapS it failed to build, even though it built fine locally on my natty chroot. will investigate. [23:52] barry: I did make some changes, so please review them for next time. [23:52] ScottK: will do, thanks [23:53] It built here too before I uploaded it. [23:54] barry: There's .pyc shipped in the 2.7 stuff. [23:55] ScottK: yikes [23:55] So that's why. [23:56] * ScottK waits for a diff .... [23:56] it looks like the 2.6 stuff also has pycs though [23:57] barry: In my local build there's stuff in pyshared and python2.7/site-packages and only the latter has .pyc. [23:58] ScottK: where can i see your changes? [23:59] apt-get source the package and then diff it with yours. [23:59] None of hte changes I made would have affected the current problem. [23:59] (it was mostly changelog enhancement)