=== dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [00:48] @pilot out === udevbot changed the topic of #ubuntu-devel to: Launchpad down/read-only from 22:00-23:30 UTC for a code update | Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Da [01:29] lear === Pilif12p is now known as P|withoutpowerma [01:50] bdrung: ping? opinions on whether it would be too magical to have backportpackage -s squeeze to pull from debian and backportpackage -s maverick to pull from ubuntu, with no additional options? [01:56] (the alternative would be to add a --debian or something, but i actually think that automagically choosing would be slightly easier to implement) [02:10] I think if you don't know squeeze is Debian and maverick is Ubuntu more obvious options are unlikely to save you. [02:12] Namespacing only becomes important if there are multiple debian derivatives that have a common suite name without direct inheritance. It's probably worth waiting until this happens before worrying about it unduly. [02:16] * ScottK thinks such a situation would be 'not our problem'. [02:18] fortunately I can't think of a Toy Story character name that is also an adjective [02:20] Welll, http://wiki.ubuntu.com/Derivatives/Census implies there are more schemes, but in practice, whoever commits the name to backportpackage second needs to sort out why there is an issue. [02:21] Keybuk: Wheezy Walrus? [02:22] * ScottK expects it's a long shot candidate. === asac_ is now known as asac [02:24] I don't suppose there is any X experts around, eh? [02:25] Just ask the question. Maybe a non-expert ran into it before, or an expert is around... [02:27] My X server is currently using 2.2GiB of RAM of which 1.9GiB of it is private dirty memory on the heap. I'm wondering what information I can gather that would be helpful to an xorg developer as I don't think its likely I'll be able to reproduce so would like to get what useful information I can before attempting to use valgrind. [02:28] cody-somerville: Oooh, that doesn't sound good. [02:31] cody-somerville, list of processes running and their memory usage. dmesg. capture any memory related files in /proc. Xorg.0.log. [02:31] cody-somerville: So, that's going to somewhat depend upon what driver you're using. However, xrestop will give a fair idea of whether it's a runaway client. [02:32] cody-somerville: Also “pmap -x $(pgrep X)” output can sometimes be useful in identifying what part of the process is claiming that memory. Chances are that it's drm mappings, though. [02:32] cody-somerville, most of the time with X memory errors it's due to a client going nutty with too many X requests. So documenting the gui apps you've been running can be valuable. [02:33] `lsw` from suckless-tools is handy to generate that list [02:33] It's time for some dueling X advice! Call and response! :) [02:34] RAOF: it's pretty much guaranteed he's using the nvidia binary blob with that much memory usage :) [02:34] No. [02:34] Nouvea. [02:34] or however its spelled [02:34] persia, sweet, didn't know about lsw [02:35] persia, wmctrl -l gives a similar listing [02:35] And I've already looked at the memory map for the process - 1.9GiB private dirty on the heap. [02:35] well, not similar; looks like lsw includes some daemons and services too [02:36] cody-somerville: Not in card0 mappings? Hm. [02:37] cody-somerville: How long has this system been up? [02:37] RAOF, 5 days. [02:37] (And have you been doing anything particularly with it) [02:37] RAOF, No. [02:37] bryceh, From looking at the manpages, I suspect that discrepancies between the two are bugs. [02:37] cody-somerville: Has it been idle & displaying the screensaver or something? [02:38] RAOF, The extreme memory usage just occurred today (I wouldn't have noticed except I had swap disabled so my machine started being really slow). [02:38] RAOF, Yes. It was only a few days ago I discovered a massive memory leak in gltext. [02:38] cody-somerville: I fixed that, damnit! What release are you on? [02:38] RAOF, 11.04. [02:39] Ok. It's clearly got unfixed at some point then. [02:39] RAOF, gltext memory leak is LP #768032 [02:39] Launchpad bug 768032 in xscreensaver (Ubuntu Natty) "gltext seems to leak memory eventually causing oom-killer to run" [Undecided,New] https://launchpad.net/bugs/768032 [02:42] cody-somerville: Ah, yes. I did fix that in natty, but it apparently didn't get uploaded for some reason. [02:47] cody-somerville: Would you have noticed if this were a slow memory leak, and it just went over the threshold today, or is this most probably a big memleak trigerrable in a shortish period? [02:49] RAOF, Its entirely possible thats its a slow memory leak. The heap hasn't grown (at least more than 0.1GiB) since I noticed. [02:56] RAOF, Unless you have anything for me to try, I'm going to reboot. [02:57] cody-somerville: No, go ahead. === P|withoutpowerma is now known as Pilif12p === dendrobates is now known as dendro-afk [05:21] persia: theoretically at least, we can handle the imaginary future problem of non-derived derivatives with shared codenames using dpkg's vendor awareness. but i'm not going to write the code to do so [05:27] broder, Write the code to have internal suite->vendor translation. Commit it to Debian. Expect extension. In the event that someone wants to have a conflicting suite (e.g. "Wheezy Walrus"), the developers for that vendor (us in the contrived example) can write that code. It's a future problem. [05:28] But please don't assume that {debian,ubuntu} is the universe, or we'll end up with a mess. [05:42] s/a/more of a / [05:42] :P [05:43] Good morning === pitti_ is now known as pitti [05:53] broder: both. magically if you specify -s otherwise get the current behaviour with --ubuntu (or unstable with --debian) [05:54] bdrung_: hmph. i was afraid you'd say something like that [05:54] what if i make it key off of DEB_VENDOR instead? [05:55] (i.e. DEB_VENDOR=Debian backportpackage -d maverick pkg would use sid as its source) [05:55] broder, What's the use case for that? [05:56] persia: use case for what? [05:56] DEB_VENDOR=Debian backportpackage -d maverick [05:56] well, on its own, it wouldn't do anything, but if you add ppa:broder/ppa ... [05:57] or alternatively, --build [05:57] Right. My questions is why one would ever want to process a backport except within a distribution. [05:57] I think anything else is probably an unhealthy sign. [05:58] sid has a newer version of a package that hasn't been synced yet, and i want to put it in a lucid PPA for personal use [05:58] such a backport would be unacceptable in the real archive, certainly [05:58] And I can't say "just sync it then" because maybe it's beta-freeze. OK. [05:59] persia: the xul extension PPA is one usecase [05:59] backportpackage can already take either a local .dsc file or a package from the ubuntu archive and mangle them appropriately, so this is just providing another source for packages [05:59] bdrung_, I don't think you want me to write my thoughts on the xul extension PPA :) [06:00] broder, Right. [06:00] broder: DEB_VENDOR is sufficient (no --ubuntu or --debian needed). "DEB_VENDOR=Debian backportpackage" should have the same result than "backportpackage -s unstable" [06:01] persia: if you want, you can write them. [06:01] What happens if someone runs `DEB_VENDOR=Debian backportpackage -s oneiric`? [06:01] bdrung_: yeah, agreed. i'll probably switch backportpackage to use the *DistroInfo classes instead of lplib, and i think it might just turn out to be almost elegant [06:02] bdrung_, In summary, I don't think it ought exist. I think that declaring that we weren't going to support N extensions in the archive and then deciding to support them in a PPA indicates a fundamental failure in our software delivery model, which saddens me. [06:02] persia: then -s wins [06:03] -s winning sounds good. [06:03] hmm...actually, i don't think that will work [06:03] at least not as i was planning to do things [06:03] because if you set DEB_VENDOR=Debian, then i wasn't going to have it recognize Ubuntu as a distribution in your genealogy [06:03] * cody-somerville isn't closely following along but would the information in /usr/share/python-apt/templates/ be helpful? [06:03] persia: the ppa is unofficial. so it can lag behind if a new FF hits the archive. [06:04] i have to leave now. [06:04] bdrung_, Yes. This is the failure, which saddens me. [06:05] bdrung_: do you really feel that DEB_VENDOR=Debian backportpackage -s oneiric needs to work? because i don't think i think it should [06:05] cody-somerville, It's incomplete, but yeah, that's probably a better source of suite->vendor mapping than an independent implementation. [06:06] broder: yes it should, because you will use dpkg-vendor to determine your basis [06:06] bdrung_: and if you set DEB_VENDOR, that will affect how dpkg-vendor works [06:07] yes [06:07] so if you set DEB_VENDOR=Debian, and i start querying for your current and parent distributions, i'll never see Ubuntu and never know to look up the Ubuntu codenames [06:08] note that i'm not planning to add any validation of the destination releases at the moment [06:08] so DEB_VENDOR=Debian backportpackage -d oneiric -s sid would still work === _LibertyZero is now known as LibertyZero [06:08] yes [06:09] but DEB_VENDOR=Debian backportpackage -s oneiric would not [06:11] pitti: ping. [06:15] pitti: could you ack my message to technical-board@lists.ubuntu.com? [06:30] hey hyperair [06:30] ah, sure [06:32] hyperair: done [06:49] meh, is there any LP operation that doesn't time out? [06:49] pitti: see the launchpadstatus feed or #launchpad topic [06:50] pitti: http://identi.ca/launchpadstatus/all [06:50] ah, thanks [06:51] OTOH https://bugs.launchpad.net/ubuntu/+bugtarget-portlet-tags-content which was an 11+second page is now pretty snappy ;) === calc is now known as Guest33618 [07:40] pitti: thanks. [07:40] good morning === smb` is now known as smb [08:23] good morning [08:43] ev: for bug #794556, have you upgraded anything else in the same time? unity 3.8.14-0ubuntu2 is just a dependency field change on compiz in debian/control [08:43] Launchpad bug 794556 in unity "Unable to load icon text-x-preview at size 48 in a loop" [Undecided,Confirmed] https://launchpad.net/bugs/794556 === mthaddon changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Da [08:45] We are releasing a new version of libgrip, transitioning from GTK2 to GTK3. Currently the version is 0.1.7 and the Ubuntu package is called libgrip-0.1. [08:46] I'm told that the version numbers should somehow be connected to GTK versions. [08:46] What's the correct way to bump version numbers and packages? [08:47] Having both the GTK2 and GTK3 versions parallel installable would be nice but not absolutely necessary. [08:51] Satoris: I believe a correct thing to do here is to bump SONAME, which will (a) be easy and (b) make them parallel-installable. [08:52] I presume that you're a member of the upstream developers? [08:52] Yes. [08:53] we also have a few libfoo-gtk3-$(SONAME) packages - whether that's worth it probably depends on the extent of dual-running that's expected [08:53] Hi Gents. [08:54] Should the package name then be updated to libgrip-0.2? [08:54] With regards to network-manager package and the applet, which file manages the layout of the applet when you click on network-manager from within the Gnome desktop? [08:54] if you're not proposing to support the new version on GTK3, or at any rate not for long, it wouldn't be worth a -gtk3 package [08:55] Wait, you mean support the new version on GTK2? [08:55] sorry, yes [08:55] or how can I determine which file manages it etc. [08:55] kingmilo: it'll be one of those listed in 'dpkg -L network-manager-gnome' [08:56] 'apt-get source network-manager-applet' if you want to inspect the source [08:57] thanks cjwatson , much appreciated. [08:59] Satoris: What's your current SONAME? The libgrip-0.1 package nomenclature suggests that the library doesn't currently have one. [09:01] I'm not exactly sure, as I just got to working on it. [09:02] configure.ac has this: m4_define([grip_interface_age], [0]) [09:02] I'm not familiar with the intricacies of library versioning and related things. :) [09:04] Yeah, it's non-obvious. === doko_ is now known as doko [09:21] Gents, the top right hand panel in the gnome desktop, ie. battery icon, network-manager date/time etc, where are the files located to edit those icons/text for those applets? [09:22] In their respective source packages; gnome-power-manager, network-manager-gnome, indicator-datetime, etc. [09:22] For example i looked through the entire Network Manager applet code for the text "Connect to Hidden Wireless Network..." as an example and I cannot find it anywhere so i am certain that I must be looking in the wrong place? [09:24] RAOF, i did # 'apt-get source network-manager-applet' and looked within the respective packages displayed for that text but I cannot find it. [09:24] I found the XML for the network-manager configuration but not for the applet. [09:34] pitti, hi [09:36] hi tkamppeter [09:42] pitti, it is about the URI migration script for CUPS. To make it working with best reliability one needs to have the user's printers turned on while updating the CUPS package. [09:43] tkamppeter: if they are off, wouldn't the autoconfiguration magic just re-add them if the URI changed? [10:04] pitti, I have to investigate this. I have saved the old URIs which CUPS had given to my printers with usblp, can hand-edit them into printers.conf and then check the system behavior. [10:06] pitti, one problem of re-detection of printers is that the user gets left with old queues which do not work any more and new queues which do not contain the user's individual default settings. [10:07] right [10:07] pitti, by the way, I have fixed the segfault in cups-driverd. The problem was in our patch. [10:07] tkamppeter: it just seems weird to me that they wouldn't have the same IEEE1284 ID? [10:08] pitti, there are the following problems: [10:08] manufacturer, model, etc. certainly shouldn't change? [10:08] 1. SOME of the new URIs have an added &interface=1 at the end when libusb is used. [10:10] 2. For some printers the new URIs have a serial number and the old not, as the libusb interface does not only search for the serial number in the device ID but also in the raw USB communication, to widen the range of printers from which two of the same model can be on one computer. [10:11] 3. My tests have shown that for some HP printers the model name in the new URI starts with "HP " and in the old URI not. [10:12] pitti, these are the discrepancies which I have observed with a sample of 8 HP printers (inkjet and laser, wide range of price classes, 40 EUR to 3000 EUR). [10:13] tkamppeter: do we actually know the device ID of already configured queues? or just the URI? [10:15] pitti, only the URI, see also the fuzzy matching of URIs which I had to do in /lib/udev/udev-configure-printer. So I am very happy that we deprecate usblp, to reduce to one standard access channel. [10:15] ah, too bad [10:15] otherwise we could match the old and new URIs via the device IDs [10:16] pitti, I need to try to read out my printer's device IDs not using CUPS. With this I could probably spot some problems. [10:20] pitti, I have read the device URIS with usblp and the stand-alone tool usb-printerid now and the MDL entries correspond with the URIs of libusb. [10:21] pitti, CUPS does always s/Hewlett-Packard/HP/ which is reducing the mess somewhat. [10:22] oh, fun -- that seems pretty arbitrary? [10:22] but as long as that replacement list is short and fixed, we might duplicate it? [10:23] pitti, for me it looks like that the URI building code in the two versions of the USB backend of CUPS is out of sync. [10:23] tkamppeter: but now we just have one left, right? [10:26] cjwatson: would you agree that we should limit the mail spam about component-mismatch to newly added "source/binary promotion"? the other sections seem like something the AAs/release team can usually deal with themselves [10:26] and having timely notifications for those is not that interesting [10:29] pitti, I am currently looking into "lsusb -vvv", but there are no device IDs. I have to find out how device IDs are read via libusb. [10:31] pitti: yeah [10:32] pitti: perhaps also source-only promotions (which are usually due to some mistake, but even so) [10:33] tkamppeter: what has been the outcome of the "color management" discussion on the Ubuntu side ? [10:34] OdyX, on Ubuntu they principally want color management, but they do not have the time for implementation, so this ends up in either me to introduce the new packages, like colord or someone at Debian. [10:35] tkamppeter: is the scope of "colord" broader than just printing ? (Core question being "would it have a logical place in pkg-printing or should we rather create another packaging team?" [10:36] OdyX, it is broader, color management covers also monitors and scanners. [10:37] tkamppeter: okay; and what number of packages would that be ? 1-3; 10 ? [10:38] I think 1-3 new packages and around 10 updates of existing packages (enable color management support). [10:39] okay, I think we have two options: a) do it "team-less" b) do that in pkg-printing. I'd go for b), with git packaging on alioth. [10:43] OdyX, see https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-icc-color-management, the "Related bugs" are the work items of the Blueprint, and to implement the Blueprint they all need to be fixed, preferrably in both Debian and Ubuntu. [10:44] tkamppeter: the other possibility is to get your packages first in Debian through sponsoring (two of us DDs offered help in that domain) and then sync, no matter where the packaging is VCS-maintained. alioth/git is my prefferred horse, but I can live with anything else. [10:47] OdyX, OK, so I will do the two "needs-packaging" items and commit them to a GIT on Alioth. Can you prepare these gits and tell me how to correctly commit? [10:47] OdyX, if someone comes up to Debian and volunterrs, he is naturally welcome. [10:48] tkamppeter: as you have collab-maint rights, you can create the repositories yourself: http://wiki.debian.org/Alioth/Git#Collab_Maint_project [10:48] OdyX, thanks. [11:08] @pilot in === udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach, Da [11:08] Daviey, can you "/nick Da" and "@pilot out"? ;-) [11:09] (I assume that was you :-)) [11:10] does the bot break if you just change the topic? [11:10] no idea [11:11] james_w, cjwatson: can one of you please mark https://code.launchpad.net/~abone/ubuntu/natty/procps/fix-for-753124/+merge/58905 and https://code.launchpad.net/~akkzilla/ubuntu/natty/gmemusage/gmemusage-fix-370735/+merge/61171 as "work in progress" please? they have both been reviewed already and it'd be good to get them out of the queue [11:17] dholbach: oops [11:18] @pilot out === Daviey is now known as Da [11:18] @pilot out === udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach === Da is now known as Daviey [11:19] * dholbach hugs Da [11:19] ;-) [11:27] james_w, cjwatson: same for https://code.launchpad.net/~chalet16/ubuntu/natty/xorg-server/fix-for-518132/+merge/60297 please [11:27] incidentally, is there anybody else I should be pinging about this? [11:28] LP, so that we don't have to do it any more :-) [11:28] * dholbach hugs cjwatson [11:28] (I'll look when I'm not on my phone which doesn't know my new LP password) [11:29] sure sure - take all the time you need - I'm happy to give you a collated list once you're back === chuck_ is now known as zul [11:47] ping Daviey [11:58] how can I make pbuilder --create reuse existing apt cache in some directory, passing --aptcache does not seem to affect this === MacSlow is now known as MacSlow|lunch [12:09] dholbach: marked those three branches WIP now [12:19] zyga: as debootstrap is used to create the base.tgz for pbuilder, I don't know if pbuilder passes --aptcache to it or if debootstrap supports some sort of cache (besides a proxy) [12:19] geser, yeah, I can see that now, I'm using apt-cacher-ng to see if I can speed things up [12:20] zyga: http://paste.ubuntu.com/622496/ may be helpful [12:20] you could use a wrapper that makes a backup of the debs on first run ... and on subsequent ones you can use the file:// protocol to pull from the backup [12:21] pitti, hi [12:21] zyga: or tell pbuilder that OTHERMIRROR=http://apt-cache-nghost:3142/archive.ubuntu.com/ubuntu === hunger_ is now known as hunger [12:24] hrw, yeah, that will work too! thanks [12:25] hrw, I hope that pbuilder reuses global apt configuration [12:25] zyga: you can configure each base system of pbuilder: "pbuilder --save-after-exit login" [12:26] hrw, yeah but that's now what I'm after [12:26] hrw, I want automated stuff [12:26] but but ... that will make you jobless one day ! [12:26] zyga: on my machine pbuilder unpacks base tarball, do apt-get update/upgrade in it, then builds. after build installs lintian and runs it. then copy results to /var/cache/pbuilder/result/DIST-ARCH/ [12:27] hrw, I'm doing something that may be interesting for you [12:27] zyga: and ~5:00 cron job updates each pbuilder base ssytem to newest packages [12:27] hrw, I'll show it to you in person in dublin [12:27] zyga: ok [12:27] zyga: nice to know that you will get there [12:27] hrw, you don't have to build packages for earlier systems do you? [12:27] zyga: I do lucid/maverick/natty/oneiric/sid here [12:28] hrw, oh good [12:28] hrw, so you feel my pain :) [12:28] hrw, I'm working on something to make it easier [12:28] zyga: pain? "DIST=lucid ARCH=i386 pdebuild" [12:28] hrw, but my use case also has many interdependent packages in the mix [12:28] hrw, yes, pain [12:28] hrw, it's not just that [12:28] hrw, you want to test while developing and release for all easily [12:29] hrw, and not just one package but many [12:29] zyga: inter builds dependencies can be solved by hook which adds results into local apt repo [12:29] hrw, some of which may be required backports, not your own stuff [12:29] zyga: ok [12:29] hrw, I have the same hook but you don't want to go and build each one by hand (even with dozen packages x 4 systems it's already messy) [12:30] hrw, and one more thing: after all this works for you you'd like to be able to reproduce the same setup on another system easily [12:30] hrw, (to do another QA, migrate your workstation, etc) [12:30] for dsc in *dsc;do for dist in lucid natty maverick oneiric sid;do for arch in amd64 i386;do DIST=$dist ARCH=$arch pbuilder --build $dsc;done;done;done [12:31] hrw, ok, which of those failed, why? can I have the logs please? ;-) what is the proper build order to get the interdependent packages to work? [12:31] hrw, can I tag the stuff that works and publish it please? [12:31] hrw, and so on :) [12:31] zyga: build logs are kept for each of them [12:31] zyga: ok, so you make pbuilder/sbuild/buildd in other way? [12:32] hrw, it's a higher-level system [12:32] hrw, it uses pbuilder [12:32] cjwatson, Is a recently introduced (new) package in Debian sync'd using the same process or the normal incremental sync's? [12:32] s/or/for [12:32] hrw, I'm still polishing it for my work but I'll gladly share it [12:33] hrw, how many source packages do you make? [12:43] Daviey: we have a tool to report which new packages in Debian haven't been synced into Ubuntu yet, and while I do garden that list more or less daily it's a while since it's been at zero. What package are you interested in? [12:44] cjwatson, There are a few that jamespage are watching, they've only been in Debian a few days. I suspected it was treated as a sync, so was confused why it hadn't appeared yet. [12:44] No hurry on them tho. [12:44] it's no work to expedite them, just tell me the package names [12:45] * Daviey dig [12:45] s [12:46] cjwatson, thanks a lot! [12:46] Daviey, cjwatson - I just double checked and most of them have now appeared; guava-libraries is the only one I can't see ATM [12:47] jamespage, what about txw2, tiger-types, sezpoz, maven-antrun-extended-plugin ? [12:48] maven-antrun-extended-plugin is there actually [12:48] bah, no it's not. [12:48] Daviey: I did all four of those recently [12:48] Daviey: all there "Ubuntu Archive Auto-Sync 30 minutes ago" [12:49] cjwatson: think that may have been when Daviey and I where discussing where they had got to... [12:49] cjwatson, Ah! I guess they haven't been published yet then. [12:49] jamespage: synced guava-libraries now [12:49] cjwatson: thankyou! [12:49] np [12:50] in fact, looks like you can have binaries for the bulk of those too *clickety* [12:56] cjwatson, allowing just the source packages through sounds like a fun tease. [12:56] Daviey: they inevitably hit NEW at separate times [12:59] cjwatson, when porting to live-build, can you take into account that armel switches to ubuntu-desktop ? [12:59] * ogra_ is wondering if it makes any sense to do that switch in livecd-rootfs at all [12:59] I shouldn't need to. you can just start building for the ubuntu project rather than ubuntu-netbook in cdimage [13:00] if you're having to take account of that explicitly in either livecd-rootfs or live-build, you're doing it wrong [13:01] (is there a spec for this I can go and read?) [13:02] cjwatson, no, no spec, we just want to drop netbook in favour of the desktop seed [13:03] looking at the code though it should just work [13:03] then the right thing to do is switch to the ubuntu project - most package selection depends on the project (aka flavour) you're building, not on the architecture [13:03] yes [13:03] * ogra_ thought we had something hardcoded in livecd-rootfs, apparently we dont, sorry to have pinged you before finishing to read the code :) [13:04] i thought the jasper switch was tied to the flavour, but we tied it to the filesystem type === MacSlow|lunch is now known as MacSlow [13:16] zyga: now I have 12 source packages [13:17] 12 little source packages, sitting on the wall... [13:40] ddebs.ubuntu.com expiry is controlled by some process external to LP that looks at the Packages files on archive.ubuntu.com or similar? [13:40] james_w: correct [13:41] pitti, is that code public somewhere? [13:41] it's meant to be, but just on people.c.c; hang on [13:42] james_w: lp:~pitti/+junk/ddeb-retriever [13:42] pitti, thanks [13:43] pitti, it seems that some ppas now build debug symbols and the refcounting doesn't take them in to account. Would it be a problem in principle to change that so that they aren't expired if the ppa still uses the package? [13:43] james_w: http://bazaar.launchpad.net/~pitti/+junk/ddeb-retriever/view/head:/archive_tools.py#L356 in particular [13:43] james_w: ddebs.u.c. doesn't count PPAs [13:43] perhaps we should just leave this up to the LP project which is likely to move this to be part of LP [13:43] s/count/handle/ [13:44] and frankly, handling the ubuntu archive alone is already way more fragile than I'd like to be :/ [13:44] this really should just go into LP, and AFAIUI it's 90% there [13:44] apparently it does pick up some ddebs from ppas though [13:44] well, yes [13:44] it downloads all ddebs from the buildds [13:44] as it doesn't know/check which builders are for PPAs and which for ubuntu [13:44] right [13:45] That's not good. [13:45] I'll likely wait for LP to do it then [13:45] but as they don't appear in Packages.gz, they wither away quickly [13:45] Ah. [13:45] otherwise I'd need to not just apt-ftparchive one archive, but umphteen thousand [13:46] pitti: hey, so I noticed that the regression-alert alerts various people (it seems like mostly tech leads?), but I think it might need to be updated [13:46] yeah [13:46] jdstrand: ah, if only I'd remember who is responsible for programming ubottu's brain [13:46] ubottu: who is your father? [13:47] hehe [13:47] "Your edit request has been forwarded to #ubuntu-ops." [13:47] * didrocks would have love for an answer to be computed :-) [13:47] heh, that might actually do it [13:47] jdstrand: if you join #ubuntu-ops, there might be people to help out? [13:47] pitti: yeah, thanks! [13:47] didrocks: at least it didn't say "Anakin" [13:48] pitti: heh, right :) === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === pgraner is now known as pgraner-afk === pgraner-afk is now known as pgraner [15:06] pitti, I am not sure the same will happen to the latest packages moved, but rmadison is telling me some of the previous images would be in *-proposed/universe. Could this be some other copy issue? [15:07] linux-image-2.6.35-30-server | 2.6.35-30.53 | maverick-proposed/universe | amd64 [15:08] smb: hm, I can't actually specify a component during copying [15:08] I'll just move it to main for now [15:09] smb: might be fallout from today's LP rollout? [15:09] pitti, I am wondering whether that had been before... I noticed uninstallable kernels yesterday but thought it might be delays [15:10] It seems meta was going to the right place... [15:10] strange [15:10] moved to main, anyway [15:10] pitti, This seems to affect at least lucid and maverick, but I would suspect any of the recent proposed uploads [15:15] smb: right, it seems to have affected all of today's package copies; seems LP changed behaviour there, even for packages which already existed in ubuntu before :/ [15:15] *just* when you think you got everything sorted out [15:15] StevenK: ^ do you happen to know about this? package copies from PPAs to ubuntu now land in universe, even if they exist in main already? [15:16] You know that has to happen when the universe is about to be understood [15:16] yeah [15:17] heh, nice. [15:51] pitti: https://launchpadlibrarian.net/73256289/buildlog_ubuntu-oneiric-i386.eglibc_2.13-5ubuntu1_FAILEDTOBUILD.txt.gz [15:52] pitti: ahh, wait, that not the error [15:55] pitti: can you set a header on those mails so that I can filter them reliably? === dendrobates is now known as dendro-afk [16:13] * apw is upgrading a box to oneiric and being asked if they want to use gdm or lightdm, does lightdm work ? [16:13] apw: I have been able to log this morning, not sure it's the case for everyone :) [16:15] * apw watches libc fail to install ... oh dear [16:18] Laney: sure, any preference? [16:18] nope [16:18] X-UbuntuRelease: component-mismatches or something [16:20] you might consider sending to the list too [16:20] :-) [16:20] Laney: hm, good point, I'm subscribed [16:21] Laney: changed to ML now [16:22] cool [16:22] thanks for doing this - will be useful === dendro-afk is now known as dendrobates === zyga is now known as zyga-afk-bbl-sry [16:46] @pilot out === udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === ogasawara_ is now known as ogasawara === deryck is now known as deryck[lunch] [17:36] hi guys !!! [17:36] hello! [17:39] chrisccoulson: how do build firefox global menu extension ? [17:39] DoctorPepper, why would you want to do that? we already provide binaries [17:40] unless you're hacking on it of course ;) [17:41] actually i am trying to create a package for fedora [17:41] DoctorPepper, it won't work in fedora will it? [17:41] unless there are also packages for the other bits of the unity stack [17:42] i don't know if that's the case though ;) [17:43] actually i was told that i would work with gnome2-globalmenu [17:43] DoctorPepper, hmmm, i'm not sure about that [17:43] i've certainly never tried it ;) [17:44] so how to generate the makefile so as to build this exention [17:44] DoctorPepper, well, you need to run autoconf2.13 in the source directory first [17:44] then ./configure --enable-application=extensions --enable-extensions=globalmenu --with-libxul-sdk= --disable-libnotify --disable-crashreporter --disable-tests --disable-webm --disable-ogg --disable-alsa --disable-strip --disable-strip-libs [17:44] then make ;) [17:45] you just need to point it to whereever your firefox SDK is [17:45] note that this extension uses a lot of volatile interfaces in firefox, so it will probably need rebuilding for each new firefox version [17:46] build/autoconf/acwinpaths.m4:44: error: defn: undefined macro: AC_OUTPUT_FILES === dholbach_ is now known as dholbach [17:47] chrisccoulson: running autoconf i get this message : ' build/autoconf/acwinpaths.m4:44: error: defn: undefined macro: AC_OUTPUT_FILES ' [17:47] what version of autoconf? [17:48] 2.68 [17:48] you need 2.13 [17:48] it uses the firefox build system, which only works with 2.13 [18:01] @pilot [18:02] (pilot (in|out)) -- Set yourself an in or out of patch pilot. [18:02] @pilot in === udevbot changed the topic of #ubuntu-devel to: Oneiric Alpha 1 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kees [18:02] @pilot in [18:02] kees, testing the bot? ;-) [18:02] * dholbach hugs kees [18:03] dholbach: hehe, well, I'm doing a double-shift, and that made me wonder if it would append me twice. :) [18:03] haha :) === deryck[lunch] is now known as deryck [18:22] linux 3.0-0.1 (Accepted) .... [18:22] Thats just.. weird.. [18:22] ;) [18:22] heh [18:23] I'd better go fix the installer soon, now that I have example packages to work from :-) [18:32] hallyn: hey, fyi I am back to testing libvirt. attach-disk also fails in a similar as the 'phy' vs 'qemu' thing you fixed. eg, this used to work: [18:32] attach-disk vmname /tmp/foo.img sdc --driver=file [18:32] that now has to be: [18:33] attach-disk vmname /tmp/foo.img sdc --driver=qemu [18:33] hallyn: I don't know how that might affect openstack or euca, but it is worth noting [18:40] Daviey: zul: I'm basically out as of this afternoon, can you two llok at uec and openstack wrt jdstrand's comment? i'd assume openstack folks would have noticed... [18:41] hallyn, Daviey, zul: fyi, this is 0.9 specific, which I plan to upload later today [18:41] * jdstrand needs to double-check natty [18:41] jdstrand: thanks [18:41] hallyn: ack [18:42] hallyn: afaik openstack doesnt use libvirt to attach disks [18:42] zul: I suggest we run the test suite.. and see if anything breaks :) [18:42] Daviey: well duh :) === jibouman` is now known as jiboumans [18:43] heh [18:47] zul: ok, then I'll ping you after I've uploaded [18:47] chrisccoulson: i manage to buid firefox globalmenu extesion but in i found that there is no make install command so where should i put the compiled files [18:48] jdstrand: thanks, there is an open mir to get libxen3-dev replaced with libxen-dev so we can use xen 4 with libvirt and therefore dropping xen-3.3 from the archive [18:48] DoctorPepper, there will be an extension in dist/xpi-stage [18:48] cool [18:49] jdstrand: i need to bug/bribe kees about it though [18:49] yes so i only install the xpi everything should be in the right place [18:49] yep [18:54] chrisccoulson: i havent found any xpi extension package in dis/xpi-stage [18:56] DoctorPepper, it will be there if it built successfully [18:59]