[00:03] How do I import a new upstream tarball using bzr-builddeb!? [00:03] I'm completely failing to grok how to make this happen, even after reading the sourcecode a bit [00:06] maxb:I posted to udd [00:06] maxb: bzr merge-upstream is the comand you need. [00:07] maxb: and you need to commit after that to record the change (but resolve any conflicts fist) [00:07] I read it's help message, and couldn't figure it out. I read its sourcecode and still couldn't make it work [00:07] details [00:09] I've found your mail wherein you suggest you have to build the new source manually and then import-dsc it [00:09] which is... not intuitive, shall we say === robbiew is now known as robbiew-afk === dendrobates is now known as dendro-afk [00:16] Hmm.... and now it has gone and imported the debian directory into the upstream branch? [00:17] maxb: hangong [00:17] maxb: firstly, 'does not work' is about as useful as a first time cygwin user asking for help. [00:17] you can do better :) [00:18] What I would like, is to know how someone learning bzr-builddeb is supposed to get started. [00:18] Because at the moment it seems to be substantially impenetrable [00:19] I agree [00:19] I nearly wrote a complete replacement for merge-upstream [00:19] but right now, I want to help you use it. [00:19] if you can just describe what you've tried, and what happens when you do, I may be able to help. [00:20] Ok: I have a branch. I have a new upstream tarball. What is the most basic thing I should do next? [00:20] is the branch a packaging import branch, or something else? [00:21] It's rather a something else. It's a bzr-git pull of the debian packaging [00:21] ok [00:21] so firstly, bzr-builddeb as packaged has bugs that will make it impossible to diagnose what you will encounter. They don't trigger so much on package import branches. [00:22] so, you'll want to bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb [00:22] already running trunk [00:22] or do a pull - the fixes were merged last night [00:22] pulled, no changes [00:22] ok, cool [00:23] secondly, does the branch you have in front of you contain the full source [00:23] or only the debian dir ? [00:23] yes [00:23] full source [00:23] ok, thats good. [00:23] now, does it have an upstream-CURRENT_UPSTREAM_VERSION tag [00:23] (bzr tags) [00:24] yes, it does [00:24] e.g. upstream-1.2.3 [00:24] merge-upstream makes a child of that tag as part of its work. [00:25] what command did you run, when you expressed surprise at an upstream code dump being done? [00:25] bzr merge-upstream ../tortoisehg-0.9.1.tar.gz --version 0.9.1 [00:26] ok. what that should have done, if you look at bzr st is, [00:26] created a pending merge from a commit 'new upstream 0.9.1' [00:26] updated debian/changelog [00:26] and done a merge of all the upstream source files that are contained in that tarball [00:28] maxb: if thats the case, then when you run 'bzr commit' you'll have done the bzr equivalent of 'uupdate'. [00:28] maxb: further, 'bzr diff -r tag:upstream-0.9.1' will show you the current packaging delta. [00:28] Except the new "Import upstream version 0.9.1" commit actually contains an addition of all the debian/* files in my current working tree, instead of any upstream updates [00:29] maxb: did you start with a clean tree? [00:29] yes [00:30] how are you determining that that is what the upstream commit contains? [00:32] bzr qlog.... but it seems my previous grappling with merge-upstream managed to replace the upstream tarball with one containing my debian dir! [00:32] * maxb redownloads, reverts, retries [00:32] if you have altered tags you will need to zap those, or start with a fresh branch. [00:36] hmm, sorry if I was grumpy before, it was meant to be humour emphasis. [00:36] ok... so actually it seems it does work now, and something in my previous flailing had caused it to overwrite my upstream tarball with a nonsense one [00:36] excellent [00:37] the revision tagged upstream-0.9.1 contains pristine tar metadata in a revision property. [00:39] I think I should go pore over the sourcecode at some point when I'm not actually trying to achieve some packaging and write a wiki page about it [00:39] totally [00:40] the biggest problem I had was having no model of the bits inside [00:40] so I couldn't guess at commands or solutions. [00:40] sadly I haven't had time to write up my learnings yet === asac_ is now known as asac [00:58] Does it make more sense to discuss changes to bzr-builddeb on ubuntu-distributed-devel@ or bazaar@ ? I'd like to try to sort out some of the copy-and-paste code from bzrtools === dendro-afk is now known as dendrobates === mbarnett changed the topic of #ubuntu-devel to: **Launchpad will be down/in read-only from 01:30 UTC until 02:30 UTC for a code update ** Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubunt [03:23] where's doko? is he on vacation or something? [03:31] Ryan52: He was on vacation last week and he's sick now. [03:31] (conference the week before) === mbarnett changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubunt [03:35] mbarnett: missing the last u in /topic [03:35] Ryan52: ta! === mbarnett changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu [03:36] ScottK: ugh, okay, thanks. [03:37] * Ryan52 needs his advice :( [03:39] !ops [03:39] Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom! [03:39] Haha. Congratulations - you got what you wanted [03:40] sigh, cyto is back. Can we ship them a psychiatrist? [03:40] lifeless: or make them play in the traffic. i wish [03:42] Hobbsee: we need a kline [03:42] he'll just rotate through ubuntu-kernel, ubuntu-motu etc. [03:42] lifeless: i know. if i could hand them out, this guy would be history.. [03:42] will likely reappear with the same hostmask, too [03:42] vorian: ^ (pici) [03:43] vorian: I hate to bug you, but you're the only staffer I know :) [03:43] lifeless: We're taking care of it [03:43] Pici: thanks [03:44] Pici: I didn't mean to nag:) [04:28] slangasek: do your speakers pop on reboot/shutdown, too? [04:48] Hmm...is there any standard advice for how to deal with the Maintainer/Original-Maintainer fields in Ubuntu derivative distributions? [04:49] (Options we're currently debating include "Original-Original-Maintainer" and dropping the maintainer if original-maintainer is already set, since the maintainer in that case isn't likely to contain a lot of information) [04:53] ebroder: you should probably move the the Maintainer to Original-Maintainer, and set whoever maintains the package in the derivative as the Maintainer [04:54] tsimpson: What if there's already an Original-Maintainer? Frequently in that case, the Maintainer is just "ubuntu-motu" or "ubuntu-devel", which is far less interesting, unique, and informative than the Debian maintainer listed in Original-Maintainer [04:55] ebroder: the original Original-Maintainer should be dropped then probably [04:56] the reason we have Original-Maintainer is because Debian wanted to make sure they got some attribution for the packaging [04:57] tsimpson: Sure, and if we re-package your re-packaging, presumably that doesn't change the fact that the Debian maintainer is interested in attribution [04:57] there is no need to keep adding Original-XYZ every time someone forks the package [04:59] ebroder: if you want, keep the Original-Maintainer as the debian maintainer, and change the Maintainer to your packagers [04:59] tsimpson: I actually just had the thought of putting both the Debian maintainer and the Ubuntu maintainer in our XSBC-Original-Maintainer, comma separated [05:00] if you want to be really nice, mention that you derive from the Ubuntu package in the debian/copyright [05:00] ebroder: it should be a single field, in the exact form "Packager Name " [05:01] tsimpson: That's not actually specified anywhere in policy for Original-Maintainer (it is for Maintainer) [05:01] (Unless it is and I just haven't found it yet) [05:01] but it's derived from Maintainer [05:01] so anything in there needs to be compatible, right? [05:02] but I think my second suggestion is closer to what you want. replace the Maintainer field, and mention in the debian/copyright that the package is derived from the Ubuntu package [05:02] that way, everyone gets attribution [05:02] tsimpson: That process is harder to automate :) [05:02] and the right contact is set [05:03] ebroder: 'cat "This package is derived from Ubuntu" >> debian/copyright' ;) [05:03] though you'll probably want to put a link or something in there too [05:04] tsimpson: I'm having a hard time understanding why Original-Maintainer should be format-compatible with Maintainer - as I see it, it's some made up field we happen to have standardized, but has no meaning through policy, and presumably no software with format expectations [05:04] but just a note at the end saying that it's based on Ubuntu is perfectly fine [05:05] ebroder: you don't know that no software anywhere doesn't use it in some way [05:05] well, you do already know that lintian uses it [05:05] This is true. I might be willing to take that chance, though. I can certainly make arguments about the /types/ of software that would care about the Original-Maintainer [05:05] how will it react to a comma separated list? [05:06] Most of the types of software that might care are p.u.c, lintian, etc - developer tools, not user tools. It's more OK if those break [05:06] if developer tools break, you'll have an even harder time packaging [05:09] Eh - but I find it unlikely. Incidentally, I checked lintian - it doesn't currently do any checks for original-maintainer other than making sure it isn't there if the version number doesn't match /ubuntu/ [05:09] it checks that it has an @lists.ubuntu.com address if it does have ubuntu changes [05:10] That's Maintainer, not Original-Maintainer [05:10] oh yeah, right [05:10] What other things are there that care about Original-Maintainer besides p.u.c? That's all I can think of at the moment... [05:11] it's mostly for decoration [05:11] p.u.c can already deal with multiple Uploaders, so presumably it wouldn't be hard to extend it to deal with multiple Original-Maintainers, even if it doesn't now [05:11] but adding yet-another-field feels wrong to me [05:11] (Also, my derivative isn't currently using p.u.c against our repo) [05:12] I don't see why you need to have multiple original maintainers anyway [05:14] For the same reason that you have Original-Maintainer in the first place - we want to show the parentage of our modified packages, without implying that they're not our responsibility [05:15] what's wrong with just adding it to debian/copyright or debian/README [05:15] ? [05:15] Why didn't Ubuntu do that for Debian packages? [05:16] probably because Debian wanted otherwise [05:17] ebroder: the Original- prefix was added later so that some non-Ubuntu DDs would not risk getting further debbugs/etc automated reports [05:18] sladen: Sure, and I realize that specific motivation is largely gone now that ubuntu doesn't ship reportbug [05:19] ebroder: there's a little bit of coverage on http://wiki.debian.org/Xcontrol [05:20] sladen: Interesting - I hadn't seen that page [05:21] sladen: But the page seems to be a bit short on actual ideas for solving the Original-Maintainer problem [05:26] ebroder: what /is/ broken? [05:26] ebroder: the ideal would be not to modify it---to preserve the credit where credit is due [05:26] sladen: The problem of wanting to give credit to the Debian and Ubuntu maintainers without implying responsibility [05:54] There was actually a poll among DD's to help set the policy [05:55] ebroder and sladen: https://wiki.ubuntu.com/DebianMaintainerField is a more detailed history. [05:55] ScottK: I did read that [05:56] The biggest problem with not changing the maintainer field is that we'd get the derivatives bugs. [05:56] People do regularly mail the maintainer with bugs/questions. [05:57] IMO a derivative's users bugs/questions are their problem, not mine. [05:57] ScottK: I totally agree [06:03] ScottK: But people also file Linux Mint bugs against Ubuntu, so I'm not sure the maintainer is much of a problem. [06:03] wgrant: I also mark them invalid unless they can explain why they think the apply to Ubuntu. [06:05] I know nothing about Linux Mint and what they change or don't change. [06:05] wgrant: Please change them to be against 'linuxmint', rather than marking invalid [06:05] sladen: That was me. [06:05] ScottK: https://bugs.launchpad.net/linuxmint [06:06] sladen: Usually it's an Ubuntu task added to a derivative's bug (I actually see this as much or more with baltix (although not recently) [06:06] sladen: I don't think it would be appropriate for me to say something is a bug in linuxmint. I don't know anything about it. [06:07] ScottK: you're not decreeing it; you're redirecting it to the appropriate project [06:07] I don't see it that way. [06:08] It I mark a bug as applying to a project, I think that means that I think that the bug applies to the project. [06:08] ScottK: Ubuntu and Mint happen to use not just the same bugtracker, but the *same instance* of a bug tracker [06:08] It's hardly worth arguing about because except for Baltix and backports bugs (which I never understood) I find it rare. [06:09] sladen: I understand that. [06:09] That choice doesn't give me any insight into what may, or may not, be a bug in linuxmint. [06:09] ScottK: marking it Invalid results in an alienated user; redirecting a mis-filing is instead a progressive, helpful engagment [06:10] sladen: Not my user. [06:10] I know that sounds harsh, but i really can't solve the world's problems. [06:10] if a person filed a bug in the Linux Mint bug tracker (also the Ubuntu bug tracker) with the wrong meta-data, that's a keying/understanding error---not something invalid [06:11] Could be. [06:11] I get enough Ubuntu bug mail without trying to sort out ones that belong to other distros. [06:12] ScottK: the same happens with Ubuntu One bugs filed against Ubuntu, and Ubuntu bugs filed against Ubuntu One (same instance of a bug tracked, shit UI) [06:12] That one I know a little more about and can, in fact, sometimes have a useful opinion about. [06:12] ScottK: sorry, I thought in the cases you were aware they were filed against Linux Mint [06:13] sladen: It is. [06:13] I just have no idea how or if they should be applied somewhere else or not. [06:13] indeed [06:14] The fact that some Ubuntu derivates choose to use the same bug tracker as Ubuntu does not create a moral obligation for me to care about their bugs. [06:15] But it's late here and I need to get to bed, so have a good day/night (whichever it happens to be) === cjwatson changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs === cjwatson changed the topic of #ubuntu-devel to: Ubuntu 9.10 now playing in a theater near you | Archive: lucid open for uploads! | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs === Zic_ is now known as Zic [07:54] good morning === Epigram is now known as Epigene [08:36] Good morning [08:41] * pitti goes to fix the runaway input_id process in udev 148, sorry for that [08:42] * jussi01 hugs pitti [08:49] mvo: hi! around? [08:56] hey free, yes [08:56] mvo: I was testing a non interactive upgrade from dapper to hardy, and I think I've hit a bug in the upgrade tool script.. http://pastebin.com/m4431c1e8 [08:57] free: thanks! let me check [08:57] mvo: it looks like the solution would be as easy as adding the [NonInteractive] stanza to DistUpgrade.cfg.dapper [08:57] mvo: with ForceOverwrite=no, as in DistUpgrade.cfg [08:59] free: thanks, let me fix it in the code. [08:59] free: the trunk/ version of u-m is not well tested yet with dapper->hardy (it may have regressed since the hardy version of u-m was released). so its probably best to use the hardy version of the upgrade tool for dapper->hardy (or do you see the bug there as well?) [09:00] mvo: I used the hardy script from http://archive.ubuntu.com/ubuntu/dists/hardy-proposed/main/dist-upgrader-all/0.87.30/hardy.tar.gz [09:00] [09:01] free: oh, thanks. thats a bug there then too :/ [09:01] * mvo scratches his head [09:01] mvo: on a dapper minimal system, kvm [09:02] mvo: there's also another problem I'm trying to understand, but couldn't yet [09:02] free: thanks, either you need to modify the DistUpgrade.cfg.dapper in the way you described in landscape then or we need to do a SRU to fix the bug [09:02] free: what is it? [09:02] mvo: with the modification suggested the script moves on, but fails with this https://pastebin.canonical.com/25309/ [09:03] (sorry pastebin.com is rejecting it as spam) [09:03] free: the crash in the earlier pastebin is fixed in trunk/ now, many thanks [09:03] mvo: cool [09:03] mvo: however the network is okay, wget-ing the Packages.bz2 manually and checking the md5sum looks okay [09:04] free: uh, hash-sum mismatches - are you behind a proxy of some sort? [09:04] mvo: nope, doesn't really seem a network problem, as said it works with wget [09:04] mvo: oh well, I'm in a NAT but that shouldn't matter [09:05] no, NAT should be fine [09:05] mvo: I can try from an ec2 instance if needed [09:05] free: give me a sec, I need to think how to add debug output to it [09:06] mvo: thanks a lot [09:06] mvo: I'm not sure but I think that code is inside some backport package which is downloaded at runtime? [09:07] yes [09:08] free: can you login into the machine with the failure? or is it "destroyed" after the failed upgrade attempt? [09:08] mvo: I'm in [09:08] oh, cool [09:08] mvo: it's up and working, the script just fails gracefully [09:09] mvo: if you feel better, I can give you the ubuntu-vm-builder command line used to build the KVM machine, so you can reproduce it on your side fairly easily, I guess [09:09] free: could you please add http://paste.ubuntu.com/333734/ and run it again? [09:10] free: should be in /tmp somewhere [09:10] mvo: I'm truing [09:13] mvo: hmm, I can't find that file [09:13] free: nothing with "find /tmp -name "dist-upgrade.py" ? [09:14] mvo: nope [09:14] mvo: the only file with that name is in the root of the extracted hardy.tar.gz [09:15] but it looks like a different one [09:15] oh, sorry. please try that one then, it probably changed a bit, my diff is against trunk/ [09:15] but that should not matter, the apt_pkg stuff will work [09:15] oh okay [09:15] and give lot of debug output of the http transfer [09:16] free: I see if I can find a dapper image in the meantime [09:17] mvo: probably an ec2 instance would do it as well [09:17] mvo: the log seems to be the same, no additional info [09:18] oh wait, my modifications got overwritten [09:19] I think I have to put them in ./hardy instead of ./dist-upgrade.py [09:19] yes, better now [09:22] mvo: http://people.64studio.com/~free/output [09:26] free: hm, that looks ok :/ could you please also add "apt_pkg.Config.Set("Debug::pkgAcquire::auth","true") ? [09:27] mvo: sure [09:28] mvo: done, please just refresh the link above [09:30] there are a couple of HTTP/1.1 206 Partial Content at the end [09:32] free: and some empty RecivedHash entries. I think I need to try to reproduce this locally, could you please give me the vm-builder commandline you used? [09:32] mvo: yes, hold on [09:34] free: could you please rm /var/lib/apt/lists/* /var/lib/apt/lists/partial/* and give me the output afterwards as well ? [09:34] (in a different file if possible so that I can compare) [09:34] mvo: something like sudo ubuntu-vm-builder kvm dapper --mirror=http://it.archive.ubuntu.com/ubuntu --ppa=landscape/ppa --addpkg=landscape-client --addpkg=openssh-server [09:35] mvo: the --ppa=landscape/ppa shouldn't be relevant [09:35] thanks [09:37] mvo: http://people.64studio.com/~free/output2 [09:39] ubuntu-vm-builder is running [09:39] * mvo waits patiently [09:42] mvo: once you have the VM, what I did was basically wget http://archive.ubuntu.com/ubuntu/dists/hardy-proposed/main/dist-upgrader-all/0.87.30/hardy.tar.gz, untar and then ./hardy --frontend DistUpgradeViewNonInteractive (with the .cfg.dapper fix mentioned above) [10:15] cjwatson, qt4-x11 ... bah, thats unfortunate [10:21] wgrant: so there was a LP rollout yesterday? Any idea whether this brought support for 3.0 format packages? [10:22] [dpkg-source output:] dpkg-source: error: Unsupported format of .dsc file (3.0 (quilt)) [10:22] pitti: The rollout failed. [10:22] apparently not [10:22] pitti: And no, it didn't quite land. Reviews, etc. [10:22] But 3.1.12 is in two weeks. [10:22] :( [10:22] thanks [10:24] Hello there! Noob speaking [10:25] Is this the right place to ask for help regarding building gtk+? [10:26] nvm, found the gtk+ channel :p [10:28] dtchen: I don't recall [10:42] hi [10:42] i am looking to develop a boot from wifi system [10:43] by keeping an initrd+kernel at client [10:43] and root filesystem at the serversude === jelmer_ is now known as jelmer [10:43] then client will mount the serverside root filesystem via wifi and chroot and execute further [10:43] is there some problem in implementing this ? [11:05] * seb128 kicks karmic and grub2 creating invalid winxp boot stanzas [11:05] seb128: still fighting with your uncle's computer? [11:05] t3rm1n4l: isn't that pretty much what ltsp already provides for ethernet? [11:06] pitti, no, my parents one this morning [11:06] I installed karmic which broke winxp boot [11:06] it doesn't chain on the right disk or something [11:06] a found a grub entry to put manually on the forum which works now [11:06] pitti: i need to implement it through wifi [11:07] t3rm1n4l: right, that's why you need a local kernel/initrd; but ltsp still provides loading of the root fs, chroot building, remote mounting, etc. [11:08] but ltsp wont work in wifi right ? [11:09] t3rm1n4l: I'm not a specialist (ogra, stgraber), but I don't see a reason why it wouldn't, once you set up wifi on the client side [11:09] t3rm1n4l: the PXE/kernel/initrd loading won't work, of course [11:09] there is no PXE for wifi [11:09] BIOSes usually don't support that [11:09] yea [11:09] it can be implemented easily right ? [11:09] use a wifi bridge [11:09] no [11:09] it cant [11:09] ogra: right, but once you set that up locally (local kenel/initrd), can you use it to load the chroot, etc.? [11:10] yes [11:10] that is my idea [11:10] mount root filesystem using sshfs [11:10] free: fun! (well, not) - dappers ssh keeps crashing in my lucid kvm, might be a kvm issue, i have seen those before, but makes testing hard :( [11:10] you need either local media with kernel and a specifically hacked up initramfs or a wifi bridge [11:10] beyond that its highly insecure [11:10] mvo: ouch [11:11] free: I will re-try on my karmic system after lunch [11:11] sorry [11:12] pitti, yes, but indeed you have to promote your wifi keys publically to the world in your rootfs for i.e. reconnects [11:12] we never implemented it in LTSP because there are to many security holes [11:12] sure [11:13] I had assumed this was for open wifis anyway [11:14] hey lovely people. I know that packages in Debian unstable automatically trickle into Ubuntu, but I haven't managed to find the page that describes the timing. When does a package have to make it into "sid" in order to make it into "Lucid Lynx"? [11:16] t3rm1n4l, pitti, there is no point in using sshfs though ... since you have to make both keys public anyway [11:16] use nbd or nfs [11:16] okay [11:17] i am looking at it as my academic project [11:17] have a look at the ltsp_nbd initramfs script in the ltsp-client-core source package [11:17] okay [11:17] you can just add the wifi stuff there and indeed need to somehow get the key into the initramfs [11:17] thanks [11:18] Could someone help me with patching a few xorg files with .patch files and building xorg or making a package with the files? [11:19] from this lovely picture I gather that alpha one is in a few days: http://anotherubuntu.blogspot.com/2009/11/lucid-lynx-timeline.html [11:20] do I need to do anything to get my package in there? [11:52] james_w: pristine-tar failed for lp:ubuntu/portma [11:52] +p [11:54] mvo: no worries! [11:57] pitti: jockey is crashing on live desktop startup are you aware of this? [11:57] davmor2: in lucid? [11:57] yes [11:57] dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Error parsing subject struct [11:57] davmor2: yes, I am; some weird regression in polkit, haven't found time to track it down yet [12:00] pitti: this bug Bug 491429 so we are on the same page [12:01] Launchpad bug 491429 in jockey "jockey-gtk crashed with DBusException in call_blocking() (dup-of: 403955)" [Undecided,New] https://launchpad.net/bugs/491429 [12:01] Launchpad bug 403955 in jockey "jockey crashed during installation of xubuntu, apparently no effect on the installation, which continued normally" [Medium,Incomplete] https://launchpad.net/bugs/403955 [12:02] davmor2: thanks [12:02] davmor2: hm, that's for karmic [12:02] that bug doens't affect karmic [12:03] pitti: the first one isn't though it's lucid [12:04] pitti: the one that retrace duped it as is karmic === MacSlow is now known as MacSlow|lunch [12:31] will source format 3.0 (quilt) packages be supported in lucid? [12:32] porthose: they actually already are since ages, it's just that launchpad doesn't accept them yet [12:33] siretart, ty :) [12:34] siretart, I was just wondering, one of the packages I look after in debian, someone did a fakesync from debian sid and removed the 3.0 formating :( [12:37] porthose: AFAIUI that feature is already implemented in launchpad and 'just' needs deployment [12:37] that's the way to do it currently [12:37] apparently the LP rollout is on the 11th [12:38] Laney, so we create a delta instead of just waiting until the 11th? [12:38] if you want the package in [12:38] Laney, Ok ty for explaining :) [12:39] to anyone doing gnome-dev work on karmic, are you using jhbuilb from source or from jaunty? [12:40] *jhbuild [12:47] there are now 44 X packages waiting to be synced ;) [12:47] protos, libs [12:50] /usr/share/gnome-pkg-tools/1/rules/check-dist.mk:19: Unknown distribution: lucid [12:50] ... we should really fix that === statik` is now known as statik [13:00] ogra, it's only a warning, the rules is to avoid to upload experimental packages to unstable [13:00] it's of no use on ubuntu [13:00] ah === chuck_ is now known as zul === rgreening_ is now known as rgreening [13:23] any library packaging gurus around that has fun with analysing a library problem involving transitive library dependencies and symbol versioning? slangasek perhaps? [13:23] * slangasek warbles [13:23] siretart`: Sounds like you need to drag sistpoty back. [13:24] slangasek: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/100196 is the upstream thread with full context. Michael Niedermayer is the lead of ffmpeg and claims that either the gnu linker or debian's ld is just 'too' broken for this situation [13:25] I try to argue against, but I cannot really call myself an expert when it comes to symbol versioning. [13:25] siretart`: do I have to actually read this thread, or can I just jump straight to the conclusion that ffmpeg upstream is crazy? [13:26] slangasek: http://article.gmane.org/gmane.comp.video.ffmpeg.devel/100343 is the relevant mail. the rest is only for full context [13:27] the first mail explains the exact situation, the longer thread is probably not that instersting here, it shows my results with experimenting with symbol versioning [13:28] siretart`: what you appear to need is not somebody who enjoys analyzing library linkage issues, what you need is someone with the time and energy to set your upstream straight [13:28] highlight from that mail: "Possibly RTLD_DEEPBIND could solve the problem. Drepper is quite vocal [13:28] on arguing against it which is a sign that this might be the right direction." [13:30] slangasek: I'd be willing to go that way, and actually already started to do so, but now I'm at a point where my experience with thist stuff endds [13:30] RTLD_DEEPBIND doesn't solve the problem, because a) it applies only to dlopen(), b) it applies to intra-library symbol lookups only [13:31] symbol versioning is a longstanding and well-understood solution to this problem [13:32] "Either way, ffmpeg isnt the only thng that seems to have been hit by this" - correct, and other libraries that get hit by this are reasonable about implementing symbol versioning [13:33] slangasek: thanks, that helps me to draft an answer [13:33] kirkland: hi, are there any known issues with kvm in lucid currently? my auto-upgrade tester with the lucid kernel as host is having some trouble it seems, seems to be hanging in FUXTEX_WAIT_PRIVATE (this is with virtio in the client) [13:34] mvo: hmm, i haven't uploaded a new kvm yet to lucid [13:34] slangasek: just a last question, in http://article.gmane.org/gmane.comp.video.ffmpeg.devel/100328, I notice that some functions (av_packet_*) have been moved from libavformat to libavcodec [13:34] mvo: sounds like a lucid kernel bug with virtio [13:34] slangasek: upstream claims this move of symbols is no ABI breakage, since libavformat links against libavcodec [13:35] question: should libavformat's SONAME be bumped or not? [13:35] siretart`: should not - but your symbol versioning therefore needs to take this into account [13:35] otherwise, the symbol versioning /itself/ introduces an ABI break [13:36] kirkland: thanks. probably, I was just curious if it was anything you might know about [13:36] I see [13:37] * mvo will just use the karmic kernel in the meantime [13:37] mvo: i don't; please file a bug, though [13:37] ok === MacSlow|lunch is now known as MacSlow [13:38] mvo: The guest is Lucid as well? [13:39] soren: hardy (its currently testing hardy->lucid) [13:41] mvo: oh, wait ... [13:41] mvo: guest is hardy? [13:41] virtio is a communication channel between the guest kernel and the host userspace. I think it's extremely unlikely to be a Lucid kernel bug. [13:41] * kirkland checks something [13:42] mvo: what version of qemu-kvm is on the lucid host? [13:42] mvo: actually, what is the host running? [13:42] kirkland: 0.11.0-0ubuntu6.3 [13:43] oh, but kvm-source is installed, could this be the problem? [13:43] mvo: hmm, yeah ... that would constrain you to running a much older kernel kvm module than karmic's [13:44] mvo: ie, kvm-source no longer exists in karmic [13:44] mvo: so you're running a jaunty-or-older kvm module [13:44] thanks, I will remove it [13:44] mvo: fwiw, that version, 0ubuntu6.3 specifically fixes a problem with virtio with hardy guests [13:44] if its actually causing problems, I can add it to update-manager so that it will ensure its getting removed on upgrade [13:44] mvo: cool, thanks. [13:46] kirkland: thanks, commited [13:47] mvo: cheers [13:47] mvo: hey, i have another one for you, btw .... [13:47] mvo: i don't think /etc/update-motd.d/91-release_upgrade is ever being run [13:47] mvo: because pam_motd uses run-parts --lsbsysinit [13:48] mvo: which, I think, dislikes "_" [13:48] mvo: i *thought* i committed a fix for that sometime during karmic, but doesn't look like it's there any more [13:48] oh, hrm. let me fix it in bzr [13:49] mvo: this might be worth an SRU, at some point, so that karmic users get the upgrade notification in MOTD once lucide releases [13:50] * mvo nods [13:50] mvo: What are /var/cache/apt/{src,}pkgcache.bin for? [13:51] soren: its the mmap cache of the package data, why? [13:51] soren: if its not there, it will just rebuild it (or build it in memory if it can not write there) [13:52] mvo: I just noticed it's taking up 24 MB of space in my VM images. [13:52] mvo: That's what I wanted to hear. Yay. [13:52] * soren fiddles with vmbuilder some more [13:52] mvo: Thanks. [13:53] :) [14:09]