[01:00] <Bsims> Ran into an error upgrading I am not sure what package caused it but I got a segfault and then this upon recomended fix"dpkg: ../../src/packages.c:221: process_queue: Assertion `dependtry <= 4' failed."
[01:04] <Devin_M> can someone here help me?
[01:04] <Bsims> Anyone have any clue
[01:04] <Bsims> whats up Devin_M
[01:04] <Devin_M> do you know of a good programming language easy to learn and good support in ubuntu?
[01:05] <Bsims> Devin_M: perl or python
[01:05] <Devin_M> do you know of any good tools for ubuntu? compilers and such
[01:05] <Bsims> Devin_M: apt-get install build essential
[01:06] <Bsims> and get used to installing package-devel
[01:06] <Bsims> er -dev
[01:07] <Devin_M> okay, so just install build-essential, but wht do you mean by "get used to installing package-devel"
[01:08] <Bsims> Well the headers used to build a package from source are packaged seperate from the deb
[01:08] <Bsims> for example gnomelibs don't contain the headers needed to complile a gnome program
[01:08] <Devin_M> still not following, sorry, new to linux
[01:10] <directhex> Devin_M, what do you use to program currently?
[01:11] <Devin_M> uh, I just want to learn, my only realy experience is with vb in windows
[01:11] <Devin_M> and a little c/c++
[01:11] <directhex> vb6 or vb.net?
[01:11] <Devin_M> 6
[01:11] <Devin_M> I think
[01:12] <Devin_M> I'm pretty sure
[01:12] <Devin_M> but just school stuff
[01:12] <Devin_M> nothing big
[01:13] <Bsims> Devin_M: try bash to start out with, then perl
[01:13] <Devin_M> bash?
[01:13] <directhex> this isn't really the place for the question
[01:14] <Devin_M> I thought that stood for born again shell?
[01:14] <directhex> and it's a "which is better, cat or dog" question too
[01:14] <Devin_M> yeah, I know, but I just wanted to start somewhere
[01:14] <directhex> ubuntu has environments for loads of programming languages. easily tens, if not a hundred. what you want to use depends on the task at hand, and personal preference
[01:14] <Devin_M> I thought here was convenient
[01:14] <directhex> i'd advocate c#. people might disagree
[01:15] <savvas> Devin_M: here's a forum post with various tutorials: http://www.ubuntucy.org/forum/viewtopic.php?f=22&t=708#p3569
[01:15] <savvas> see which one seems better/easier for you
[01:15] <Devin_M> okay, thanks a lot, I really appreciate it
[01:17] <savvas> and since you're new, don't forget the ubuntu guide book: http://www.ubuntupocketguide.com/
[01:17] <savvas> thankfully the author provides a free pdf :)
[01:18] <Devin_M> yeah, I was just about to look at it, but I don't think I have and pdf viewers installed other that ooo
[01:18] <savvas> in ubuntu?
[01:18] <savvas> you have pre-installed pdf viewers
[01:18] <directhex> evince.
[01:18] <Devin_M> oh, oka
[01:18] <Devin_M> okay*
[01:19] <Devin_M> good to know
[01:39] <Devin_M> is bash the same as the terms and commands used in the terminal?
[01:42] <kolby> is there a REVU channel?
[01:43] <kolby> #revu didn't work
[01:43] <mrooney> kolby: I think you want #ubuntu-motu
[01:44] <kolby> thanks
[01:46]  * lamont pounds his head on the desk
[01:46] <lamont> so... how do I convince d-i that the install of the base system succeeded, now that I've finished doing its job for it?
[01:47]  * lamont pokes slangasek 
[01:47] <slangasek> um
[01:47] <lamont> seems that 8.04.2 lacks linux-restricted-modules$mumble-hppa32, so the install FAILS
[01:47] <slangasek> hotwiring the postinst of whatever script was supposed to do it?
[01:48] <lamont> yeah. it's the "whatever script" that's the question
[01:48] <slangasek> base-setup, maybe?
[01:48] <lamont> outside the /target, yes?
[01:48] <slangasek> yes
[01:49] <lamont> bootstrap-base
[01:53] <lamont> run_waypoints base-installer/progress/installing-base
[01:53] <lamont> ^^ now how do I get it to forget that a step failed, I wonder
[02:03] <lamont> Installation complete
[02:03]  * lamont checks for LYING
[02:06] <lamont> [17179577.264000] VFS: Cannot open root device "md0" or unknown-block(2,0)
[02:06] <lamont> hrmpf
[02:07] <lamont> clearly I'll need to get my duct tape out in a bit
[06:52] <tag> I don't know what fix exactly it was that you pushed out in the last 48 hours, but it stopped this constant problem I've been having for the last year with my system running incredibly hot.  So, thanks!
[06:57] <Hobbsee> (you're welcome)
[07:01] <Mithrandir> hi Hobbsee
[07:01] <Hobbsee> hey there Mithrandir!
[09:06] <cjwatson> Laney: I believe that the conflicts were superseded by a different solution (maintainer script hacking)
[09:07] <cjwatson> Laney: but if you notice that the conflicts are present in the *current* Debian package but not in Ubuntu, by all means file a bug ...
[11:03] <ebroder> Hmm...so hardy-backports has Xen 3.3, but ubuntu-xen-server in hardy explicitly depends on Xen 3.2 components. Who gets the bug? Backports? The xvm-meta package?
[11:04] <Hobbsee> ebroder: backports
[11:04]  * Hobbsee mumbles about crackports, and how stuff's obviously not getting tested properly before going through?
[11:07] <Hobbsee> ebroder: basically, if it's not a problem with the latest release (usually the release it was backported from), it's a bug for backports.
[11:08] <ebroder> Ok. And...if I'm going to propose a fix, what should I use for a version number? Hardy has 0.0.1-2ubuntu8, and Intrepid has 0.0.1-2ubuntu9, so 0.0.1-2ubuntu8hardy1 or something?
[11:09] <ebroder> (Also, why on earth isn't this a Debian-native package?)
[11:24] <Hobbsee> ebroder: 0.0.1-2ubuntu9~hardy1 is the usual convention, as far as i know
[11:24] <Hobbsee> (no idea on why it isn't native, i don't deal in xen)
[11:24] <ebroder> Ok
[13:57] <mnabil_work> guys , is there an application or a framework for building ubuntu from source ?
[13:57] <ion_> For what purpose?
[13:57] <mnabil_work> as i wanna to trim down package dependencies
[13:58] <mnabil_work> ion_, development and customization purposes
[14:03] <mnabil_work> ion_, any idea ?
[14:13] <daan> hey, i need some help
[15:53] <jelmer> are bzr looms a valid patching system ?
[16:05] <emgent> someone saw google ?
[16:19] <G__81> i installed Ubuntu 8.10 for the first time and i am really impressed. Great Work Guys. I see a big difference between this and Fedora as i ve been a long time fedora user
[16:19] <G__81> Keep up the Great work
[16:28] <ziroday> Hi, does anyone know what might have happened to the welcome slideshow that was supposadly targeted for jaunty according to http://brainstorm.ubuntu.com/idea/136/ or who I might want to talk to?
[16:42] <superm1> ziroday, as far as i'm aware, it's still targeted for jaunty.  you'll want to check with evand sometime during the week (UK work hours)
[16:42] <ziroday> superm1: awesome, thanks!
[17:09] <DktrKranz> cjwatson, re bug 323413, it seems it hasn't been synced correctly, I still see old version in LP.
[17:24] <ScottK> jelmer: I wouldn't think so.
[17:25] <ScottK> jelmer: Although if you wrote sufficient documentation in README.Source, it might.
[17:26] <jelmer> ScottK: Ok, so no particular reason other than the fact that it's not listed atm?
[17:26] <ScottK> jelmer: It's not really a patch system.
[17:26] <sharperguy> anyone here know if/when we might see python3-tk in jaunty? (sorry if this is the wrong place to ask)
[17:27] <jelmer> ScottK: Looms? They're pretty similar to quilt, just more integrated with the VCS
[17:28] <ScottK> I don't really know about them as I'm a pretty basic bzr user.
[17:28] <ScottK> One can use a lot of different tools, but using relatively obscure ways to solve common problems is not, IMO, generally good.
[17:28] <ScottK> It makes it harder for whoever comes along next to touch the package.
[17:29] <jelmer> ScottK: Well, Ubuntu seems to be moving in this particular direction
[17:30] <ScottK> We have future plans, but I don't recall looms being mentioned in the specs.
[17:31] <jelmer> NoMoreSourcePackages mentions  it
[17:32] <ScottK> OK.   I missed that then.
[17:32] <ScottK> Today, stuff like that will narrow the range of people who will/can work on the package.
[17:33] <ScottK> The future is likely to be different.
[18:25] <cjwatson> DktrKranz: I forgot to flush that batch into the queue. In progress now.
[18:26]  * DktrKranz hugs cjwatson, sorry for bothering you during weekend
[18:26] <cjwatson> jelmer,ScottK: I would say that since it's perfectly valid to use no patch system at all, it's also valid to use looms, *provided* that you take responsibility for merging in changes made by people who don't know how to drive it.
[18:26] <cjwatson> (i.e. people might upload changes not represented in the loom)
[18:26] <ScottK> cjwatson: Sounds reasonable to me.
[18:27] <cjwatson> there are probably people today who have packages in a revision control system which isn't publicly usable, which is sort of equivalent (I certainly do for some of my Debian packages, although I'm trying to move them all to bzr)
[18:32] <ScottK> Certainly, but I think the Debian situation is a bit different because there uploads by someone other than a dedicated maintainer are an exception and when there is a team, the team has generally agreed on a common toolset.
[20:27] <lool> I'm about to push ubuntu-meta to update the dep on hwtest-gtk to checkbox-gtk; hope that's ok
[20:27] <lool> (WRT A4)
[20:27] <pochu> hi lool :)
[20:27] <lool> Hey
[20:27] <lool> pochu: how is it going?
[20:28] <pochu> lool: quite good. almost finished my exams
[20:28] <lool> Oh nice
[20:28] <pochu> and I'm starting to learn C :)
[20:28] <lool> Eh, is certainly useful around what you package :)
[20:28] <pochu> yeah :)
[20:29] <pochu> the bad news are that my AM seems to have gone MIA ;)
[20:29] <lool> Ah; hopefully not for too long or you'll get a new one
[20:29] <lool> Hmm how useful
[20:29] <lool>     raise RuntimeError('Unable to retrieve package list from debootstrap: %s' % debootstrap_stdout)
[20:29] <lool> RuntimeError: Unable to retrieve package list from debootstrap:
[20:31] <lool> But then I'm not up-to-date due to checkbox/hwcheck; vicious circle
[20:38] <ogra> lool, did you deliberately wait until slangasek stepped on the train to do that meta update ? :)
[20:39] <ogra> err
[20:39] <ogra> plane indeed
[20:42] <sharperguy> Right I'm trying to add the "Replaces:" line to the package python3.0 (which I think might be why idle-python3 isn't installable) but everytime I run "debuild -S" it undoes the changes...
[20:42] <lool> ogra: I think it breaks upgrades; didn't you get that issue when upgrading to checkbox?
[20:43] <lool> I'd rather unbreak them before A4
[20:43] <ogra> lool, i shamefully admit that my lappie still runs intrepid
[20:43] <lool> wow
[20:44] <sistpoty> sharperguy: maybe control is generated from e.g. control.in?
[20:45] <sharperguy> sistpoty, yeah that might make sense (I'm new to packaging)
[20:45] <ogra> lool, i'll do my upgrade from the local mirror in berlin
[20:45] <sistpoty> sharperguy: maybe #ubuntu-motu might be a better place to ask that questions ;)
[20:46] <sharperguy> ah ok ty
[20:46] <sistpoty> you're welcome, sharperguy:
[20:51] <bluefoxicy> so when this thing says "restart session"
[20:51] <bluefoxicy> as in, you go to share a folder, it installs samba, and says "You need to restart your session in order to enable sharing"
[20:51] <bluefoxicy> what does it mean, "Session"?
[20:52] <bluefoxicy> ... log-in session?
[20:52] <lool> Hmm even after upgrading, ./update files
[20:52] <lool> *fails
[20:52]  * lool runs germinate manually
[20:57] <lool> Hmm worked; weird
[20:57] <lool> No special changes in debootstrap and germinate
[21:09] <lool> Uhoh, my install is seriously hosed
[21:16] <pochu> lool: that's why ogra still runs Intrepid :)
[21:16] <ogra> lool, perfect for a day before the sprint :P
[21:17] <lool> I was fearing all my python modules were broken, but actually I just hit two bugs
[21:18] <lool> It seems I can't ./update because debootstrap returns an error code, but doesn't output anything
[21:20] <lool> Weird, it runs: ['debootstrap', '--arch', 'amd64', '--print-debs', 'jaunty', 'debootstrap-dir', 'http://archive.ubuntu.com/ubuntu/']
[21:20] <lool> And that works fine here
[21:22] <ogra> hmm
[21:23]  * lool tries agian withing python
[21:23] <lool> Printing stderr this time
[21:23] <lool> Oh I wonder whether it's just archive.u.c failing from time to time
[21:23] <lool> I get many errors recently
[21:26] <ogra> yep
[21:26] <lool> Yeah, it passed amd64 fine; so it must be transient issues with archive.u.c  :-/
[21:26] <ogra> i noticed that too
[21:26] <ogra> apparently loaded ... though i wonder what causes the load
[21:26] <elmo> ogra: the kernel security updates
[21:26] <ogra> probably 8.04.2
[21:26] <elmo> no
[21:26] <ogra> ah
[22:06] <slangasek> ogra, lool: heh
[22:06] <slangasek> what broke, exactly?  Anything I can help with?
[22:06] <slangasek> (The Portland Mafia have a 5-hour layover here in JFK)
[22:07] <ogra> something about the change from hwtest-gtk to checkbox-gtk
[22:07] <lool> slangasek: Mailed you
[22:08] <slangasek> ok - wasn't sure if that mail was from before or after something being broken :)
[22:08] <lool> slangasek: The actual problem I had on IRC earlier seemed to be due to archive.u.c slowness
[22:08] <slangasek> ah
[22:08] <lool> slangasek: hwcheck was fragile and hwcheck -> checkbox made this obvious; I'm hoping that making the move to checkbox easier will help
[22:08] <lool> Which is why I was trying to push an ubuntu-meta if it's still not too late
[22:09] <slangasek> yeah, not too late at all; merging ubuntu-meta is a normal part of the milestone process anyway :)
[22:10] <slangasek> lool: was the libwmf addition yours, or just something pulled in when you ./update-d?
[22:10] <sistpoty> tjaalton: libdrm, I just saw http://launchpadlibrarian.net/21861310/buildlog_ubuntu-jaunty-powerpc.mesa_7.3-1ubuntu1_FAILEDTOBUILD.txt.gz... will the new version fix that and I only need to click on rebuild for mesa?
[22:11] <slangasek> ah, Riddell's addition
[22:12] <slangasek> Riddell: why did you add libwmf0.2-7-gtk to the desktop seed, exactly?  Your bzr changelog includes no rationale
[22:13] <slangasek> Riddell: libraries should normally be pulled in by the packages that need them instead of being directly seeded, surely?
[22:13] <sistpoty> tjaalton: ah, obviously not... I'll add the depends back on any for linux-libc-dev... ok? (or bryce)?
[22:14] <lool> slangasek: No, Riddell split libwmf because of the gtk dep it has, but I mailed him that it should probably be seeded if we want to keep the same functionality
[22:15] <lool> slangasek: libwmf0.2-7-gtk is a gtk module to load wmf files
[22:15] <slangasek> right
[22:15] <slangasek> ok, all makes sense now :)
[22:15] <lool> libwmf0.2-7 is pulled anyway, so for a marginal size we get support in gtk for them in gtk seeds
[22:15] <lool> Such as thumbnails etc
[22:15] <lool> Or eog
[22:16] <sistpoty> crap, I'm still at -0ubuntu2... damn mirror lag *g*
[22:16] <sistpoty> (drm)
[22:17] <lool> slangasek: (pushed ubuntu-meta)
[22:17] <slangasek> cheers
[22:17] <lool> mailed cjwatson
[22:22] <sistpoty> ScottK (or bryce): second opinion about libdrm... I dropped the arch specific linux-libc-dev and have it require on all arches, so that mesa should build... however I can't say I know what I'm doing right now definitely, so I'd like to hear a second opinion
[22:22] <ScottK> sistpoty: It was versioned before it was dropped.
[22:22] <lool> sistpoty: We need the versionned dep where possible
[22:23] <sistpoty> ScottK, lool: good point, thanks!
[22:23] <lool> sistpoty: I'm not sure what you mean, did you see libdrm 2.4.4-0ubuntu3?
[22:23] <sistpoty> lool: yep
[22:23] <lool> Is there anything to fix after it?
[22:23] <slangasek> who here has a panasonic, sony, toshiba, asus, or IBM (not Lenovo) laptop running jaunty?
[22:23] <ScottK> lool: But then when I rebuilt mesa on the ports archs it couldn't find drm.h
[22:23] <slangasek> (with hotkeys)
[22:24] <lool> ScottK: Right, the problem is that it's in the kernel
[22:24] <lool> now
[22:24] <sistpoty> lool: but the dependency on linux-libc-dev was dropped for anything not amd64 armel i386
[22:24] <lool> So we would have to install drm.h from libdrm on the other arches
[22:24] <sistpoty> lool: which I guess is what makes mesa FTBFS on other arches
[22:24] <ScottK> So how does dropping the build-dep help us then.
[22:24] <lool> But the best fix is really to uploda linux-libc-dev on these arches instead
[22:24] <lool> The problem is that linux-libc-dev is lagging on all other arches
[22:25] <slangasek> lagging, or stuck in NEW?
[22:25] <slangasek> oh, you're talking -ports
[22:25] <sistpoty> lool: ah, so if it were built, it could make libdrm built on the other arches and then mesa would build fine?
[22:25] <sistpoty> slangasek: yep
[22:26] <lool> sistpoty: yes
[22:27] <lool> slangasek: Right ports kernel lagging
[22:27] <sistpoty> lool: do you see any problem with requiring linux-libc-dev now? (as libdrm-dev  3 is already built?)
[22:27] <sistpoty> -3 even
[22:27] <slangasek> no panasonic toshiba sony asus IBM? :)
[22:27] <lool> sistpoty: ?
[22:28] <ScottK> I see an lpia kernel in New but that's it.
[22:28] <slangasek> everyone here is Dell and Lenovo then? :)
[22:28] <lool> sistpoty: I think linux-libc-dev is still too old on the other arches
[22:28] <slangasek> c'mon, people, help me kill off acpi-support
[22:28] <sistpoty> lool: well, libdrm would sort this via its version...
[22:28] <sistpoty> lool: (>= 2.6.28-5.15)
[22:28] <lool> sistpoty: It's going to cause other problems downstream
[22:29] <sistpoty> lool: as in?
[22:29] <lool> sistpoty: Let's not spend any effort in a hackish solution; the solution is clear
[22:29] <sistpoty> lool: but what is the solution?
[22:29] <lool> sistpoty: Solution is to update the ports kernel
[22:29] <lool> which will update the headers and you can restore the drm bdep
[22:29] <sistpoty> lool: oh, and that didn't happen yet?
[22:29] <lool> err dep
[22:29] <lool> sistpoty: I don't see it
[22:30] <sistpoty> lool: ah, thanks for your insight!
[22:30] <ScottK> lool: Who's updating the ports kernels?
[22:30] <sistpoty> ScottK: so: you know what to do, but I don't touch a kernel, sorry :P
[22:30]  * ScottK doesn't get how the 'solution' of dropping the build-dep was any kind of solution at all.
[22:30] <lool> ScottK: I have no idea; I think I saw a mention recently
[22:31] <lool> It seems smb might do it
[22:31] <lool> see thread alpine.OSF.1.99.0901292328210.384018@replicant.hut.fi
[22:31] <lool> http://article.gmane.org/gmane.linux.ubuntu.devel.kernel.general/3536
[22:31] <ScottK> lool: On what list?
[22:31] <ScottK> Ah.
[22:31] <ScottK> Thanks.
[22:31] <sistpoty> lool: but out of interest, would it break anything if the arch dependency was dropped from libdrm? Imo it just wouldn't build due to the versioned build-dep... right?
[22:32] <lool> sistpoty: What do you propose exactly, sorry I'm not sure I understand
[22:32] <lool> sistpoty: We need the dependency, it was removed for some arches to make libdrm-dev installable
[22:32] <sistpoty> lool: currently there's:  linux-libc-dev (>= 2.6.28-5.15) [i386 amd64 (maybe others)]
[22:32] <sistpoty> lool: so I propose to get rid of the arch requirement
[22:33] <sistpoty> (in build-deps)
[22:33] <lool> Yes, it should be linux-libc-dev (>= 2.6.28-5.15) in an ideal world, but until linux-ports is uploaded it's best to keep it like that
[22:33] <lool> sistpoty: It was without the arch specification
[22:33] <lool> These were addedd
[22:33] <sistpoty> lool: yes... but still, I don't see where it would break anything... it just would be in dep-wait for other arches, right?
[22:34] <ScottK> It seems like adding the arch specification just traded not installable for not actually useful.
[22:34] <lool> Anyway current situation is broken, what you propose was the previous situation which was also broken without linux-libc-dev on the other arches
[22:34] <lool> ScottK: Exactly
[22:34] <lool> So let's not trade back and forth, just need a linux-ports upload
[22:34] <ScottK> So color me a little frustrated at this response to the discussion at the release team meeting.
[22:34] <lool> ?
[22:35] <ScottK> It may be coindence, but we discussed this problem at the release team meeting yesterday.
[22:35] <lool> I didn't pay attention to that part I'm afraid
[22:35] <ScottK> I assume that upload less than a day later is related.
[22:35]  * sistpoty won't do kernel ports, for sure :P
[22:35] <ScottK> I could be wrong.
[22:35]  * ScottK neither.
[22:36] <lool> ScottK: You mean the libdrm upload?
[22:36] <ScottK> Yeah
[22:36] <ScottK> That added the per-arch specification on the build-dep
[22:36] <lool> tjaalton wasn't in that meeeting
[22:37] <ScottK> Maybe coincidence then.
[22:37] <ScottK> Does the lpia kernel in New solve it for LPIA?
[22:37] <lool> Also, I'm not sure why "bdep" gets mentionned, as far as I know it's a dep
[22:37] <lool> ScottK: Quite certainly
[22:38] <lool> Hmm actually it depends whether the packaging was really merged
[22:38] <ScottK> Right,  Dep, not build-dep.
[22:38]  * lool checks
[22:38] <ScottK> slangasek: Any chance you could use some of your layover to get the lpia kernel out of New.  That'd give us at least one more arch to try and get working.
[22:39] <ScottK> Ah.
[22:39]  * ScottK waits.
[22:39] <lool> ScottK: What was uploaded is a linux-lpia-meta right?  It wont help the linux-libc-headers
[22:40] <ScottK> Yes.  That's what is it.
[22:40] <ScottK> slangasek: Never mind ...
[22:40] <ScottK> is it/it is
[22:41]  * lool grabs linux-libc-dev_2.6.28-1.2_lpia.deb
[22:41] <lool> It has drm
[22:41] <lool> So it should be fine to also let libdrm-dev dep on linux-libc-dev (>= foo) on lpia
[22:42] <lool> Probably tjaalton didn't know about the special lpia tree
[22:46] <sistpoty> lool: sorry to bother you again, but what would be wrong with uploading a librm, which drops the arch-specific b-d on linux-libc-dev? wouldn't it just wait in dep-wait for the arches that don't have a fitting kernel yet? (as the version on the b-d would still be there)?
[22:46] <lool> sistpoty: Build-depends?
[22:46] <sistpoty> lool: yep
[22:46] <lool> I see no such build-depend
[22:46] <lool> Build-Depends: debhelper (>= 5.0.0), libx11-dev, dpkg-dev (>= 1.13.19), quilt (>= 0.40), automake, libtool, pkg-config, libpthread-stubs0-dev
[22:46] <ScottK> I think going back to that would be better as the arch specific change didn't actually help.
[22:47] <sistpoty> lool: erm, sorry, depends
[22:47] <ScottK> My fault.
[22:47] <lool> ScottK: They help installability
[22:48] <sistpoty> lool: but that wouldn't help ports, would it?
[22:48] <ScottK> In that case we'll need to upload and change the archs as they are done.
[22:48] <lool> sistpoty: it might for builds which pull libdrm-dev and don't use it
[22:48] <ScottK> Anything the does that is buggy anyway.
[22:49] <sistpoty> lool: ah, good pointer... though I think that would be a bug in itself?
[22:49] <lool> I'm sorry but what are you trying to solve?  The only proposal which makes all packages build again is to upload linux-ports
[22:49] <lool> ScottK: It's not, libdrm-dev might be pulled but might not be required in all cases
[22:49] <ScottK> I guess.
[22:49] <lool> When I say pull, it might be directly or indirectly
[22:49] <sistpoty> lool: that's for sure... I'm trying more or less to find out why that change was done
[22:49] <ScottK> Right.   Forgot about indirect.
[22:49] <lool> having libdrm-dev might impact a lot of other packages
[22:50] <lool> Actually probably not
[22:50] <lool> It has no rdep
[22:50] <lool> So nevermind
[22:50] <sistpoty> lool: and I certainly appreciate your insight :)
[22:51] <lool> Ok, I'm just going to push libdrm-dev with the same change for lpia
[22:54] <ScottK> That'll be progess.
[22:54] <ScottK> I guess I do want slangasek to get lpia out of New then ...
[22:54] <lool> sistpoty, ScottK: documented in the new libdrm upload I just pushed
[22:54] <ScottK> Great.
[23:00] <sistpoty> lool: thanks a lot!
[23:00] <lool> Well that wont help you much I'm afraid :)
[23:00] <sistpoty> hehe
[23:02]  * lool &
[23:05] <sistpoty> lool: but I still fail to understand, why you didn't remove all of the architectures in depends? wouldn't that help r-build-depends to fail unless a new ports-kernel was uploaded? (so that these builds could simply be clicked on retry?)? am I missing s.th.?
[23:05]  * sistpoty is pretty confused right now, admitted
[23:16] <lool> sistpoty: We really need the version; the package is always installed anyway
[23:16] <sistpoty> lool: yes, but the version is either satisfied, or would cause the package to dep-wait?
[23:16] <lool> sistpoty: it's a dep of libc6-dev
[23:17] <lool> sistpoty: No idea what's best here except pushing a new linux-ports :)
[23:18] <lool> I don't think we should waste too much thinking in this situation
[23:18] <sistpoty> lool: ok, just wanted to figure out lp myself ;)
[23:18] <sistpoty> lool: so let's not waste any more time to it ;)
[23:32] <DBO> bryce, are you here?
[23:33] <DBO> I am playing 7 degrees of ubuntu developers and you ended up being my next stop =)  I am looking for someone knowledgeable in the x dnd protocol so that I might make a window that is transparent to it
[23:36] <sladen> DBO: IIRC, just don't listen for DnD messages
[23:36] <DBO> does that work...
[23:37] <DBO> i can try
[23:37] <sladen> to make DnD work, you have to actively do something
[23:37] <DBO> no i want DND to go to something behind it
[23:37] <DBO> my window is transparent
[23:37] <sladen> (again, IIRC, E&OE, I haven't written an DnD app for a while)
[23:38] <DBO> yeah i just confirmed, it still "eats" the drag and drop event
[23:38] <DBO> so the window below does not get the event
[23:38] <DBO> it just goes into oblivion
[23:43] <sladen> DBO: so, if you're not transparent, but you are preventing to be, you need to proxy and pass through all the events that you're [pretending] to be transparent to (DnDrops too)
[23:44] <sladen> DBO: what is the application that you're trying to write?
[23:45] <sladen> DBO: XdndProxy  may, or may not be helpful
[23:45] <slangasek> ScottK: we seem to only have linux-lpia-meta in NEW currently?
[23:47] <DBO> sladen, Docky
[23:47] <DBO> sladen, I am the primary author of Docky if you have any idea what that is
[23:54] <sladen> DBO: I'm clearly behind the times.  From Googling it appears to be a Mac OS X work-alike.  Is that correct?
[23:54] <DBO> sladen, i prefer not to think of it like that
[23:54] <DBO> but yeah, its like that
[23:55] <DBO> but its also part of GNOME Do and a full out frontend for it
[23:55] <DBO> but you can see where the problem comes in
[23:56] <sladen> DBO: so, (guessing again and pulling straws from the sky), all the crap stuck to the edges of the desktop is preventing the users getting at their real work underneath?
[23:56] <DBO> no, really its just dnd thats failing
[23:56] <DBO> input masking is working fine
[23:56] <DBO> if you drag something around on your desktop
[23:57] <DBO> and you try to drop it onto your desktop under an invisible part of the window
[23:57] <DBO> docky eats the event (bad)
[23:58] <sladen> DBO: http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html#id2447278