[00:11] <neeraj> Let say package A depends on B. And B on C. Now including B as a dependency of A will install C also.. right? Or we have to add both B and C as a dependency.
[00:16] <JontheEchidna> Other than libraries which are automatically hanlded, dependencies can change. So while at the moment B would bring in C, it's best to assume that it might not always do so, and depend on both B and C
[00:19] <JontheEchidna> neeraj: did you catch my message before you lost your connection?
[03:01] <robert_ancell> slangasek, ping
[03:01] <slangasek> robert_ancell: hithere
[03:02] <robert_ancell> slangasek, hey, question about this vte include problem - what package is using it in this way.  There seems to be an inconsistency in how "includedir" is defined
[03:02] <slangasek> robert_ancell: both gir-repository and vinagre both FTBFS this way
[03:04] <robert_ancell> slangasek, ok, looking into what they're doing - note that vinagre has it's pkg-config file set up the same way
[03:08] <micahg> any archive admins want to sync a security update? :)
[03:10] <robert_ancell> slangasek, vinagre builds for me, and appears to have built fine in the archives - do you have a build log?
[03:12] <slangasek> robert_ancell: hmm, didn't keep a log; don't even remember now for sure that I did build it, as opposed to inspecting the source visually.  Will double check and get back to you in a bit
[03:12] <robert_ancell> ok
[03:19] <slangasek> robert_ancell: ah; no, I didn't try to build vinagre, I just looked at the source to confirm that it expected "vte/vte.h" as a header rather than "vte-0.0/vte/vte.h"
[03:19] <slangasek> robert_ancell: so it may just be gir-repository affected by ths
[04:28] <nigelb> kirkland: beautiful blog post :)
[07:32] <pitti> Good morning
[07:38] <G> pitti: evening
[07:51] <geser> good morning
[07:55] <dholbach> good morning
[07:56] <mvo> hey dholbach
[07:56] <dholbach> heya mvo
[08:09] <jibel> mvo, good morning, we've found another culprit causing bug 614993.
[08:09] <jibel> mvo, xserver-xorg-video-radeonhd has been removed from maverick and is blocking the upgrade.
[08:10] <jibel> mvo, but that does'nt fix the pb for everybody and there is still another one.
[08:11] <mvo> thanks jibel, I look at it again
[08:12] <mvo> jibel: odd that it worked for me, but maybe I had the wrong set of package, I investigate
[08:14] <jibel> mvo, I'm able to reproduce the issue on a fresh 10.04.1
[08:15] <jibel> mvo, but that doesn't fix it for bdmurray and another reporter. There is probably something left from a previous upgrade.
[08:16]  * mvo nods
[08:22] <mdke> didrocks: don't think so
[08:50] <lucidfox> dholbach> Just saw your post on Planet Ubuntu... So are the Launchpad daily builds a feature that allows anyone to request Launchpad to do daily builds from VCS without any manual intervention or setting up your own daemons?
[08:50] <dholbach> lucidfox, yes, the code needs to live in Launchpad though (vcs imports)
[08:51] <lucidfox> Neat
[08:51] <dholbach> https://help.launchpad.net/Packaging/SourceBuilds/
[08:51] <lucidfox> Yes, saw that page :)
[08:51] <dholbach> https://help.launchpad.net/Packaging/SourceBuilds/KnownLimitations is current breakage, but being worked on
[08:51]  * lucidfox goes to set up a daily build for Pinta
[08:51] <dholbach> some of them will be fixed in the next LP release
[09:00] <jibel> mvo, that's xserver-xorg-video-dummy which is blocking the upgrade. it provides xserver-xorg-video-7 in maverick
[09:00] <mvo> jibel: yeah, I just found it out as well, I'm preparing a new xserver-xorg-core
[09:01] <mvo> jibel: it appears there is also -glamo
[09:01] <mvo> jibel: and (just to be on the safe side) I merged some from debian (vga, i81, imstt) that we probably don't need, but they will not hurt (and make the merge later easier)
[09:02] <didrocks> mdke: thanks for the info :)
[09:04] <mvo> jibel: next thing is to debug apt so that its either more clever or gives at least better debug output
[09:06] <jibel> mvo, yep. apt.log gives no clue about what's wrong.
[09:06] <mvo> jibel: indeed :/
[09:06] <mvo> jibel: thanks for keeping a eye on this bug! much appreciated
[09:07] <jibel> mvo, have a look at -glide too
[09:09] <mvo> jibel: aha, thanks. I missed that one (was in a amd64 chroot and that is i386 only afaics)
[09:19] <mvo> jibel: the updated breaks list http://paste.ubuntu.com/486211/
[09:40] <dholbach> if anybody has a tiny bit of time, can you branch  lp:~dholbach/harvest/release-prep  follow the instructions in the INSTALL file and play with it and see if there's anything glaringly broken? :-)
[09:47] <G> dholbach: having a poke
[09:49] <jibel> mvo, I think that -newport, -psb, tga, unichrome and -via are missing from that list.
[09:51] <G> dholbach: how long should the manage.py update take?
[09:51] <dholbach> g: the first one takes a bit longer
[09:51] <mvo> jibel: thanks, that makes sense (modulo -via,that is just a transitional package)
[09:51] <G> oh, never mind, something happened :)
[09:51] <mvo> jibel: I add them now
[09:52] <persia> jibel, -psb works?  I thought it was unsuitable for use still.
[10:07] <OdyX> tkamppeter: ping
[10:08] <jibel> persia, I don't know if it works but I can install it in hardy and then upgrade to a release where it's not available anymore.
[10:09] <persia> jibel, Ah, OK.  So a lucid thing, rather than a maverick thing?  I believe it was available for hardy and jaunty (and not intrepid).
[10:10] <jibel> persia, yes. it was only available in hardy from what I've found. I haven't checked intrepid.
[10:11] <persia> I'm fairly certain that if it was in intrepid, it was pointlessly broken, because Intel never released binaries that worked with that kernel and X.
[10:11] <persia> For jaunty, it was only available in a PPA, but lots of folks with that hardware (which was common at the time) installed from there.
[10:12] <Kmos> hi persia
[10:13] <persia> Hey Kmos.  Are you going to submit your "I'd like to be involved again" application soonish?  I've been waiting.
[10:13] <persia> (otherwise I'm supposed to ask you to leave the channel)
[10:14] <Kmos> I was thinking I was still banned from talking here. but I'm stopping now
[10:22] <G> dholbach: that looks pretty neat!
[10:25] <G> dholbach: any particular bits you want tested?
[10:39] <dholbach> g: just something glaringly obvious that breaks :)
[10:39] <dholbach> g: so we can get it out there and deployed
[10:39] <dholbach> if we have to fix small stuff later on, that's fine
[10:58] <G> dholbach: the only thing I'd say is for the bug numbers, include the bug titles
[10:58] <dholbach> g: there's an open bug in harvest-data about that
[10:58] <dholbach> thanks a lot for your review!
[11:00] <G> dholbach: ooh, here is one
[11:00] <G> Packages all unticked, Opportunities->sponsoring, Pidgin, a code branch has appeared, is that intentional?
[11:01] <G> ahhh actually I guess it is
[11:01] <dholbach> yes
[11:17] <\sh> hmm...who approves new uploads for bugfixes these days?
[11:27] <persia> \sh, If you break freeze, ubuntu-release.  if you don't, you.
[11:28] <persia> (check if it's seeded first: generally apt-cache show works, because it ends up in tasks)
[11:28] <\sh> persia, aehm...it's zend-framework, new bugfix release but new upstream version too...I uploaded it regarding the ffe guidlines...(all universe)
[11:29] <\sh> and now it sits in "approval state" :)
[11:29] <seb128> dholbach, would be nice to have a way to display the opportunities not listed
[11:29] <seb128> dholbach, or to know why those nn are not listed
[11:30] <dholbach> seb128, not listed because the opportunity lists are not chosen :)
[11:30] <dholbach> or the filtering limited :)
[11:31] <persia> \sh, Oh, that's the release team.  They've just got the upload queue on manual.  Check in #ubuntu-release if you need it fast, or wait a bit, and they'll likely push it.
[11:31] <\sh> persia, thx :)
[11:32] <seb128> dholbach, would be nice to have a "select all opportunities"
[11:33] <seb128> dholbach, oh, it seems clicking on "selected" does that
[11:33] <dholbach> seb128, yes, how do you think that could be made more obvious?
[11:34] <seb128> changing the label
[11:34] <seb128> "limit to selected"
[11:34] <seb128> or something which indicates it's a filter and not only a title for the sublist
[11:34] <dholbach> and I guess the same for packagesets?
[11:34] <seb128> yes
[11:35] <seb128> I though those were just titles
[11:35] <seb128> I didn't get that you could click to toggle
[11:35] <seb128> dholbach, otherwise great work ;-)
[11:36] <dholbach> seb128, bug 627340
[11:36] <dholbach> seb128, it was mostly Dylan McCall's doing
[11:36] <seb128> dholbach, danke
[11:36] <seb128> dholbach, is he on IRC?
[11:37] <seb128> dholbach, if not just tell him great work from me ;-)
[11:38] <dholbach> seb128, sometimes - he's in west canada, so at the other end of the world :)
[11:38] <seb128> ;-)
[11:38] <seb128> dholbach, btw the fedora things is pretty useless
[11:39] <seb128> not your fault but they let all the old patches on their cvs it seems
[11:39] <seb128> so we get tons of things listed which are old and outdated and not used
[11:39] <dholbach> yeah, I guess so
[11:40] <dholbach> I hope we can fix bug 581719 quickly
[11:40] <dholbach> if it's a one click operation, I hope that'll make it easier for people to make use of that list
[11:40] <seb128> that would be nice
[11:40] <G> seb128: are you sure?  if you look at something like Autoconf if it was that case you'd get a heap of them
[11:41] <seb128> I would not dislike having the label telling you about opportunities not listed doing the "list those" on click
[11:42] <dholbach> seb128, I'm not sure I understand - can you rephrase?
[11:42] <G> dholbach: the thing that bugs me the most is the bit on the left
[11:42] <dholbach> g: what's that?
[11:42] <seb128> G: http://cvs.fedoraproject.org/viewvc//devel/autoconf/
[11:42] <seb128> G: ?
[11:42] <G> when scrolling it gets confusing w/ where I am on the page
[11:42] <G> dholbach: because it's not smooth/stuck at the top etc
[11:43] <G> the bouncing around is distracting
[11:43] <seb128> dholbach, I think I was asking for what "permalink" does
[11:43] <seb128> the wording is just not obvious
[11:43] <dholbach> g: what's bouncing around?
[11:43] <G> dholbach: the left bit w/ the filtering options
[11:43] <seb128> dholbach, I'm browsing the list and just show that gnome-session has 11 opportunities
[11:44] <seb128> dholbach, I was wondering if there was a way to quickly see those without changing the filtering
[11:44] <dholbach> seb128, so a 'reset filters' link?
[11:44] <dholbach> ah ok
[11:44] <G> dholbach: if you say display all packages w/ fedora patches and scroll to the bottom it gets a little sickening
[11:44] <seb128> dholbach, no, just a "show me all the opportunities for that source"
[11:44] <dholbach> seb128, do you think you can file a bug explaining how you'd like it to work?
[11:44] <seb128> dholbach, well "permalink" does it
[11:44] <dholbach> ah ok
[11:44] <seb128> just not inline
[11:44] <seb128> but I can work with that
[11:45] <dholbach> maybe you can file a bug for that, so it's inline?
[11:45] <seb128> ok
[11:45]  * dholbach hugs seb128
[11:45] <dholbach> …and submit a patch :-P
[11:45]  * seb128 hugs dholbach
[11:45] <seb128> lol
[11:45] <seb128> let's see
[11:45] <seb128> but lunch first
[11:45] <dholbach> :)
[11:45] <G> dholbach: haha
[11:45] <dholbach> g: it's not bouncing for me
[11:45] <seb128> dholbach, great work to Dylan and you in any case
[11:45] <G> seb128: can't check any other packages, looks like their CVS server has died
[11:46] <G> dholbach: might just be firefox for me
[11:46] <G> let me try my mac
[11:46] <dholbach> seb128, maybe we can fix http://bugs.launchpad.net/fedora-patches-overview too
[11:46] <dholbach> (it's what produces the fedora.csv list)
[11:46] <G> dholbach: I don't think it's broken
[11:46] <G> it's just that some maintainers don't delete unused patches
[11:47] <dholbach> yeah, I guess
[11:47] <G> and it's not much use changing it now
[11:47] <seb128> dholbach, ;-)
[11:47] <G> because I can tell you, that Fedora are moving to git
[11:47] <dholbach> I'm very glad you find it generally useful though
[11:47] <seb128> G: they are moving to git for how many years now?
[11:47] <G> seb128: they are serious this itme
[11:47] <G> *time
[11:47] <seb128> I'm waiting to see
[11:48] <seb128> I don't doubt they want to
[11:48] <seb128> they just seem to be busy with other things
[11:48] <G> seb128: their release engineering team are building the architecture for it now as I understand
[11:48] <seb128> ok
[11:49] <seb128> they might have the same issue on git though
[11:49] <G> and I know when I was involved in their Infra side (back in March) they were getting alive demo going
[11:49] <seb128> if the issue is due to people not doing a vcs delete
[11:49] <G> seb128: nah, as I recall they are going to exploded source
[11:49] <seb128> ok
[11:49] <seb128> let's wait then and see what they come with ;-)
[11:49] <seb128> seems interesting
[11:49] <tkamppeter> OdyX, hi
[11:50] <G> seb128: well thats what I last heard anyway
[11:53] <cjwatson> last time I tried to look in Fedora's CVS, there was a note up saying that they'd already moved to git, and when I looked there it seemed to have unexploded source
[12:12] <ttx> slangasek: re: eucalyptus-udeb/avahi: the udeb uses avahi to detect existing components and provide default sane "next" installation choices.
[13:24] <tkamppeter> OdyX, hi
[13:29] <OdyX> tkamppeter: hi
[13:46] <mehranhu> hello
[13:47] <mehranhu> Im having a problem in ANDOID lnux kernel driver
[13:47] <mehranhu> can someone help me?
[13:47] <mehranhu> I want to READ a file in a kernel driver.
[13:47] <mehranhu> is there some set of APIs available.
[13:49] <persia> We don't really do much android stuff here.  Are you sure there isn't a more relevant channel?
[13:49] <mehranhu> android person dont know much about Linux-C
[13:49] <mehranhu> so i think you are most suitable to help me
[13:50] <mehranhu> can we read file in linux kernel?
[13:50] <amitk> mehranhu: sys_read() is not really supposed to be used from inside the kernel. If you are using it you're doing something wrong
[13:51] <mehranhu> what should i use?
[13:52] <mehranhu> i didnt found any API over the internet
[13:56] <amitk> mehranhu: you're not looking hard enough :) http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad ,  http://lkml.indiana.edu/hypermail/linux/kernel/0502.0/1763.html, http://www.linuxjournal.com/article/8110
[14:42] <jdstrand> micahg: did you ever get an AA to perfrom your security copy?
[14:45] <G> whats the rules of regressions between releases?
[14:51] <persia> G, regressions are bad.  File a bug.  mark it a regression.  The folks in #ubuntu-bugs and #ubuntu-testing likely have good pointers to wiki pages with procedures to handle that sort of thing (I forget them offhand)
[14:51] <G> persia: yeah, it's an already filed bug but feeling more and more like a regression
[14:52] <persia> Yeah.  Chat with the folks in #ubuntu-bugs, and make sure it has all the rights tags, status, etc.
[14:53] <G> ahhh I went into -testing, if I don't get anything there soon I'll pop into -bugs
[14:53] <G> persia: thanks though
[15:27] <micahg> jdstrand: no, bug 622900
[15:42] <micahg> jdstrand: thanks
[15:47] <cjwatson> cking: do you have an amd64 system with UEFI to which you could attach a serial console or some other way to debug early code?
[15:49] <cking> cjwatson, afraid not, I sent mine to manjo in TX
[15:49] <cking> cjwatson, we could ask manjo to ship it to you, but it's a big dev box
[15:50] <cjwatson> probably not a plan
[15:50] <pitti> cjwatson: how do I find if I have UEFI?
[15:50] <pitti> cjwatson: I have a fairly recent ThinkPad X201, with current maverick amd64 on it
[15:50] <pitti> "find out"
[15:50] <manjo> pitti, your bios should say UEFI v2.1
[15:51] <cking> pitti, check in /sys/firmware perchance
[15:51] <pitti> $ ls /sys/firmware/
[15:51] <pitti> acpi  memmap
[15:51] <cjwatson> cking,manjo: so, the current situation is as follows
[15:51] <pitti> cking:  find /sys/firmware -iname '*efi*'
[15:51] <pitti> -> nothing
[15:51] <pitti> I guess that's a bad sign?
[15:52] <cjwatson> current amd64 (only) CDs contain a GRUB EFI build
[15:52] <manjo> I think sys firmware only has interrupts and such
[15:52] <jdstrand> micahg: sure
[15:52] <cjwatson> you can boot them using either BIOS or UEFI on a system capable of doing either
[15:52] <cjwatson> GRUB appears to boot the kernel fine; I used a test kernel cking gave me at the sprint which issues beeps right at the start of head_64.S
[15:52] <cjwatson> however, there is no output from the kernel
[15:53] <cjwatson> this is obviously a showstopper but it's not quite clear what's going on
[15:53] <manjo> cjwatson, is there a 64bit image I can get to on cdimage ?
[15:54] <cjwatson> the 'newreloc' branch was landed recently in GRUB upstream, and there's a possibility that it was due to the initramfs being loaded incorrectly in which case that might fix it
[15:54] <cjwatson> otherwise, it's hard to say
[15:54] <cjwatson> manjo: yes, any current amd64 one
[15:54] <manjo> ah yesw
[15:54] <cjwatson> newreloc was a pretty significant piece of work though
[15:54] <manjo> cjwatson, let me try down the latest x64 iso and give that a spin on my box
[15:55] <manjo> give me 30mts or so
[15:55] <cjwatson> right, it's always possible it was just this system, though I'm doubtful
[15:56] <manjo> I just got a new box from intel with latest build of uefi
[15:56] <manjo> I was wanting to install it anyways
[15:57] <manjo> but x64 image was not available for the last few builds
[15:58] <cjwatson> right, only landed recently.  would have been longer ago except that there was a PATH issue in the daily builds
[15:59] <manjo> cjwatson, now downloading image ... will report back soon
[15:59] <cjwatson> thanks
[16:00] <cjwatson> I'll see if I can get to network-console
[16:00] <pitti> manjo, cjwatson: sorry, no trace of UEFI in BIOS or /sys
[16:02] <G> pitti: as I recally UEFI & 'BIOS' are mutually exclusive
[16:02] <G> i.e. you have one or the other
[16:03] <pitti> ok, s/BIOS/the ASCII GUI thing for configuring hardware/ :)
[16:03] <cjwatson> G: not true
[16:03] <cjwatson> G: I have a laptop just here --> that lets you select at boot time
[16:04] <G> cjwatson: between BIOS & UEFI?
[16:04] <cjwatson> G: I mean, it's probably a BIOS compatibility shim over the top of UEFI or something, but it lets you select either, yes
[16:04] <G> ahhh right yeah
[16:04] <G> yeah, I'd say it's a compatibility hack over the top
[16:05] <cjwatson> but functionally, that's all that's relevant
[16:06] <G> cjwatson: yeah, but for the most case, I am right is saying you can have one over the other at any particular time?
[16:06] <cjwatson> sure
[16:06] <G> *only one
[16:07] <G> personally I'm hoping UEFI catches on fast
[16:10] <cjwatson> G: I have mixed feelings
[16:10] <manjo> pitti, does any of your "boot" options in bios say uefi ?
[16:11] <pitti> manjo: no
[16:11] <manjo> pitti, if you have uefi bios it should give you an option in boot menu to switch between legacy and uefi
[16:12] <G> cjwatson: definately for servers, the 2TB boot partition thing has been a nightmare for ages, but for desktops, it will (hopefully) push the HDD makers away from the ugly 2TB+ hacks (like the WD Advanced Format drives)
[16:13]  * manjo wonders why we need 2TB on clients ... don't we have cloud for storage ?
[16:13] <persia> manjo, reduced latency
[16:14] <G> manjo: haha, storage clouds make me laugh, especially when I'm sitting here w/ my 1.5Mbit down, 400kbps up link :)
[16:17] <G> manjo: but the other reason is that I create a ton of backups/shelve a heap of data to refer to later (not exactly important enough to warrant offsite backup but interesting enough to warrant something near-by)
[16:33] <manjo> cjwatson, I get a splash screen...
[16:35] <manjo> cking, what was the problem that cjwatson reported ?
[16:36] <manjo> cjwatson, I am going to proceed with the install ... looks like the CD booted fine (I need to double check that I booted in UEFI mode), UEFI CD/DVD was my 1st boot device and it looked like it recognized it as such
[16:37] <cjwatson> manjo: do you get into the installer?
[16:37] <cjwatson> G: GPT is the best feature of UEFI
[16:38] <manjo> cjohnston, yes
[16:38] <cjwatson> manjo: coo
[16:38] <manjo> I am on allocate drive space etc...
[16:38] <manjo> but I see a problem there :)
[16:38] <cjwatson> let me know how it goes!  my test machine doesn't get that far
[16:38] <manjo> select drive space : 360GGB ATA
[16:38] <manjo> below that
[16:38] <manjo> Ubuntu 0.0 B
[16:39] <manjo> what is that ?
[16:39] <G> cjwatson: yeah, hence why I want to see UEFI more common :)
[16:41] <cjwatson> manjo: I believe I've seen that bug on BIOS too
[16:41] <manjo> cjwatson, copying file now ... installing ..
[16:41] <cjwatson> manjo: I was expecting you to try server first :)
[16:41] <cjwatson> I can give desktop a try
[16:41] <manjo> cjwatson, was the problem on server iso not desktop ?
[16:41] <cjwatson> yeah
[16:41] <manjo> s**t
[16:41] <cjwatson> good to know that desktop seems to work though
[16:42] <cjwatson> that's useful in itself
[16:42] <manjo> ok will try the sever iso on another machine
[16:42] <cjwatson> do double-check that it booted in UEFI mode though
[16:44] <manjo> yep will do once its done installing
[16:44] <manjo> I need to reseed my server iso anyway
[16:44] <manjo> cjwatson, even if it booted cdrom in legacy mode I should be able to boot the HDD in UEFI mode correct ?
[16:45] <cjwatson> probably not since if it did that it would have put a BIOS version of grub there
[16:46] <manjo> cjwatson, bad newsw
[16:46] <manjo> cjwatson, grub install failede
[16:47] <manjo> cjwatson, grub-efi package failed to install into /target/
[16:48] <cjwatson> manjo: logs?
[16:48] <cjwatson> (with any luck I can try this too, in 1h45m or so)
[16:54] <manjo> cjwatson, http://kernel.ubuntu.com/~manjo/logs/logs.tgz
[16:54] <manjo> cjwatson, let me know if you need more info ... I will wait  on reboot
[16:56] <ScottK> superm1: Is the mythbuntu-common upload one that you need in for beta?
[16:56] <manjo> cjwatson, were you able to get the logs ?
[16:57] <cjwatson> yes
[16:57] <superm1> ScottK, yes ideally
[16:58] <ScottK> OK.  Let me check.
[16:58]  * manjo standing by
[16:58] <cjwatson> hm, I just queued up a mythbuntu build
[16:58] <cjwatson> oh well, you can just do another one later
[17:02] <cjwatson> manjo: ok, just a seed bug, fixed (though not in time for current beta builds)
[17:02] <manjo> can I work around ?
[17:04] <pitti> Keybuk: does ureadahead have some minimum blocking time on SSD as well? it seems the boot blocks on that on my system (http://people.canonical.com/~pitti/bootcharts/donald-maverick-20100805-1.png)
[17:04] <ScottK> superm1: Accepted.
[17:04] <superm1> thanks
[17:05] <ScottK> No problem.
[17:06] <cjwatson> manjo: uh, not sure
[17:07] <cjwatson> manjo: certainly not easily except by remastering the CD (which is in itself rather challenging)
[17:08] <cjwatson> actually, wait, the seed change was in ship-live!
[17:08] <cjwatson> not live - so that means the build in progress should pick it up
[17:08]  * manjo fingers crossed
[17:08] <Keybuk> pitti: not usually
[17:08] <manjo> cjwatson, ok will try the server cd to make sure it can make progress like desktop..
[17:08] <Keybuk> I think it may read the pack before going into the background
[17:09] <Keybuk> but that's no time
[17:09] <manjo> cjwatson, you need anymore info from this box before I reboot ?
[17:09] <Keybuk> pitti: get a blktrace of that?
[17:09] <pitti> Keybuk: I'll read about it (never used that so far)
[17:10] <cjwatson> manjo: nope
[17:10] <cjwatson> manjo: actually
[17:10] <cjwatson> manjo: cat /proc/fb
[17:10] <pitti> Keybuk: but thanks (I mainly was curious about whether this is expected); so I'll put that on my todo list
[17:10] <cjwatson> manjo: and can you try ctrl-alt-f1 and see if you see anything on the console?
[17:11] <manjo> I am on f1
[17:11] <manjo> proc/fb == 0 inteldrmfb
[17:12] <cjwatson> ok
[17:12] <manjo> there was noting on f1 when I switched
[17:13] <cjwatson> but there is now?  what did you do?
[17:13] <manjo> ?
[17:13] <Keybuk> pitti: no, but it's hard to tell what's going on there
[17:13] <manjo> I switched to f1 to copy logs etc to usb stick and put it up on kernel.ubuntu.com
[17:13] <cjwatson> manjo: do you mean that there was just a login prompt or something on ctrl-alt-f1 when you switched?
[17:13] <manjo> right
[17:13] <manjo> just a log in prompt
[17:13] <cjwatson> by "anything" I meant "not a blank screen" :-)
[17:14] <cjwatson> as in, is the console working
[17:14] <manjo> :) yeah console was working
[17:14] <Keybuk> pitti: for example, it could be that ureadahead is reading the things that modprobe already has loaded
[17:14] <manjo> heh I have gotten used to seeing a working console that Q confused me sorry
[17:14] <Keybuk> so it's null reads, that still cost syscall time
[17:14] <Keybuk> blktrace would reveal more detail
[17:14] <cjwatson> so it's possible that efifb isn't working, but that things get sorted out when inteldrmfb is loaded
[17:15] <cjwatson> in which case we'll need to bloat up the amd64 d-i initramfs some more
[17:15] <cjwatson> and figure out *why* efifb isn't working
[17:15] <cjwatson> or maybe there's some other difference between your machine and mine
[17:17] <cjwatson> I'm not entirely convinced that my initramfs is coming up
[17:17] <manjo> cjwatson, booting server now
[17:18] <manjo> cjwatson, server iso install in progress ...
[17:18] <cjwatson> that will suffer from the same problem at grub-efi, but cool, it works
[17:19] <cjwatson> that's an astonishing relief
[17:19] <cjwatson> now I need to figure out what's different about this box
[17:21] <manjo> cjwatson, yeah I guess its going to be the same fate... but I will let it make progress
[17:34] <manjo> cjwatson, ok hit the same spot ie bug
[17:34] <manjo> cjwatson, so you think the beta build for live server & desktop will pick up your fix ?
[17:36] <besogon> Just for a survey: what do you, developers, use for building a package?
[17:39] <manjo> cjwatson, I am 99.999% sure that I am booting UEFI mode, the 1st boot option on my boot list is EFI DVD/CDROM and it does not seem to fail that ie it hits option 1 and boots CDROM. \
[17:40] <cjwatson> yes, you are booting in UEFI mode
[17:40] <cjwatson> the desktop build just completed has picked it up (but is oversized and needs investigation); not sure if server will be respun
[17:41] <manjo> cjwatson, ok I have DVD I can use to burn image on
[17:41] <manjo> cjwatson, so if I reseed now I should get the latest correct ?
[17:42] <cjwatson> yep
[17:42] <manjo> cjwatson, which build should I use ? daily-live/current ? or daily/current ?
[17:42] <cjwatson> the former
[17:42] <manjo> daily-live it is
[17:43] <manjo> cjwatson, will test that bad boy in couple of mts
[17:50] <SpamapS> pitti: howdy, I submitted another optimization to the WI tracker today as a merge proposal. Should speed it up a lot actually.
[17:50] <pitti> SpamapS: I saw, thanks!
[17:52] <SpamapS> pitti: I'm trying to add some useful little panels to the HTML report, like a list of assigned bug tasks in ubuntu.. but I don't want to add this to collect. I'm wondering, do you know if there is a launchpad/ajax proxy available on people.canonical.com?
[17:52] <pitti> SpamapS: I'm afraid I don't even know what an ajax proxy is :/
[17:52] <SpamapS> pitti: I'm thinking of opening up an RT ticket to allow for one. That would let us put in some on demand stuff and not have to collect it all.
[17:53] <SpamapS> pitti: its just a program that would be running on there to get around javascript's "same-origin" restriction.
[17:53] <SpamapS> pitti: basically I can't ask launchpad.net for JSON from a script that originated on people.canonical.com
[17:54] <SpamapS> pitti: but if we could have a script on people.canonical.com that proxied directly to api.launchpad.net, there's no problem. :-P
[17:54] <SpamapS> actually I wonder if launchpad supports JSONP ..
[18:03] <superm1> cjwatson, with that respun oversized disk, on an e6410 it looks like there is a grub menu, but selecting the first option just yields a black screen
[18:04] <manjo> superm1, I did not want to hear that ! vanhoof ^^
[18:05] <manjo> superm1, on intel efi test bed.. its booting and installing as of now
[18:06] <manjo> vanhoof, I should try this iso on 4310 I have an make sure we see an install menu etc on maverick
[18:06] <cjwatson> superm1: seems that there are different results on different machines.  I get a blank screen too
[18:06] <cjwatson> superm1: the next thing I'm going to try is the grub newreloc branch, since I'm becoming convinced that the initramfs isn't being loaded properly
[18:06] <cjwatson> but this is why I wanted somebody to try with a serial console
[18:06] <superm1> cjwatson, i can likely get a port replicator that has a serial port if it would be useful
[18:07] <cjwatson> it's amazingly hard to debug this when the amount of information you get is a blank screen
[18:07] <manjo> cjwatson, the new iso fails grub install
[18:08] <manjo> executing grub-install on /dev/sda failed ...
[18:08] <manjo> I will put up the logs in a minute
[18:10] <vanhoof> manjo: perhaps he doesnt have the fix that was just released?  also there is 554569 which has helped a few people w/ 6410's, but its not been released yet
[18:10] <cjwatson> that might be a grub-installer bug; it probably shouldn't be offering device selection on EFI, and should be calling grub-install without a device argument
[18:10] <cjwatson> vanhoof: which fix?
[18:13] <vanhoof> cjwatson: 561802
[18:13] <vanhoof> which was released today in .42, but is only resolving a bug for UMA based 6410's
[18:13] <vanhoof> cjwatson: the 6410/6510 are a big pain atm :)
[18:14] <cjwatson> possible, though both those bugs seem a bit late for the symptoms I'm seeing at least
[18:14] <cjwatson> superm1: you might also try 'set gfxpayload=keep'
[18:14] <superm1> vanhoof, this is a UMA 6410, if I boot the DVD in legacy mode, i do get gfx.  it's only in EFI mode that the black screen comes up
[18:14] <cjwatson> (in grub, before the 'linux' command)
[18:14] <cjwatson> I'm not sure why I left that out, I think that was an oversight; you need gfxpayload=keep on EFI or you don't get a console
[18:14] <cjwatson> well, you might get a KMS one
[18:15] <manjo> cjwatson, logs are in http://kernel.ubuntu.com/~manjo/logs/logs-respiniso.tgz
[18:16] <cjwatson> manjo: right, as I thought
[18:17] <manjo> cjwatson, if you put in a fix today... will we have it in tomorrows spin of the iso ?
[18:17] <manjo> cjwatson, or are you planning on repinning ?
[18:17] <manjo> respinning
[18:19] <superm1> cjwatson, unfortunately no improvements with set gfxpayload=keep on the line before the linux line
[18:22] <ara> mdeslaur, hello
[18:23] <mdeslaur> hi ara
[18:24] <ara> mdeslaur, I am getting an error when trying to create a vm in virt-manager
[18:24] <mdeslaur> ara: which error?
[18:24] <ara> mdeslaur, can you have a look to the traceback, please?
[18:24] <ara> http://pastebin.ubuntu.com/486396/
[18:26] <cjwatson> manjo: I think I'm too late for beta now, but can work on things for post-beta
[18:26] <cjwatson> manjo: perhaps you could try applying http://paste.ubuntu.com/486399/ to /usr/share/grub-installer/grub-installer before starting ubiquity?
[18:27] <manjo> cjwatson, ok will do and retry
[18:29] <mdeslaur> ara: what are you doing to get that issue? also, could you paste the end of ~/.virt-manager/virt-manager.log ?
[18:29] <manjo> Sarvatt, your ppa ios ready ?
[18:29] <manjo> is
[18:29] <mdeslaur> ara: do you have anything related in dmesg?
[18:29] <ara> mdeslaur, I am just creating a VM without harddisk
[18:31] <ara> mdeslaur, http://pastebin.ubuntu.com/486402/
[18:31] <ara> mdeslaur, it does not seem to be anything relevant in dmesg
[18:33] <Shock> I've modified the nethogs package to adapt to terminal size changes. How do I generate a patch suitable and useful for inclusion in Ubuntu?
[18:33] <Shock> I didn't find the wiki information clear enough
[18:34] <mdeslaur> ara: which version of libvirt0? if you restart libvirt with sudo /etc/init.d/libvirt restart, does it help?
[18:37] <ara> version:  0.8.3-1ubuntu8
[18:37]  * ara tries restarting
[18:37] <Sarvatt> manjo: i386 is, amd64 is still waiting publication but you can just grab the deb
[18:37] <manjo> Sarvatt, ack
[18:38] <ara> mdeslaur, same thing after restarting
[18:38] <mdeslaur> ara: can you walk me through reproducing it?
[18:39] <ara> mdeslaur, sure
[18:39] <ara> create a new VM, any name
[18:39] <ara> select and ISO image as installation media
[18:39] <ara> and leave os type and version as "generic"
[18:40] <ara> leave ram and number of cpus with the default values
[18:40] <ara> uncheck "Enable storage for this virtual machine"
[18:40] <ara> and click on Finish
[18:41] <mdeslaur> ara: darn, that works for me :(
[18:41] <mdeslaur> ara: do your other VMs still work?
[18:41] <mdeslaur> ara: where is your iso file located?
[18:41] <ara> mdeslaur, yes
[18:41] <ara> mdeslaur, somewhere in my $HOME
[18:42] <mdeslaur> ara: did the iso get chowned to libvirt-qemu:kvm ?
[18:45] <ara> mdeslaur, mmm, it did
[18:45] <ara> mdeslaur, why did that happened?
[18:45] <mdeslaur> ara: yeah, stupid new libvirt chowns everything it touches
[18:45] <mdeslaur> ara: ok, that's normal
[18:46] <manjo> Sarvatt, with your ppa install I only see 1366x768
[18:46] <ara> mdeslaur, mmm, some other thing
[18:46] <Sarvatt> manjo: you rebooted? thanks for checking!
[18:46] <ara> mdeslaur, I have running another machine that has that ISO associated as well
[18:46] <manjo> Sarvatt, ofcourse!
[18:47] <mdeslaur> ara: as a test, could you try copying it over?
[18:47] <ara> mdeslaur, copying what¿
[18:47] <Sarvatt> manjo: have you tried maverick on that machine to see if its any different by any chance?
[18:48] <mdeslaur> ara: make a copy of the iso, to see if it's the fact that you're using it twice that libvirt doesn't like
[18:48] <ara> mdeslaur, OK, will do
[18:48] <manjo> Sarvatt, did few weeks back and same results .. yes was going to try the new beta spin that just happend
[18:49] <ara> mdeslaur, or I can try shutting down the other machine, for that matters
[18:49] <mdeslaur> ara: ok
[18:49] <Sarvatt> manjo: of course it wouldn't be that easy, thanks for the info :)
[18:51] <ara> mdeslaur, yes, that seems to be the problem
[18:51] <mdeslaur> ara: argh...what a piece of *&"/%/$&
[18:52] <mdeslaur> hehe
[18:52] <ara> mdeslaur, :)
[18:52] <cjwatson> manjo: so, no joy booting the desktop image here either
[18:52] <mdeslaur> ara: could you please file a bug?
[18:52] <ara> mdeslaur, it is a regression, AFAIK, I never had that problem before
[18:52] <mdeslaur> ara: under "libvirt"
[18:52] <ara> mdeslaur, sure, will do
[18:53] <manjo> cjwatson, :(
[18:53] <cjwatson> manjo: doesn't seem to be doing much in the way of CD access, so I rather suspect that this is not a graphics issue, but a memory map issue
[18:54] <mdeslaur> ara: thanks :)
[18:54] <cjwatson> manjo: still, it's good to know that it's not completely toast, just only on certain systems
[18:54] <cjwatson> that's a state I can work from
[18:54] <manjo> do you have an SDV that intel shipped ?
[18:54] <cjwatson> it's a Dell laptop
[18:55] <cjwatson> don't want any more hardware ... ;-)
[18:55] <manjo> heh
[18:56] <cjwatson> (plus, would in general rather have broken hardware than working hardware if it's something I'm meant to fix)
[18:56] <mdeslaur> ara: curiously, I can't reproduce...I can access the same iso twice without problems...
[18:56] <mdeslaur> weird
[18:57] <ara> mdeslaur, mmm, it does not seem to be the issue, as I reproduced now again having one the machines started (but without the ISO associated to it)
[18:57] <mdeslaur> ara: ok, cool. Could you send me the .xml files of those two vms?
[18:57] <ara> sure, will do
[18:58] <manjo> cjwatson, can't find /usr/sbin/grub-installer
[18:58] <cjwatson> manjo: I believe I said /usr/share/grub-installer/grub-installer
[18:59] <manjo> ah
[18:59] <cjwatson> smoser: what kind of state are ec2/uec builds in?
[18:59] <cjwatson> (for the purpose of posting to iso.qa)
[19:00] <smoser> cjji think they're good.
[19:00] <smoser> cjwatson,
[19:00] <smoser> i was going to start a testing run this afternoon.
[19:00] <cjwatson> should I be posting them?
[19:01] <ara> mdeslaur, where does virt-manager store those xml by default?
[19:02] <mdeslaur> ara: /etc/libvirt/qemu
[19:03] <manjo> cjwatson, installing with modified grub-installer now
[19:04] <ara> mdeslaur, sent them to your inbox
[19:05] <mdeslaur> ara: thanks
[19:09] <smoser> cjwatson, please post the 20100831, yes.
[19:12] <cjwatson> smoser: sorry, help for the stupid needed - 20100831 is a server build rather than an ec2/uec build, isn't it?
[19:12] <cjwatson> smoser: post-amis-to-iso-tracker.py seems to need an input file in some format
[19:12] <smoser> yeah. here.
[19:13] <smoser> http://uec-images.ubuntu.com/maverick/20100831/published-ec2-daily.txt
[19:13] <cjwatson> oh, right, duh
[19:13] <cjwatson> so 'curl http://uec-images.ubuntu.com/maverick/20100831/published-ec2-daily.txt | ./post-amis-to-iso-tracker.py'?
[19:17] <cjwatson> er, only with correct syntax
[19:18] <manjo> cjohnston, installer stuck in determining grub boot device ...
[19:18] <cjwatson> smoser: OK, posted.  What do I do for UEC?  Just post the server image build id?
[19:18] <manjo> cjwatson, ^^
[19:18] <smoser> yeah. just use the serial
[19:18] <smoser> 20100831
[19:18] <cjwatson> manjo: can you be a bit more exact?
[19:19] <cjwatson> ok
[19:19] <cjwatson> smoser: done
[19:19] <smoser> cjwatson, i've never run that script, but if it reads from stdin, that is what i would expect
[19:19] <smoser> thanks.
[19:19] <cjwatson> it needs a file name, so I adjusted
[19:21] <manjo> cjwatson, it says "Determining GRUB boot device ..." and is just hung there, no details in the message window, just Message: UseQuirks:
[19:21] <hunger> Could someboby please sync sash from debian unstable into maverick to fix bug no. 609201? Thanks!
[19:22] <cjwatson> hunger: nothing to sync, it's 3.7-10 in both
[19:23] <hunger> cjwatson: Can you then please have it rebuild?
[19:23] <cjwatson> hunger: can you first check that a no-change rebuild fixes it?  I don't have a 64-bit machine terribly convenient
[19:24] <hunger> cjwatson: It coredumps right on start for all amd64 mashines I tried it on. The version I build from the debian/unstable package works fine.
[19:24] <cjwatson> well, the unstable source package is the same as the maverick one, so I guess that's good enough
[19:24]  * hunger wonders what went wrong with the package then if it is the same sources.
[19:25] <cjwatson> built at different times with different toolchains.  did you build it from unstable using a current maverick system?
[19:25] <hunger> cjwatson: A fairly current maverick, yes.
[19:26] <hunger> cjwatson: Less than 1 week old.
[19:26] <cjwatson> I've uploaded a no-change rebuild
[19:26] <cjwatson> would appreciate a check that that fixes it, once it buils
[19:26] <cjwatson> *builds
[19:27] <hunger> cjwatson: Sure.
[19:30] <Shock> I've modified the nethogs package to adapt to terminal size changes. How do I generate a patch suitable and useful for inclusion in Ubuntu?
[19:43] <njin> ev, cjwatson: hello, i want to help in triaging Ubiquity, is possible ? Actually i'm on bugsquad under mentoring of pedro_
[20:16] <Shock> bzzz
[20:19] <cjwatson> Shock: what wiki page have you already looked at, and what did you find confusing about it?
[20:19] <cjwatson> that would be easier than telling you it all from scratch
[20:20] <cjwatson> Shock: (fundamentally, any patch in 'diff -u' format will be usable, though; depends whether you want to bother with the sponsorship process)
[20:20] <Shock> https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[20:20] <Shock> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[20:20] <Shock> https://wiki.ubuntu.com/UbuntuDevelopment/Patches
[20:20] <Shock> https://wiki.ubuntu.com/UbuntuDevelopment
[20:21] <Chipzz> Shock: yes, but the 3 first all describe different things
[20:21] <Shock> too much info; I'm not able to discern which applies to my usecase: I've modified a program and I want to make the modifications available to Ubuntu
[20:22] <Chipzz> Shock: I'll try to summarize (from the urls)
[20:22] <Shock> would it be sufficient it I opened a bug in launchpad and attached my diff?
[20:22] <cjwatson> are you familiar with producing patches in general?
[20:22] <Shock> yes
[20:22] <cjwatson> Shock: yes, it would
[20:22] <Shock> i've already produced the diff
[20:23] <Shock> thanks, I'll do that then
[20:23] <Chipzz> Shock: 3) is normal patch; 2) is inter-deb-version diffs (to see what changed between 2 uploads; takes the package as a whole into consideration)
[20:23] <Shock> any particular format the patch needs to be in?
[20:23] <cjwatson> then just do that.  there are more minutiae involved if what you're trying to do is to produce a new version of the package that somebody can just upload
[20:23] <cjwatson> which is useful if you're in training to become an Ubuntu developer
[20:23] <Chipzz> and 1) is a system to *apply* patches (i fyou have multiple in 1 package)
[20:24] <cjwatson> but if you just want to submit a drive-by patch, then a unified diff ('diff -u') is sufficient
[20:24] <Shock> cool
[20:24] <Chipzz> (1) is closely related to *building* the packages; 2) is entirely not)
[20:25] <Shock> which of the urls I listed apply to 1, 2 and which to 3?
[20:25] <Chipzz> lemme rephrase that: 1) only gets involved when building packages
[20:25] <Chipzz> 1) 21:20 < Shock> https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[20:25] <Chipzz> 2) 21:20 < Shock> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[20:25] <Chipzz> 3) 21:20 < Shock> https://wiki.ubuntu.com/UbuntuDevelopment/Patches
[20:25] <Shock> those are 2, i guess
[20:26] <Chipzz> nope
[20:26] <Chipzz> debdiff's are used to "audit" uploads
[20:26] <Shock> oh, i see
[20:27] <Chipzz> lets say cjwatson wants to upload a new version of a package; ppl *may* (but will not always) request a debdiff
[20:27] <Chipzz> the debdiff will contain all changes and hence you can see what changed on the source-level
[20:27] <Chipzz> to see if no unnecessary changes were introduced for example
[20:28] <Chipzz> patch-systems are more of this sort
[20:29] <Chipzz> lets say you have a package, and you make 2 seperate changes wrt the upstream source, lets call them patch_a.diff and patch_b.diff
[20:29] <Chipzz> now you need a way to easily apply those to the source
[20:29] <Shock> i know what patch systems are, e.g. quilt
[20:29] <Chipzz> ah k
[20:29] <Chipzz> good
[20:29] <Shock> i'm not sure how they fit in the overall picture in package development
[20:30] <Chipzz> trijntje: Dutch or Flamish? :)
[20:30] <Shock> especially as I've seen several patch systems used
[20:30] <Shock> dpatch, cdbs...
[20:30] <trijntje> Chipzz: Yeah, Dutch
[20:30] <Chipzz> they're a convenience feature mostly
[20:31] <Chipzz> Shock: and which one... is a matter of taste
[20:31] <Shock> so, if I'm a package maintainer I can use the one that suits my taste?
[20:31] <Chipzz> trijntje: nick gives you away ;)
[20:31] <Chipzz> yes
[20:31] <Chipzz> BUT
[20:31] <Chipzz> if you're just changing someone elses package
[20:31] <Chipzz> that's a different thing
[20:32] <Shock> even though others that might want to contribute to my package will need to learn the one I chose for my package?
[20:32] <Chipzz> for security uploads, the introduction of patch systems is disallowed for example
[20:32] <Chipzz> yeah
[20:32] <Shock> isn't that a higher barrier to entry for drive-by contributors?
[20:32] <trijntje> Chipzz: so it wasnt my IP ;)
[20:33] <Chipzz> trijntje allmost instantly reminded me of katrijn(tje) :)
[20:34] <Chipzz> Shock: not necessarily
[20:34] <Shock> Chipzz: how so? :)
[20:34] <Chipzz> Shock: I don't think most maintainers require you to submit patches to them in the form of their preferred patch system
[20:34] <Chipzz> it only applies if you're doing an upload
[20:35] <Chipzz> like cjwatson said, regular patch will be just fine
[20:35] <Shock> Chipzz: if you use cdbs in your package and I only know dpatch, don't I need to learn cdbs?
[20:35] <Chipzz> Shock: you just submit a regular patch
[20:35] <Shock> ok
[20:35] <trijntje> Chipzz: I just picked a random dutch sounding name, but now people think i'm female and a famous singer..
[20:35] <Chipzz> unless you want to try building it yourself *integrated* into the patch system
[20:35] <Shock> thanks Chipzz, cjwatson
[20:36] <Chipzz> Shock: but nothing prevents you from just hacking on the package and submitting a patch resulting from that
[20:36] <Chipzz> although the maintainer will have to convert it to his favorite patch system, and hence it may take longer to process
[20:36] <Chipzz> but that's a different matter :)
[20:36] <Shock> :)
[20:40] <manjo> cjwatson, if I set -x in grub_installer script where does the the messages go ?
[20:40] <manjo> I don't see it on the console
[20:41] <manjo> cjwatson, the install is stuck in "determining grub boot device.. "
[20:41] <manjo> this is after I applied your patch
[20:49] <manjo> cjwatson, logs in usual place named logs-withgrubpatch.tgz
[21:14] <arek_deepinit> hi all. i got problem with my display. from time to time it goes out of sync for about 1/10sec, dunno what is reason, im on gnome and i got ati x1550graphics, its really annoying
[21:14] <arek_deepinit> please help
[21:18] <Shock> arek_deepinit: try in #ubuntu, this is not a support channel
[21:19] <arek_deepinit> whoops
[21:19] <arek_deepinit> wrong room
[21:19] <arek_deepinit> ye, i meant #ubuntu
[21:19] <arek_deepinit> sorry
[22:15] <cjwatson> manjo: oh, sorry, my bad
[22:15] <manjo> cjwatson, :)
[22:16] <cjwatson> manjo: http://paste.ubuntu.com/486487/ should be better
[22:16] <manjo> I have another one for you
[22:16] <cjwatson> (extra 'else break')
[22:16] <manjo> Bug# 627672
[22:16] <manjo> cjwatson, ok will try that
[22:18] <cjwatson> manjo: I'm not dealing with ubiquity much this cycle; ev will probably need to look at that
[23:14] <ev> manjo: I'm going to take a look at that bug first thing in the morning.  Before I go though, are you able to reproduce it with a CD, or is this only occurring on the USB disk?  What did you create it with, is it a stock Ubuntu image?
[23:14] <ev> thanks in advance
[23:14] <manjo> ev, no CDrom on my netbook
[23:15] <manjo> ev, will update the bug with that info
[23:23] <SpamapS> is there any reason we don't like to use 'console output' in upstart jobs? Its very disconcerting that we won't be warned or informed about any problems when starting critical things like sshd.
[23:59] <slangasek> james_w`, lifeless: if I have a bzr packaging branch that doesn't contain pristine-tar info, but I want to start carrying that going forward, how can I import just the current package?