[00:03] <sistpoty> bdmurray: maybe you're needs-packaging script is a little bit too greedy, or directhex shouldn't have put needs-packaging in the bug (bug #537691) ;)
[00:04] <directhex> sistpoty, the docs say needs-packaging with assignment is the correct tag for ITP equivalents!
[00:04] <sistpoty> directhex: the docs don't say "don't spam ubuntu-release".... yet :P
[00:05] <sistpoty> (there was a "kernel-version-unknown" script at work that created much more spam though, seems fixed at least now)
[00:05] <directhex> well... the risks of combining an ITP, FFe, and removing four old source packages into a single bug...
[00:05] <sistpoty> heh
[00:06] <bdmurray> sistpoty: wow, that's weird its been running for quite awhile and I haven't seen that happen
[00:06] <sistpoty> bdmurray: that wasn't really to blame you, just a late night observation ;)
[00:07] <bdmurray> sistpoty: okay, I think it is because its status is tracked in Lucid
[00:08] <sistpoty> bdmurray: interesting, thanks!
[00:09]  * directhex sets bdmurray to wishlist
[00:09] <directhex> time for sleep
[00:11] <sistpoty> gn8 directhex
[00:56] <ScottK> In Soviet Russia, wishlist sets you.
[00:57] <sistpoty> hah
[00:58] <jayvee> lol
[00:59] <sistpoty> ScottK: btw.: what do you think about bug #535386... (I'm not even halfway through)
[01:01] <ScottK> sistpoty: I say go for it.
[01:01] <sistpoty> ScottK: also my impression, but I think I'll still go through the entire list to make sure that there's no fallout
[01:01] <ScottK> OK.
[01:03] <ddecator> i'm trying to learn packaging, and i watched the video tutorials on the wiki (very helpful btw), but i'm wondering if there is a good way just to practice packaging?
[01:19] <jayvee> out of curiosity, when I've uploaded a .diff.gz to a bug and I'm waiting for someone to look at it, should the bug be In Progress, Fix Committed, or what?
[01:19] <jayvee> the statuses don't seem to fit exactly
[01:19] <jpds> In progress I believe.
[01:28] <sistpoty> jayvee: a .diff.gz means that you want to get a new upstream version in?
[01:28] <jayvee> sistpoty: yeah
[01:29] <sistpoty> jayvee: then new please and subsribe ubuntu-release
[01:29] <sistpoty> subscribe even
[01:29] <jayvee> I have ~ubuntu-universe-sponsors subscribed already. What's the difference?
[01:29] <jayvee> LP #529350 if you're interested, btw
[01:30] <sistpoty> jayvee: we're in feature freeze right now, so unless the new upstream version is a bugfix only version, it needs a ffe
[01:30] <sistpoty> !FFe
[01:30] <jayvee> yeah, it's only a bugfix release from upstream
[01:30] <jayvee> so not a problem
[01:31] <sistpoty> jayvee: then sponsors will deal with it, no matter if it's new or confirmed or triaged
[01:32] <jayvee> sistpoty: so do I still need to subscribe ~ubuntu-release?
[01:32] <sistpoty> jayvee: not for a bugfix only update
[01:33] <sistpoty> but please note that in the bug
[01:33] <jayvee> okay
[01:43] <jayvee> sistpoty: the bug description already notes that it is bugfix–only
[01:43] <jayvee> “This is a bug-fix release which changes nothing except for fixing a few small regressions or bugs in v1.6.0.”
[01:43] <sistpoty> jayvee: good, good ;)
[02:20]  * sistpoty can't see ada now for at least 10 days *g*
[02:36]  * sistpoty goes to bed... gn8 everyone
[03:00] <nigelb> persia: got time to review brian's reply about patch review?
[03:31] <wzssyqa> if i want to use dh_pysupport,where should i install the .so module?
[04:35] <wzssyqa> can dh_pysupport install modules for python of several versions,such as for both python2.6 and python3.1?
[04:36] <persia> That is precisely the reason it exists.
[04:36] <wzssyqa> persia: how to do it?
[04:37] <persia> wzssyqa: For that, I'm not the right person to ask.
[04:37] <wzssyqa> persia: who is the right man?i have googled for days
[04:38] <persia> Did you encounter the python policy document?  I believe it explains things for module packagers.
[04:38] <wzssyqa> persia: it seems that just ask for copying files to /usr/local/lib/pythonX.Y
[04:38] <persia> I can't help if you get stuck, but I'd really recommend starting from http://www.debian.org/doc/packaging-manuals/python-policy/
[04:39] <persia> I'm sure that's wrong.
[04:39] <ScottK> Actually, I don't think pysupport works for Python3.1 yet.
[04:39] <ScottK> Definitely not /usr/local.
[04:39] <ScottK> POX_ is working on a new and better way to package things for Python 3.
[04:41] <ScottK> wzssyqa: IIRC, /usr/lib/python2.6/dist-packages although that may be where pysupport moves it.
[04:41]  * ScottK is really tired.
[07:00] <fabrice_sp> jayvee, ping
[07:00] <jayvee> fabrice_sp: pong
[07:01] <jayvee> ?
[07:02] <jayvee> fabrice_sp: pong
[07:02] <fabrice_sp> soory: my xwindows got killed
[07:02] <jayvee> ouch, that's always fun
[07:03] <fabrice_sp> especially when you have a lot of opened windows :-/
[07:03] <fabrice_sp> it's about bug 529350
[07:03] <jayvee> okay
[07:03] <fabrice_sp> would you mind changing it to source format 3.0, to add the change in upstream source as a patch?
[07:04] <fabrice_sp> also, the watch file has to be updated (I can give you the right one, if you want)
[07:04] <fabrice_sp> and there are 2 lintian warnings that should be fixed
[07:04] <fabrice_sp> will you take care of all that, or you prefer me to do it? :-)
[07:05] <jayvee> oops, didn't get your e-mail
[07:06] <jayvee> I use thunderbird, and it is terrible at notifying
[07:06] <fabrice_sp> hmm, to be honest, I din't updated the bug report yet :-)
[07:06] <fabrice_sp> I know
[07:06]  * fabrice_sp uses also thunderbird
[07:06] <jayvee> whatever the lintian warnings are, they were probably already there when I took the package
[07:06] <fabrice_sp> well, used: my motherboard stopped working, and I lost my main system
[07:07] <fabrice_sp> jayvee, sure: like the absence of patch system
[07:07] <fabrice_sp> but it would be cleaner. That's why I'm asking you here :-)
[07:07] <jayvee> to be honest, I'm really inexperienced
[07:07] <jayvee> I'm willing to have a go, though, but just not right now
[07:07] <jayvee> quite busy at the moment.
[07:07] <fabrice_sp> it's up to you
[07:08] <fabrice_sp> ok: I'll make the changes then
[07:08] <fabrice_sp> thanks for your debdiff, anyway!
[07:08] <jayvee> I could maybe do it later tonight
[07:08] <jayvee> but if you want it done quickly, you'd better do it :)
[07:08] <fabrice_sp> as soon as it's before release date, it's ok :-)
[07:09] <fabrice_sp> I'll put that comments in the bug report and assigned it back to you, ok?
[07:09] <jayvee> sure thing
[07:09] <fabrice_sp> cool.
[07:09] <fabrice_sp> thanks!
[07:09] <jayvee> thanks for the guidance with the sponsorship
[07:09] <jayvee> I'll know to unassign myself and mark as confirmed in future. :)
[07:11] <fabrice_sp> that's why I made that comment ;-)
[07:20] <wzssyqa> which is dh_pysupport standard-dir
[07:20] <fabrice_sp> man dh_pysupport ?
[07:21] <fabrice_sp> yeah, it's in the manpage :-)
[07:23] <wzssyqa> fabrice_sp: there is nothing about it
[07:25] <fabrice_sp> wzssyqa, /usr/lib/pythonX.Y/site-packages is not what you are looking for?
[07:25] <wzssyqa> fabrice_sp: what i am looking for is about pyshared
[07:26] <fabrice_sp> wzssyqa, sorry, then. I don't understand your question
[07:27] <wzssyqa> fabrice_sp: it seems that put python modules to /usr/lib/pyshared ,it can support several versions of python ,auto
[07:32] <wzssyqa> fabrice_sp: there is a xxx.public file ,is it auto geneart or manual write?
[07:34] <fabrice_sp> wzssyqa, it's supposed to be generated automatically: I never saw this files in any Debian package I touched
[07:34] <wzssyqa> fabrice_sp: o ,thx
[08:20] <randomaction> kamalm: ping re bug 260406
[09:22] <ricotz> RAOF, hello, is there allready progress on https://bugs.edge.launchpad.net/ubuntu/+source/gjs/+bug/537903 ?
[09:25] <RAOF> ricotz: You're itching to have an installable gnome-shell? :)
[09:25] <ricotz> RAOF, yeah it only effects i386 so it not bugging myself ;-)
[09:26] <RAOF> ricotz: There's some progress on it, but micahg would know more; he had another day's work on it.
[09:28] <ricotz> RAOF, i didnt look into the problem much deeper after i saw this bug report, so hoped it will get fixed :P
[09:28] <RAOF> It'll certainly get worked around if nothing else; disabling the JIT makes everything work.
[09:30] <ricotz> ok, will look into this
[09:31] <ricotz> RAOF, ty
[10:41] <ari-tczew> is FFe needed for new upstream release _necessary_ to get in lucid?
[10:42] <persia> ari-tczew: An FFe is required if new features are introduced.  This is unrelated to version numbers or upstream releases.
[10:43] <persia> Frequently new upstream releases contain new features, which is why many believe an FFe is required for a new upstream release.
[10:44] <persia> also, note that we're currently in BetaFreeze, so please refrain from uploading anything that affects images until the freeze has lifted.
[10:44] <persia> (except if fixing a bug apparent in the images)
[10:45] <ari-tczew> persia, my request is for broken package (and ftbfs), fix is merging new upstream release with debian testing
[10:45] <ari-tczew> maybe do you want take a look ?
[10:52] <persia> ari-tczew: Does this involve new features?  Is there a way to solve it without introducing the new features?  Do these features affect anything else?  (related packages, documentation, etc.)
[10:57] <ari-tczew> persia: this is package called xserver-xorg-input-joystick which currently ubuntu's version is related to xserver 1.6, but now lucid has got xserver 1.7 and xserver-xorg-input-joystick from debian testing is related to xserver 1.7
[10:59] <persia> That doesn't answer any of my questions :)
[11:01] <ari-tczew> okay, so I think that there's no other way to fix problem
[11:02] <ari-tczew> and current debian testing's package is adjusted for xserver 1.7
[11:04] <persia> ari-tczew: OK.  That still leaves: Does this involve new features?  Do these features affect anything else? (related packages, documentation, etc.)
[11:09] <ari-tczew> persia: I think that there is no big-major changes, bug 538376
[11:09] <persia> ari-tczew: That, again, is not what I asked.  Are there new features?  Do these features affect anything else?
[11:10] <ari-tczew> new features - I don't know.
[11:11] <persia> ari-tczew: Also, the merge is borderline useless in it's current state, as X no longer uses HAL.
[11:12] <persia> ari-tczew: Well, find out :)
[11:13] <persia> ari-tczew: There's a good chance that you do not need an FFe for this (depending on the results of your feature investigation).  That said, I think that you also have to investigate to see if the merge does anything useful : it may be that a sync is sufficient.
[11:16] <ari-tczew> persia: great! but now I need to ask a delta uploader about delta utility
[11:19] <persia> ari-tczew: Well, you've asked for feedback from two teams for this bug, potentially wasting the time of both of them, because you don't know if it needs an FFe, and you don't know if the merge is correct.
[11:19] <persia> Please finish this before going to the next thing.
[11:21] <ari-tczew> persia: so what's the conclusion: FFe is need or not?
[11:22] <persia> ari-tczew: The conclusion is waiting on your investigation to determine if there are new features.
[11:22] <persia> ari-tczew: So, please investigate.
[11:23] <persia> ari-tczew: Also, please investigate whether the .fdi file is used or not when the driver is loaded into X.  If it is not, then this becomes a sync.
[11:30] <ari-tczew> persia: ok, I'm unsubscribing teams
[11:30] <persia> You can't :)
[11:31] <ari-tczew> huh! a few days ago launchpad got option: if you have subscribed someone else, you can unsubscribe!
[11:31] <persia> Oh.  That's great!  Thanks.
[11:32] <persia> Please investigate, and resubscribe when the investigation is done.
[11:32] <persia> I'd personally like to see this update happen.
[11:33] <ari-tczew> persia: oh, this option propably is gone, could you unsubscribe sponsors?
[11:33] <persia> Sure.
[11:34] <persia> Because they are busy, you might want to ask the release team to unsubscribe in #ubuntu-release : this avoids then reviewing bugs that aren't ready for their review.
[11:35] <ari-tczew> persia: I;m busy also :)
[11:36] <persia> Well sure, but they try not to waste your time: you could extend the same courtesy to them :)
[11:38] <ari-tczew> arrrghhh, don't love procedures and bureaucracy ;f
[11:38] <iulian> persia, ari-tczew:  What is the bug number?
[11:39] <ari-tczew> iulian:  bug 538376
[11:39] <iulian> OK, I've unsubscribed ubuntu-release.  Please resubscribe when ready.
[11:40] <ari-tczew> thnx
[11:44] <ari-tczew> is there any different between MoM and Lucas merges?
[11:45] <persia> They are generated independently, but the lists of what isn't merged ought be the same.
[11:46] <ari-tczew> ok thanks
[12:08] <samgee> Hi. 'apt-cache show joe' shows "Section: universe/editors", but if I 'apt-get source joe' and dpkg-buildpackage it I get "Section: editors". What magic is involved to get it in universe?
[12:11] <geser> what you mean with "get it in universe"?
[12:11] <geser> joe is in universe
[12:12] <persia> samgee: There's an overrides file that changes things in the distributed packages.
[12:14] <samgee> persia, how does that work? any docs about that?
[12:14] <samgee> geser, I want the section to say "universe/editors"
[12:15] <persia> samgee: When something is published, the contents of the override, if present, override the package settings when generating Packages and Sources.  You might find docs in the Soyuz docs, or for other archive management tools in their docs.
[12:15] <persia> samgee: You really don't care.  If you download joe, you'll find it claims to be in Section: editors inside the package.
[12:16] <samgee> as a user I wouldn't care, but as a gNewSense developer I do need this
[12:16] <persia> The distinction is only important if one uses components to manage one's archive, which tends only to matter when one has some reason to differentiate thousands of packages.
[12:17] <persia> samgee: Which tool does gNewSense use to manage it's repository?
[12:17] <samgee> reprepro
[12:17] <samgee> well, reprepro and some bash scripting around that
[12:17] <persia> Then you need to investigate the reprepro docs to see if it supports Overrides.
[12:18]  * samgee checks
[12:18] <persia> This is done by the archive management software, not in the individual packages.
[12:19] <samgee> for our repo we mirror the ubuntu repo and change some package by doing: apt-get source + change some stuff + dpkg-buildpackage
[12:19] <persia> OK.
[12:19] <samgee> in that process we lose the component, so all binaries go in main
[12:19] <samgee> and that's not what should be happening for e.g. linux
[12:20] <persia> The key bit is that the value "universe/editors" is not stored within the package.  You don't have to do anything to the package to get it.
[12:20] <persia> You need to make the changes in the repository management software.
[12:20] <jpds> samgee: http://archive.ubuntu.com/ubuntu/indices/
[12:21] <samgee> jpds, that looks very useful, thanks
[12:22] <persia> jpds: Hey.  Can you review my ubumirror merge?
[12:30] <jpds> persia: Sure, give me a bit to wake up.
[12:31] <persia> jpds: Sure :)
[14:42] <kamalm> randomaction: good morning - pong re bug 260406
[14:51] <randomaction> kamalm: morning :) Why are additional build dependencies necessary?
[14:54] <kamalm> randomaction: because the package FTBFS in Lucid without them.  I don't know why Debian doesn't seem to need those additional build-deps:  (libdirectfb-dev, libesd0-dev, libpulse-dev, libaa1-dev, libcaca-dev), and I couldn't find any single package that I could depend on that would bring them all in.
[14:58] <randomaction> I tried removing them, and the package built (so the only reason for FTBFS were the moc files). This was several days ago, I'll check again now.
[14:58] <kamalm> randomaction: oh really!?
[14:59] <kamalm> randomaction: I will try building without them again also (it was considerably more than several days ago that I did this work!)
[15:02] <randomaction> and another thing: I believe that removal of stale moc files belongs to the clean target
[15:03] <BlackZ> please, help with bug #538265 thanks!
[15:03] <randomaction> it's called first on buildds and by pbuilder, and this way we keep the semantics of "clean undoes build"
[15:04] <vish> BlackZ: you reported the bug?
[15:04] <BlackZ> vish: yes
[15:04] <vish> BlackZ: then you need to ask someone in #ubuntu-devel , [ is that right persia? ]
[15:05] <kamalm> randomaction: I think I experimented with putting the moc-removal into the distclean target (and was unsatisfied with the result).  How about if I make another pass at it, and try moving it to the clean target -- and also re-try without the additional build-deps?
[15:05] <vish> BlackZ: oops  , i'm the wrong channel. :/  [/me thought it was ubuntu-bugs]
[15:05] <randomaction> kamalm: I mean, clean target in debian/rules
[15:06] <kamalm> randomaction: yes, I undestand
[15:06] <BlackZ> vish: no worries !
[15:06] <kamalm> *I understand too
[15:07] <randomaction> kamalm: sure, if it works out, I think it's time we uploaded it
[15:08] <kamalm> randomaction: yeah, before it dies of old age!  ;-)  Okay, I'll get on it.  Thanks!
[15:10] <kamalm> randomaction: please unsub u-u-s from bug 260406 while I work on it
[15:11] <randomaction> done
[15:18] <persia> vish: This channel is fine (as you saw) :)
[15:20] <vish> ;)
[15:29] <lfaraone> If I discover a package in universe has a local DoS / loss of data vulnerability, who do I call? (other than Ghostbusters, of course)
[15:32] <persia> lfaraone: File a security bug
[15:34] <lfaraone> persia: are security bugs automagically marked as private? Marking a bug as such no longer seems an option on the bug form, and this bug has not been publicly disclosed yet.
[15:35] <persia> lfaraone: Ask for more guidance on #ubuntu-hardened.  I'm not sure.
[15:36] <persia> lfaraone: Look for an answer from someone who is on the ubuntu-security or MOTU SWAT teams.
[15:39] <lfaraone> persia: looks like the docs confirm it, security bugs start as private. But I'll test in staging just to be sure :)
[15:42] <persia> lfaraone: Obviously, don't put the real details in for your test :)
[15:43] <lfaraone> persia: "lipsum - allows people to generate dummy text, disclosing secret latin magic" :P
[15:43] <persia> Oh yeah!
[15:46] <nigel_nb> persia: thanks for the reply.  I would have a tough time explaining :)
[15:46] <MattJ> If I'm fixing a package in universe, but the Maintainer field in debian/control is a Debian developer, what should I update it to?
[15:46] <nigel_nb> matti: just use 'update-maintainer' command
[15:46] <MattJ> Aha, thanks
[15:46] <nigel_nb> bah, tabfail
[15:46] <MattJ> Heh, don't worry, he's used to it :)
[15:47] <nigel_nb> hehe
[15:59] <MattJ> How's this: http://matthewwild.co.uk/uploads/meld_1.3.0-2ubuntu1.debdiff
[16:00] <matti> ;]
[16:01] <matti> Meld.
[16:01] <MattJ> I like Meld
[16:01] <matti> I like it too.
[16:02] <MattJ> I like it most when it works :)
[16:05] <kamalm> randomaction: you're right -- no additional build-deps aren't needed to build gnuradio in Lucid -- I'll investigate what made me believe otherwise (trying it in Karmic now).  I did move the moc-removal into the clean target, which works fine.   So, bug 260406 is now once again ready for review.
[16:06] <randomaction> kamalm: thank you, I'm already test-building
[16:07] <kamalm> randomaction: thank *you* for noticing the problems!
[16:08] <randomaction> What is the procedure for moving the package from multiverse to universe? Just file a bug and subscribe ubuntu-archive?
[16:10] <persia> randomaction: Well, first verify the license (not only debian/copyright, but the source again as well), but otherwise, yes.
[16:16] <randomaction> persia: Thanks. I have an additional clue that the package moved to main in Debian.
[16:16] <persia> That's usually a strong indication :)
[16:36] <MattJ> I attached my patch to https://bugs.launchpad.net/ubuntu/+source/meld/+bug/505285
[16:36] <MattJ> Is there anything else I need do? or is my job done?
[16:44] <randomaction> MattJ: I've subscribed the sponsorship team for you
[16:48] <ryanakca> Could someone take a look at bug 538283 please?
[16:50]  * DktrKranz remembers something about turnin-ng :)
[16:51] <MattJ> randomaction: thanks
[16:53] <ryanakca> DktrKranz: Hehe :D
[16:55] <DktrKranz> ryanakca:  Fakesyncs used to have build1, but I remember there was some discussion on that.
[16:55] <Laney> did they?
[16:56] <DktrKranz> IIRC, yes
[16:56] <Laney> but then the autosyncer would try it
[16:56] <DktrKranz> so, in case of new upstream releases, they can be autosynced directly
[16:57] <DktrKranz> that was one of the topic during discussion
[16:57] <persia> Fakesyncs *never* had build1
[16:58] <persia> That's always been wrong.
[16:58] <Laney> Nothing changed from that discussion anyway
[16:59] <DktrKranz> so I probably remember it wrong
[17:00] <persia> Well, a few people uploaded stuff with "fakesync1", but I think the conclusion was that this was a bug in the archive admin tools that ought be fixed.
[17:02] <DktrKranz> Indeed.
[17:02] <persia> Mind you, I don't know what version we're supposed to use until the bug is fixed.
[17:03] <persia> We probably ought make best efforts to not let that happen.
[17:03] <persia> DktrKranz: Do you know if UDD tracks artifact variance in a way that we can use to identify the outstanding issues?
[17:05] <DktrKranz> persia: do you mean md5sums for .orig.tar.* ?
[17:05] <persia> Well, I mean actual artifact identity, but checksum mismatches are a proxy for that :)
[17:06] <DktrKranz> I can have a look
[17:07] <DktrKranz> projectb (the monster behind Debian archive does), but its data is not available on public services
[17:08] <persia> I wonder if we oughtn't make some effort to resolve all of them over time.  I imagine we ought be able to avoid new ones (and I think we've been doing a reasonable job of that).
[17:09] <DktrKranz> persia: from what I see, UDD tracks md5sums, so I can easily prepare a query to match them
[17:10] <persia> Oh, cool.  Probably not worth promoting now, because of the freezes.
[17:10] <DktrKranz> definitely
[17:10] <persia> But I suspect we'll want to push to try to get back in sync as soon as squeeze releases, or so.
[17:11] <persia> (as I expect squeeze to be well-frozen by the time lucid releases)
[17:11] <DktrKranz> probably, RC count dropped recently, and RT could eventually see for a freeze soon
[17:11] <DktrKranz> but no assurance of that
[17:13] <persia> No, but the hints were all that it was expected for this month, so I'm guessing it'll happen in the next few weeks.
[17:13] <persia> (maybe April, but probably still before end-april)
[17:14] <ScottK> It had been scheduled for March, but ~ a month ago it was announced that it wouldn't happen yet.
[17:14] <persia> I saw that.  I just have a feeling that it's close anyway.  Maybe I'm wrong.
[17:22] <DktrKranz> persia: it's not that immediate as I thought, but I can easily integrate query with some Python to have a more precise picture, let's schedule it for {lucid,squeeze}+1
[17:22] <persia> squeeze+1 is the right schedule, in my mind, because syncs are one-way, really.
[17:23] <persia> Where we are in Ubuntu doesn't matter, as long as we can overwrite in the next sweep of syncs.
[17:23] <slytherin> Do I need to add upstream fixes descriptions in debian/changelog when uploading a new bugfix only release?
[17:25] <persia> slytherin: If the upstream bugfixes are considered end-user-interesting, and the upstream changelog isn't in the package, yes.  If the upstream changes are the justification for an upload while the archive is on manual-accept, yes.  In all other cases, no.
[17:25] <persia> The archive is currently on manual-accept, by the way :)
[17:25] <slytherin> yes I know. That is why I asked. I will add the fixes.
[17:26] <persia> slytherin: Just add enough that are interesting to end-users and archive-admins, rather than all of them :)
[17:26] <slytherin> I will only add that are relevant to the contents of the package.
[17:28] <persia> Does anyone know a good workaround for Debian bug #284274?  Is there a canned script somewhere?
[17:44]  * persia wishes all computers were self-contained things that didn't need power cables or network cables or anything else.
[17:45] <jpds> A world of complete wirelessness.
[17:46] <hyperair> that would be cooll
[17:50] <sebner> persia: intel(?) or some company is developing wireless power. Works already up to ~1 meter :P
[17:51] <jdong> or you can build big coils and plug one into your mains and the other into your computer.....
[17:52] <jdong> and as long as you have a decent active PFC power supply you might get somewhere.
[17:52] <persia> Or I could just clean out under my desk properly one day :)
[17:52] <jdong> (not responsible for any fires, huge electric bills, ....)
[17:53] <DktrKranz> sebner: be sure to power off power while you check back side of your PC, or you get *shoooooocked* :)
[17:54] <persia> DktrKranz: Actually, that's the nice thing about inductive broadcast : it only slowly cooks the user, rather than shocking them.
[17:54] <sebner> DktrKranz: hahaha
[17:54] <sebner> DktrKranz: he said *cooks* hahahaa
[17:55] <DktrKranz> persia: I'm all for slow food
[17:55] <persia> heh
[17:55] <DktrKranz> american folks love McDonald's, we still keep tradition
[17:57] <persia> That's the trick where you let the meat sit on a table in the warm breeze for 3 years, rather than putting it under the heat lamp?
[17:57] <DktrKranz> mostly, but 3 years is only for cheese, some other products stay there for much more
[17:58] <persia> Sorry.  It's my impatience showing :)
[18:02] <sebner> persia: Our bacon only takes some weeks ;D
[18:04]  * DktrKranz has a 26-year-old wine handy
[18:42] <kamalm> randomaction: https://launchpad.net/ubuntu/+source/gnuradio suddenly says I'm "Not allowed here".   Is this due to it moving from multiverse to universe?  (Or has Launchpad finally decided that its had enough of me?  ;-)
[18:43] <randomaction> kamalm: I think it's a bug, I'm not allowed too
[18:43] <kamalm> I'll whine about it in #launchpad
[18:44] <randomaction> and it got uploaded to multiverse
[18:44] <randomaction> I opened a bug to move it to universe