[00:00] (alternate answers accepted: a step-by-step of grafting LP's package history into my branch with richer revision history) [00:13] slangasek: if you are preparing a new upstream at the same time then you can use merge-upstream by tricking it [00:13] slangasek: otherwise you can basically do the same thing, and re-merge the same version that is currently there [00:13] james_w`: how does that work? :) [00:13] james_w`: I consistently get an error whining that it can't find the previous upstream version [00:14] slangasek: you find a revision that you want to be the current tip of the "upstream" branch and tag that with upstream-$UPSTREAM_VERSION [00:14] that will stop it whining about that [00:14] james_w`: does this have a wiki page? [00:14] after you have done the import then you can delete that tag again [00:14] maco: it does not, as far as I know [00:14] bcurtiswx was trying to do a merge with upstream last night and my bzr-fu started whimpering [00:14] (he was asking me for help) [00:15] james_w`: oho, thanks [00:15] ah, his was straight forward if it was the case I helped him with earlier [00:15] that should have a wiki page at least [00:16] * maco grumbles about varying definitions of "straightforward" [00:16] heh [00:17] I mean the usual case, not trying to do it for the first time like Steve [00:19] manjo: thanks [00:28] maco: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstreamVersion [00:28] james_w`: thanks [00:57] james_w`: seems I need to create tags for both the old and the new upstream versions? [00:58] slangasek: it should be creating the new upstream version for you [00:59] slangasek: what command are you running? [00:59] ah, so I only needed the one for the old upstream version [00:59] I misunderstood then [00:59] yeah, it just needs a hint of where to start, then it will do the rest [00:59] bzr merge-upstream --version 1.1.2 ../pam_1.1.2.orig.tar.gz ../bzr/bzr/Linux-PAM/tags/Linux-PAM-1_1_2/ [00:59] the error you were getting to start with was that it didn't know where to pick up the "upstream branch" from, and so didn't want to act [00:59] that looks fine [01:00] * slangasek nods [01:00] thanks :) [01:32] james_w`: so should this "create the tag yourself" hack be documented on the wiki page? [01:59] slangasek: probably, yes === hagebake is now known as hagabaka === steve|m1 is now known as steve|m === dendrobates is now known as dendro-afk [04:11] Hi guys. I'm a noob in kernel development. How do you load and use a kernel after building it? [04:13] msehudi: Sounds like you want to be in #ubuntu-kernel. You need to set up your bootloader to load the new kernel, but if you're using the Ubuntu build process that'll be done automatically when you install the package. [04:13] thanks :) [07:18] Good morning === ara_ is now known as ara [07:49] good morning [07:51] maco, HAPPY BIRTHDAY! [07:51] dholbach: danke! [07:52] * maco hugs dholbach [07:52] * dholbach hugs maco back [07:54] good morning [09:03] pitti, Morning Martin, could you put on your danger sensitive sunglasses and accept the uploaded Lucid kernel and lbm for sru? (in the case of lbm it probably makes sense to accept both -24 and -25?) [09:21] smb: ok, will do an SRU round [09:21] pitti, \o/ [09:32] smb: can you please reupload lbm with -v to include the last two changelog records? [09:32] pitti, Which one? The 24 or th -25 or both [09:33] smb: the -25 one [09:33] smb: same for linux-meta [09:33] pitti, ok, can do [09:33] * pitti rejects the current uploads [09:33] smb: thanks [09:34] smb: linux was uploaded twice (same version), so I'll reject the older upload and look at the newer; ok? [09:34] https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1 FYI [09:34] one 18 hours ago, one 11 h [09:34] hm, let me check [09:34] I am unaware of the second [09:35] pitti, How on earth would it be possible to upload the same version twice? [09:35] smb: you can upload as many broken or duplicated versions to the unapproved queue as you like :) [09:35] but you can only accept one version [09:36] pitti, Hm, I thought it would not let me upload anything again when it had gone into accept [09:36] right [09:36] but it wasn't accepted yet [09:36] it's in "unapproved" [09:37] right, for some reason I thought I need to increment the version even then. But so I can upload the just rejected packages only with more history [09:37] correct [09:37] usually, when this happens, I look at the most recently uploaded one [09:38] Probably ok, though very weird. I am pretty sure I did upload only once [09:38] ... [09:38] If I am not dream walking [09:38] pitti, hi [09:38] hello tkamppeter, how are you? [09:39] pitti, fine, as you have perhaps seen from earlier IRC discussion and from my weekly report I have cleaned up another 18 MB from the installed default system. [09:40] tkamppeter: from foomatic ppds? right, I saw that; nice work! [09:40] pitti, Hm, one seems to contain the orig tar.gz and the other not... Mine should not... [09:40] 18MB> coo [09:41] tkamppeter: that's uncompressed in the installed system, right? the .deb size shouldn't be affected that much, since that's already compressed, right? [09:41] pitti, I have replaced the Foomatic XML by a compressed PPD archive, saving said space and made printer driver listing (the "searching for drivers" in s-c-p, or simply "lpinfo -m") significantly faster. [09:41] http://cdimage.ubuntu.com/daily-live/20100901/ is still the same size as a few days ago [09:41] pitti, Is it possible for you to see who did the upload? [09:42] pitti, Of the newer one [09:42] pitti: well, there was some language-pack fiddling in there [09:42] smb: not really, I'm afraid [09:42] pitti, I could not upload due to beta freeze. I have prepared all packages. [09:42] tkamppeter: ah, that explains it [09:43] cjwatson: oh, just saw in the seeds; so something else got added to the CDs recently, or grew? [09:43] pitti, Ok, hold off. I want to investigate there [09:43] cjwatson: the day after the OO.o dependency fix landed, they all fit [09:43] smb: okay [09:44] pitti, in terms of .deb files it saves only half a meg, but there is still the speed advantage, which is probably much bigger when running a live system from a CD-ROM. [09:45] pitti, what has to be done to get the change onto the CDs are two steps, first me uploading the changed packages and then a core-dev changing the seeds from pulling foomatic-db and foomatic-db-engine to pulling foomatic-db-compressed-ppds. [09:45] pitti: the update-seeds cron job was stuck on a lock, so seed changes weren't being applied properly [09:46] which caused considerable confusion [09:46] ah, I see [09:47] cjwatson: oh, and the other issue is that we recently got a langpack update, so the delta packages aren't empty [09:47] cjwatson: it's not a biggie for beta, and for final we'll coordinate this more carefully [09:49] nod [09:49] smb: sconklin pinged me last night, so maybe it was him? [09:49] smb: ok, please let me know when I should look at them [09:50] at least the lucid SRU queue is empty except for this linux upload now [09:50] pitti: sorry to ask, but where as the udev upload been stuck ? (I don't know the exact process, but saw you'r tagging in the bzr.) [09:51] OdyX: it's held in unapproved; we are in beta freeze [09:51] OdyX: it'll go in tomorrow evening, if things go as planned [09:52] ah okay. But there's reasonable hope to get that in, right ? [09:52] not for beta [09:52] OdyX: not into beta [09:52] it'll go in for final [09:52] OdyX: but certainly into maverick === adamjiang is now known as jcadam === jcadam is now known as adamjiang [09:52] OdyX: people installing beta can just upgrade [09:52] okay. Otherwise I can release an usb-modeswitch not requiring the /lib/udev/hotplug.functions... [09:53] OdyX: don't worry [09:53] OdyX, hi [09:54] pitti: Okay. Thanks for your time to explain the basics of Ubuntu release management. :-> [09:54] tkamppeter: hi [09:54] heh [09:54] OdyX, if you want to see how my new replace Foomatic-XML-by-PPD-package looks like, all is on git now. [09:55] tkamppeter: yeah, saw that. As Debian is in freeze, I probably wont take a look before its release, but thanks for your work ! [09:57] pitti, one question about the migration from old XML ugliness to the new lightweight PPD archive: I made foomatic-db conflicting with the new foomatic-db-compressed-ppds and plan to replace foomatic-db and foomatic-db-engine by foomatic-db-compressed-ppds in the seeds (ubuntu-desktop, ...). Would the migration work then or do I need more. [09:58] tkamppeter: the new packages should conflicts:/replaces: the old ones; without the replaces:, apt will hold back the new ones instead of installing the new ones and removing the old ones [09:58] pitti, especially I want to avoid a "Replaces: foomatic-db" in foomatic-db-compressed-ppds as the PPD archive does not exactly replace foomatic-db, it only provides the PPDs to CUPS. [09:59] tkamppeter: can you install them in parallel? [09:59] tkamppeter: well, but the net result is the same, it supplies PPDs to cups; so replaces: wouldn't be really wrong from a semantics point of view? [10:00] pitti, yes, but I want that foomatic-db is removed for updaters so that once they get the space free, second there are no duplicate listings of the same PPDs, once coming from XML and second coming from the archive, and third there is no XML being processed making "lpinfo -m" slow. [10:01] tkamppeter: right; so I think C:/R: will do fine [10:02] pitti, so if I do the "Replaces:" can I be sure that the Build-depends: foomatic-db in the gutenprint package really installs foomatic-db on the buildds and not foomatic-db-compressed-ppds? This build process needs the actual XML. [10:02] tkamppeter: it doesn't affect build-depends [10:03] tkamppeter: the buildd chroots have neither pacakage installed, so they will install whatever you specify in the B-Dep: line [10:03] pitti, so build-depends always pulls the native packages and never Provides:? [10:03] tkamppeter: I think what you mean is "provides" [10:03] tkamppeter: but first, real pacakges are preferred over virtual ones, and second I don't think you need provides her [10:03] e [10:04] pitti, s/Provides/Replaces/ [10:04] tkamppeter: right; if there is a package "a" and a package "b" which "provides: a", an apt-get install a will always install a, not b [10:04] (unless b is already installed) [10:05] tkamppeter: replaces don't have that kind of magic [10:06] OdyX, would it be a problem for Debian if I add Replaces: foomatic-db to foomatic-db-compressed-ppds? [10:07] it would be weird _not_ to do it in Debian [10:07] tkamppeter: Conflicts: too, please; otherwise the other package wouldn't be removed [10:09] pitti, adding the C:/R: (C: was already there, adding R:). [10:19] pitti, apparently the second upload was done by tim. It is mostly the same, just is an upload which contains the orig.tar.gz. I would prefer to re-upload my version which has the diff only. Could you reject that currently uploaded one? [10:20] smb: well, can do, but having the orig.tar.gz doesn't hurt really [10:20] it'll be rejected if it's different from teh archive, and ignored otherwise [10:20] Hm, ok. The rest was the same. Then lets go with this one [10:21] And I prepare the lbms and meta [10:28] okay [10:31] sebner, hello [10:31] ricotz: hoi, what can I do for you? Currently a little bit short on time though [10:32] sebner, could you upload a new docky package to the lucid queue? [10:32] ricotz: just uploading? [10:32] sebner, https://edge.launchpad.net/~ricotz/+archive/staging/+files/docky_2.0.6-0ubuntu1.dsc [10:32] mvo: what about moving gdebi maintainer address to ubuntu-dev-team@lists.alioth.debian.org, so ubuntu-devel doesn't get spammed with PTS/BTS mails? [10:33] sebner, yes, as lucid-proposed [10:33] ricotz: sure, give me a minute [10:33] sebner, thank you! [10:36] DktrKranz: oh, excellent idea [10:36] DktrKranz: *cough* should have done that ealier, feel free to change bzr [10:36] pitti: I tried to backport cups from maverick to lucid to see if it fixes a bug I'm seeing, but the packaging fails when it complains about changed libcups2 symbols [10:37] tjaalton: oh, what's the symbol diff? [10:37] pitti: so should I just skip that test in the build, or? [10:37] pitti: hang on [10:37] tjaalton: I made it quite picky on symbol changes recently, since a previous upload wreaked a lot of havoc due to a changed gnutls [10:37] pitti: http://pastebin.com/TLiEF94X [10:38] mvo: doing now :) [10:39] tjaalton: ugh, lucid's dpkg-gensymbols apparently doesn't understand regexps yet? [10:39] ricotz: done, no problem yw :) [10:39] tjaalton: so, you can drop those two lines from debian/rules: [10:39] DPKG_GENSYMBOLS_CHECK_LEVEL=4 [10:39] export DPKG_GENSYMBOLS_CHECK_LEVEL [10:40] pitti: alright, I'll give it a go, thanks [10:41] smb: ugh, quite an update :) [10:41] pitti, Ok, lbm and meta for -25 uploaded again. [10:42] pitti, Heh, yeah four upstream stable version have some footprint [10:42] Unfortunately we were delayed quite a bit by security [10:42] and sprints [10:42] smb: does it have the "slow umount" fix?-) [10:42] tjaalton, yes [10:43] smb: sweet [10:43] pitti, If it is an relief for you, I am running most of it for quite a while now [10:52] pitti: thanks for approving the lucid SRU :) [10:53] no problem [10:53] pitti, hello, are ready to have a look at docky? [10:53] smb: FYI, I'll be on vac this Friday and next week, in case there are problems with this [10:54] ricotz: will do later; need to get back to some other work [10:54] pitti, Tbh I was planning the same for next week. :) [10:54] smb: nice timing! [10:54] pitti, no problem thanks [10:54] pitti, hehe [10:57] pitti: yep, built fine with that change === amitk is now known as amitk-afk === MacSlow is now known as MacSlow|lunch [11:57] pitti, where are the seeds for Ubuntu originally defined? In ubuntu-meta? Or is ubuntu-meta only a machine-generated derivative of the original definitions? [11:59] the latter. lp:~ubuntu-core-dev/ubuntu-seeds/platform.maverick lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.maverick [12:04] cjwatson, thank you. [12:05] the update script in ubuntu-meta generates it (mostly by just calling germinate-update-metapackage) === bilalakhtar_ is now known as bilalakhtar === amitk-afk is now known as amitk === MacSlow|lunch is now known as MacSlow [13:32] hello, i'm looking for the right package to report a bug on: whenever the X server fails to start, i'm stuck at the plymouth splash screen (five red dots, system only reacts to sysrqs) rather than getting a login prompt. [13:41] htorque: I'd say upstart [13:41] just a guess though [13:41] raphink: I was thinking more plymouth/xorg package for relevant video card [13:42] it sounds like more a framebuffer issue [13:42] G: the problem is not that X doesn't start, it is that it doesn't switch to a console login [13:42] exactly [13:43] well the thing is, plymouth really does start X [13:43] so it seems the problem is in dependency resolution of starting services [13:43] so it's more the transition isn't working [13:43] plymouth starts X and fails [13:43] htorque: out of interest, what Xorg/vid card are you running? [13:43] then plymouth should still die and leave the user with a way to log in [13:43] G: nvidia 6600 gt === schmidtm_ is now known as schmidtm [13:44] i can reproduce this by just renaming the device driver in xorg.conf to something bogus [13:44] htorque: try booting with "nomodeset" before filing a bug [13:49] james_w`: hi, what do you make of http://paste.ubuntu.com/486741/ === MacSlow is now known as MacSlow|afk === zyga is now known as zyga-away [14:08] apachelogger: fixed in the next version I believe [14:10] james_w`: I'll try trunk then ... merging all of core kde manually is a bit horrible ... thanks :) [14:11] apachelogger: should be http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/revision/471 [14:14] james_w`: yay, works :) [14:14] good === zyga-away is now known as zyga === oubiwann is now known as oubiwann-away === oubiwann-away is now known as ouibiwann [14:55] manjo,cking,superm1: interesting progress on figuring out what's wrong with EFI boot on this Dell laptop [14:55] firstly, the grub newreloc branch doesn't help [14:56] however, booting a 32-bit kernel rather than a 64-bit kernel works just fine [14:57] cjwatson, that's very useful data point. wonder why that is [14:59] cjwatson, so the 64 bit kernel is being executed and hangs, or just never gets executed? [15:00] cking: I can check again, but I believe your beeping kernel reached the beeps [15:00] er, led-flashing, that is [15:01] cjwatson, hrm. Have you tried booting into a non-debug 64 bit kernel? [15:01] I've tried the one that's on the maverick server amd64 CD, which I assume is non-debug [15:02] ttx: question about bug 625882 === MacSlow|afk is now known as MacSlow [15:02] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/625882) [15:02] bug 625882 [15:02] Launchpad bug 625882 in libdbi (Ubuntu) "libdbi0: ABI breakage without package name change" [High,New] https://launchpad.net/bugs/625882 [15:03] ttx: upstream released a fixed version that is just the ABI bump... [15:04] SpamapS: sounds good. want it targeted against Maverick ? [15:04] ttx: but now it would seem we need to rebuild everything that build-deps on libdbi0-dev .. [15:04] uh [15:04] ttx: the issue is that libdbi0 has broken error codes [15:04] SpamapS: how many packages would that be [15:05] ttx: source packages, I think 9 [15:05] ttx: total binary packages depending on libdbi0 is like 15 [15:05] SpamapS: that still sounds like a worthwhile goal === ouibiwann is now known as oubiwann [15:06] SpamapS: but you should run it past the release team (I'd suggest, after beta release) [15:06] SpamapS: I can do that for you on the release meeting if you don't get hold of them before. [15:07] ttx: is there a build-depends version of 'apt-cache rdepends' ? [15:07] hm, it's all in universe [15:07] ah no, some MIR was done on it [15:08] SpamapS: there is a tool, I think in ubuntu-dev-tools [15:08] I would check it out if I weren't deep in eucalyptus mud right now [15:08] ttx: yes libdbi had to be MIR'd because of rrdtool's dependence [15:10] ttx: no worries, I'll ask the release team what they think. [15:11] pitti: looking into that key error now. I think I have a fix [15:15] SpamapS: ah, thanks [15:17] pitti: just pushed to lp:~clint-fewbar/launchpad-work-items-tracker/parallel-reports [15:17] pitti: I don't think I ever let my run all the way to the global reports. oops. :-/ [15:18] SpamapS: merged, thanks! [15:20] pitti: hopefully the thing runs a bit faster now? [15:20] SpamapS: I don't know, it doesn't tell me the time [15:20] but I suppose it does [15:20] Question about GDM: how to get a pointer for structures hidden under the hood as priv attributes? For example how to aquire GdmGreeterSession.panel? [15:22] pitti: well given that all 3 are relatively similar in CPU/IO needs, and that they only read from the sqlite db (so no blocking on eachother AFAIK), it should mean nearly 3x improvement. ;) [15:23] pitti, hello, do you have time for a sru? [15:24] * pitti is in meeting, later [15:25] cking: any suggestions for where I might go from here? [15:25] I'm not perhaps entirely stuck but getting pretty close === diwic is now known as diwic_afk [15:27] cking: are we going to have to bisect LED-flashing at various points or something gross like that? I've confirmed that the LED-flashing kernel you gave me at the sprint does indeed flash the LEDs [15:27] cjwatson, this is the point where I boot with quiet and splash disabled - if I don't get any console output then I fall back to putting flashy LED code into the kernel in the initial boot stages to see where it fails [15:27] I've not been using quiet or splash at all [15:27] could I have the exact patch you used for http://kernel.ubuntu.com/~cking/uefi/? I couldn't see exactly how to plumb in your assembler [15:28] cjwatson, lemme dig it up [15:29] cjwatson: Curious about something regarding openssh. Is there any reason the upstart job doesn't run it with -D (so that it doesn't have to use expect fork) ? [15:32] cjwatson, email'd [15:32] SpamapS: I don't recall. Probably because I don't regard 'expect fork' as a particular hardship and wanted to keep it as close to the same as prior init scripts as possible [15:34] cjwatson: sounds reasonable. One issue I'm seeing is that if you break the config file, and do 'start ssh' the start command returns as successful....which is confusing. [15:40] cjwatson, however, I think one needs to shove the LED flashy code into x86_64_start_kernel() in arch/x86/kernel/head64.c - also, I suggest using earlyprintk=vga [15:41] will vga work here? [15:41] cjwatson, not 100% sure. It's been a while since I had to resort to this. [15:42] doesn't appear to do much with an unmodified kernel [15:43] cjwatson, that's why it's probably best to see if the kernel made it through x86_64_start_kernel() with flashy LEDs as a starting place [15:43] cjwatson, just sent you info in a mail [16:12] robbiew, cjwatson, skaet: FYI, I just documented the broken USB 3G cards in tech notes; not sure whether you consider it important enough for that, if not, please just kill it again (or ask me to do that) [16:12] pitti: thnx...I think it's worth keeping in [16:12] (fix is sitting in unapproved) [16:19] pitti, thanks! [16:21] hey skaet, how are you? [16:23] seb128, doing well. Watching how it all comes together, and helping where I can. [16:25] skaet, excellent [16:27] skaet: so you are currently absorbing all the MilestoneProcess, BetaProcess and "how to unscrew the archive" bits? :-) [16:29] pitti, yup trying to. firehose is on full ;) [16:31] jdstrand, bug #627812 [16:31] Launchpad bug 627812 in gdm (Ubuntu) "GDM restarts when pressing SHIFT+2" [Low,Incomplete] https://launchpad.net/bugs/627812 [16:31] that seems similar to the plymouth race pitti debug in portland last year [16:31] pitti, ^ remember the gdm crashing on first enter use we had in portland? [16:31] seb128: yes, I do [16:31] we started receiving quite some bugs about that for a week [16:32] the keystrokes went to both gdm and the underlying console with a getty underneath [16:32] do you know if there is anything which changed recently which could introduce back that issue? [16:32] because gdm wasn't started on vt7 initially [16:32] we still have an ugly hackish patch for this [16:32] jdstrand, ^ can you verify on what vt gdm is started? [16:32] pitti, I'm wondering if some update broke that [16:32] seb128: I'm not aware of anything [16:32] pitti, we got 5 bugs this week that seem similar [16:32] doesn't happen here, anyway [16:32] pitti, ok thanks [16:32] I don't have it either [16:33] * pitti checks bzr [16:33] jdstrand, I meant bug #626723 [16:33] Launchpad bug 626723 in xorg-server (Ubuntu) "gdm restarts on initial login" [Undecided,Confirmed] https://launchpad.net/bugs/626723 [16:34] jdstrand: and, do you have /var/run/gdm/firstserver.stamp ? [16:35] jdstrand: ^ take care, that dir is not readable for users, so you need sudo ls [16:37] kenvandine: around? :D [16:37] shadeslayer, hey [16:37] hey [16:38] kenvandine: i was told you work on gwibber [16:38] yup [16:38] so what are you doing about the OAuth switch for lucid? [16:38] about to upload to -proposed [16:38] ok [16:38] did a stable release last night [16:38] since choqok has a similar problem [16:38] seems a bunch of clients are broken [16:38] pitti, thanks, I've asked that on the bugs as well [16:39] ill be requesting a upload to proposed as well [16:39] we just got twitter to agree on a compromise a few days ago... not sure what choqok is doing about the consumer key [16:39] kenvandine: choqok 0.9.90 has OAuth support [16:39] but now i need 2 SRU's , qoauth and choqok === mathiaz_ is now known as mathiaz === yofel_ is now known as yofel [17:12] pitti: I do have /var/run/gdm/firstserver.stamp [17:14] seb128: tty8 [17:14] $ sudo lsof -p 4093 | grep tty [17:14] Xorg 4093 root 7u CHR 4,8 0t0 4616 /dev/tty8 [17:16] let me see something... [17:16] * jdstrand -> reboots [17:27] * jdstrand -> back [17:27] cking, cjwatson i should be able to help get a port replicator that works on a e6410 if you would like me to help do some instrumentation / debug over serial rather than you having to mess around with the meaning of different beeps or LED flashes [17:28] superm1, that's v.useful === smb is now known as smb-afk [17:36] seb128, pitti: ok, please see comment #9 in bug #626723 [17:36] Launchpad bug 626723 in xorg-server (Ubuntu) "gdm restarts on initial login" [Undecided,Confirmed] https://launchpad.net/bugs/626723 === beuno is now known as beuno-lunch [17:59] jdstrand, ok, seems a different issue then [17:59] jdstrand, the stracktrace in the log suggests xorg quits but not sure why === deryck is now known as deryck[lunch] === dendro-afk is now known as dendrobates [18:21] ogasawara, could you check if bug 605619 still needs to be documented in the release notes from the linux perspective? grub2 is resolved, but I can't tell if something needs to be done on linux side or not. [18:21] Launchpad bug 605619 in linux (Ubuntu) "display goes to sleep while system is in use" [Undecided,Invalid] https://launchpad.net/bugs/605619 [18:21] urk. [18:21] bug 605614 [18:21] Launchpad bug 605614 in linux (Ubuntu Maverick) "[ATI] GPU lockup with gfxpayload=keep" [Undecided,New] https://launchpad.net/bugs/605614 [18:25] skaet: it's still open because it needs to be cleared up for natty, as we'd like to turn that grub2 option back on (enables smooth visual transition from the bootloader to the OS), but it's no longer an issue for maverick [18:25] skaet: I don't believe it needs a release note from a linux package perspective since the the kernel issue was trigged if gfxpayload=keep, and grub2 switched back to gfxpayload=text for Maverick [18:25] cjwatson, thanks, will edit out of notes then. [18:25] skaet: but like cjwatson said, we want to keep the linux task open for Natty [18:26] ogasawara, thanks. [18:30] cjwatson, bug 612370 looks like its in, ok to edit out that comment as well? [18:30] Launchpad bug 612370 in sqlite3 (Debian) "Sync sqlite3 3.7.0-1.1 (main) from Debian unstable (main)" [Unknown,Confirmed] https://launchpad.net/bugs/612370 === cking_ is now known as cking [18:45] Hmm, so if I am renaming a -dev library (from libdbi0-dev to libdbi-dev) .. should I use Replaces, Conflicts *and* Provides? Packages that build-depend on libdbi0-dev will build just fine w/ libdbi-dev ... [18:51] cjwatson: sash works again! Thanks! === hunger___ is now known as hunger === dendrobates is now known as dendro-afk === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck [19:12] cjwatson, hi, do you have time for a sru? === dendro-afk is now known as dendrobates [19:18] SpamapS: I think Replaces/Breaks these days. === fddfoo is now known as fdd [19:29] Does anyone happen to have a launchpad-driven daily build of anything for Maverick that works? [19:29] I have one that doesn't, and I'd like to see one that does work so that I can work out what the difference is. [19:34] cking, cjwatson here's the output from a serial console: http://paste.ubuntu.com/486907/ [19:38] superm1, were you able to install maverick on EFI based system ? [19:38] superm1, or did you have to hack ? [19:39] manjo, that's booting from the amd64 daily in efi mode [19:39] with serial console enabled [19:39] superm1, reason I ask is yesterday I was not able to install [19:39] superm1, this is live CD ? [19:39] yes [19:39] ah [19:39] ok [19:40] superm1, looks like the calls to the EFI firmware are screwing up badly there [19:41] superm1, what version of EFI ? [19:41] 2.1 ? 2.3 ? [19:41] how can I check? [19:41] concurs with what cjwatson was seeing, e.g. it's fairly early in the kernel boot, just after x86_64_start_kernel() was entered [19:41] superm1, should say in your bios I guess [19:42] manjo, not seeing it anywhere in the firmware settings at least [19:43] superm1, I have a fairly new intel engg test bed with 2.1 and live CD works fine with 2.1 [19:43] when I hit F2 to get to fw [19:43] I see Bearlake Release # and EFI2.1.0 PI1.0 x64 [19:44] i suspect that is obfuscated from the stable firmware release on this machine === ivoks_away is now known as ivoks [19:48] superm1 [19:48] superm1, go to EFI shell and type ver [19:49] manjo, the efi shell is disabled for customer BIOSes [19:49] superm1, you can select boot manager [19:49] superm1, :) [19:49] ok === cking is now known as cking-afk [20:09] superm1, I think you load the legacy bios 1st, then use duet to do EFI, which intel EFI guru says can cause memory map issues, leacy does not have any memory map, so using duet to do memory map later you might have issues. Intel says only dell does this, and duet is not recommended to use on productiuon systems. [20:09] superm1, so this could be a dell EFI implementation issue you are hitting [20:10] however EFI worked with Windows 7... [20:10] i'm not sure on the actual implementation detail here though if duet was used [20:11] yeah they say using duet can cause strangeness.. if it works on their waybridge implenentation then it should be the duet memorymap that is causeing the problems [20:11] superm1, can you check with your bios ppls ? [20:11] sure, i'll see what i can find out === kentb is now known as kentb_dell === ivoks is now known as ivoks_away === Guest89807 is now known as porthose [21:16] what is the next version after lucid called? [21:16] 10.04 broke my portrait monitors for 3d accell and i want to try that before doing the whole crazy video song and dance [21:22] ni|: maverick. [21:39] anyone run portrait monitors? [21:39] nobody seems to know how to get proper acceleration [21:40] everything is fine in Normal mode; however, when i run orientation left everythign esplodes and goes really slow [21:40] i'm running Gallium and all. [21:40] (radeon) === ion_ is now known as ion === dendrobates is now known as dendro-afk [22:32] skaet: 612370> looks fair enough to remove [22:32] hunger: glad to hear it [22:36] superm1: oho, information. must get myself a serial console setup ... [22:36] ScottK: on Breaks/Replaces vs. Conflicts/Replaces/Provides , my thinking is that anything that will build against libdbi0-dev will also build against libdbi-dev .. and according to debian policy, thats the correct way to make sure there's only one of something that is installed and provides the same dependencies. [22:38] ScottK: IIRC, breaks is more for packages that configure the system in incompatible ways [22:39] SpamapS: breaks/conflicts is not about configuration [22:39] SpamapS: its about what phase of the dpkg transaction the graph incompatibility is permitted at [22:39] "When one binary package declares that it breaks another, dpkg will refuse to allow the package which declares Breaks be installed unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured." [22:39] yes [22:40] configuration in the very narrow sense of debian policy, not in the sense of 'oh, and I put my files in /srv' [22:40] a configured package isn't necessarily useful, but it is in a valid state to *run* [22:40] right, in the maintainer scripts configure, etc. right? [22:40] SpamapS: there was a recent change to Debian policy to be explicit that Breaks+Replaces is better than Conflicts+Replaces in nearly all situations. [22:41]