[00:03] <maxb> How do I import a new upstream tarball using bzr-builddeb!?
[00:03] <maxb> I'm completely failing to grok how to make this happen, even after reading the sourcecode a bit
[00:06] <lifeless> maxb:I posted to udd
[00:06] <lifeless> maxb: bzr merge-upstream is the comand you need.
[00:07] <lifeless> maxb: and you need to commit after that to record the change (but resolve any conflicts fist)
[00:07] <maxb> 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] <lifeless> details
[00:09] <maxb> I've found your mail wherein you suggest you have to build the new source manually and then import-dsc it
[00:09] <maxb> which is... not intuitive, shall we say
[00:16] <maxb> Hmm.... and now it has gone and imported the debian directory into the upstream branch?
[00:17] <lifeless> maxb: hangong
[00:17] <lifeless> maxb: firstly, 'does not work' is about as useful as a first time cygwin user asking for help.
[00:17] <lifeless> you can do better :)
[00:18] <maxb> What I would like, is to know how someone learning bzr-builddeb is supposed to get started.
[00:18] <maxb> Because at the moment it seems to be substantially impenetrable
[00:19] <lifeless> I agree
[00:19] <lifeless> I nearly wrote a complete replacement for merge-upstream
[00:19] <lifeless> but right now, I want to help you use it.
[00:19] <lifeless> if you can just describe what you've tried, and what happens when you do, I may be able to help.
[00:20] <maxb> Ok: I have a branch. I have a new upstream tarball. What is the most basic thing I should do next?
[00:20] <lifeless> is the branch a packaging import branch, or something else?
[00:21] <maxb> It's rather a something else. It's a bzr-git pull of the debian packaging
[00:21] <lifeless> ok
[00:21] <lifeless> 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] <lifeless> so, you'll want to bzr branch lp:bzr-builddeb ~/.bazaar/plugins/builddeb
[00:22] <maxb> already running trunk
[00:22] <lifeless> or do a pull - the fixes were merged last night
[00:22] <maxb> pulled, no changes
[00:22] <lifeless> ok, cool
[00:23] <lifeless> secondly, does the branch you have in front of you contain the full source
[00:23] <lifeless> or only the debian dir ?
[00:23] <maxb> yes
[00:23] <maxb> full source
[00:23] <lifeless> ok, thats good.
[00:23] <lifeless> now, does it have an upstream-CURRENT_UPSTREAM_VERSION tag
[00:23] <lifeless> (bzr tags)
[00:24] <maxb> yes, it does
[00:24] <lifeless> e.g. upstream-1.2.3
[00:24] <lifeless> merge-upstream makes a child of that tag as part of its work.
[00:25] <lifeless> what command did you run, when you expressed surprise at an upstream code dump being done?
[00:25] <maxb> bzr merge-upstream ../tortoisehg-0.9.1.tar.gz --version 0.9.1
[00:26] <lifeless> ok. what that should have done, if you look at bzr st is,
[00:26] <lifeless> created a pending merge from a commit 'new upstream 0.9.1'
[00:26] <lifeless> updated debian/changelog
[00:26] <lifeless> and done a merge of all the upstream source files that are contained in that tarball
[00:28] <lifeless> maxb: if thats the case, then when you run 'bzr commit' you'll have done the bzr equivalent of 'uupdate'.
[00:28] <lifeless> maxb: further, 'bzr diff -r tag:upstream-0.9.1' will show you the current packaging delta.
[00:28] <maxb> 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] <lifeless> maxb: did you start with a clean tree?
[00:29] <maxb> yes
[00:30] <lifeless> how are you determining that that is what the upstream commit contains?
[00:32] <maxb> 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] <lifeless> if you have altered tags you will need to zap those, or start with a fresh branch.
[00:36] <lifeless> hmm, sorry if I was grumpy before, it was meant to be humour emphasis.
[00:36] <maxb> 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] <lifeless> excellent
[00:37] <lifeless> the revision tagged upstream-0.9.1 contains pristine tar metadata in a revision property.
[00:39] <maxb> 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] <lifeless> totally
[00:40] <lifeless> the biggest problem I had was having no model of the bits inside
[00:40] <lifeless> so I couldn't guess at commands or solutions.
[00:40] <lifeless> sadly I haven't had time to write up my learnings yet
[00:58] <maxb> 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
[03:23] <Ryan52> where's doko? is he on vacation or something?
[03:31] <ScottK> Ryan52: He was on vacation last week and he's sick now.
[03:31] <ScottK> (conference the week before)
[03:35] <Ryan52> mbarnett: missing the last u in /topic
[03:35] <mbarnett> Ryan52: ta!
[03:36] <Ryan52> ScottK: ugh, okay, thanks.
[03:37]  * Ryan52 needs his advice :(
[03:39] <whatchasay> !ops
[03:39] <ebroder> Haha. Congratulations - you got what you wanted
[03:40] <lifeless> sigh, cyto is back. Can we ship them a psychiatrist?
[03:40] <Hobbsee> lifeless: or make them play in the traffic.  i wish
[03:42] <lifeless> Hobbsee: we need a kline
[03:42] <lifeless> he'll just rotate through ubuntu-kernel, ubuntu-motu etc.
[03:42] <Hobbsee> lifeless: i know.  if i could hand them out, this guy would be history..
[03:42] <dtchen> will likely reappear with the same hostmask, too
[03:42] <lifeless> vorian: ^ (pici)
[03:43] <lifeless> vorian: I hate to bug you, but you're the only staffer I know :)
[03:43] <Pici> lifeless: We're taking care of it
[03:43] <lifeless> Pici: thanks
[03:44] <lifeless> Pici: I didn't mean to nag:)
[04:28] <dtchen> slangasek: do your speakers pop on reboot/shutdown, too?
[04:48] <ebroder> Hmm...is there any standard advice for how to deal with the Maintainer/Original-Maintainer fields in Ubuntu derivative distributions?
[04:49] <ebroder> (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] <tsimpson> 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] <ebroder> 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] <tsimpson> ebroder: the original Original-Maintainer should be dropped then probably
[04:56] <tsimpson> the reason we have Original-Maintainer is because Debian wanted to make sure they got some attribution for the packaging
[04:57] <ebroder> 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] <tsimpson> there is no need to keep adding Original-XYZ every time someone forks the package
[04:59] <tsimpson> ebroder: if you want, keep the Original-Maintainer as the debian maintainer, and change the Maintainer to your packagers
[04:59] <ebroder> 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] <tsimpson> if you want to be really nice, mention that you derive from the Ubuntu package in the debian/copyright
[05:00] <tsimpson> ebroder: it should be a single field, in the exact form "Packager Name <packager email>"
[05:01] <ebroder> tsimpson: That's not actually specified anywhere in policy for Original-Maintainer (it is for Maintainer)
[05:01] <ebroder> (Unless it is and I just haven't found it yet)
[05:01] <tsimpson> but it's derived from Maintainer
[05:01] <tsimpson> so anything in there needs to be compatible, right?
[05:02] <tsimpson> 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] <tsimpson> that way, everyone gets attribution
[05:02] <ebroder> tsimpson: That process is harder to automate :)
[05:02] <tsimpson> and the right contact is set
[05:03] <tsimpson> ebroder: 'cat "This package is derived from Ubuntu" >> debian/copyright' ;)
[05:03] <tsimpson> though you'll probably want to put a link or something in there too
[05:04] <ebroder> 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] <tsimpson> but just a note at the end saying that it's based on Ubuntu is perfectly fine
[05:05] <tsimpson> ebroder: you don't know that no software anywhere doesn't use it in some way
[05:05] <tsimpson> well, you do already know that lintian uses it
[05:05] <ebroder> 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] <tsimpson> how will it react to a comma separated list?
[05:06] <ebroder> 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] <tsimpson> if developer tools break, you'll have an even harder time packaging
[05:09] <ebroder> 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] <tsimpson> it checks that it has an @lists.ubuntu.com address if it does have ubuntu changes
[05:10] <ebroder> That's Maintainer, not Original-Maintainer
[05:10] <tsimpson> oh yeah, right
[05:10] <ebroder> 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] <tsimpson> it's mostly for decoration
[05:11] <ebroder> 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] <tsimpson> but adding yet-another-field feels wrong to me
[05:11] <ebroder> (Also, my derivative isn't currently using p.u.c against our repo)
[05:12] <tsimpson> I don't see why you need to have multiple original maintainers anyway
[05:14] <ebroder> 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] <tsimpson> what's wrong with just adding it to debian/copyright or debian/README
[05:15] <tsimpson> ?
[05:15] <ebroder> Why didn't Ubuntu do that for Debian packages?
[05:16] <tsimpson> probably because Debian wanted otherwise
[05:17] <sladen> ebroder: the Original- prefix was added later so that some non-Ubuntu DDs would not risk getting further debbugs/etc automated reports
[05:18] <ebroder> sladen: Sure, and I realize that specific motivation is largely gone now that ubuntu doesn't ship reportbug
[05:19] <sladen> ebroder: there's a little bit of coverage on http://wiki.debian.org/Xcontrol
[05:20] <ebroder> sladen: Interesting - I hadn't seen that page
[05:21] <ebroder> sladen: But the page seems to be a bit short on actual ideas for solving the Original-Maintainer problem
[05:26] <sladen> ebroder: what /is/ broken?
[05:26] <sladen> ebroder: the ideal would be not to modify it---to preserve the credit where credit is due
[05:26] <ebroder> sladen: The problem of wanting to give credit to the Debian and Ubuntu maintainers without implying responsibility
[05:54] <ScottK> There was actually a poll among DD's to help set the policy
[05:55] <ScottK> ebroder and sladen: https://wiki.ubuntu.com/DebianMaintainerField is a more detailed history.
[05:55] <ebroder> ScottK: I did read that
[05:56] <ScottK> The biggest problem with not changing the maintainer field is that we'd get the derivatives bugs.
[05:56] <ScottK> People do regularly mail the maintainer with bugs/questions.
[05:57] <ScottK> IMO a derivative's users bugs/questions are their problem, not mine.
[05:57] <ebroder> ScottK: I totally agree
[06:03] <wgrant> ScottK: But people also file Linux Mint bugs against Ubuntu, so I'm not sure the maintainer is much of a problem.
[06:03] <ScottK> wgrant: I also mark them invalid unless they can explain why they think the apply to Ubuntu.
[06:05] <ScottK> I know nothing about Linux Mint and what they change or don't change.
[06:05] <sladen> wgrant: Please change them to be against 'linuxmint', rather than marking invalid
[06:05] <ScottK> sladen: That was me.
[06:05] <sladen> ScottK: https://bugs.launchpad.net/linuxmint
[06:06] <ScottK> 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] <ScottK> 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] <sladen> ScottK: you're not decreeing it;  you're redirecting it to the appropriate project
[06:07] <ScottK> I don't see it that way.
[06:08] <ScottK> 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] <sladen> ScottK: Ubuntu and Mint happen to use not just the same bugtracker, but the *same instance* of a bug tracker
[06:08] <ScottK> It's hardly worth arguing about because except for Baltix and backports bugs (which I never understood) I find it rare.
[06:09] <ScottK> sladen: I understand that.
[06:09] <ScottK> That choice doesn't give me any insight into what may, or may not, be a bug in linuxmint.
[06:09] <sladen> ScottK: marking it Invalid results in an alienated user;  redirecting a mis-filing is instead a progressive, helpful engagment
[06:10] <ScottK> sladen: Not my user.
[06:10] <ScottK> I know that sounds harsh, but i really can't solve the world's problems.
[06:10] <sladen> 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] <ScottK> Could be.
[06:11] <ScottK> I get enough Ubuntu bug mail without trying to sort out ones that belong to other distros.
[06:12] <sladen> 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] <ScottK> That one I know a little more about and can, in fact, sometimes have a useful opinion about.
[06:12] <sladen> ScottK: sorry, I thought in the cases you were aware they were filed against Linux Mint
[06:13] <ScottK> sladen: It is.
[06:13] <ScottK> I just have no idea how or if they should be applied somewhere else or not.
[06:13] <sladen> indeed
[06:14] <ScottK> 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] <ScottK> But it's late here and I need to get to bed, so have a good day/night (whichever it happens to be)
[07:54] <dholbach> good morning
[08:36] <pitti> 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] <free> mvo: hi! around?
[08:56] <mvo> hey free, yes
[08:56] <free> 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] <mvo> free: thanks! let me check
[08:57] <free> mvo: it looks like the solution would be as easy as adding the [NonInteractive] stanza to DistUpgrade.cfg.dapper
[08:57] <free> mvo: with ForceOverwrite=no, as in DistUpgrade.cfg
[08:59] <mvo> free: thanks, let me fix it in the code.
[08:59] <mvo> 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] <free> 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] <free>  
[09:01] <mvo> free: oh, thanks. thats a bug there then too :/
[09:01]  * mvo scratches his head
[09:01] <free> mvo: on a dapper minimal system, kvm
[09:02] <free> mvo: there's also another problem I'm trying to understand, but couldn't yet
[09:02] <mvo> 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] <mvo> free: what is it?
[09:02] <free> mvo: with the modification suggested the script moves on, but fails with this https://pastebin.canonical.com/25309/
[09:03] <free> (sorry pastebin.com is rejecting it as spam)
[09:03] <mvo> free: the crash in the earlier pastebin is fixed in trunk/ now, many thanks
[09:03] <free> mvo: cool
[09:03] <free> mvo: however the network is okay, wget-ing the Packages.bz2 manually and checking the md5sum looks okay
[09:04] <mvo> free: uh, hash-sum mismatches - are you behind a proxy of some sort?
[09:04] <free> mvo: nope, doesn't really seem a network problem, as said it works with wget
[09:04] <free> mvo: oh well, I'm in a NAT but that shouldn't matter
[09:05] <mvo> no, NAT should be fine
[09:05] <free> mvo: I can try from an ec2 instance if needed
[09:05] <mvo> free: give me a sec, I need to think how to add debug output to it
[09:06] <free> mvo: thanks a lot
[09:06] <free> mvo: I'm not sure but I think that code is inside some backport package which is downloaded at runtime?
[09:07] <mvo> yes
[09:08] <mvo> free: can you login into the machine with the failure? or is it "destroyed" after the failed upgrade attempt?
[09:08] <free> mvo: I'm in
[09:08] <mvo> oh, cool
[09:08] <free> mvo: it's up and working, the script just fails gracefully
[09:09] <free> 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] <mvo> free: could you please add http://paste.ubuntu.com/333734/ and run it again?
[09:10] <mvo> free: should be in /tmp somewhere
[09:10] <free> mvo: I'm truing
[09:13] <free> mvo: hmm, I can't find that file
[09:13] <mvo> free: nothing with "find /tmp -name "dist-upgrade.py" ?
[09:14] <free> mvo: nope
[09:14] <free> mvo: the only file with that name is in the root of the extracted hardy.tar.gz
[09:15] <free> but it looks like a different one
[09:15] <mvo> oh, sorry. please try that one then, it probably changed a bit, my diff is against trunk/
[09:15] <mvo> but that should not matter, the apt_pkg stuff will work
[09:15] <free> oh okay
[09:15] <mvo> and give lot of debug output of the http transfer
[09:16] <mvo> free: I see if I can find a dapper image in the meantime
[09:17] <free> mvo: probably an ec2 instance would do it as well
[09:17] <free> mvo: the log seems to be the same, no additional info
[09:18] <free> oh wait, my modifications got overwritten
[09:19] <free> I think I have to put them in ./hardy instead of ./dist-upgrade.py
[09:19] <free> yes, better now
[09:22] <free> mvo: http://people.64studio.com/~free/output
[09:26] <mvo> free: hm, that looks ok :/ could you please also add "apt_pkg.Config.Set("Debug::pkgAcquire::auth","true") ?
[09:27] <free> mvo: sure
[09:28] <free> mvo: done, please just refresh the link above
[09:30] <free> there are a couple of HTTP/1.1 206 Partial Content at the end
[09:32] <mvo> 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] <free> mvo: yes, hold on
[09:34] <mvo> free: could you please rm /var/lib/apt/lists/* /var/lib/apt/lists/partial/* and give me the output afterwards as well ?
[09:34] <mvo> (in a different file if possible so that I can compare)
[09:34] <free> 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] <free> mvo: the --ppa=landscape/ppa shouldn't be relevant
[09:35] <mvo> thanks
[09:37] <free> mvo: http://people.64studio.com/~free/output2
[09:39] <mvo> ubuntu-vm-builder is running
[09:39]  * mvo waits patiently
[09:42] <free> 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] <ogra> cjwatson, qt4-x11 ... bah, thats unfortunate
[10:21] <pitti> wgrant: so there was a LP rollout yesterday? Any idea whether this brought support for 3.0 format packages?
[10:22] <pitti>  [dpkg-source output:] dpkg-source: error: Unsupported format of .dsc file (3.0 (quilt))
[10:22] <wgrant> pitti: The rollout failed.
[10:22] <pitti> apparently not
[10:22] <wgrant> pitti: And no, it didn't quite land. Reviews, etc.
[10:22] <wgrant> But 3.1.12 is in two weeks.
[10:22] <pitti> :(
[10:22] <pitti> thanks
[10:24] <xartigas> Hello there! Noob speaking
[10:25] <xartigas> Is this the right place to ask for help regarding building gtk+?
[10:26] <xartigas> nvm, found the gtk+ channel :p
[10:28] <slangasek> dtchen: I don't recall
[10:42] <t3rm1n4l> hi
[10:42] <t3rm1n4l> i am looking to develop a boot from wifi system
[10:43] <t3rm1n4l> by keeping an initrd+kernel at client
[10:43] <t3rm1n4l> and root filesystem at the serversude
[10:43] <t3rm1n4l> then client will mount the serverside root filesystem via wifi and chroot and execute further
[10:43] <t3rm1n4l> is there some problem in implementing this ?
[11:05]  * seb128 kicks karmic and grub2 creating invalid winxp boot stanzas
[11:05] <pitti> seb128: still fighting with your uncle's computer?
[11:05] <pitti> t3rm1n4l: isn't that pretty much what ltsp already provides for ethernet?
[11:06] <seb128> pitti, no, my parents one this morning
[11:06] <seb128> I installed karmic which broke winxp boot
[11:06] <seb128> it doesn't chain on the right disk or something
[11:06] <seb128> a found a grub entry to put manually on the forum which works now
[11:06] <t3rm1n4l> pitti: i need to implement it through wifi
[11:07] <pitti> 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] <t3rm1n4l> but ltsp wont work in wifi right ?
[11:09] <pitti> 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] <pitti> t3rm1n4l: the PXE/kernel/initrd loading won't work, of course
[11:09] <ogra> there is no PXE for wifi
[11:09] <pitti> BIOSes usually don't support that
[11:09] <t3rm1n4l> yea
[11:09] <t3rm1n4l> it can be implemented easily right ?
[11:09] <ogra> use a wifi bridge
[11:09] <ogra> no
[11:09] <ogra> it cant
[11:09] <pitti> ogra: right, but once you set that up locally (local kenel/initrd), can you use it to load the chroot, etc.?
[11:10] <t3rm1n4l> yes
[11:10] <t3rm1n4l> that is my idea
[11:10] <t3rm1n4l> mount root filesystem using sshfs
[11:10] <mvo> 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] <ogra> you need either local media with kernel and a specifically hacked up initramfs or a wifi bridge
[11:10] <ogra> beyond that its highly insecure
[11:10] <free> mvo: ouch
[11:11] <mvo> free: I will re-try on my karmic system after lunch
[11:11] <mvo> sorry
[11:12] <ogra> pitti, yes, but indeed you have to promote your wifi keys publically to the world in your rootfs for i.e. reconnects
[11:12] <ogra> we never implemented it in LTSP because there are to many security holes
[11:12] <pitti> sure
[11:13] <pitti> I had assumed this was for open wifis anyway
[11:14] <ciphergoth> 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] <ogra> t3rm1n4l, pitti, there is no point in using sshfs though ... since you have to make both keys public anyway
[11:16] <ogra> use nbd or nfs
[11:16] <t3rm1n4l> okay
[11:17] <t3rm1n4l> i am looking at it as my academic project
[11:17] <ogra> have a look at the ltsp_nbd initramfs script in the ltsp-client-core source package
[11:17] <t3rm1n4l> okay
[11:17] <ogra> you can just add the wifi stuff there and indeed need to somehow get the key into the initramfs
[11:17] <t3rm1n4l> thanks
[11:18] <FIN__Master> 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] <ciphergoth> 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] <ciphergoth> do I need to do anything to get my package in there?
[11:52] <slangasek> james_w: pristine-tar failed for lp:ubuntu/portma
[11:52] <slangasek> +p
[11:54] <free> mvo: no worries!
[11:57] <davmor2> pitti: jockey is crashing on live desktop startup are you aware of this?
[11:57] <pitti> davmor2: in lucid?
[11:57] <davmor2> yes
[11:57] <pitti> dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Error parsing subject struct
[11:57] <pitti> davmor2: yes, I am; some weird regression in polkit, haven't found time to track it down yet
[12:00] <davmor2> pitti: this bug Bug 491429 so we are on the same page
[12:02] <pitti> davmor2: thanks
[12:02] <pitti> davmor2: hm, that's for karmic
[12:02] <pitti> that bug doens't affect karmic
[12:03] <davmor2> pitti: the first one isn't though it's lucid
[12:04] <davmor2> pitti: the one that retrace duped it as is karmic
[12:31] <porthose> will source format 3.0 (quilt) packages be supported in lucid?
[12:32] <siretart`> porthose: they actually already are since ages, it's just that launchpad doesn't accept them yet
[12:33] <porthose> siretart, ty :)
[12:34] <porthose> 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] <siretart`> porthose: AFAIUI that feature is already implemented in launchpad and 'just' needs deployment
[12:37] <Laney> that's the way to do it currently
[12:37] <Laney> apparently the LP rollout is on the 11th
[12:38] <porthose> Laney, so we create a delta instead of just waiting until the 11th?
[12:38] <Laney> if you want the package in
[12:38] <porthose> Laney, Ok ty for explaining :)
[12:39] <geekles> to anyone doing gnome-dev work on karmic, are you using jhbuilb from source or from jaunty?
[12:40] <geekles> *jhbuild
[12:47] <tjaalton> there are now 44 X packages waiting to be synced ;)
[12:47] <tjaalton> protos, libs
[12:50] <ogra> /usr/share/gnome-pkg-tools/1/rules/check-dist.mk:19: Unknown distribution: lucid
[12:50] <ogra> ... we should really fix that
[13:00] <seb128> ogra, it's only a warning, the rules is to avoid to upload experimental packages to unstable
[13:00] <seb128> it's of no use on ubuntu
[13:00] <ogra> ah
[13:23] <siretart`> 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] <ScottK> siretart`: Sounds like you need to drag sistpoty back.
[13:24] <siretart`> 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] <siretart`> I try to argue against, but I cannot really call myself an expert when it comes to symbol versioning.
[13:25] <slangasek> 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] <siretart`> slangasek: http://article.gmane.org/gmane.comp.video.ffmpeg.devel/100343 is the relevant mail. the rest is only for full context
[13:27] <siretart`> 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] <slangasek> 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] <siretart`> highlight from that mail: "Possibly RTLD_DEEPBIND could solve the problem. Drepper is quite vocal
[13:28] <siretart`> on arguing against it which is a sign that this might be the right direction."
[13:30] <siretart`> 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] <slangasek> 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] <slangasek> symbol versioning is a longstanding and well-understood solution to this problem
[13:32] <slangasek> "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] <siretart`> slangasek: thanks, that helps me to draft an answer
[13:33] <mvo> 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] <kirkland> mvo: hmm, i haven't uploaded a new kvm yet to lucid
[13:34] <siretart`> 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] <kirkland> mvo: sounds like a lucid kernel bug with virtio
[13:34] <siretart`> slangasek: upstream claims this move of symbols is no ABI breakage, since libavformat links against libavcodec
[13:35] <siretart`> question: should libavformat's SONAME be bumped or not?
[13:35] <slangasek> siretart`: should not - but your symbol versioning therefore needs to take this into account
[13:35] <slangasek> otherwise, the symbol versioning /itself/ introduces an ABI break
[13:36] <mvo> kirkland: thanks. probably, I was just curious if it was anything you might know about
[13:36] <siretart`> I see
[13:37]  * mvo will just use the karmic kernel in the meantime
[13:37] <kirkland> mvo: i don't;  please file a bug, though
[13:37] <mvo> ok
[13:38] <soren> mvo: The guest is Lucid as well?
[13:39] <mvo> soren: hardy (its currently testing hardy->lucid)
[13:41] <kirkland> mvo: oh, wait ...
[13:41] <kirkland> mvo: guest is hardy?
[13:41] <soren> 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] <kirkland> mvo: what version of qemu-kvm is on the lucid host?
[13:42] <kirkland> mvo: actually, what is the host running?
[13:42] <mvo> kirkland: 0.11.0-0ubuntu6.3
[13:43] <mvo> oh, but kvm-source is installed, could this be the problem?
[13:43] <kirkland> mvo: hmm, yeah ...  that would constrain you to running a much older kernel kvm module than karmic's
[13:44] <kirkland> mvo: ie, kvm-source no longer exists in karmic
[13:44] <kirkland> mvo: so you're running a jaunty-or-older kvm module
[13:44] <mvo> thanks, I will remove it
[13:44] <kirkland> mvo: fwiw, that version, 0ubuntu6.3 specifically fixes a problem with virtio with hardy guests
[13:44] <mvo> if its actually causing problems, I can add it to update-manager so that it will ensure its getting removed on upgrade
[13:44] <kirkland> mvo: cool, thanks.
[13:46] <mvo> kirkland: thanks, commited
[13:47] <kirkland> mvo: cheers
[13:47] <kirkland> mvo: hey, i have another one for you, btw ....
[13:47] <kirkland> mvo: i don't think /etc/update-motd.d/91-release_upgrade is ever being run
[13:47] <kirkland> mvo: because pam_motd uses run-parts --lsbsysinit
[13:48] <kirkland> mvo: which, I think, dislikes "_"
[13:48] <kirkland> mvo: i *thought* i committed a fix for that sometime during karmic, but doesn't look like it's there any more
[13:48] <mvo> oh, hrm. let me fix it in bzr
[13:49] <kirkland> 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] <soren> mvo: What are /var/cache/apt/{src,}pkgcache.bin for?
[13:51] <mvo> soren: its the mmap cache of the package data, why?
[13:51] <mvo> soren: if its not there, it will just rebuild it (or build it in memory if it can not write there)
[13:52] <soren> mvo: I just noticed it's taking up 24 MB of space in my VM images.
[13:52] <soren> mvo: That's what I wanted to hear. Yay.
[13:52]  * soren fiddles with vmbuilder some more
[13:52] <soren> mvo: Thanks.
[13:53] <mvo> :)
[14:09] <ScottK> cjwatson: I have a couple of more questions about the kubuntu packageset.  Do you have a preferred venue for such discussion?
[14:11] <cody-somerville> pitti, did you ping me?
[14:14] <cjwatson> ScottK: u-d's fine
[14:14] <ScottK> Thanks.
[14:17] <pitti> cody-somerville: hm, can't remember any more
[14:26] <kirkland> pitti: how often does http://www.piware.de/workitems/server/lucid-alpha2/report.html run?
[14:27] <pitti> kirkland: hourly every :12
[14:27] <kirkland> pitti: cool, thanks
[14:27] <pitti> but of course feel free to poke me if I should do a manual run
[14:29] <slangasek> pitti: eep, why does http://piware.de/workitems/foundations/lucid/report.html think there are 105 work items for https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-distributed-development ?
[14:30] <pitti> hm, looks more like 50
[14:30] <slangasek> 35, by my count
[14:30] <pitti> slangasek: looks like a big; I'll have a look soon, thanks for pointing out
[14:30] <pitti> a bug, too
[14:30] <pitti> "too big" bug
[14:32] <cjwatson> pitti: that's odd, my local version shows 35
[14:32] <pitti> I hope it's not a weird bug in lenny's sqlite
[14:35] <dtchen> slangasek: (WRT AD1981 and powerdown pop) thanks. I'd appreciate your confirmation, but it isn't pressing; asac has also confirmed on his codec. It affects the linux patch I'm working on.
[14:37] <slangasek> dtchen: ok, cheers
[15:38] <Keybuk> slangasek, kirkland, soren: FYI you should never need to use that "reload-configuration" thing
[15:38] <Keybuk> it's there for people who compile inotify out of their kernel
[15:38] <soren>  Ah.
[15:38] <slangasek> okie
[15:39] <kirkland> Keybuk: hrm...  so inotify picks up changes to /etc/init automatically in karmic?
[15:39] <kirkland> Keybuk: and if it doesn't, is it a bug?
[15:39] <soren> Yes.
[15:39] <slangasek> kirkland: yes, but you still have the issue of job != jb
[15:39] <slangasek> job
[15:39] <Keybuk> Upstart (and its test suite) are very good at finding inotify kernel bugs ;)
[15:39] <Keybuk> right
[15:40] <soren> kirkland: It does notice changes in /etc/init, but it considers a changed file a new job, not a change to the old job.
[15:40] <Keybuk> the strange behaviour that kirkland was having is because "restart JOB" restarts the running job
[15:40] <Keybuk> with the configuration it had when it was first started
[15:40] <kirkland> Keybuk: so stop/start != restart
[15:40] <Keybuk> kirkland: right
[15:40] <soren> Precisely.
[15:40] <Keybuk> if stop/start == restart, there wouldn't be a restart ;)
[15:40] <kirkland> Keybuk: ah
[15:41] <kirkland> Keybuk: a little non-intuitive, but now I know
[15:41] <Keybuk> for example
[15:41] <Keybuk> restart might not run the pre-stop/post-stop/pre-start/post-start scripts
[15:41] <Keybuk> it does right now, but that's not a guaranteed thing
[15:41] <Keybuk> restart might just kill and respawn the daemon itself
[15:41] <Keybuk> I'm not entirely sure that this is desired behaviour or not
[15:42] <Keybuk> I added restart quite late in 0.6
[15:42] <Keybuk> and didn't anticipate it's odd behaviour
[15:42] <Keybuk> it was put in as an atomic stop/start
[15:42] <Keybuk> and the whole "doesn't use the new config" thing is a side-effect
[15:43] <kirkland> Keybuk: well, my natural expectation was that restart would reload all configurations, in between stop and start
[15:43] <kirkland> Keybuk: perhaps that's just an uneducated expectation
[15:49] <Keybuk> kirkland: not necessarily
[15:49] <Keybuk> it may be an uneducated implementation :p
[15:52] <ttx> pitti: about http://piware.de/workitems/server/lucid-alpha2/report.html, some strange things
[15:53] <ttx> pitti: shows 272 wi for canonical-application-support, while there are only 79 in the whiteboard
[15:53] <pitti> ttx: seems to be the same problem that slangasek was pointing out above; I'll have a look now, I'm done with my previous task
[15:53] <ttx> ah sorry for the duplicate :)
[15:53] <mvo> free: I have my dapper VM running now, but I was not able to reproduce the hashsum issue (both with interactive, non-interactive, archive.u.c and it.archive.u.c :/
[15:54] <pitti> ttx: no worries, I'm glad that it is a dupe :)
[15:54] <free> mvo: ah :/
[15:54] <free> mvo: I'll ask other Landscapers to test the same too see if we can reproduce it
[15:54] <free> mvo: thanks for now
[15:55] <pitti> ttx: or later on, rather; got a conf call in 5
[15:56] <kirkland> Keybuk: i think what you've described is more what i'd expect from an init "reload" action
[15:56] <kirkland> Keybuk: for an init "restart", i'd expect the job to stop and start again
[15:56] <mvo> free: thanks
[15:56] <kirkland> Keybuk: doing whatever is involved with both "stopping" and "starting" the process
[15:57] <Keybuk> right
[15:57] <Keybuk> that's what it does
[15:57] <Keybuk> but the problem here is the definition of "the job" :)
[15:57] <free> mvo: btw, what is the timeframe for the .cfg.dapper fix to be published in the meta-release file?
[15:59] <mvo> kirkland: kvm seems to be much more reliable now, but also much slower (same test, hardy->lucid on a lucid system). nothing to worry about just yet, I keep a eye on it
[16:00] <kirkland> mvo: hmm...  are you sure you're running with kvm acceleration?
[16:00] <mvo> free: no schedule for this yet, if you manage the upgrade with landscape and do the unpacking yourself, you might as well just add it yourself into the config, that will be much quicker than doing a SRU
[16:00] <kirkland> mvo: and are you sure that virtio is working?
[16:00] <kirkland> mvo: did you reboot after uninstalling kvm-source?
[16:00] <free> mvo: I see, sounds reasonable
[16:00] <kirkland> mvo: what does kvm-ok say?
[16:00] <mvo> kirkland: it used to warn me when kvm was not available, it did not complain
[16:01] <mvo> kirkland: kvm-ok> neat! does not complain either
[16:01]  * mvo was not aware of kvm-ok
[16:16] <slangasek> Keybuk: you marked "package plymouth" done as a work item, but I haven't seen it land in lucid yet, nor in the new queue?  (also blocks my cryptsetup upload, so just wondering when that's going to land - not urgent)
[16:16] <Keybuk> hand intended it to land a couple of days ago
[16:16] <Keybuk> but been off obviously
[16:16] <Keybuk> and found bugs in the meantime
[16:16] <Keybuk> I'll probably work on that tomorrow
[16:16] <slangasek> okie
[16:17] <Keybuk> too many other things being distracting today
[16:18] <davmor2> okay come on own up who put shiny stuff out side keybuk's
[16:20] <Keybuk> sadly not shiny
[16:23] <ion> keybuk: Can you push your current stuff to some public repository? Dunno whether i’ll get around to implementing the selectable-progress/input-dialogs-from-programs thing, but having plymouth code that already builds and more or less integrates with my lucid system would be a motivator. :-P
[16:24] <Keybuk> ion: what current stuff?
[16:24] <Keybuk> plymouth is pushed
[16:24] <cjwatson> Keybuk: do we want ureadahead in the required seed (i.e. do we want it on server installs)? it's priority: required but currently due for demotion
[16:24] <Keybuk> cjwatson: yes, it should be in server
[16:24] <Keybuk> ion: https://code.launchpad.net/ubuntu/+source/plymouth
[16:24] <cjwatson> I'll seed it then. thanks. (hmm, perhaps minimal rather than required though; first-stage debootstrap doesn't need it)
[16:25] <cjwatson> so that'll make it prio: important
[16:25] <Keybuk> cjwatson: I think I just guessed at priority ;)
[16:25] <cjwatson> required is the stuff that needs to be dpkg -x'd in the first stage of debootstrap
[16:26] <ion> keybuk: Ah, thanks. I had only checked apt-cache showsrc plymouth.
[16:26] <cjwatson> actually - standard would be fine, thinking about it
[16:26] <cjwatson> but I think I'll put it in minimal anyway to propagate it as widely as possible
[16:31] <CarlFK> seb128: bug 491732 "fixed upstream in git now!" - what is the schedule for it hitting the repo?  and is this the place I would watch: https://edge.launchpad.net/ubuntu/+source/gtk+2.0
[16:32] <CarlFK> no hurry, I just want to know when to test that the app it depends on (dvswitch) works
[16:32] <seb128> CarlFK, not sure it will go in karmic, lucid did you check if 2.19.1 has it?
[16:46] <pitti> ttx, slangasek: work items by assignee fixed; was a bad SQL join
[16:49] <LucidFox> Er... I uploaded qutim to NEW three times in a row, could someone nuke the earlier two uploads?
[16:49] <ttx> pitti: ok, thx
[16:50] <pitti> LucidFox: done
[16:50] <LucidFox> Danke.
[17:12] <CarlFK> seb128: gtk resolution "Fixed in master (b509f28559dba03684ecc88acac498b6f27d2ebf) and on the 2.18 branch."  I assume that means 2.19.1 has it
[17:13] <seb128> CarlFK, well depends if that commit was before or after tarball
[17:15] <CarlFK> seb128:  patch date  Wed, 02 Dec 2009 10:09:37 +0000  so 'yesterday'
[17:15] <seb128> so no
[17:17] <CarlFK> if I get gtk to back port it to 2.16, is there a chance it can get into karmic?
[17:19] <CarlFK> does it matter that I need this so I can record Suttleworth ?  it shouldn't, but it's kinda funny:)
[17:24] <CarlFK> oh wait.. I am not sure if karmic is using 2.16 or .18... checking
[17:28] <pitti> cjwatson: "status by work item" -> sweet, thanks!
[17:28] <cjwatson> works for me ... :-)
[17:34] <seb128> CarlFK, 2.18 it uses
[17:34] <seb128> CarlFK, I guess it could yes
[17:36] <CarlFK> seb128: anything I can do to push it along?
[17:36] <seb128> add a debdiff to the bug?
[17:36] <seb128> and do the sru work
[17:36] <seb128> ie add a testcase, etc
[17:37] <CarlFK> debdiff and testcase - no prob.  whats is sru?
[17:37] <seb128> CarlFK, stable release update
[17:38] <seb128> CarlFK, https://wiki.ubuntu.com/StableReleaseUpdates
[17:38] <CarlFK> seb128:  got it - thanks
[17:39] <seb128> np, thank you for looking at the issue
[17:57] <sleepy> in theater huh ? interesting
[18:12] <cody-somerville> pitti, did you get my question the other day about launchpad-registry being a member of ubuntu-sru?
[18:14] <cody-somerville> Cody A.W. Somerville  → Canonical Launchpad Engineering  → Registry Administrators  → Ubuntu Stable Release Updates Team
[18:15] <ScottK> Cool.
[18:15] <ScottK> You can approve all my SRUs then.
[18:26] <micahg> pitti: I just attached the debdiff for the apport bug 476513 if you wanted to push it through...
[19:35] <pitti> cody-somerville: I got your q, but I don't know the answer
[19:57] <RoAkSoAx> slangasek, I was wondering when are the daily builds for the Ubuntu Server ISO restart?
[20:04] <ScottK> RoAkSoAx: It's more a question of when they will succeed.
[20:04] <enzotib> Hi, can I ask a question about package dependences and automatically installed packages?
[20:07] <RoAkSoAx> ScottK, ah! so its still "that" broken then
[20:15] <tjaalton> how often does the autosyncer run?
[20:15] <pitti> tjaalton: it's not automated; an archive admin has to run it
[20:16] <pitti> since it falls apart very often, it's actually a fairly interactive process
[20:16] <tjaalton> pitti: ah ok
[20:32] <pitti> cjwatson: would you know which team membership/privilege bit is necessary to be able to prioritize specs? dbarth can't prioritize dx-lucid-* specs himself
[20:32] <pitti> cjwatson: is that ubuntu-drivers?
[21:04] <Eren> kees, hello
[21:07] <Eren> kees, it seems that mitre isn't informed about the issue
[21:08] <kees> Eren: privmsg please
[22:27] <mpt> robbiew, I've now specced all except one of the features listed on <https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-software-center-ui-improvements>
[22:27] <robbiew> mpt: okay, thank you
[22:32] <mpt> robbiew, does <https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-ratings-and-reviews-in-software-center> need any more detail for approval from the Ubuntu side?
[22:35] <robbiew> mpt: I can approve it
[22:35] <mpt> mbarnett, there's no such channel as #ubunt :-)
[22:36] <mpt> thanks robbiew, I will draw and attach a diagram of the rating/review dialog tomorrow but it's 10.30pm here now
[22:36] <Tm_T> mpt: there is, join and see
[22:36] <mpt> Tm_T, there wasn't three minutes ago, anyway
[22:36] <Tm_T> mpt: (:
[22:37] <mbarnett> it really likes to truncate that message
[22:37] <slangasek> I'm pretty sure that used to say something more than "see #ubuntu" :)
[22:37] <Tm_T> for support or something
[22:37] <Tm_T> but it hits the maxlength
[22:38] <slangasek> closer ;)
[22:38] <mbarnett> yeah, that is as long as it allows
[22:38] <mbarnett> See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
[22:38] <mbarnett> is what used to be there
[22:38] <ajmitch> the info about 9.10 being released probably isn't needed now
[22:38] <mbarnett> once the outage is done i swear i will set it back
[22:39] <slangasek> there :)
[22:39] <mbarnett> whee!
[22:39] <mpt> What does "See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs" mean anyway? :-P
[22:39] <mbarnett> i think you are suppoosed to parse the end of that url
[22:39] <mbarnett> mentally
[22:39] <mpt> and ignore the protocol and hostname
[22:39] <slangasek> or use moin as your IRC client
[22:40]  * mpt -> home now, really
[23:49] <cjwatson> pitti: prioritise specs> I think it's drivers, yes