[01:00] <bryce> slangasek: what package are we assigning hotkey issues to nowadays?
[01:55]  * lamont looks around for jdstrand or any ufw-literate person so he can grumble at them
[01:55] <StevenK> I can use it, but I didn't write it, does that help?
[01:56] <jdstrand> lamont: yes?
[01:56] <lamont> StevenK: how the hell do I add a rule to ufw-user-forward through the &%(%) CLI?
[01:56] <jdstrand> lamont: you don't-- ufw doesn't allow modification to that chain (yet) via the cli
[01:56] <jdstrand> lamont: but you can add it to /etc/ufw/before.rules (or after.rules if it makes sense to you)
[01:57] <lamont> jdstrand: ah... that would explain my frustration.... so... given ufw alive and well on the machine, how do I have forward rules
[01:57] <lamont> ?
[01:57] <lamont> or do I just throw baby and bathwater out?
[01:57]  * lamont learns to read while typing
[01:57] <jdstrand> lamont: think of ufw as two parts: a) the cli command and b) the framework
[01:57] <Baby> eh?
[01:57] <StevenK> Haha
[01:57] <lamont> rotfl
[01:58] <StevenK> I would love it if ufw would support SNAT and forwarding rules.
[01:58] <jdstrand> lamont: the cli command allows for very easy host-based firewalls. the framework allows for all the power of iptables
[01:58] <jdstrand> lamont: so, add what you want to before.rules, then do 'sudo ufw disable ; sudo ufw enable'
[01:59] <jdstrand> StevenK: nat would be nice yes
[01:59] <StevenK> jdstrand: Fix it? :-D
[02:00] <jdstrand> StevenK: sure, I don't seem to have your patch... :P
[02:00] <lamont> yeah...  my big issue is (1) two different users with firewall needs that are not up to iptables, but want to co-admin what I set up for them, and (b) the pain that an incomplete ufw brings
[02:00] <StevenK> Haha!
[02:00] <lamont> mixed in with the fact that I've never even used iptables-restore...
[02:00] <StevenK> That's my current firewall script
[02:00]  * lamont has always just rolled his own - it's not like it's complicated or anything...
[02:01] <lamont> (given a network-engineering background)
[02:01] <StevenK> lamont: Simplest way to use iptables-restore is run iptables-save > file, edit the file and iptables-restore it
[02:01]  * jdong has observed most people struggling with setting up iptables general don't have a solid grasp of what they are trying to do conceptually...
[02:01] <jdstrand> lamont: for the most part, you can write an iptables rules, and leave iptables off the front
[02:01] <jdong> not to downplay the significance of that hurdle of course :)
[02:02] <lamont> heh
[02:02] <jdstrand> lamont: if I may say, ufw works quite well for host-based firewalls. more than that and there are a few niggles, but works pretty well for the most part
[02:03] <lamont> jdong: exactly.  given a firm understanding of the protocol interactions, iptables is trivial.  without it, well... pain
[02:03] <jdong> right.
[02:03] <wgrant> Pain and insecurity.
[02:03] <jdstrand> lamont: using it for routing is doable, but likely too hard for now
[02:03] <jdong> generally when you find someone griping about iptables and ask them to explain specifically what they are trying to do, they fail to be able to do so without resorting to magical terms :)
[02:04] <jdstrand> but, it is actively being developed... I seem to remember StevenK offering a nat patch not too long ago ;)
[02:04]  * StevenK kicks jdstrand 
[02:04] <jdstrand> hehe
[02:05]  * kees waves good-bye to opera
[02:06] <NCommander> hey StevenK
[02:06] <wgrant> kees: Why?
[02:06]  * StevenK waves to NCommander 
[02:06] <NCommander> StevenK, how was your flight?
[02:06] <kees> wgrant: it's not in the partner archive any more except for jaunty
[02:06] <StevenK> NCommander: Crap
[02:06] <wgrant> kees: Oh, why? Security?
[02:06] <kees> wgrant: yeah
[02:06]  * wgrant sleeps at StevenK.
[02:06] <NCommander> StevenK, ah, I know the feeling
[02:07] <lamont> kees: security hard.  lets go shopping
[02:07] <StevenK> wgrant, NCommander: I slept on the plane for 6 hours, that wasn't why it was crap
[02:07] <wgrant> Oh.
[02:07]  * wgrant fidgets instead.
[02:07]  * NCommander had turberance all the way from Chicago to Rochester
[02:07] <NCommander> First time I ever got quizzy while flying
[02:07]  * StevenK kills wgrant, casts Redepmtion on him, and then brutally kills him again
[02:08]  * wgrant is uninterruptable.
[02:08] <StevenK> NCommander: The flight was bumpy and turblent, the service was terrible, and BABIES!
[02:08] <StevenK> Argh, babies!
[02:08]  * NCommander removes the NMI for wgrant and then calls int wgrant
[02:08] <wgrant> Ah yes, the babies.
[02:08] <wgrant> They weren't too bad from where we were (the back row), but they were present.
[02:09] <wgrant> What was wrong with the service?
[02:09] <StevenK> Slow
[02:09] <StevenK> I pressed my call button and waited ten minutes, two times
[02:09] <wgrant> I did notice that they seemed to do only one side at once and were fairly late.
[02:09] <wgrant> Hah.
[02:12] <elitest> hey erbody
[02:57]  * lamont grumbles at the menu system.. generally speaking, where is the command associated with a menu in the stock menus found?  more specifically, how do I see what command is exceuted for "administration -> create a usb startup disk'??
[02:58] <lamont> or should I just go to bed/
[02:59]  * lamont finds his answer, or at least enough of one
[03:21]  * wgrant wonders what is going on with yorick's armel build.
[03:21] <wgrant> I've seen it building at least three times today.
[03:22] <lamont> what does the log look like when it dies?
[03:22] <wgrant> Illegal instruction.
[03:25] <lamont> \o/
[03:26] <wgrant> But somebody keeps retrying it, but it doesn't look like a normal give-back.
[03:28] <lamont> interesting
[03:35]  * lamont -> home
[03:36] <ebroder> I'd like to see an SRU for LP #216761 in both Hardy and Intrepid. Is there some way I can represent in ths bug status that the bug has been fixed in Jaunty, but Intrepid is still affected?
[03:39] <ebroder> Should I just open a separate bug for the SRU?
[03:41] <pitti> calc: suitesparse> that's fine
[03:41] <pitti> doko: cython> ah, thanks
[03:42] <pitti> Good morning everyone
[03:42]  * StevenK waves to pitti 
[03:42]  * pitti hugs StevenK
[03:42] <LaserJock> pitti: where are you? it seems quite late for DE
[03:42] <pitti> LaserJock: no, it's rather terribly earliy
[03:43] <pitti> 4:42
[03:43] <pitti> but I can't sleep any more
[03:43] <ArneGoetje> pitti: can't sleep? :)
[03:43] <LaserJock> ugg
[03:43] <ArneGoetje> pitti: jet lag?
[03:43] <pitti> yeah
[03:43] <pitti> I slept 2 hours in the plane Sat-Sun, and four hours last night, now 5 hours
[03:43] <pitti> so I'm making progress :-P
[03:50] <LaserJock> I'd have thought by now you'd be used to UDSlag
[03:50] <LaserJock> maybe a person's body never really gets used to it
[03:51] <StevenK> I'm dealing with jetlag much better than when I started going to UDS
[03:51] <NCommander> hey pitti
[03:51] <xivulon> awake here (3am)
[03:52] <StevenK> I think I'll need one more sleep cycle, and I'll be back in the timezone
[03:53] <LaserJock> I've only been to 2 out of my timezone, but I think I had more problems while I was there than when I got home
[03:54] <LaserJock> 'course the Ubuflu got me a few days sleep post-
[03:54] <StevenK> That's what Melatonin is for, but I only needed that once
[03:54] <LaserJock> UDS
[03:55] <ajmitch> StevenK: it helps if you don't have a regular sleep cycle anyway :)
[03:55] <jamesh> perhaps you could try adjusting to the new time zone a few weeks before going to UDS
[03:56] <StevenK> ajmitch: I do so!
[03:56] <pitti> fortunately I didn't get UbuFly on either the way there nor back this time \o/
[03:56] <pitti> erm, UbuFlu
[03:56] <wgrant> Very few got UbuFlu.
[03:56] <StevenK> I think I missed out, too
[03:57] <StevenK> Hmph. How am I supposed to modify $PATH in debian/rules ?
[03:58] <jamesh> StevenK: "export PATH" ?
[03:59] <jamesh> make variables are not exported as environment variables by default
[03:59] <StevenK> Well, I want to modify it first
[03:59] <StevenK> Neither $$PATH, $PATH or $(PATH) are giving me love
[03:59] <jamesh> export PATH := whatever:$(PATH)
[04:00] <StevenK> Oh, duh, :=
[04:00]  * StevenK kicks make for being obtuse
[04:01] <jamesh> ":=" to evaluate immediately
[04:01] <StevenK> Yup
[04:01] <StevenK> Hence the "Oh, duh, :="
[04:01]  * calc was one of the UbuFlu victims
[04:05]  * NCommander may be developing UbuFlu
[04:05] <NCommander> Freaking free viruses
[04:05] <NCommander> NOT WHAT I WANT!
[04:09] <pitti> NCommander: that's why you are using Linux, aren't you?
[04:09] <NCommander> Viruses shouldn't be freeware ...
[04:09] <NCommander> or shareware
[04:09] <ajmitch> it's all about sharing
[04:19] <ScottK-laptop> NCommander: Next time you'll know to sit next to people you don't like and breath on them.
[04:19]  * StevenK stares at the buildlog for apex which insists -Bsymbolic-functions isn't valid
[04:19] <StevenK> ScottK-laptop: Harsh
[04:19] <ScottK-laptop> But realistic.
[04:20] <StevenK> Someone remind me to keep at least one room distance from ScottK-laptop
[04:20] <NCommander> StevenK, apex is packaged?
[04:21] <StevenK> And in both Ubuntu and Debian
[04:21] <ScottK-laptop> Apparently not very well.
[04:21] <StevenK> I think it's an upstream thinko
[04:23]  * StevenK hits ScottK-laptop with the shovel he just used to move blame around
[04:23] <NCommander> lol
[04:24]  * NCommander grumbles :-/
[04:24]  * ScottK-laptop has had too much Scotch to actually feel it, so whatever.
[04:24] <NCommander> o_o;
[04:24]  * NCommander decides to take another whack at kde
[04:26] <StevenK> NCommander: KDE on armel?
[04:26] <NCommander> yeah
[04:26] <NCommander> Argh
[04:26] <NCommander> kde4libs is still building
[04:27]  * LaserJock just lost his grading pen :(
[04:27]  * NCommander is currently waiting for a few more test images to finish with imagewriter-qt
[04:27] <ajmitch> LaserJock: all you need is a big red pen, right?
[04:27] <LaserJock> ajmitch: yeah, but i was down to my last one
[04:27] <LaserJock> I got up, got a drink of water, came back, no pen
[04:28] <LaserJock> but I just found it behind my laptop so all is not lost
[04:28] <LaserJock> poor students :-)
[04:28] <StevenK> Ah ha. Now I get why apex built on Debian, but not Ubuntu.
[04:28] <StevenK> dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions
[04:42] <NCommander> So apex is fixed StevenK
[04:42] <StevenK> NCommander: Oh?
[04:43] <NCommander> ^?
[04:43] <StevenK> NCommander: Fixing. It's in the queue after this schroot build
[04:43] <NCommander> ah, nice :-)
[04:43] <NCommander> We should probably have redboot packaged ...
[04:44] <StevenK> gcc-snapshot adds a whole lot to the Build-Depends
[04:58] <pitti> calc: no, suitesparse is in hardy/universe, and I can't find a MIR wiki page or bug
[04:58] <StevenK> pitti: Looks like I need three armel packages promoted for d-i, shall I write three MIRs and prod you?
[05:03] <calc> pitti: it had been in main for 3.0.0-3 in gutsy but got knocked back into universe
[05:04] <calc> pitti: lp-solve had also been in gutsy main at one point but got knocked back out as well
[05:41] <ebroder> For a package that's not in Debian, am I supposed to set XSCB-Original-Maintainer, or am I the maintainer?
[06:42] <lool> morning
[06:43] <nxvl> morning
[06:47]  * pitti recovers from X segfault after dist-upgrade
[06:47] <pitti> StevenK: just subscribe ubuntu-mir, I'll get mailed
[06:47] <pitti> calc: okay
[06:48] <nxvl> pitti: good morning
[06:48] <pitti> hey nxvl
[06:48] <pitti> slightly more civilized time now :)
[06:49] <StevenK> pitti: Hum? Do I need to write 3 seperate MIRs, or something else?
[06:49] <pitti> StevenK: if it's three unrelated sources, yes; if they are trivial, just file bug tasks
[06:50]  * StevenK needs to fix one of them to build first
[06:50] <pitti> tjaalton: so you broke X on G945 :)
[06:54] <lool> pitti: Do you think it's specific to this chip?  I'm pondering dist-upgrading to jaunty, but then not if I'd miss xorg on intel (I have g33 though)
[06:54] <nxvl> pitti: you have a 2 lines terminal, right?
[06:54] <pitti> lool: I don't know
[06:54] <dholbach> good morning
[06:54] <pitti> nxvl: "2 lines"?
[06:54] <nxvl> s/terminal/promt
[06:54] <pitti> hey dholbach
[06:54] <nxvl> promt
[06:54] <pitti> nxvl: yes, why?
[06:55] <dholbach> hi pitti
[06:55] <nxvl> pitti: i'm playing with mine, and i'm having a strange issue, when i type a long command which doesn't fit in my terminal it continues on the beggining on the same line
[06:55] <nxvl> pitti: have you seen something like this
[06:55] <nxvl> dholbach: hi!
[06:56] <pitti> nxvl: only on the VTs, not in gnome-terminal
[06:56] <nxvl> i've it everywhere
[06:56] <dholbach> hiya nxvl
[06:57] <tjaalton> pitti: yes, and no way to fix it until the drm.h issue is solved (the segfault is fixed upstream) :)
[06:58] <pitti> tjaalton: oh, is that the linux-libc-dev vs. libdrm-dev file conflict?
[06:58] <tjaalton> pitti: yes
[06:58] <pitti> tjaalton: ah, so if I rebuild -intel against the right one, it shuold work?
[06:58] <tjaalton> everything that b-deps libdrm-dev should fail to build
[06:58] <tjaalton> pitti: it's a bug in the xserver, not the driver
[06:58] <pitti> tjaalton: I just tried locally rebuilding -intel, doesn't work
[06:58] <pitti> oh, ok
[06:59] <pitti> tjaalton: so that's xorg-server?
[06:59] <tjaalton> pitti: yes
[06:59] <tjaalton> bug 308225
[06:59] <tjaalton> duh
[06:59] <pitti> tjaalton: I'll duplicate my bug then (bug 308464)
[07:00] <tjaalton> pitti: oh, that might be different, let me check
[07:00] <pitti> tjaalton: I do have the current version, though, so it's not FTBFS
[07:00] <tjaalton> pitti: I meant that uploading a new version would FTBFS
[07:01] <StevenK> pitti: slugimage and uboot-mkimage look completly trivial, do you still want MIRs?
[07:01] <pitti> StevenK: as I said, only for nontrivial packages; we always need MIR bugs, but not always wiki pages
[07:03] <tjaalton> pitti: looks similar enough, I'll dupe it
[07:03] <StevenK> pitti: Okay, I'll file one bug for all three, but only do a report for apex.
[07:14] <nxvl> k, fixed
[07:32] <slangasek> bryce: depends on the kind of issue? :)
[07:42] <tjaalton> what should be done about bug 308387?
[07:43] <tjaalton> debian does not have drm/* in their package, so the change seems to have pulled in a bit too much
[07:43] <bryce> tjaalton: can you set https://blueprints.edge.launchpad.net/ubuntu/+spec/xorg-jaunty to completed (unless you wish to use it for tracking progress or something)?
[07:45] <tjaalton> bryce: hmm ok
[07:48] <StevenK> pitti: MIR filed. Bug 308465
[07:48] <StevenK> pitti: I should say sorry for including the word "hand-wave" in an MIR
[08:04] <pitti> tjaalton: bug 308225 updated; I have my normal X back \o/
[08:05] <NCommander> yay pitti
[08:05] <pitti> tjaalton: hey, and the "Control-C kills server" bug is fixed, too
[08:10] <tjaalton> pitti: great, I've pulled 1.6-branch and will upload. it will FTBFS though because of the aforementioned kernel bug
[08:18] <bryce> tjaalton: thanks
[08:22] <tjaalton> bryce: my pleasure ;)
[08:22] <tjaalton> pitti: strange, AllowEmptyInput is the default
[08:22] <pitti> tjaalton: I killed xorg.conf again, doesn't crash any more; I needed the file with 1.5
[08:22] <tjaalton> pitti: so the ctrl-c thingy should've not had any effect
[08:24] <wgrant> tjaalton: I found I needed to tell evdev to GrabDevice on statik's VM last week.
[08:24] <wgrant> Same on my machine.
[08:24] <wgrant> It works fine without now.
[08:24] <tjaalton> huh, weird
[08:25] <wgrant> Yes.
[08:25] <tjaalton> but, if it works now.. \o/
[08:25] <wgrant> Yep.
[08:25] <wgrant> Once that segfault gets fixed.
[08:26] <tjaalton> yep.. and not everyone can/should touch the kernel
[08:26] <wgrant> Of course.
[08:26] <tjaalton> so it'll take some time
[08:26] <bryce> heya fabbione
[08:26] <fabbione> hey bryce
[08:27] <tjaalton> I guess no-one has tried nvidia/fglrx with the new xserver?
[08:28] <wgrant> I don't think anybody is that crazy.
[08:28] <wgrant> There's a new video ABI, isn't there?
[08:29] <tjaalton> wgrant: yes, the packages should be rebuilt if they work
[08:31] <bryce> I assume both are busted now
[08:31] <wgrant> And probably will be until the day before release.
[08:31] <tjaalton> safer to assume that :)
[08:32] <tjaalton> but not necessarily, since there shouldn't be same kind of API changes like with 1.5, AIUI
[08:32] <bryce> wgrant: well, I'm scheming to get them working sooner than that ;-)
[08:32] <tjaalton> I'll install a box with 8600GT to test nvidia..
[08:47] <lool> tjaalton: concerning drm, I wrote to upstream a while ago and he said that the drm headers were now moving to the kernel; so I understand that we should drop them from libdrm and add Replaces
[08:48] <lool> I can forward you the emails if you like
[08:48] <tjaalton> lool: ok, that would be nice
[08:50] <bryce> heya lool
[08:57] <lool> hey
[09:09] <lool> tjaalton, bryce: forwarded
[09:12] <tjaalton> lool: thanks
[09:16] <tkamppeter> pitti, hi
[09:18] <\sh> pitti: taking care of bug #298611
[09:29] <\sh> pitti: why didn't you merge all the changes from intrepids into jaunties ia32-libs regarding debian/rules?
[09:30] <pitti> \sh: I did, TTBOMK; there might have been some obsolete stuff; what do you mean in particular?
[09:30] <\sh> pitti: the libnspr4.so.0d symlinks as an example :)
[09:31] <pitti> \sh: that didn't apply any more (I don't remember the reason any more, though)
[09:31] <\sh> pitti: ah ok...I'll have a look...I hope that they are set now by default :)
[09:31] <pitti> I didn't just ignore it, I remember investigating this
[09:34] <directhex> is it okay to request a sync now if it build-depends on something i need to 0ubuntu1 this evening?
[09:35] <NCommander> directhex, what needs syncing?
[09:35] <\sh> does anyone has problems connecting to a.u.c (91.189.88.40)?
[09:35] <NCommander> a.u.c?
[09:35] <NCommander> expansion needed :-)
[09:35] <pitti> archive.ubuntu.com
[09:36] <NCommander> Yes.
[09:36] <pitti> \sh: WFM
[09:36] <directhex> NCommander, gnome-subtitles from experimental. it has a new dep which is in debian NEW right now, so i need to 0ubuntu1 it
[09:36] <NCommander> directhex, no Ubuntu changes?
[09:36] <pitti> \sh: well, I might have caught a different mirror, of course
[09:36] <NCommander> Is that in main or universe?
[09:36] <directhex> NCommander, ubuntu changes? this is pkg-mono you're talking about! and it's universe
[09:37] <NCommander> fair enough
[09:37] <NCommander> Ok
[09:37] <NCommander> What you can do is a fast sync
[09:37] <NCommander> Version an upload with 0build0 (or something equivelent)
[09:37] <NCommander> Essentially what your doing is making it so when gnome-subtitiles clears NEW, it will autosync
[09:37] <directhex> aha, clever
[09:38] <directhex> thanks for that
[09:38] <NCommander> (you could probably use 0sync0, but the version string must be less than 1, and not contain the ubuntu substring for this handy trick to work)
[09:39] <maxb> Rather handy that "ubuntu" comes late in the alphabet, all things considered :-)
[09:40] <NCommander> Actually, the ubuntu substring is what kate uses to determine if it should autosync something
[09:40] <NCommander> (as far as kate is concerned, 0ubuntu1, 0~ubuntu1, etc. are all equivelent)
[09:41] <maxb> What I mean is, it's because b < u that it doesn't have to be -0~build0, right?
[09:43] <NCommander> Yeah
[09:43] <NCommander> I know we do some funny things w.r.t. to versioning in dpkg
[09:44] <directhex> the alphabet is one of my main complaints about the popular "~ppa" suffix ;)
[09:44]  * NCommander hates that hack
[09:44] <NCommander> PPAs should autoversion like REVU
[09:45] <directhex> NCommander, perhaps. they certainly shouldn't encourage use of ~ppa which supersedes foo-backports' ~foo
[09:45] <NCommander> ACK
[09:45] <directhex> well, that problem goes away once persistent prawn gets released
[09:45] <NCommander> TBH, crackport and SRU versioning is fairly miserable
[09:45] <NCommander> crackports are slightly better
[09:46] <NCommander> I wish SRU would just standardize on one style of versioning and that would be that :-)
[09:46] <directhex> the most awesome package version in the world though has to be 10.0.1.218+10.0.0.525ubuntu1~hardy1+really9.0.124.0ubuntu2
[09:46]  * NCommander hears Scott groan
[09:46] <NCommander> There is a really sad story about that one
[09:47] <Mithrandir> directhex: it's clearly missing +added+salt+and+pepper+stab+stab+stab in the version number.
[09:47] <NCommander> directhex, well, that happened because we had a crackport that broke firefox and flash
[09:47] <NCommander> :-)
[09:47] <\sh> sounds like flash ,-)
[09:47] <NCommander> We had to do an emergency downgrade
[09:48] <directhex> NCommander, or qt3? 3:3.3.8really3.3.7-0ubuntu11.1
[09:48] <NCommander> TBH, I don't know the story about that one.
[09:48] <gnomefreak> it was flash. I backoprted it before it was final and it broke the 64 bit users so it was reversioned
[09:49] <NCommander> Flash doesn't even work on 64-bit archs O_o;
[09:49] <directhex> NCommander, iirc 3.3.8 had a completely broken databse lib
[09:49] <gnomefreak> NCommander: it sure does
[09:49] <directhex> there's a 64-bit flash lib now
[09:49] <NCommander> flash-nonfree works on 64-bits out of the box?
[09:49] <NCommander> We don't support it in Ubuntu
[09:49] <NCommander> 64-bit flash is not freely redistirbutable
[09:49] <directhex> but nspluginwrapper is a sorry beast. it takes me ~7 browser restarts to read my daily webcomics
[09:50]  * NCommander hugs his 64-bit flash plugin
[09:50] <gnomefreak> NCommander: we dont support it due to it being non-free
[09:50] <NCommander> No more sudden firefox crashs
[09:50] <NCommander> gnomefreak, when I say support
[09:50] <NCommander> I mean any support
[09:50] <NCommander> YOu can't install 64-bit flash via apt-get
[09:50] <gnomefreak> NCommander: why cant you?
[09:50] <\sh> oh darn...
[09:50] <NCommander> you can't redistribute the 64-bit flash binaries
[09:50] <directhex> NCommander, meanwhile, i have a nice friendly 64-bit moonlight plugin sat right here...
[09:50] <NCommander> It says so in the license
[09:51] <NCommander> directhex, right, but there are no useful silverlight pages out there
[09:51] <\sh> if this ia32-libs insaneness doesn't stop...we deliver a complete libubuntu 32bit version in it
[09:51] <directhex> NCommander, that's because everyone(tm) uses flash!
[09:51] <directhex> \sh, multiarch dpkg!
[09:51] <NCommander> directhex, try dpkg-cross/apt-cross
[09:52] <\sh> pitti: what do you think about bug #277454
[09:52] <pitti> \sh: at the given rate/size I seriously consider replacing it with a 1 KB shell script to set up a 32 bit chroot
[09:52]  * NCommander has coded against SDL
[09:52] <directhex> NCommander, showing my age here. i remember discussing multiarch amd64 with Mithrandir yeeeeeeeears ago
[09:52] <NCommander> Why can't we simply use apt-cross in this case
[09:52] <pitti> this is and remains a pain in the butt, and it is a gross and unsupported hack
[09:52] <NCommander> the ia32 linker actually works last time I checked
[09:53] <NCommander> ^with apt-cross's paths
[09:53]  * NCommander would love if we could kill ia32-libs
[09:53] <tjaalton> lool: so, linux-libc-dev needs Replaces: libdrm-dev (<= current), and the new libdrm-dev should just drop the headers and possibly depend on linux-libc-dev?
[09:56] <TheMuso> oss/c
[09:58] <Keybuk> that was weird
[09:58] <Keybuk> updated to intrepid-updates, and every single process segfaulted after the reboot
[10:00] <lool> tjaalton: No, you need to push a new libdrm first
[10:00] <pitti> Keybuk: !
[10:00] <lool> tjaalton: then replace libdrm << new-version
[10:01] <lool> tjaalton: You might also want to add some versionned dep one way or the other e.g. let the new libdrm dep on the new linux-libc-dev
[10:01] <Keybuk> pitti: it's mysteriously fine now
[10:01] <Keybuk> things went wrong after the nvidia module was build and assumedly inserted
[10:01] <Keybuk> but after a reboot it was ok
[10:01] <Keybuk> I'm also suspicious that the machine gave one of its strange beeps on the reboot before, and may have needed a full power down
[10:04] <tjaalton> lool: of course, libdrm is first. and I can't add the Replaces to linux-libc-dev, so that'll just have to wait
[10:04] <lool> The two uploads need to be coordinated
[10:04] <lool> tjaalton: Do you have a new libdrm upstream version without the headers?
[10:04] <tjaalton> lool: in a minute
[10:05] <tjaalton> upstream? no
[10:05] <lool> tjaalton: Perhaps you want to poke upstream about it?
[10:05] <lool> the thread was in september
[10:05] <lool> and we're well within 2.6.28 now
[10:05] <tjaalton> lool: why? isn't it enough to just drop them from the package?
[10:05] <tjaalton> oh you mean it's newer in .28?
[10:06] <tjaalton> gah, those are never going to be in sync
[10:06] <lool> tjaalton: It's enough, but if you get a new upstream version it will be best that this API move is made upstream and your dependency will look like replaces: libdrm << x.y and will be compatible with debian's
[10:06] <tjaalton> libdrm releases are rare
[10:06] <lool> Yeah :-/
[10:07] <lool> tjaalton: still wouldn't hurt to ask for a heads up
[10:08] <tjaalton> lool: ask who? I'm lost now :)
[10:08] <lool> Dave Airlie
[10:15] <\sh> pitti: the symlinks are provided now automagically ,-)
[10:17] <tjaalton> lool: seems to be too late/early to get a prompt reply
[10:19] <lool> tjaalton: I guess you need to grab someone from the kernel team to ack this move and coordinate your uploads
[10:20] <\sh> bah uploaded that monster of source package
[10:22] <pitti> asac: Michael Biebl was on a NM packaging spree yesterday and today; might be an useful merge (not sure how closely you cooperate)
[10:25] <pitti> \sh: it was nice while it consisted of 10 packages, but right now it is an unmaintainable and very brittle monster; WDYT about dropping it completely and providing a shell script around debootstrap instead?
[10:25] <NCommander> Can someone explain to me why ia64 is building ia-32libs?
[10:25] <pitti> I honestly think that would be much more maintainable
[10:25] <Mithrandir> NCommander: because it needs it to run ia32 executables?
[10:25] <broonie> NCommander: It can use it.
[10:25] <NCommander> ia64 can run ia-32 binaries?
[10:25] <\sh> pitti: well, the problem will be wine32 for amd64
[10:25] <NCommander> I thought that only worked in Windows because MS enginneereed a software emulator
[10:25] <pitti> \sh: can't that run in a chroot?
[10:26] <\sh> pitti: that was what I was proposing since ages...but nobody agreed on this one with me :)
[10:27] <\sh> pitti: talk to Yokozar (Scott) about it..because the whole ia32-libs situation is a mess...and should be cleaned up asap
[10:27] <pitti> \sh: that's what I did last week
[10:27] <pitti> Scott said he might go for changing the packages to build lib32foo
[10:27] <pitti> but that's a huge effort as well
[10:28] <pitti> so until (if ever) we get proper multiarch support, people should install a 32 bit chroot
[10:28] <\sh> pitti: that will take ages..
[10:28] <directhex> NCommander, it's emulated, but YES
[10:28] <broonie> There's been some effort to move to lib32 in Debian.
[10:28] <StevenK> It's an enormous amount of work in either case
[10:28] <pitti> but even building lib32foo is just a hack, and far from a proper solution
[10:28] <pitti> besides utterly complicating packaging
[10:29] <\sh> pitti: and yes...the 32bit chroot with dchroot magic will help us all...but that was my proposal for people needing wine on amd64 in 2005/2006 already...
[10:29] <StevenK> ....
[10:29] <StevenK> wine works on amd64
[10:30] <StevenK> And if you don't think it doesn't, at least ajmitch and I use it to play WoW
[10:30] <pitti> StevenK: without ia32-libs?
[10:30] <\sh> StevenK: it does work because of the ia32-libs madness
[10:30] <directhex> jms@orac:~> uname -m
[10:30] <directhex> ia64
[10:30] <directhex> jms@orac:~> file a.out
[10:30] <directhex> a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), for GNU/Linux 2.6.4, not stripped
[10:30] <directhex> jms@orac:~> ./a.out
[10:30] <directhex> Hello World!
[10:30] <directhex> NCommander, ^^
[10:30] <\sh> StevenK: and no, wine on amd64 doesn't work...because they are starting right now to implement win64 apis ,-)
[10:31] <NCommander> directhex, you must love your itantic
[10:31] <NCommander> and wine works fine on amd64
[10:31] <directhex> NCommander, jms@orac:~> grep -c ^processor /proc/cpuinfo
[10:31] <directhex> 256
[10:31] <pitti> doko_: should packages still b-dep on java-gcj-compat-dev? or default-jdk-builddep only?
[10:31] <NCommander> o_o;
[10:31] <directhex> NCommander, who couldn't love that face?
[10:31] <StevenK> Ah, but with ia32-libs
[10:31] <StevenK> directhex: Guh?
[10:32] <NCommander> wine is 64-bit native app
[10:32] <NCommander> It just can only run 32-bit windows apps
[10:32] <NCommander> And given the state of 64 on Windows, I think Linux will have 64-bit windows apps before windows users :-)
[10:32] <StevenK> NCommander: It does require ia32-libs, though
[10:32] <directhex> StevenK, would you believe me if i said gnome is still a big sluggish on there?
[10:32] <NCommander> It does?
[10:32] <\sh> NCommander: yes
[10:32] <StevenK> NCommander: It's in the Depends line
[10:33] <NCommander> neat
[10:33] <\sh> NCommander: because native wine on amd64 would give you win64 compatiblity ;)
[10:33] <StevenK> directhex: Gnome is perfectly usable on my amd64 :-P
[10:33] <directhex> \sh, not that simple
[10:33] <\sh> directhex: if it would work right now...but it never worked ;)
[10:35] <NCommander> \sh, well, for one thing, GCC doesn't support the x64 calling conventions used by Microsoft
[10:35] <directhex> doesn't win64 assume long is 32-bit?
[10:35] <directhex> or somesuch
[10:36] <asac> pitti: not sure. he usually is behind. I can ask him anyway.
[10:36] <pitti> asac: not urgent, just FYI
[10:37]  * NCommander notes Win64 is WEIRD
[10:37] <pitti> I got some 50 commit logs from alioth svn, all updated to 0.7
[10:37] <NCommander> I had to pleasure of writing IE-64 plugins
[10:37] <NCommander> Ugh
[10:37] <pitti> NCommander: weirder than win32?
[10:37] <asac> pitti: yeah. usually we share stuff through upstream ... he didnt want to share packaging
[10:37] <NCommander> That was nasty
[10:37] <pitti> asac: okay
[10:37] <NCommander> pitti, it gets weird w.r.t. to COM and Unicode and stuff
[10:37]  * NCommander had a bunch of weird typedefs to get it building on i386, amd64, and itanatic
[10:37] <asac> pitti: i guess the commits are because of the git migration
[10:38] <directhex> NCommander, come now. if you think ia64 linux is a fringe platform, are there more than six people in microsoft's basement who use ia64 windows?
[10:38] <NCommander> We had five of them at my last company
[10:38] <NCommander> Hence why I had to port our inhouse IE plugin to the itantic
[10:38] <NCommander> Which involved more fun like compiling MySQL for that beast
[10:38] <NCommander> Without VS professional
[10:39] <NCommander> (I got the compilers from the SDK, then hacked a makefile to link everything properly)
[10:40] <NCommander> I don't actually think the ia64 is a horrible platform
[10:40] <NCommander> It's got a rock-solid toolchain
[10:40] <NCommander> I might even pick up a machine
[10:40] <NCommander> (I'm told the ia64's Canonical have were ebay specials, I might just do the same thing)
[10:43] <asac> pitti: against which subtree did those commits go?
[10:46] <pitti> asac: packages/experimental
[10:46] <pitti> asac: http://svn.debian.org/wsvn/pkg-utopia/?op=log&rev=2674&sc=1&isdir=1
[10:48] <asac> yeah
[10:57] <pitti> asac, lool, kees: if you have some time today, I'd appreciate some help for MIR processing (bug 305790 in particular); I already did a bunch, but completing this alone would take my entire day
[10:58] <asac> urgh
[11:02] <\sh> NCommander: http://repo.or.cz/w/wine/wine64.git <- it needs something new for the gcc toolchain...and it's far away from being mainline
[11:03] <NCommander> Yeah, I saw that
[11:03]  * NCommander reads Slashdot too
[11:03] <NCommander> ooooh
[11:03]  * \sh doesn't ;)
[11:03] <NCommander> I'm happy I'm not on MIR :-)
[11:04] <sebner> \sh: everything ok with your fork so far? :)
[11:04] <\sh> sebner: yepp...status green :)
[11:04] <sebner> \sh: great =)
[11:14] <pitti> Keybuk: just for coordination with my DK uploads, do you happen to know when you plan to upload udev 130?
[11:21] <Keybuk> pitti: this week sometime
[11:21] <pitti> Keybuk: ah, great
[11:22] <Keybuk> depends how long it takes me to do it
[11:22] <Keybuk> and how long it takes me to do the things I want to do first
[11:23] <mnabil_work> j #gentoo
[11:23] <mnabil_work> sorry
[11:30] <tseliot> Keybuk: is the new dbus (the one with the security fix) available anywhere (e.g. PPA) for testing already?
[11:31] <Keybuk> no
[11:31] <tseliot> Keybuk: ok
[11:32] <Keybuk> I can make a "correct" D-Bus config file available
[11:32] <Keybuk> but it will break your system
[11:41] <tkamppeter> pitti, hi
[11:41] <pitti> hi tkamppeter
[11:52] <fabbione> hi guys
[11:53] <fabbione> what was teh sysadmin channel here on irc? #canonical-admin?
[11:54] <cjwatson> #canonical-sysadmin
[11:54] <fabbione> hi cjwatson .. thanks!
[11:54] <NCommander> hey cjwatson
[11:54] <NCommander> cjwatson, how goes it?
[11:54] <cjwatson> getting by :)
[11:55] <NCommander> cjwatson, how's your new kid?
[11:56] <cjwatson> great
[11:56] <NCommander> boy or girl?
[11:56] <fabbione> cjwatson: are you getting any sleep? ;)
[11:56] <cjwatson> starting to sleep something that vaguely approaches normal hours, though it'll be a while yet ...
[11:56] <cjwatson> girl
[11:56] <fabbione> ehhe
[11:56] <\sh> cjwatson: congrats :)
[11:56] <cjwatson> thanks :)
[12:09] <doko_> pitti: default-jdk-builddep has a dependency on java-gcj-compat-dev
[12:10] <pitti> doko_: I know, my Q was whether packages should b-dep on default-jdk-builddep, or whether it's okay to pull in openjdk-6 or gcj-compat-dev directly
[12:10] <pitti> doko_: so far I rejected most of the OO.o MIRs due to that
[12:11] <doko_> pitti: default-jdk-builddep, no explicit b-d on openjdk-6 if possible
[12:11] <ogra> sigh ... so many PAS on the armel ftbfs page
[12:11] <directhex> twelvety!
[12:11] <directhex> armel/experimental buildd should help matters
[12:11] <NCommander> ogra, I take it LP isn't quite respecting PAS properly?
[12:13] <ogra> directhex, not for things like newlib, vbetool, acpica-unix, linux86, libx86 atc
[12:15]  * NCommander filed a bug about that
[12:15] <ogra> cool
[12:15] <NCommander> ogra, probably the mass giveback broke things
[12:15] <ogra> most of them were there before it
[12:15]  * NCommander shrugs
[12:15] <ogra> newlib is new
[12:16] <NCommander> newlib isn't in PAS
[12:16] <directhex> longcat is long?
[12:16] <NCommander> One would think.
[12:16] <ogra> heh
[12:21] <ogra> hmm, fontforge still seems to call libtoolize --force --copy
[12:21] <Keybuk> ogra: missing --install
[12:22] <ogra> Keybuk, well, it also calls aclocal and autoconf so i think autoreconf should just replace all of that
[12:22] <Keybuk> agree
[12:25] <NCommander> ogra, sounds like RPM ...
[12:25] <ogra> well, rpm only exploded *after* i ran autoreconf ... :)
[12:26] <NCommander> The sad part is we need rpm to be lsb-complaintant :-/
[12:26] <NCommander> argh
[12:26] <NCommander> Is it still borked?
[12:26] <asac> pitti: do we have a special java policy ... or just debian one?
[12:26] <fabbione> NCommander: you know rpm and .spec files are not that bad afterall.. the problem is stuff like yum that makes it a hell
[12:27] <directhex> rpm needs to learn KISS. it's powerful, but very easy to hang yourself with
[12:27] <NCommander> RPM got a lot better after they added the vender field
[12:27] <NCommander> I do perfer the RPM source format over the debian one
[12:27] <NCommander> in some ways
[12:27] <NCommander> I hate RPM management tools
[12:27] <NCommander> Nothing compares to pbuilder/sbuild/dput
[12:28] <Keybuk> NCommander: except perhaps having your testicles ritually grated over a hot fire
[12:28] <fabbione> NCommander: well mock is decent and easy to setup.. same level of pbuilder
[12:28]  * ogra only cares that the resulting rpm binary works ...
[12:28] <NCommander> Keybuk, o_o;
[12:28] <NCommander> ogra, +1
[12:28] <NCommander> I used to use Red Hat 5
[12:28] <NCommander> I blew my feet off a few times
[12:28] <NCommander> :-)
[12:28] <fabbione> NCommander: well I have to do rpm packaging on a daily base now :)
[12:29] <fabbione> some how I can talk from experience ;)
[12:29]  * NCommander sighs
[12:29] <NCommander> ogra, we'll probably have to give RPM a rootcanal to get it building, and rip out popt and zlib from it and force it to use system libraries
[12:30] <ogra> NCommander, i have the new version half way packaged ... but want to have a less jetlagged haed to finish it off ...
[12:31] <NCommander> There is a new version?
[12:31] <NCommander> Which new version?
[12:31] <ogra> somehow my brain still thinks it's 4am
[12:31] <NCommander> THe Red Hat RPM 5? Or the other RPM5?
[12:31] <ogra> 4.6.x
[12:31] <NCommander> when did that come out O_o?
[12:31] <ogra> we have 4.4.x
[12:31] <NCommander> Oh fun
[12:31] <directhex> alias rpm='alien --to-deb && dpkg'
[12:32] <directhex> done!
[12:32] <ogra> its in beta(something), but i was told by several RH people i should rather ackage that version than poking around in 4.4.x
[12:32] <NCommander> Might want to poke the RPM maintainer
[12:32] <ogra> FC10 ships with 4.6.x
[12:32] <NCommander> Or we could just go with that :-)
[12:32] <ogra> so i assume its relatively safe
[12:32] <NCommander> I don't know of anything that actually uses Debian RPM or apt-rpm
[12:32] <ogra> after all its only needed by lsb and alien
[12:33] <NCommander> yeah
[12:33] <NCommander> We should probably run that lsb compliance checker Theodore T'so talked about at UDS
[12:33] <NCommander> Make sure everything stacks up on ARM
[12:36] <tkamppeter> pitti, about the CUPS SRU, I have put it together except your Brother fix. How should we proceed?
[12:38] <asac> doko_: why are the glassfish jars/packages not starting with lib prefix?
[12:44] <ogra> Keybuk, heh, fontforge doesnt run --install because of:
[12:44] <ogra>     cp /usr/share/misc/config.guess /usr/share/misc/config.sub fontforge/mensis/
[12:44] <ogra>     set -e; cd fontforge/mensis; libtoolize --force --copy; aclocal; autoconf
[12:53] <cjwatson> mvo: conflictchecker seems to need a poke to update it to jaunty
[12:57] <doko_> asac: I didn't package these
[12:57] <asac> doko_: ah. ok
[12:58] <asac> doko_: is default-jdk/jre ubuntu specific?
[12:59] <mvo> cjwatson: conflictchecker is currently unhappy, I was working on it with lifeless on uds, we are close but not quite ready yet
[13:00] <StevenK> cjwatson: d-i is unhappy on armel, I've filed the relevant MIRs to help prod it along (LP #308465)
[13:01]  * ogra hugs StevenK for uboot-mkimage
[13:01]  * ogra strikes it from his MIR list :)
[13:01] <cjwatson> StevenK: thanks, I thought devio had been done a while back already
[13:01]  * StevenK checks
[13:02] <StevenK> It had, yeah
[13:02] <StevenK> <- is a dork
[13:02]  * NCommander handwaves
[13:03]  * ogra waits for several people die in wristpain with all the handwaving since UDS
[13:03] <StevenK> Hey, I'm proud of that MIR. It contains the word "hand-wave"
[13:03] <ogra> haha
[13:16] <doko_> pitti: *cough* ia32-libs back to main as a dependency for wine?
[13:24] <cjwatson> pitti: lool says you have a fix for X/jaunty/intel 965?
[13:24] <cjwatson> it just died on me ...
[13:25] <lool> 09:04 < pitti> tjaalton: bug 308225 updated; I have my normal X back \o/
[13:25] <cjwatson> pitti: (actually, never mind, I just found the discussion)
[13:27] <cjwatson> ah yes, the drm stuff I heard about
[13:27] <cjwatson> I'll abuse it into building locally
[13:34] <DktrKranz> doko_: mind looking or commenting at bug 254790?
[13:34] <lool> cjwatson: right we discussed the drm issues on #ubuntu-kernel
[13:34] <lool> and here a little
[13:35] <doko_> DktrKranz: already done, I think pitti did notice.
[13:51] <afflux> bug 303040 seems to only need a rebuild. Could anyone have a look at it?
[13:52] <seb128> afflux: looking
[13:52] <afflux> thanks
[13:52] <DktrKranz> doko_: ubuntu task is still open, "Fix released" is related to upstream task.
[14:05] <ogra> oh, sigh, fontforge packaging is a PITA
[14:05] <cjwatson> ok, so X at least starts now, but gdm hangs after typing my password
[14:09] <cjwatson> AUDIT: Tue Dec 16 14:07:11 2008: 6121: client 4 rejected from local host ( uid=0 gid=0 pid=6446 )
[14:09] <cjwatson> AUDIT: Tue Dec 16 14:07:30 2008: 6121: client 4 rejected from local host ( uid=1000 gid=1000 pid=6485 )
[14:09] <cjwatson> this can't be helping
[14:10] <wgrant> IIRC I get that and it still works fine.
[14:10] <wgrant> (after patching xserver so -intel doesn't make it segfault)
[14:43] <pitti> re; sorry, did a nap (getting up at 4:30 has some downsides...)
[14:44] <pitti> asac: using default-jdk/jre is debian standard now, too, but doko would know better
[14:44] <cjwatson> pitti: don't suppose you had problems with gdm hanging after upgrade, did you?
[14:44] <pitti> tkamppeter: why should we leave out the brother fix?
[14:44] <pitti> doko_: ia32-libs> nope, that's why I discussed multibuild of libraries with YokoZar
[14:45] <pitti> cjwatson: yes, I just pulled the two upstream commits and rebuilt xorg-server; before that I was using vesa
[14:45] <cjwatson> amusingly my laptop didn't work with vesa either (!)
[14:45]  * pitti hugs se128, how are you?
[14:46] <pitti> cjwatson: no, gdm, X, video etc. works fine again
[14:46] <pitti> 1.6beta3 even fixes that crash on Control-C
[14:46]  * Keybuk has definitely decided he has a compiz bug
[14:47] <Keybuk> the GTK+ FileChooser dialog appears too small
[14:47] <cjwatson> damn, I was hoping it wasn't just me
[14:47] <Keybuk> but the hilarious thing is that first it appears scaled down ;)
[14:48]  * seb128 hugs pitti, good thanks, you?
[14:48] <pitti> seb128: fighting with timezones, but otherwise okay; didn't get a cold this time
[14:49] <pitti> cjwatson: silly question, but you are fully up to date (mirror?), so no version skew between drivers and server?
[14:49] <seb128> pitti: ah, I'm dealing fine with jetlag, I managed to do 23h to 11h nights
[14:49] <pitti> cjwatson: I'm on intel GM945
[14:54] <cjwatson> pitti: pretty sure ...
[14:55] <rickspencer3> bueno: I hear you're the guy who can give me rights to the fridge
[14:59] <pitti> hey rickspencer3
[14:59] <calc> fun, i see all my new OOo build-deps need to be migrated to default-jre, lol
[14:59] <calc> i'll be busy today :)
[14:59]  * pitti hugs calc
[15:00] <calc> pitti: do you know of any simple cdbs java package already migrated so i make sure i do the right thing?
[15:00] <rickspencer3> pitti: hi
[15:00] <pitti> calc: unfortunately, seems that many of those aren't maintained very intensively in Debian either; but kaffe is a no-go for main
[15:01] <calc> pitti: yea
[15:01] <pitti> calc: everything in main should DTRT already; try ant, it uses cdbs
[15:01] <calc> pitti: ok thanks
[15:02] <pitti> calc: or jakarta-log4j
[15:02] <calc> pitti: thanks for the examples :) i'll see if i can get these done in a few hours
[15:12] <pochu> rickspencer3: s/bueno/beuno/g ? :-)
[15:25]  * directhex prepares rather high priority patch
[15:27] <ikonia> patch away !
[15:27] <directhex> currently all gtk# apps in jaunty are broken
[15:29] <beuno> rickspencer3, hi
[15:29] <beuno> you should use the tab key, it's awesome!
[15:35] <directhex> can someone who isn't staggeringly busy either give https://bugs.launchpad.net/ubuntu/+source/gtk-sharp2/+bug/308619 a high priority, or put it into the archive?
[15:42] <calc> rickspencer3: if you aren't already aware most irc clients do something called tab complete so you don't have to type out the users nick and if you type it correctly it highlights on that users screen so they see you addressed them without having to scan the log
[15:47] <pitti> calc: oh, so 3.0 uses both saxon and xalan now?
[15:53]  * directhex gently prods pitti over bug 308619, since it makes f-spot & tomboy unrunnable
[15:54] <ScottK-desktop> directhex: The mono examples in kde4bindings FTBFS with KDE 4.2 beta 2, so we've had to disable them.  I was wondering if you might be able to have a look and see what the problem is?
[15:54] <apw> superm1, hey ... does divert the headers have some special meaning?
[15:55] <directhex> ScottK-desktop, yeah, okay. when i get a sec
[15:56] <ScottK-desktop> directhex:
[15:56] <ScottK-desktop> directhex: Thanks.
[15:56] <superm1> apw, i'm referring to using dpkg-divert in the libdrm-dev package
[15:57] <superm1> it allows two packages to both ship the same files, but if one package gets installed, it renames the files of the other until the package is removed
[15:57] <apw> hmmm, /me gets the manual out
[15:57] <superm1> i'm not sure it's the right solution, but figured it's worth bringing up as an idea
[15:57] <apw> for sure, as its another magic twist in the debian packaging that i don't know about
[15:58] <superm1> apw, you can take a look on your current system what packages are already doing this with "dpkg-divert --list"
[15:58] <apw> diversion of /bin/sh to /bin/sh.distrib by dash ... heh
[16:02] <calc> pitti: i think it switched to saxonb from xalan
[16:02] <calc> pitti: looking a bit more to be certain
[16:02] <calc> pitti: yea in changelog says: remove xalan/xerces conditionals, add saxon ones
[16:03] <directhex> tiger.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit Mono/.Net assembly
[16:04] <directhex> okay, i have an example building, now to see about that fail log
[16:06] <directhex> ScottK-desktop, there IS a log of the fail, right? i don't have to spend another evening watching kde4bindings churn away at an hour per attempt?
[16:07] <pitti> calc: ah, good to know, thanks
[16:09] <cjwatson> apw: but make absolutely sure that you really want to do this - it's fiddly especially if you make a mistake
[16:09] <fabbione> superm1: hi
[16:09] <superm1> hi fabbione
[16:10] <fabbione> superm1: do we have a mythtv/ubuntu irc channel to talk?
[16:10] <superm1> yes
[16:10] <fabbione> superm1: that being?
[16:10] <superm1> #ubuntu-mythtv
[16:10] <fabbione> ok thanks
[16:11] <apw> cjwatson, diversion looks to be used very rarely.  is it better or worse to rev the kernel twice instead?  risk wise?
[16:11] <cjwatson> rev twice what for?
[16:12] <apw> we have a collission between the kernel-libc-dev and libdrm-dev as the latter is carrying some kernel headers.  from what i can see we should be using the kernel ones, but the libdrm-dev ones are modified and so right now we need to use those
[16:13] <apw> so we are looking for a nice way forward, sorting the problem in the short term, and allowing it to be resolved in the longer term correctly
[16:13] <pitti> apw: hm, I thought tjaalton wanted to modify libdrm to drop them?
[16:14] <apw> yes, but they are modified manually from the ones taken from the kernel and so dropping them in favour of the kernel ones is not going to work until we understand why they cannot be used without modification
[16:14] <cjwatson> is libdrm-dev ultimately going to be dropped entirely, or merely shrunk?
[16:14] <apw> there were other files in there iirc, at least other headers i believe
[16:15] <cjwatson> we are effectively dropping the files in the short term anyway ...
[16:15] <apw> and all this in the face of -alpha2 being imminent
[16:15] <cjwatson> so I'd have thought the right answer was to remove them physically from libdrm-dev for the moment, file a bug on libdrm targeted at jaunty, and upload linux-libc-dev with Replaces: libdrm-dev (<< first-version-without-those-files)
[16:16] <apw> but the ones in the kernel may not be compatible with the consumers of the files, if the comments next to the modifications to the copies in libdrm are to believed
[16:16] <apw> which puts the risk at high in my mind
[16:16] <apw> especially as the package affected would be the x server (according to the comments)
[16:17] <cjwatson> so the short-term answer is to use the files in libdrm-dev instead, then?
[16:17] <apw> i think that is the low risk strategy for the -alpha2 milestone
[16:18] <cjwatson> I agree; in that case, remove the files from linux-libc-dev and upload libdrm-dev with Replaces: linux-libc-dev (<< first-version-without-those-files)
[16:18] <apw> it sounded like there is a push with the consumers of these headers to fix the headers in the kernel or the consumer packages to cope, but i don't think its going to be instant
[16:18] <apw> the bug is also occuring in debian upstream too
[16:18] <pitti> cjwatson: why a libdrm-upload in this case?
[16:20] <cjwatson> because it's the right thing to do - otherwise people with the old linux-libc-dev installed might get errors on upgrade
[16:27]  * calc thinks default-jdk depends on all of main
[16:28] <calc> hmm actually that is probably an effect of recommends
[16:28] <pitti> calc: try the -headless versions
[16:28] <pitti> (someone made a comment in the MIR bug about that)
[16:29] <calc> ah ok
[16:30] <calc> hmm no default-jdk-headless but i did make the resulting binary packages depend on the headless bit like stated in doko's email
[16:30] <calc> default-jdk is the build-dep side of it
[16:32] <calc> hmm first package seemed relatively easy to convert :)
[16:34] <lool> superm1: Diverts?  I hate these; what's wrong with pushing a kernel?
[16:34] <lool> We're going to spend much more human time to write diverts install / removal properly than to disable install of drm headers and reenable it
[16:36] <superm1> lool, hence i wasn't sure it would be an appropriate solution here as was determined above
[16:37] <lool> I'm toooo slowwwww
[16:37] <lool> superm1: Sorry, didn't see the discussion above
[16:40] <pitti> asac: "shiretoko"? nice :) (just installed firefox-3.1)
[16:40] <pitti> asac: gave me some weird message about the xulrunner and langpack plugins not being compatible, and fonts are ugly, but otherwise seems to work well
[16:41] <pitti> asac: it completely ate my bookmarks in the toolbar, is that a known bug or shall I file it?
[16:43] <mok0> pitti, you have a couple of minutes?
[16:44] <pitti> mok0: (on phone, just ask, I'll respond later)
[16:46] <mok0> pitti: I am looking at lxml under jaunty. It FTBFS on all platforms. I now tried building it in my Lenny and Sid sbuilders. It also FTBFS'es in Sid, but not in Lenny. I think it has something to do with cython, which is version 0,10.2 in Sid (and jaunty) but 0.9.8 in Lenny
[16:47] <pitti> hm, I wonder why it didn't get autosynced
[16:47] <mok0> 308633bug 2
[16:47] <mok0> bug 308633
[16:48] <mok0> pitti: what didn't
[16:48] <pitti>     cython |   0.10.2-1 |        jaunty | source, amd64, i386
[16:48] <pitti> it was
[16:48] <pitti> oh, nevermind, you meant that the *new* version has the problem
[16:48] <mok0> pitti: yes
[16:49] <mok0> pitti: I am not aware of other packages that use cython
[16:50] <mok0> pitti: anyway, this is an error that seems to come via distutils
[17:01] <asac> pitti: hmm ... bookmarks issue is definitly unknown ... can you backup your .mozilla/firefox-3.1 directory, remove it and start again? (it will re-copy it, so we see if it reproducible)
[17:02] <asac> pitti: langpacks and plugins are mostly incompatible ... yes.
[17:02] <asac> pitti: talk to fta about fonts are ugly ... he investigated that quite in depth, but he didnt get all answers about why we ship some of the fontconfig files
[17:03] <pitti> asac: yes, we discussed the font bug at UDS
[17:03] <asac> ah
[17:03] <asac> so now you see it ;)
[17:07] <rickspencer3> let's try this again
[17:08] <rickspencer3> beuno: I hear you're the person who can give me access to the fridge
[17:08] <pitti> asac: bug 308666
[17:09] <pitti> asac: is there a particular file in the 3.0 profile which has the UI layout? I don't want to attach the entire dir, it has my keyring and cookies, etc.
[17:10] <asac> pitti: there are two files that could cause the problem: 1. localstore.rdf (removing that should after stopping should fix)
[17:10] <pitti> asac: yes, reproducible that way
[17:10] <asac> pitti: but most likely its places.sqlited
[17:11] <beuno> rickspencer3, I may be able to, yes. What's your Launchpad username?  is this to add events?
[17:11] <asac> pitti: huh?
[17:11] <asac> so removing localstore.rdf cures you?
[17:11] <pitti> asac: reproducible> you asked for removing .mozilla/firefox-3.1 and trying again
[17:11] <asac> pitti: ah ;) ... right. now try to remove localstore.rdf from within firefo*3.1/*/
[17:12] <asac> (sorry for the shorthand)
[17:14] <mok0> pitti: lxml FTBFS: it happens when building the -dbg version
[17:15] <mok0> pitti: If I comment that out, the package builds
[17:15] <pitti> asac: yes, that kills my toolbar customizations and restores the standard layout
[17:16] <pitti> asac: I try it the other way around now
[17:16] <asac> pitti: oh. so localstore.rdf it is?
[17:16] <asac> pitti: you can copy the firefox-3.0 one in again
[17:16] <asac> (guess thats what you mean by "the other way")
[17:18] <pitti> asac: bug updated with my localstore.rdf and recipe
[17:19] <asac> pitti: restarting ffox doesnt cure alone right?
[17:19] <kees> pitti: can you give me a crash-course in MIR-handling?
[17:20] <pitti> asac: right
[17:20] <pitti> kees: later, I'm afraid, need to ru
[17:20] <pitti> n
[17:20] <slangasek> directhex: gtk-sharp2 - I can have a look, but should the pkgconfig for cairo not be fixed, too?
[17:20] <kees> pitti: okay
[17:20] <pitti> my wife's bday dinner
[17:20] <asac> pitti: ok so localstore.rdf doesnt modify ... is adblock plus disabled?
[17:21] <directhex> slangasek, long term, yes - as soon as apps are done in debian
[17:21] <slangasek> ok
[17:21] <pitti> asac: I have adblock plus in my local profile, but not in the guest one
[17:21] <pitti> asac: as I said, standalone isloated reproduction recipe in bug (sorry, need to run now)
[17:22] <asac> pitti: well ... i see adblock plus in localstore
[17:23] <asac> but i will try
[17:23] <mok0> pitti: I think this is an error in the python package
[17:24] <slangasek> directhex: uploaded, thanks
[17:25] <slangasek> directhex: oh, the changelog was missing a bug reference though; guess I'll close that by hand
[17:48] <slangasek> directhex: bah, mono-addins has 'mcs' embedded in all of its Makefile.am, despite having an autoconf check for mcs
[18:37] <slangasek> directhex: even ndesk-dbus and ndesk-dbus-glib shouldn't have package renames for the transition?  The current binary names are libndesk-dbus1.0-cil and libndesk-dbus-glib1.0-cil ...
[19:21] <kirkland> slangasek: cjwatson: any chance you (or someone) can respin the server/alternate iso's with the -3 kernel?
[19:22] <slangasek> er, not so long as there's not a full set of packages available for -3
[19:34] <calc> garrr
[19:34] <calc> evolution is fubar'd
[19:35] <calc> it won't let me reassign the draft/sent folder for one of my accounts
[19:38] <ion_> More like snafu
[19:44] <mbiebl_> pitti: hi
[19:45] <mbiebl_> have you seen, that the pkg-utopia exp branch has packages for DK et al?
[19:45] <mbiebl_> They are not updated yet to the latest version, as Debian doesn't have a recent enough udev.
[19:46] <mbiebl_> But you can take them as a base, might save you some work
[20:06] <cjwatson> bryce: would you mind applying my patch in bug 308649 if it makes sense to you? it broke my preferred terminal emulator configuration ...
[20:07] <bryce> cjwatson: yep; in fact it's already committed to git
[20:08] <cjwatson> oh, great, thanks
[20:08] <cjwatson> ah yes, helps if I reload the bug ;-)
[20:08] <bryce> timo's working on the new xserver 1.6 stuff and will include it next time he does an upload
[20:23] <calc> how is bug 303528 'fix committed' when it is only fixed upstream and not in ubuntu or bzr repo for ubuntu, etc?
[20:24]  * calc added intrepid to the bug just now
[20:25] <slangasek> calc: sounds like an incorrect use of that state to me, yeah
[20:27] <kirkland> slangasek: which kernel, then, is targeted for the alpha2 iso's?
[20:28] <slangasek> well, it would be nice to have -3, but that requires a linux-meta upload to happen
[20:30] <LaserJock> calc: I think that's how the gnome packagers often use "Fix Committed"
[20:30] <LaserJock> i.e. if it's "Fix Released" in an upstream task it's "Fix Committed" in the Ubuntu task
[21:05] <bryce> slangasek: is alpha-2 still on schedule for being released late this week?  I want to give nVidia and AMD head's up when the ISO's will be available for their testing
[21:05] <slangasek> bryce: yes; just about to get the freeze mail sent out
[21:06]  * NCommander grumbles
[21:06] <NCommander> so much for KDE on arm for alpha 2
[21:06] <slangasek> well currently, kubuntu isn't installable on any archs, so feel free to fix that. :)
[21:07] <NCommander> Why isn't it installable?
[21:08] <slangasek> something with plasma?
[21:08] <NCommander> oh that one
[21:08] <NCommander> I thought that was fixed
[21:09] <tjaalton> slangasek: what about the drm headers mess?
[21:09] <slangasek> tjaalton: I appear to not be in the loop on this - what's going on?
[21:10] <tjaalton> slangasek: ok, so linux-libc-dev now includes the drm headers which libdrm-dev used to have
[21:10] <calc> LaserJock: ah ok
[21:11] <tjaalton> the problem is that the drivers don't build against the kernel headers just yet, so dropping them from libdrm-dev right now isn't going to work
[21:11] <tjaalton> "drivers" are in this case at least ati and intel
[21:12] <tjaalton> intel being the hard one to fix, while ati is trivial and fixed upstream
[21:12] <slangasek> tjaalton: but l-l-d Replaces: libdrm-dev and clobbers the headers needed by the drivers?
[21:12] <tjaalton> slangasek: better just drop the headers from l-l-d for now
[21:13] <slangasek> I'm asking whether that's the current situation
[21:13] <tjaalton> oh, it doesn't replace, it conflicts on install, meaning that xorg-server is waiting for that to be fixed
[21:13] <cjwatson> slangasek: discussion between 16:12 and 16:20 UTC on this channel today is relevant
[21:14] <tjaalton> and a thread on ubuntu-kernel@
[21:14] <jack_> how do you build a (realtime) kernel for Ubuntu, which can be used by as much as people as possible (like the official Ubuntu kernel). Do you use chroot for it?
[21:15] <slangasek> right
[21:15] <tjaalton> the post-alpha2 plan is to use the headers from l-l-d, but this is maybe a bit too early
[21:15] <directhex> jack_, kernels with -rt at the end?
[21:15] <slangasek> tjaalton: so cjwatson seems to have already suggested the same thing I was going to, which was to keep the headers in libdrm-dev for alpha-2, and upload that package with a Replaces: l-l-d?
[21:15] <jack_> directhex, for example
[21:15] <jack_> directhex, rt = realtime yes
[21:16] <tjaalton> slangasek: although, we might not care about the drivers for alpha2 and drop the headers from libdrm-dev, and fix the drivers after alpha2
[21:16] <directhex> jack_, install linux-rt
[21:16] <slangasek> tjaalton: is there a bug open about this, btw?  Because it should be targeted to the release and have the alpha-2 milestone set :)
[21:16] <jack_> directhex, that was not the question ;)
[21:16] <tjaalton> slangasek: ah, that's indeed quicker to build than the kernel :)
[21:16]  * calc is converting java... one package at a time, heh
[21:17] <directhex> silly java
[21:17] <tjaalton> slangasek: *cough* yes, it's bug 308387
[21:18] <slangasek> tjaalton: thanks, on my list now
[21:20] <tjaalton> slangasek: so you suggest adding Replaces to libdrm-dev?
[21:21] <slangasek> tjaalton: versioned replaces: only, yes, so that we have a way to get the l-l-d version of the headers back onto users' systems after alpha-2
[21:23] <slangasek> tjaalton: dumped some comments to the bug.
[21:23] <kirkland> slangasek: btw ... did you see the output of Friday night's conversation?  http://blog.dustinkirkland.com/2008/12/ubuntu-server-includes-window-manager.html
[21:26] <slangasek> kirkland: yes - though I'm pretty sure my contributions to the conversation were in fact negligible :-)
[21:27] <kirkland> slangasek: well, you didn't can the idea ... that's something :-)
[21:30] <tjaalton> slangasek: righto, http://users.tkk.fi/~tjaalton/dpkg/drm.diff
[21:31] <Combatwombat_nz> can somebody tell me where to find info on compiling an app specifically for Ubuntu, making use of crontab?
[22:08] <yao_ziyuan> i find Nodoka gtk2 style + X-Colors metacity style a good combination
[22:09] <yao_ziyuan> if ubuntu uses this combination by default, would it infringe red hat's rights?
[22:11] <Baby> just out of curiosity, what are the requirements for becoming a Ubuntu developer?
[22:14] <cjwatson> Baby: https://wiki.ubuntu.com/UbuntuDevelopers
[22:15] <Baby> thanks
[22:16] <CarlFK> cjwatson: you back from holiday?
[22:23] <cjwatson> CarlFK: aye
[22:25] <CarlFK> welcome back
[22:28] <slangasek> tjaalton: looks reasonable to me; will you upload?
[22:29] <tjaalton> slangasek: yep
[22:29] <tjaalton> thanks
[22:29] <slangasek> cool
[22:30] <slangasek> tjaalton: will that take care of the xserver-xorg-core/xserver-xorg-input-2.1 issue once it's fixed, or does that require some other upload?
[22:30] <tjaalton> slangasek: vmmouse needs some love :/
[22:31] <slangasek> what kind of love?  is there a bug open? :-)
[22:31] <tjaalton> of course not, that would be totally reasonable ;)
[22:31] <tjaalton> it fails to build, and just including xf86OSmouse.h (like -mouse does) isn't quite enough
[22:32] <slangasek> ok, I'll have a poke at it
[22:33] <tjaalton> copy the header from -mouse to vmmouse/src
[22:33] <slangasek> tjaalton: are changes to these packages expected to be committed to git somewhere? the vcs-* headers still refer to the XSF git repo
[22:34] <tjaalton> slangasek: yes, these should be synced once 1.6 is in experimental/unstable and the drivers fixed there too.. most of the fixes were oneliners
[22:35] <tjaalton> (removing #include xf86Version.h)
[22:37] <tjaalton> slangasek: what I meant was that the changes to these packages were from upstream, and will be included once the versions are bumped for xserver 1.6 (and pushed to unstable/experimental)
[22:37] <slangasek> tjaalton: ok, but does that mean there's a repo/branch that corresponds to the packages you upload to Ubuntu?  or do you just feed the patches back to Debian?
[22:46] <tjaalton> slangasek: there's no branch for the ad-hoc updates I did to get them build, no. I'll feed debian git once alpha2 is out
[22:47] <slangasek> ok
[22:47] <tjaalton> just asked upstream, there will be new driver releases to sort this out
[22:49] <Caesar> I'm surprised to discover that udev seems to start the network
[22:49] <tjaalton> slangasek: the vmmouse build failure should be a packaging problem, since it build fine using just configure & make
[22:50] <slangasek> udev starts the WORLD

[22:51] <Caesar> So what's the point of S40networking?
[22:51] <Caesar> Supposedly the network is going to be up by the end of S10udev
[22:51] <Caesar> Except when DHCP decides to take its time
[22:51] <slangasek> tjaalton: hrm, that's with the current version of the package in jaunty?
[22:52] <Caesar> (we're trying to debug a fun situation where syslog-ng sometimes fails to start because the network isn't up yet at runlevel 2 S10syslog-ng)
[22:52] <slangasek> Caesar: udev actually only starts the networking if allow-hotplug is set (IIRC), and even then it's asynchronous as you note
[22:52] <Caesar> slangasek: hmm
[22:53] <slangasek> S40networking is the "old" way, but it's still the only one that presents a synchronization barrier, AFAIK
[22:53] <tjaalton> slangasek: no, it fails, but the latest upstream release builds
[22:53] <slangasek> tjaalton: ok; I would rather leave pulling a new upstream version to you, then
[22:53] <slangasek> (or to some other X-er with time for it)
[22:54] <Caesar> slangasek: udev is calling ifup --allow auto $INTERFACE
[22:54] <Caesar> So that's going to include an auto eth0 that uses DHCP is it not?
[22:55] <slangasek> then udev is more clever than when I last looked
[22:55] <Caesar> This isn't seeming all that clever...
[22:56] <Caesar> This is going to cause DHCP to start before /var is mounted, by the looks of it
[22:56] <slangasek> heh
[22:56] <slangasek> file a bug on Keybuk then? :)
[22:56] <Caesar> I might shoot him an email to make sure my reasoning is correct
[22:57] <slangasek> oh, don't we do a bind-mount-shuffle for /var/run?
[22:57] <slangasek> so that it's always available early
[22:57] <Caesar> What about /var/lib?
[22:57] <slangasek> does dhcp need that?
[22:57] <Caesar> You know, where the lease file is...
[22:58] <Caesar> kinda important...
[22:58] <slangasek> yeah, that can't be mounted early
[22:58] <Caesar> I fear I'm discovering a shambles
[23:01] <slangasek> Caesar: so, how would a system with /var on NFS, + DHCP, work?
[23:02] <slangasek> (in theory)
[23:08] <imachine> tseliot, hey
[23:08] <imachine> tseliot, I've installed the updates from -proposed, everything works great now!
[23:09] <imachine> tseliot, all the driver building etc, 173 or 177, I just choose them from the proprietary driver manager in gtk2, and it "just works". testing for 96 now, since both 173 and 177 have the glitch with window titlebar artifacts over here :-)
[23:10] <tjaalton> slangasek: I'd say we should drop vmmouse from -input-all for now, since it _doesn't_ build without the extra header, and likely wouldn't work anyway since those functions are gone from the server (I had the header still in the tarball root, that's why it built)
[23:10] <slangasek> tjaalton: fine by me
[23:11] <slangasek> will you upload, or are you asking me to?
[23:11] <tjaalton> slangasek: no, just checking it's on. doing it now
[23:11] <tjaalton> s/on/ok/
[23:11] <slangasek> cool
[23:16] <slangasek> so in the end, was a solution found for gnome help stuff + langpacks for jaunty?
[23:18] <LaserJock> slangasek: what was the problem?
[23:20] <slangasek> LaserJock: we currently don't split translations of gnome help stuff off into langpacks, so it contributes to core package size on the CDs
[23:21] <slangasek> I think this was on the UDS agenda, but in desktop land which was far away from me :)
[23:21] <LaserJock> slangasek: by gnome help stuff do you mean system documentation?
[23:21] <slangasek> yes
[23:22] <stgraber> slangasek: are the current ISO images supposed to be installable ? report.html doesn't say anything
[23:23] <slangasek> stgraber: that's interesting; ubuntu-desktop is uninstallable, so I guess report.html is buggy
[23:23] <slangasek> (file-roller had a dep on packages in universe, I've just fixed this so in theory the next builds will be installable)
[23:24] <stgraber> yeah, that's what I thought. I remember seeing some p7zip errors during the few tests I did today
[23:25]  * slangasek nods
[23:25] <slangasek> X stuff is broken too, tjaalton is working on that part
[23:25] <ScottK> slangasek: I've got a couple of binary promotions that need doing to fix unistallables for the alpha.  Do you want bugs or can I just ask ....
[23:26] <slangasek> ScottK: just ask
[23:26] <LaserJock> hmm, using Rosetta to translate the gnome help files is probably not a great idea right now, but I guess extraction into lang packs should be workable
[23:26] <ScottK> slangasek: libkrosspython0 libsmokekde4-2 are needed for kde4bindings to sort out.  Source is already in Main.
[23:27] <slangasek> LaserJock: I'd recommend tracking down the UDS spec and reviewing it, rather than re-deriving from first principles. :)
[23:27] <LaserJock> slangasek: I did read it
[23:27] <hyperair> sru anyone? bug 202089
[23:28] <LaserJock> slangasek: and it looks to be in fairly early stages: https://wiki.ubuntu.com/DesktopTeam/Specs/JauntyGnomeHelpLangpacks
[23:29] <slangasek> ScottK: promoted
[23:29] <slangasek> LaserJock: ah, well, doh.  And it doesn't link to a blueprint page?
[23:29] <LaserJock> slangasek: no, but I got there from the blueprint
[23:30] <ScottK> slangasek: Thanks.
[23:30] <slangasek> LaserJock: right, perhaps you could check with ArneGoetje and/or pitti regarding its status
[23:30] <slangasek> as I said, I'm pretty sure this was a session at UDS, so the "drafting" status probably means there's more detail to come
[23:30] <LaserJock> slangasek: right, sure
[23:31] <LaserJock> I guess it should make a dent in CD size, though it'll probably make the langpacks even heftier to get
[23:32] <LaserJock> i.e. having to download the entire langpack just to look at a single help file in a native language
[23:33] <LaserJock> that may be a fairly corner case though, I guess if you want a language you probably want it all
[23:33] <imachine> tseliot, https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/278472 <- I've commented adequately here.
[23:33] <slangasek> LaserJock: yes, I certainly think it's consistent with the other langpack handling we do
[23:34] <imachine> tseliot, I don't think there's any reason to file a new bug report, as a similar has already been filed (even tho it's not the same issue I had, the error message is the same).
[23:34] <imachine> tseliot, I'll file a new one about nv and resume/suspend (if there isn't one there yet, ofcourse:))
[23:36] <imachine> tseliot, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-driver-nv/+bug/128413
[23:37] <imachine> tseliot, here's another bug, about the suspend to ram broken on nv. it seems it's quite old :-) fist discovered under .22
[23:37] <ScottK> slangasek: Binary promotions for bomber kapman killbots should get kdegames sorted.
[23:38] <stgraber> slangasek: ok, so there are actually 3 unmet dependencies: file-roller (depends on p7zip), update-manager (depends on update-manager-core=1:0.95.1, instead of 0.95.2) and xserver-xorg-core (conflicts with xserver-xorg-input-2.1)
[23:38] <ScottK> IIRC p7zip needs promotion too.
[23:39] <stgraber> yeah, that's for the file-roller one, it depends on p7zip which is in universe
[23:45] <ScottK> The libkrosspython0 promotion you already did will sort out kdesdk too.
[23:52] <ScottK> slangasek: kdeedu-kvtml-data needs binary promotion to fix kdeedu.