[06:37] <mlankhorst> RAOF: yeah needs testing though
[06:41] <mlankhorst> plymouth was really annoying, had to rebuild that one first without shlib depends before I could install renamed libdrm
[06:43] <RAOF> Yeah, essential: yes packages make the baby Jesus cry.
[06:45] <mlankhorst> RAOF: I had to disable the binary driver packages because I wasn't sure it would be needed to rename those. Newer versions will probably work with new abi too.
[06:45] <tjaalton> right
[06:45] <tjaalton> although, probably the 'stable' version needs to be renamed
[06:45] <RAOF> That's a fair point; we'd need to ship {nvidia-current,fglrx}-updates, though.
[06:46] <mlankhorst> indeed
[06:47] <mlankhorst> but since this was meant to  be a proof of concept for testing mechanics I felt just using open source drivers was enough for now :)
[06:47] <tjaalton> sure
[06:48] <mlankhorst> the part that scares me is the versioned replaces, I could install xfonts-base on top of the renamed package because it was newer
[06:49] <tjaalton> why would you need a renamed xfonts-base?
[06:49] <mlankhorst> tjaalton: this is just testing mechanics
[06:49] <mlankhorst> so why not
[06:49] <tjaalton> guess there are plenty of packages to test with already :)
[06:50] <mlankhorst> xfonts-base was special because of its dependency on xfonts-utils
[06:50] <tjaalton> ok
[06:51] <mlankhorst> I learned from that renaming xfonts-utils is non-trivial and an update would probably be better in that case
[06:52] <tjaalton> likely no need for either
[06:52] <mlankhorst> true, but good to test regardless
[06:53] <mlankhorst> and maybe not for quantal, but there are some other stacks to test too :)
[06:53] <tjaalton> core fonts, who uses them anymore anyway :)
[06:54] <tjaalton> no great new features to be seen there
[06:54] <RAOF> Are you sure we shouldn't backport xfs? :P
[06:54] <tjaalton> i'm sure we should drop it :)
[06:54] <mlankhorst> tjaalton: yeah but if xshiny-new-bright-fonts comse along that requires a new xfonts-utils
[06:55] <tjaalton> well maybe not drop it, low maintenance
[06:56] <RAOF> You mean: drop it as soon as someone files a bug against it. ?
[06:56] <tjaalton> hehe
[06:56] <mlankhorst> well duh D:
[06:56] <mlankhorst> dont drop it, just replace by empty package, see who complains, bahah
[06:57] <mlankhorst> lets see if the renamed stack installs on the cd
[06:58] <mlankhorst> im not going to let it anywhere near my dummy pc's hard drive
[07:15] <mlankhorst> hm console-setup gets annoyed too
[07:26] <mlankhorst> I guess now the goal is to get it installed without causing ubuntu-desktop and ubuntu-minimal to be removed :)
[07:31] <RAOF> :)
[07:33] <tjaalton> that would mean the provides are broken
[07:34] <mlankhorst> tjaalton: yeah can't do versioned provides
[07:35] <tjaalton> do they actually need those?
[07:35] <mlankhorst> that's the reason they're broken..
[07:35] <tjaalton> huh
[07:38] <RAOF> What's depending on explicit versions of the stack?
[07:47] <mlankhorst> usually because of a Depends ${shlib:Depends}
[07:48] <mlankhorst> which means basically anything that links to any library in our stack
[08:14] <RAOF> Oh, right.
[08:14] <RAOF> I thought we weren't updating libraries, though.
[08:14] <tjaalton> libdrm..
[08:14] <tjaalton> at least
[08:15] <tjaalton> probably not due to that though
[08:15] <RAOF> Right. But there's nothing outside the stack that depends on libdrm (?).
[08:15] <tjaalton> yeah
[08:17] <mlankhorst> RAOF: yeah but plymouth/intel-gpu-tools have versioned depends
[08:17] <mlankhorst> and console-setup had a versioned depends on xkb or something
[08:17] <RAOF> Yeah, but I was counting those as a part of the stack.
[08:17] <RAOF> Ah, console-setup?  Hmm.
[08:18] <mlankhorst> atm im just trying to get to 0 removes, so by pushing new packages im keeping track of which packages break
[08:18] <tjaalton> console-setup could drop the versioned depend
[08:18] <tjaalton> >= 0.9..
[08:18] <mlankhorst> thats what my rebuild does
[08:19] <tjaalton> we're at 2.5 now
[08:19] <mlankhorst> get it in for quantal, then :D
[08:19] <mlankhorst> i dont have the rights to push anything
[08:20] <tjaalton> it should go as an SRU for precise as well
[08:20] <tjaalton> preferably before 12.04.1..
[08:26] <mlankhorst> tjaalton: we're not sure yet what packages we would need, this is just a test of the mechanics
[08:27] <tjaalton> so it's not blocking anything?
[08:27] <tjaalton> i'm confused
[08:27] <mlankhorst> erm, it depends if we decide we need a new xkeyboard-config and x11-xkb-utils or not
[08:27] <tjaalton> it's a nice-to-have, not something hw enablement needs
[08:29] <mlankhorst> if you want it drop version in console-setup and sru it, if not just dont ship those 2 renamed :-)
[08:30] <tjaalton> dropping the version is easier
[08:31] <mlankhorst> oh right, need to rebuild the xorg package too
[08:32] <mlankhorst> RAOF: any objections if the xorg source package will be treated specially? makes things a lot easier
[08:36] <RAOF> None at all.
[08:36] <mlankhorst> perfect :-)
[08:36] <tjaalton> yeah, big thumbs up from me
[08:37] <tjaalton> most of the metapackages it builds make no sense
[08:37] <tjaalton> for the backports
[08:37] <mlankhorst> tjaalton: those metapackages need to be tweaked to depend on the oldname | newname
[08:37] <tjaalton> right
[08:59] <mlankhorst> hm, how can I see why apt-get install .*lts-backport-quantal decides to remove some packages?
[09:01] <RAOF> mlankhorst: I find that aptitude's resolver is sometimes more usefully verbose.
[09:02] <mlankhorst> yeah but it doesn't allow regexp install
[09:02] <RAOF> ~nlts-backport-quantal
[09:02] <mlankhorst> ty :)
[09:03] <RAOF> You can also play around with the debug options (pass -o to apt-get, check out "man apt.conf" for the things you can actually *pass* to apt-get)
[09:05] <mlankhorst> oh libxklavier16 was going to be removed it seems
[09:05] <mlankhorst> xkb-data >= 0.8, sigh
[09:07] <tjaalton> uh
[09:09] <mlankhorst> klavier is flemish for keyboard :)
[09:19] <mlankhorst> oh fun, it keeps adding the versioned depend on xkb-data back
[09:19] <tjaalton> check if there's a control.in
[09:20] <tjaalton> since it's a gnome package..
[09:20] <mlankhorst> yeah it has ;s
[09:20] <mlankhorst> just independently noticed it 
[09:20] <tjaalton> so modify that instead
[09:21] <mlankhorst> yeah i did, i keep running into weird new ways of packaging :-)
[09:23] <mlankhorst> almost all packages seem to have their own silly way to break
[09:25] <mlankhorst> success! It only replaces the X stack itself now
[09:27] <tjaalton> nice
[09:29] <mlankhorst> still some package failure it seems
[09:29] <mlankhorst> oh right.. cant install libgl1-mesa-swx11 at the same time as the normal version
[09:33]  * RAOF wonders why we even build that package
[09:36] <mlankhorst> no idea :-)
[09:37] <mlankhorst> probably carried over from debian and removing was more work
[09:38] <tjaalton> just that it's become somewhat obsolete on the hw we support
[09:38] <tjaalton> due to llvmpipe
[09:39] <tjaalton> i'd like to drop the 8 & 16bit osmesa packages..
[09:39] <mlankhorst> oh woops, probably broken due to rename
[09:41] <mlankhorst> looks like mesa packaging needs more love
[09:56] <mlankhorst> hm, how do the bug scripts work?
[09:57] <mlankhorst> seems they're path dependent on package name, but with renamed package it looks like it would break
[10:21] <tjaalton> do we want bugs for them?-)
[10:21] <tjaalton> besides, you can just use the original names/links
[10:21] <tjaalton> we don't really want bugreports against the renamed source packages..
[10:22] <mlankhorst> i have no idea how the mechanism is supposed to work for that
[10:24] <mlankhorst> but ok I'll trust you on that one. :s
[10:25] <tjaalton> well, it's just pointing to the xorg bug script
[10:26] <tjaalton> but not sure if apport will use the package source name anyway
[10:28] <mlankhorst> ill just keep it broken for now
[10:29] <mlankhorst> I don't think it's a source package, but the binary package being used
[12:58] <tjaalton> hm, apport isn't that useful.. my gpu hung and apport offered to report a bug, but after clicking 'continue' the window just closed and didn't open lp for finishing the submission
[12:58] <mlankhorst> oh seems we DO need all open source drivers including the ugly ones for testing, else xserver-xorg-video-all fails
[12:59] <tjaalton> or you create xserver-xorg-{input,video}-some
[12:59] <tjaalton> probably not a good idea..
[13:02] <mlankhorst> well i can replace the X stack now at least
[13:03] <mlankhorst> I think the upgrade is breaking because of the last missing ones to satisfy the xserver-xorg-video-all install
[13:08] <mlankhorst> my goal for today is simply being able to install the renamed stack without removing any packages that haven't been renamed.
[13:35] <tjaalton> hmm, does kernel 3.4 require something special for intel? it's not using intel kms here..
[13:35] <tjaalton> but vesa, which probably makes the kernel hang hard after maybe 10s
[13:37] <mlankhorst> anything in xorg log?
[13:38] <tjaalton> just that it falls back using vesa
[13:38] <tjaalton> in fact it doesn't initialize drm at all
[13:38] <tjaalton> ..
[13:38] <mlankhorst> o.o
[13:38] <tjaalton> revealed by dmesg
[13:39] <mlankhorst> well there you go, then
[13:40] <mlankhorst> the pae kernel should work on non-pae hardware right?
[13:42] <tjaalton> not sure
[13:43] <tjaalton> actually no, it doesn't work
[13:47] <tjaalton> 3.4 works on an old i965 based machine
[14:04] <bjsnider> is there still a non-pae i386 kernel?
[14:06] <tjaalton> it's getting removed from quantal
[14:06] <tjaalton> or not built anymore, dunno
[14:12] <tjaalton> the problem I had was missing dri modules from the drm-next build
[14:12] <tjaalton> ..
[14:15] <mlankhorst> hm during upgrading it removes ubuntu-desktop, but i can install it again afterwards, sigh
[14:21] <mlankhorst> I guess I'll need to specify ALL the packages to apt-get in 1 go :)
[14:21] <tjaalton> check with aptitude why it removes u-d
[14:22] <mlankhorst> i know why, i missed some packages causing xorg to be removed
[14:23] <mlankhorst> so I'm just going to create a dummy package in xorg that has a dependency on the whole renamed stack
[14:24] <tjaalton> ok
[14:30] <mlankhorst> hm, how do I sed variables in a makefile?
[14:31] <mlankhorst> nm I think ill split it off to its own package
[16:46] <mlankhorst> bryceh/raof: I can install the updated stack from q-lts-backport now, see the mail I sent on the ubuntu-x mailing list :-)
[23:36] <bryceh> mlankhorst, sweet