[00:10] <minghua> Fujitsu: The leader of the EeeXubuntu thing seems to a a mysterious person: http://forum.eeeuser.com/profile.php?id=2298
[00:11]  * Fujitsu grumbles at lucas.
[00:12] <minghua> Fujitsu: Why?  I think Lucas has a point.
[00:12] <Fujitsu> He does, but he made it sound like this was an officially sanctioned derivative.
[00:12] <Fujitsu> Akin to Kubuntu, Xubuntu, etc.
[00:13]  * minghua has seen {,K,X}Ubuntu spin-offs in Chinese Ubuntu-related forums as well.  "A new derivative" seems a very common attitude among Ubuntu user communities.
[00:14] <minghua> Fujitsu: Agreed on your point.  Lucas should have made that more clear.
[00:15] <pochu> Don't forget the soon-to-be-announced {Eee}{k,x,ed,}ubuntu-Xmas-Edition ;-)
[00:16] <Fujitsu> pochu: And then eeeXubuntu Xmas Edition CE.
[00:17] <minghua> Do we get a New-Year version as well?
[00:17] <pochu> minghua: why not? The more, the better ;-)
[00:17]  * pochu hides
[00:39]  * minghua starts gutsy->hardy upgrade.
[00:39]  * Fujitsu applauds minghua 
[00:39]  * Fujitsu upgrades.
[00:39]  * StevenK doesn't.
[00:39] <minghua> Fujitsu: Already running gutsy?
[00:40] <Fujitsu> I haven't upgraded for a couple of days.
[00:40] <minghua> "You have to download a total of 474M."  Hmm.
[00:41] <Fujitsu> Hm, is this another Flash security update that I see, or is it the same one?
[00:42] <minghua> Fujitsu: Ahh, I meant "already running hardy", but since you are talking about security updates, I assume you are running gutsy.
[00:44] <Fujitsu> No, Hardy.
[00:45] <Fujitsu> I see an Flash security announcement from Adobe on the 18th.
[00:55] <imbrandon> Fujitsu: same one iirc
[00:59] <pochu> imbrandon: nice specs!
[00:59]  * pochu envies your ram ;-)
[01:00] <nixternal> UserInterfaceFreeze  <- whoever thought of that, kudos to you!
[01:01] <nixternal> when is universe freeze?
[01:03] <Fujitsu> A couple of days before FinalRelease, probably.
[01:05] <nixternal> heh
[01:09] <imbrandon> killer, did yall see this ? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457371
[01:09] <ubotu> Debian bug 457371 in dpkg "dpkg: please add the DEB_VARIANT build environment variable" [Wishlist,Open]
[01:09] <imbrandon> pochu: thanks
[01:14]  * persia wants "edit comment" in launchpad
[01:17] <Fujitsu> persia: Would bug #80895 describe what you want?
[01:17] <ubotu> Launchpad bug 80895 in malone "Give people five minutes to edit/delete their comment" [Undecided,Confirmed] https://launchpad.net/bugs/80895
[01:17]  * jonnymind is away: sleeping
[01:18] <Fujitsu> imbrandon: Nice!
[01:18] <persia> Fujitsu: Yes.  Preceisely.  Thanks for the bug number (and for generally knowing all the Malone bugs off the top of your head).
[01:18]  * Fujitsu only knows a couple of bug numbers, but remembers the keywords in the summaries of most malone/soyuz bugs.
[01:19] <imbrandon> heh yea like the digg.com 2 minutes to edit the comment thing
[01:21]  * pochu was angry while he replied to a bug report and typoed FYI with YFI, which in fact made sense as he was angry... :-)
[01:21] <pochu> Luckily the reported didn't take it seriously but interpreted it as FYI...
[01:27] <bddebian> Heya gang
[01:28] <pochu> Night bddebian
[01:28] <bddebian> Hi pochu
[01:28] <bddebian> Err gnight pochu :)
[01:28] <Fujitsu> Hey bddebian.
[01:28] <bddebian> Heya Fujitsu
[01:39]  * Hobbsee waves
[01:39] <bddebian> Heya Hobbsee
[01:43] <imbrandon> ello Hobbsee and bddebian
[01:43] <imbrandon> mmm time for food
[01:43] <imbrandon> brb
[01:43] <bddebian> Heya imbrandon
[01:44]  * persia cheers blueyed for fixing debdiff for native packages
[01:45] <blueyed> You're welcome persia :)
[01:45] <minghua> hello Hobbsee
[01:46] <Hobbsee> ...yay, motu ML
[01:46] <Hobbsee> heya bddebian, imbrandon, minghua
[01:46] <persia> Hobbsee: What on MOTU ML?  I only see MC bother.
[01:46] <Hobbsee> sorry, MC
[01:46] <Hobbsee> they all go to the same filter on my inbox
[01:47] <persia> Ah.  Good.  Two would have been too many :)
[01:48] <Hobbsee> yeah well.
[01:49]  * Hobbsee should just resign or something.
[01:54] <minghua> Hobbsee: Why?  Because of the MC decision?
[01:56] <minghua> My gutsy->hardy upgrade claims firefox and openoffice.org as obsolete after the upgrade and offers to remove them.  Curious.
[01:56] <bddebian> What'd I miss now?
[01:57] <persia> bddebian: A spat about specific vs. general in terms of mechanisms to ask someone disruptive to stop, and what to do when they don't.
[01:58] <bddebian> Ah, I can guess who that was about
[01:59] <persia> bddebian: That was the seed, but the discussion has moved into other, more pointless areas.  That's the problem with multiple threads.
[02:00] <persia> (not that Robert's Rules of order would work in email anyway :) )
[02:00] <effie_jayx> persia,  I just checked the runghc bug and I hadn't received any notifications on email.. I am buiding with the changes...
[02:00] <effie_jayx> should have a patch shortly
[02:01] <persia> effie_jayx: Strange.  Are you not subscribed to the bug?
[02:01] <effie_jayx> persia,  yesm I am . I found t odd myself
[02:01] <bddebian> persia: :)
[02:04] <Hobbsee> minghua: that, and wider issues related to that.
[02:04] <Hobbsee> minghua: and the fact that i'm not doing uploads, etc, anyway
[02:07] <minghua> Hobbsee: It would be sad if you resign.  But to be honest, I personally just care if you are still going to hang around on IRC or not. :-)
[02:08] <Hobbsee> minghua: well, yeah.  as for that, i don't know.
[02:09] <Hobbsee> minghua: i can ignore all of MOTU if i don't hang out here, and unsubscribe from teh lists
[02:25] <imbrandon> wow intels new moble device looks alot like a ipod only bigger
[02:25] <imbrandon> http://images.appleinsider.com/silverthorne-071221-3.jpg
[02:29] <minghua> Good, nothing big seems broken after upgrading to hardy.
[02:36] <Larose> I did a small module for linux, I would like, when "make install" is called, that the module insert itself into "/etc/modprobe.d". What is the best way to do this ? (cp foo /etc/modprobe.d?)
[02:38] <minghua> Larose: dh_installmodules(1), perhaps.  You can also ask in #ubuntu-kernel channel.
[02:39] <Larose> minghua: Thanks
[02:40] <minghua> No problem.
[02:57] <imbrandon> ok anyone semi familiar with licensing ( GPL ) , i'm not wanting legal advice but if someone knows about a link in lamens terms explaining the diffrences in GPL2 and 3
[02:57]  * bluefoxicy stabs the 7.04 livecd
[02:58] <bluefoxicy> failsafe terminal
[02:58] <imbrandon> i have some new code i'm writing and would like to stick with GPL just not familiar with v3 at all
[02:58] <bluefoxicy> LOADING GNOME
[02:58] <bluefoxicy> stupid.
[02:59] <persia> imbrandon: http://www.fsf.org/licensing/licenses/rms-why-gplv3.html might be part of what you seek.
[02:59] <imbrandon> cool /me looks
[03:00] <persia> imbrandon: http://www.fsf.org/licensing/licenses/quick-guide-gplv3.html is likely some of the rest of it.  Details are best left to careful inspection.
[03:01] <imbrandon> right, basicly i want to avoid the situation that if someoen is using gplv2 only code cant use mine, i would like them to be able to
[03:01] <imbrandon> infact in htis instance i might be better off with BSD or something
[03:01] <persia> imbrandon: Then you have to license under "GPLv2 or any later version".  GPLv3 code cannot be pushed into GPLv2.
[03:02] <persia> imbrandon: For permissive, ISC is really nice.  Gives more protection than PD, but doesn't block anyone.  Don't use BSD unless you've had a discussion with the Regents.
[03:02] <imbrandon> ok v2 or later it is then, that was my major question
[03:02] <bluefoxicy> unix systems are awesome
[03:02] <bluefoxicy> the system is retarded
[03:02] <imbrandon> ISC and PD ?
[03:03] <persia> imbrandon: http://en.wikipedia.org/wiki/ISC_license, Public Domain
[03:03] <imbrandon> i rarely write my own code so i'm not well versed in licenses :)
[03:03] <bluefoxicy> while true; do killall -9 $(ps -e | grep "\(gnome|nautilus\)" | awk '{print $1}'); done &
[03:03] <bluefoxicy> so much for I can't kill anything because something revives it.
[03:03] <persia> bluefoxicy: Better to make it not be revived, no?  That path leads to thrashing.
[03:03] <imbrandon> bluefoxicy: just kill all of X
[03:04] <bluefoxicy> imbrandon:  i did that
[03:04] <bluefoxicy> then I logged in in failsafe Xterm session and it started Gnome
[03:04] <imbrandon> heh
[03:08]  * bluefoxicy also disables hal
[03:10] <imbrandon> ok persia quick question i think i understand but just makin sure, so if i ( or anyone but using *i* here to make the question easy ) release say a single c file program ( just to be the simplest as possible ) under gplv2 or later , only *i* can redistribute that as v3 or can anyone ?
[03:10]  * imbrandon thinks the latter but makin sure
[03:10] <persia> imbrandon: Anyone.
[03:11] <persia> imbrandon: Stepping back, what do you want from your license?
[03:11] <imbrandon> cool, ok , but at that point its effectively forked as the new code cant go into the v2 version
[03:11] <imbrandon> correct ?
[03:11] <persia> imbrandon: Right.
[03:11] <persia> imbrandon: I presume you want open source, and credit due.  Do you want copyleft?  If so, how strong?
[03:12] <imbrandon> really i want it to be as permissive as possible without theft
[03:12] <imbrandon> heh
[03:12] <bderrly> bsd?
[03:12] <bderrly> that's pretty open
[03:13] <persia> imbrandon: For permissive, use ISC.  For copyleft, GPLv2 is good if you don't mind someone selling a device with DRM to prevent using the modified code, or GPLv3 in most cases.  In special cases, LGPL is appropriate (infrastructure code, deep libraries, etc.)
[03:13] <persia> bderrly: BSD requires discussion with the Regents of the University of California.  ISC gets all the same benefits, but avoids the discussion.
[03:14] <bderrly> wha?!
[03:15] <bderrly> what is ISC? haven't heard of that...
[03:15] <imbrandon> well since i'll likely at some point want to pull in others gplv2 stuff i'll stick with v2 or later
[03:15] <bderrly> and i didn't know anything about discussing with the regents of ucb
[03:15] <persia> bderrly: Basically, a cleaned up BSD without the specific references to the Regents of the University of California and a couple minor language changes to better match the Berne convention.
[03:16] <persia> bderrly: Take a look at /usr/share/common-licenses/BSD to see why it matters.
[03:16] <bluefoxicy> there.  Swap partition ELIMINATED
[03:16]  * bluefoxicy swapd
[03:17] <bderrly> awesome, i didn't know about /usr/share/common-licenses/
[03:17] <bderrly> :)
[03:19] <imbrandon> ok last quickie for the night, is there a list of "current" ( being the opertive word ) Source: section fields for debian/control as of 3.7.3 ?
[03:20] <imbrandon> i'm guessing on the debian wiki somewhere
[03:20] <persia> imbrandon: /usr/share/doc/debian-policy/policy.html/ch-controlfields.html
[03:21] <persia> (assuming you have debian-policy 3.7.3 installed)
[03:21] <imbrandon> you rock'
[03:21] <imbrandon> yea
[03:21]  * persia thinks people should look in /usr/share/ more often.  Lots of good stuff there.
[03:23]  * bddebian rm -rf'd /usr/share to save space ;-P
[03:24] <imbrandon> heh
[03:24]  * persia finally understands so much :)
[03:24] <bddebian> Oh ouch.. :'-(
[03:24] <bddebian> Good one though :-)
[03:24] <persia> bddebian: Sorry.  I couldn't resist that :)
[03:27] <bddebian> s'ok, it was well deserved ;-)
[03:50] <imbrandon> persia: mind adding to this list http://paste.ubuntu.com/2918/plain/  on the -dev metapackage
[03:51] <nxvl_work> can someone take a look at bug 150036 and sponsor it :D
[03:51] <ubotu> Launchpad bug 150036 in dillo "Dillo menu item should be in Internet category" [Low,Confirmed] https://launchpad.net/bugs/150036
[03:55] <imbrandon> nxvl_work: i'll sponsor it
[03:55] <nxvl_work> imbrandon: thnx :D
[03:56]  * nxvl_work *HUGS* imbrandon
[04:01] <imbrandon> nxvl_work: done
[04:03]  * nxvl_work *HUGS* imbrandon again
[04:18] <persia> imbrandon: On which list does that belong?
[04:19] <imbrandon> ?
[04:20] <persia> imbrandon: persia: mind adding to this list http://paste.ubuntu.com/2918/plain/  on the -dev metapackage
[04:20] <imbrandon> no i mean sugestions for the depends
[04:20] <imbrandon> tot he -dev pacakge
[04:21] <nixternal> how goeth those kde4bindings?
[04:21] <nixternal> having issues with qyoto yet?
[04:21] <imbrandon> nah qyoto was fine
[04:21] <imbrandon> its the ruby mess thats killing me
[04:21] <nixternal> ahh ya
[04:22] <nixternal> you would dep on ruby, and it would tell you ruby wasn't installed?
[04:22] <imbrandon> yea lol
[04:22] <nixternal> ya, same crap building from svn with amarok
[04:22] <imbrandon> i got it fixed i think
[04:22] <nixternal> I think I had to go with 1.8
[04:22] <imbrandon> yup
[04:23] <nixternal> I need to make tty1-6 buffer a few thousand lines
[04:23] <imbrandon> btw who uploaded amarok last ,Rid*dell and apache*logger_ ask me to then like 20 minutes later someone else already had done it
[04:23] <nixternal> I hate scrolling up to find an issue, and it doesn't make it all the way up
[04:23] <nixternal> I don't know who did it, I seen apache&laggers name on it though
[04:24] <nixternal> apachelogger_: who served you homey? :p
[04:24] <imbrandon> yea but he isnt core so couldnt have :)
[04:24] <nixternal> speak up, or imbrandon and I go gangstah on ya
[04:24] <imbrandon> oh well no biggie, just was curious
[04:24] <nixternal> when it happened, JR was zzZzzZzZzzzZ
[04:25] <nixternal> this is sad, i can't remember families birthdays, but I can remember uploads and versions
[04:25] <nixternal> I need a life
[04:25] <persia> imbrandon: 1) s/Pre-Depends/Depends/, 2) s/(= ${binary:Version})//, 3), s/devscripts//, 4) s/pbuilder//, 5) s/subversion/subversion, \n cvs, desktop-file-utils, debian-policy, lintian, linda
[04:26] <imbrandon> k
[04:27] <persia> pbuilder is Recommends: and devscripts is Depends: of ubuntu-dev-tools.
[04:27] <imbrandon> right
[04:28] <imbrandon> desktop-file-utils ?
[04:28] <imbrandon> i'm guessing for .desktops
[04:28] <persia> imbrandon: Right.  It's default for Ubuntu/Xubuntu, but not for Kubuntu.  Maybe Recommends:
[04:29] <persia> Also, for meta-packages, consider doing everything as Recommends: so that people can push things if they don't like them.  Even apt-get does Recommends-by-default for metapackages.
[04:29] <imbrandon> ahh i dident know that
[04:29] <imbrandon> the -by-default
[04:30]  * persia may be mistaken: last review of apt source was > 6 months back
[04:36]  * Fujitsu wonders why the Janitor now does changelog-closes-bugs messages.
[04:37]  * minghua noticed that too.
[04:46] <nxvl_work> i have a doubt on Bug 178046
[04:46] <ubotu> Launchpad bug 178046 in dillo "dillo failed to unpatch" [Undecided,New] https://launchpad.net/bugs/178046
[04:47] <nxvl_work> is better to change the patch or the rules?
[04:47] <persia> nxvl_work: Likely the patch.
[04:47] <nxvl_work> its a weird patch
[04:47] <persia> The rules appears to be trying to unpatch, but the patch doesn't unpatch cleanly.  Something is odd.
[04:47] <nxvl_work> it removes some files
[04:48] <nxvl_work> --- dillo-0.8.6/ABOUT-NLS       1970-01-01 09:00:00.000000000 +0900
[04:48] <nxvl_work> +++ dillo-0.8.6-i18n-misc-20070916/ABOUT-NLS    2006-05-16 01:21:07.000000000 +0900
[04:48] <persia> nxvl_work: Not just set to zero bytes, but remove?
[04:48] <nxvl_work> and under this there are only + sentences not even one -
[04:49] <persia> nxvl_work: That appears to be creating a file.
[04:49] <nxvl_work> and isn't it deleting ABOUT-NLS?
[04:50] <nxvl_work> mmm, that file doesn't exist
[04:50] <nxvl_work> persia: is there any way to check in what point is it failing?
[04:51] <persia> nxvl_work: Yes.  Run the build manually (debuild -b), and check to see the status of the files at failure.  I recommend running that in a chroot to not affect the rest of your system.
[04:51] <nxvl_work> can it affect my system?
[04:51] <nxvl_work> same output as on the report
[04:52] <persia> nxvl_work: If you run debuild not in a chroot, the commands in debian/rules run against your current system, and you must have all build-dependencies installed.  Once you've run debuild, go look at the status of things: maybe there will be some .rej files to help you understand how the patch failed.
[04:53] <nxvl_work> yep
[04:53] <nxvl_work> there is many .ref files
[04:56] <nxvl_work> what am i looking for on this rej files?
[04:58] <persia> nxvl_work: The .rej files show you what hunks of the patches couldn't deapply.  This may help you to understand the issue.  In the worst case, you might need to repack the patch.
[04:58] <nxvl_work> mmmm
[04:58] <nxvl_work> there are many + and - sentences
[04:59] <nxvl_work> so, those can't be applied?
[04:59] <persia> nxvl_work: looks like they cannot be de-applied from the report.
[05:00] <nxvl_work> mmm
[05:00] <nxvl_work> im not understanding i will google for rej files to understand them better
[05:00] <nxvl_work> thnx for pointing me to them :D
[05:05] <nxvl_work> maintainer notified
[05:11] <persia> nxvl_work: Huh?  We don't really have maintainers.  Better to patch the package to not have the bug, no?
[05:11] <nxvl_work> persia: the Debian one
[05:11] <minghua> Pbuilder's command line is really fragile.  A leading space in the --mirror option gives cryptic error messages.
[05:12] <persia> nxvl_work: We've passed DIF, so pushing the work to Debian doesn't help as much anymore.  Much better to fix it, and send the patch to Debian for later reference.
[05:19] <nxvl_work> yep
[05:19] <nxvl_work> i think so too
[05:19] <nxvl_work> but maybe he can help :D
[05:19] <nxvl_work> i will give a look tomorrow, now i'm to tired
[05:19] <Fujitsu> O_o
[05:19] <Fujitsu> What at packages.qa.d.o?
[05:19] <Fujitsu> *ate
[05:20] <nxvl_work> Fujitsu: huh?
[05:20] <persia> nxvl_work: Maybe.  In these cases, best to try to duplicate in a debian chroot, adn if you can, just file a bug in the BTS rather than emailing a maintainer.
[05:20] <persia> Fujitsu: New look for a new age?
[05:20] <Fujitsu> It's so bright and LP-like.
[05:20] <nxvl_work> persia: i have a debian system on a VM and it's there too
[05:20] <nxvl_work> IIRC
[05:21] <persia> nxvl_work: Great.  Did you file a bug in the BTS?
[05:21] <nxvl_work> let me recheck
[05:21] <nxvl_work> i'm unsure
[05:22] <nxvl_work> why it shows me that error the 2nd time i run it, is there any difference between the 1rs and the 2nd?
[05:22] <persia> nxvl_work: The clean rule doesn't properly restore state.
[05:23] <persia> More generally, running debian/rules clean should return the package to the same state as it was when it was originally unpacked, assuming no manual adjustment of files.
[05:24] <nxvl_work> yep, exactly same error, reporting
[05:24] <nxvl_work> oh! so it is patching it, but no unpatching at the end?
[05:25] <persia> nxvl_work: OK.  Please note that using the BTS to report bugs in Debian is the best way to tell the maintainer about an issue.  A fix may benefit Ubuntu, but a Debian maintainer generally prefers to get information about Debian in the BTS, rather than direct email, and usually prefers to only get BTS reports for things that would improve the package in Debian.
[05:28] <slangasek> unless you're sneaky like me and bundle some Ubuntu-specific changes in with some other patches
[05:28]  * Fujitsu wants some of the crack that the first responder to Debian bug #453620 is on.
[05:28] <ubotu> Debian bug 453620 in qmail-src "qmail under public domain" [Important,Open] http://bugs.debian.org/453620
[05:28]  * persia thinks slangasek gets a special pass
[05:30] <persia> Fujitsu: Perhaps having a package in non-free has a special feeling for some people?
[05:30] <Fujitsu> Hah.
[05:31]  * Fujitsu notes we should probably push qmail to universe, though with 44 Debian revisions there could be something nasty there.
[05:31] <slangasek> persia: I don't think it's a special pass, I'm just Cunning :)
[05:31] <persia> 44?  I thought qmail was previously under a "do not modify" license.
[05:32] <Fujitsu> I find it strange too.
[05:32] <persia> slangasek: Maybe.  I still think you have a special "yes, that is the way to do it" certificate that makes it easy.  Anyway, wouldn't you prefer a BTS entry asking you to be sneaky than private email?
[05:35] <slangasek> persia: oh, yes, absolutely it should go via the BTS
[05:35] <slangasek> persia: even if the package maintainer is willing to accept patches by other means
[05:35] <persia> nxvl_work: That'd be the Voice of Authority speaking on the matter :)
[05:38] <Fujitsu> persia: Ahhh, I see. Debian can modify it because they only distribute source.
[05:40] <persia> Fujitsu: Ah.  That might make the maintainer correct that it doesn't apply to the qmail-src package then.  On the other hand, a qmail package might be nice.
[05:41] <Fujitsu> The qmail source package only builds the qmail-src binary, but could probably now build qmail, right.
[05:42] <persia> Fujitsu: Well, maybe.  It depends on the patches.  It might need a fresh download of the PD stuff, and then cherrypicking of the acceptable patches into the tree (perhaps involving license verification).
[05:43] <persia> Still, it's not as trivial as just moving it to main (and thereby syncing to universe).
[06:00]  * Fujitsu wonders what Kubuntu's lack of LTSness means to upgrades.
[06:04] <Fujitsu> So not only do we have Dapper's Canonical-sponsored-LTS main and the community-driven-LTS universe, but also non-LTS subset of main... Yay.
[06:06] <minghua> Does that also mean the only supported upgrade path for Kubuntu dapper will be dapper -> edgy -> feisty -> gutsy -> hardy -> ... ?
[06:07] <minghua> :-D
[06:07] <Fujitsu> That is what I was asking with my first question.
[06:07] <Fujitsu> And are we supporting Dapper->L* for Kubuntu?
[06:08] <minghua> Fujitsu: yes.  But there is also hardy -> next LTS upgrade.
[06:09] <Fujitsu> One could presumably upgrade Dapper->Hardy, as upgrades are tested.
[06:09] <Fujitsu> But once on Hardy, you can't safely get to L*
[06:09] <Fujitsu> As that will be released after support ends.
[06:09] <minghua> L* being the next LTS?
[06:09] <Fujitsu> Assuming a 2-year gap as seems to be the standard.
[06:10] <minghua> h -> j -> k -> l -> m, shouldn't that be M*?
[06:10] <minghua> Ah, I missed I.
[06:10] <Fujitsu> Heh.
[06:10]  * minghua can't recite alphabet. :-(
[06:11]  * minghua blame physics' convention of skipping vowels when choosing letters as super/subscripts.
[06:12] <Fujitsu> Haha.
[06:12]  * Fujitsu thinks that any LTS deployments of Kubuntu are going to be in a bit of trouble.
[06:16]  * persia wonders where the "official no LTS for Kubuntu" announcement can be found.
[06:16] <Fujitsu> persia: I found it linked from Planet, with a reference to the kubuntu-devel ML.
[06:17]  * Fujitsu digs up a link
[06:17] <Fujitsu> https://lists.ubuntu.com/archives/kubuntu-devel/2007-December/002066.html
[06:20] <persia> Hmm.  I read that differently.  Looks to me like 8.04 dual KDE3.5 & KDE4, with KDE4 being normal LTS, and 6.06 users being encouraged to upgrade to KDE3.5.  I'd think it could be solved by providing a KDE3.5 -> KDE4 migration wizard to be applied at some point prior to the 8.04 -> 10.04 upgrade.
[06:20] <Fujitsu> No, read the followups.
[06:22] <Fujitsu> nixternal: Why is there an unfinished merge .changes in your latest sync bug?
[06:22] <nixternal> cuz I forgot to dch -e when I was teaching....bad teacher ey?
[06:22] <nixternal> hey, at least I taught him to dch -e though, but I didn't listen
[06:23] <Fujitsu> The unfinished bit was extra - why is there a merge .changes at all? It's a bit odd...
[06:24]  * persia is vaguely unhappy about the marketing efforts of a single sponsor having an influence, but doesn't do LTS deployments anyway, so stops worrying about it.
[06:24] <nixternal> hrmm, ya...I copied changes..just noticed that
[06:31]  * Fujitsu is thoroughly confused on how this will all be handled. main is defined by support from the Canonical security team, but after 18 months much of it won't be... upgrades are problematic...
[06:32] <warp10> Hi all!
[06:33] <persia> Fujitsu: From what I read on the list, it's just a matter of branding for Kubuntu, from the marketing team, and a complete lack of upgrade testing 8.04 -> 10.04.  Security should still be about the same, I'd think, especially as Ubuntu LTS users may well install kdebase for whatever reason.
[06:34] <Fujitsu> persia: So it's LTS in some ways, but not others. These are yet to be properly defined. Great.
[06:34] <persia> Fujitsu: It's LTS except that it's not called LTS, and the kubuntu-devel team doesn't expect to be chasing non-security SRUs after 18 months would be my gloss.
[06:35]  * persia is not a Kubuntu developer, and so any statements are necessarily interpretive, and may not reflect any known reality
[06:36]  * Fujitsu pities people who accidentally install KDE packages on LTS releases, and get themselves broken systems on upgrades that look to be supported.
[06:36] <warp10> Argh... REVU still down?
[06:36] <Fujitsu> warp10: I believe so; the server it is on seems to have died.
[06:37] <persia> warp10: Looks that way :(  The admins have been notified.
[06:37] <Fujitsu> And I'm not sure anybody has physical access at the moment.
[06:37]  * persia suspects the hosting university is closed for the holidays
[06:37] <RAOF> It seems a bunch of things are uninstallable, care of libgif/libungif fun.
[06:38] <warp10> Too bad... ok, let's wait!
[06:39] <Fujitsu> RAOF: Yep, the transition is partly done, and they conflict.
[06:39] <persia> warp10: In the meantime, there's lots of packaging bugs available for consideration from https://bugs.launchpad.net/ubuntu/+bugs?field.tag=packaging :)
[06:39] <RAOF> Since libungif is unmaintained, and libgif replaces it, should there be a nice mass-bug filed?_
[06:40] <Fujitsu> RAOF: Already done.
[06:40] <persia> RAOF: There likely is.  Which packages are left?
[06:40] <Fujitsu> I think it has caught most of them.
[06:40] <RAOF> Aaaah, there it is.  At the bottom of the emacs22 bug list.
[06:40]  * persia only sees icedtea-java7-bin left for hardy AMD64
[06:41] <RAOF> persia: You obviously don't have emacs installed.  Heretic!
[06:41] <warp10> persia: ty, bugs.launchpad.net/ubuntu is always in a firefox tag :)
[06:42] <persia> RAOF: My data comes from `apt-cache rdepends libgif4` and is not related to the presence or absence of any specific packages.  Anyway, I gave up on emacs years ago, in preference of telepathically adjusting the electrons.
[06:42]  * Fujitsu binds his vi into a nice arrow, and kills off RAOF.
[06:42] <Fujitsu> persia: Wrong way.
[06:42] <Fujitsu> We're going *to* libgif, aren't we?
[06:42] <persia> Fujitsu: Ah.  Right.
[06:42]  * persia goes off to play with grep-dctrl
[06:42] <Fujitsu> bug #174252
[06:42] <ubotu> Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252
[06:43] <persia> Right.  There we have it.  It's just a build-dep swap?
[06:44]  * persia notes that the "affects" list in the bug report is rather short, considering...
[06:44] <Fujitsu> persia: That should be all that is necessary.
[06:44]  * Fujitsu gets a list of sources.
[06:45] <persia> Fujitsu: Explain why we don't need to do paul or mgp or mtpaint please :)
[06:45] <Fujitsu> persia: I meant that to you `It's just a build-dep swap?' question.
[06:45] <Fujitsu> s/you/your.
[06:45] <persia> Fujitsu: OK.  Sorry then :)
[06:49] <persia> Has the library dependencies abolition effort gone far enough down-stack that it's worth updating these before imlib, etc. have been updated?
[06:58] <minghua> Quick question: Is there a way to refresh my group information after "addgroup minghua foo" without logging out?
[06:59] <RAOF> minghua: start a new shell?
[06:59] <minghua> RAOF: Doesn't seem to work under hardy.  I tried "bash -l"
[07:00] <RAOF> You should have the right group information inside that shell, thoug?
[07:01] <minghua> Doesn't seem so:
[07:01] <persia> minghua: Try a new terminal emulator with a new login session, or ssh to your bok.
[07:01] <minghua> $ grep "^src" /etc/group
[07:01] <minghua> src:x:40:minghua
[07:01] <minghua> $ id
[07:01] <minghua> uid=1000(minghua) gid=100(users) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),100(users),104(scanner),108(lpadmin),114(netdev),116(powerdev),118(admin),1000(minghua)
[07:03] <minghua> persia: Checked "run command as a login shell" in gnome-terminal's profile, quit gnome-terminal, relaunch gnome-terminal, nothing changed.
[07:03] <minghua> I swear the same thing worked in Debian before...
[07:03]  * persia tries
[07:06] <persia> minghua: Odd indeed.  I can replicate here.  ssh works.
[07:06] <minghua> Aha.  Thanks persia.
[07:06]  * minghua heads to malone.
[07:07] <minghua> Hmm, what package should the bug be against, though?
[07:07] <persia> minghua: The very odd bit is that `groups` is supposed to be `id -Gn`, but `groups` provides the right data, even without reloading the terminal session (which is different than in the past).  perhaps something related to PolicyKit or ConsoleKit?
[07:08] <BiG_ALLen> Sup Peeps?
[07:08] <BiG_ALLen> Any1 here?
[07:08] <minghua> persia: "groups" doesn't work here, gives the same output as "id -Gn".
[07:08] <minghua> !ask | BiG_ALLen
[07:08] <ubotu> BiG_ALLen: Don't ask to ask a question. Just ask your question :)
[07:09] <persia> minghua: Interestingly, running `id -Gn persia` provides the updated output.
[07:09] <minghua> Ah.
[07:09] <BiG_ALLen> What do u do 1st when u start this game?
[07:09] <minghua> persia: Yes, yes, "groups minghua" works here, too.
[07:09] <persia> BiG_ALLen: find a bug you like, and fix it.
[07:10]  * minghua straces id.
[07:10] <persia> minghua: But that doesn't help the entitlements of the current shell :(
[07:10] <BiG_ALLen> what does that meen...?
[07:14] <minghua> persia: I don't see anything related to consolekit in strace.
[07:14] <persia> minghua: I was just guessing wildly.
[07:18]  * minghua is attempted to just report it against Ubuntu in general...
[07:18]  * persia suspects it may get lost in that case, or someone may tell you it's not a bug report.
[07:19] <persia> minghua: Perhaps start with coreutils: anyone triaging bugs there ought to know better than we where it really belongs.
[07:23] <minghua> persia: Okay, since both id and groups are in coreutils...
[07:23] <persia> minghua: That was my thinking
[07:23]  * minghua is skeptical that coreutils bugs gets more attention than general Ubuntu bugs, though.  Let's see...
[07:24] <persia> minghua: Likely less attention, but more likely to get attention by the right people.
[07:24] <minghua> BTW Debian's "general" bug is cc:ed to debian-devel list, therefore has a high visibility.
[07:24] <minghua> persia: Fair enough.
[07:24] <persia> minghua: There used to be something like that in Ubuntu, but it was rejected as too much traffic before the migration away from bugzilla.
[07:26] <minghua> persia: Yes, it's just too easy to file general bugs in LP.
[07:26] <persia> minghua: True.  I realise I don't even know how to do that properly in the BTS (and no, don't explain, I'll likely never need to do it).
[07:28] <minghua> Heh.
[07:36] <minghua> Yeah, coreutils has two bugmail contacts. :-)
[07:36] <minghua> persia: bug 178059 if you are interested.
[07:36] <ubotu> Launchpad bug 178059 in coreutils "Strange behavior after adding a user to a certain group" [Undecided,New] https://launchpad.net/bugs/178059
[07:37] <minghua> Feel free to suggest a better description. :-)
[07:40] <persia> minghua: That seems to sum it up.  Let's hope one of the bug contacts has a better idea :)
[07:51] <apachelogger_> nixternal: imbrandon: I actually thought Riddell did it ;-)
[07:51] <apachelogger_> wasn't me, for sure
[07:51] <nixternal> about time you spoke up
[07:51] <nixternal> imbrandon is getting the bats right now, just for you :)
[07:52] <imbrandon> hahaha nixternal shush
[07:52] <apachelogger_> Oo
[07:52] <nixternal> I thought he crashed though before you get it finished or what not
[07:52] <nixternal> oh well, imbrandon he admitted to it, so lets get um!
[07:52] <imbrandon> i was just curious, if i was *that* curious i could check hte sig on the changes file
[07:52] <imbrandon> :)
[07:52] <imbrandon> brb
[07:53] <apachelogger_> arrr
[07:53] <apachelogger_> <-- needs a coffee
[07:53] <nixternal> it isn't "speak like a pirate day"
[07:53] <nixternal> I will too, looks like I am pulling an all nighter
[07:53] <apachelogger_> nixternal: @amarok it's always talk like a prite day
[07:54] <apachelogger_> or 'use as many unknown words as possible' day
[07:54] <nixternal> also, amarok2 isn't building in svn for me, fix it! :)
[07:54] <apachelogger_> honestly
[07:54] <nixternal> I wouldn't doubt if there is an issue with the deps on my desktop though
[07:54] <apachelogger_> I didn't have time to build for the last week ;-)
[07:56] <apachelogger_> nixternal: what error message do you get?
[07:56] <nixternal> I can't remember...I will tweak it up a bit tomorrow
[07:56] <nixternal> I guess I am staying up for this kubuntu meeting
[07:56] <nixternal> 3 more hours until the meeting
[07:57] <minghua> Good, at least logout-and-relogin works...
[08:57] <\sh> moins
[08:58] <Lure> hi \sh
[09:02] <\sh> now it's the best time of the year...no need to go to the office anymore...until 1st of Feb no need to do something for a living...and 5 Eizo FlexScan M1700 are waiting to be tested...
[09:51] <minghua> My understanding is that REVU is offline because the machine is down.  So I added that to topic.
[09:52] <minghua> It would be nice if someone sends an notice to the mailing list as well.
[09:52] <persia> Are we firmly expecting to stay that way for a long time?  I don't remember anyone saying it couldn't be fixed soon.
[09:52] <minghua> Well, it's still down.  And it's been about how many hours?  8?
[09:53] <minghua> persia: Feel free to remove it if you like. :-)
[09:54] <persia> minghua: I've no issues with it being there, just curious if there was any firm feedback from those with local access.
[09:54] <minghua> persia: ... or change it to something like "REVU is temporarily offline".
[09:55] <persia> Personally, I'm not expecting much, given that it's housed in Germany, and this weekend is likely to be long and most people busy there.
[09:56] <imbrandon> persia / minghua : siretart is hte only one with physical access and he is aware its down but not sure on an eta for fixing it
[09:56] <imbrandon> s/hte/the
[09:56] <persia> imbrandon: sistpoty doesn't have physical access?
[09:56] <\sh> persia, siretart has
[09:56] <Fujitsu> persia: He said he didn't.
[09:56] <imbrandon> persia: no they are at diffrent campusus iirc
[09:57] <siretart> imbrandon: yes, but I'm atm rather ill in bed, and I don't know when I make it next to the server room. sorry :(
[09:57] <persia> Ah.  Different campus.  That makes sense.
[09:57] <imbrandon> siretart: no worries, i was just updating them on the situation
[09:57] <persia> siretart: Please get better soon (and not for REVU).
[09:57] <siretart> it's the same campus, but sistpoty doesn't have access to the door for the server room
[09:57] <minghua> siretart: Sorry to hear that.  Hope you can recover soon.
[09:57] <siretart> thanks!
[09:57] <imbrandon> :)
[09:59] <imbrandon> wow i'
[09:59] <imbrandon> m  actualy able to run a vm
[09:59] <imbrandon> now
[09:59] <\sh> guys...if someone has still old SDRAM ... i'm in need :) I have still 2 old 2x PIII 1GHz servers and they need sdram :(
[09:59] <Fujitsu> imbrandon: Aw, your 200MHz weren't enough?
[09:59] <imbrandon> so i can run stable on my desktop and hardy kubuntu and hardy ubuntu
[09:59] <Fujitsu> \sh: I have a shortage here too :(
[10:00] <imbrandon> been quite a while since i could do that
[10:00]  * imbrandon quickly installs kvm 
[10:00] <imbrandon> Fujitsu: hehe
[10:00] <\sh> Fujitsu, 768MB is laying around here...so I could try to setup at least one of those...and trying to build a nice buildfarm here at home...;)
[10:01] <imbrandon> this desktop is quite nice, i was suprised the 4600+ is only clocked at 2.7ish but still blazing fast compared to what i'm used to
[10:01]  * minghua wonders if mailing SDRAMs over oceans is cheaper than buying it in local store (or second market)...
[10:01] <\sh> ha...that's a good task for today...wife is travelling to helgoland and I have all the time I need to do some real work :)
[10:02] <persia> imbrandon: Just out of curiosity, why the 4600+ rather than the 4400+ or 4800+?  I'd think the extra cache in those would generally be better for development-type loads.
[10:02] <imbrandon> minghua: to you or from you, i'd imagine you could get it cheaper then me from what i've seen
[10:02] <\sh> minghua, you know how expensive sdram is today? you can even buy ddr1 laptop ram for ibms very cheap but not sdram :)
[10:02] <Fujitsu> SDRAM must be about 3 times the price of DDR2 here.
[10:02] <imbrandon> persia: thats where the price break was
[10:03] <\sh> Fujitsu, yeah
[10:03] <persia> imbrandon: Ah.  Makes sense.
[10:03] <minghua> Ebay price seems to be at $25 / 512MB, which seems reasonable to me.
[10:04] <imbrandon> minghua: quite, its far more expensive than that here localy
[10:04] <\sh> minghua, check for GB modules
[10:04] <minghua> imbrandon: Why?  It was just a hypothetical question though, as I know \sh and Fujitsu are both far away from me.
[10:04]  * \sh needs 8x 1GB modules for those...
[10:05]  * minghua has some spare SDRAMs at hand, but they don't belong to me.
[10:05] <imbrandon> i have 1 or 2 spare but only 256mb size
[10:05] <jeromeg> hello
[10:05] <minghua> \sh: Makes sense.  I've never seen GB-size SDRAMs, actually.
[10:08]  * \sh has in this very special moment too much hardware in his flat...
[10:09] <imbrandon> :)
[10:09] <imbrandon> i used to love it when i worked for a DC here in town where i got all the "old" hardware ( most of it better than the "new" stuff i have now )
[10:09] <\sh> hey...if oyu have the possibility to buy from your comapny some eizos m1700 tfts for 35 Euros and there is still 3 years bring in service available...
[10:09]  * imbrandon misses those days
[10:10] <\sh> 175 euros for 5 tfts is not much ;)
[10:10]  * persia doesn't have that many desks (nor pairs of eyes)
[10:11] <imbrandon> heh
[10:11] <\sh> persia, three of them are already sold for 175 bucks each :)
[10:11]  * minghua didn't know that you need new pairs of eyes for new monitors. :-)
[10:11] <persia> \sh: Bah.  Petty capitalism.
[10:11] <\sh> persia, lol
[10:11] <imbrandon> my setup at work is 4x 19'' lcd's , 2 on top 2 on bottom
[10:12] <imbrandon> spoils me
[10:12]  * \sh and his wife are having an expensive life ;)
[10:12] <\sh> imbrandon, nice servicedesk :)
[10:12]  * Fujitsu has 2x 17" CRTs at work, and a 14" laptop at home.
[10:12] <imbrandon> \sh: yea, but i've actualy found the guys with 2x 22in widescreens have a better setup
[10:12]  * Fujitsu is outdated.
[10:13] <imbrandon> easier to use
[10:13] <\sh> I wonder how I can determine the type of radeon card I have laying around here..without plugging it into a computer
[10:13] <imbrandon> google the p/n
[10:13] <persia> Fujitsu: Nah.  Small is not always bad.  I use a 4.7" laptop.
[10:13] <Fujitsu> That's... small.
[10:13] <imbrandon> wow
[10:13] <imbrandon> i thought the 3epc was tiny
[10:14] <imbrandon> at 7in
[10:14] <persia> imbrandon: Nope.  That wouldn't fit in my pocket :)
[10:14] <imbrandon> what kinda cpu and ports are on it?
[10:14]  * persia dislikes the 7" form-factor.  Too big for the pocket, and too small for doing two things at once.
[10:15] <persia> imbrandon: ARM, USB, CF, power, SD, serial.
[10:15] <imbrandon> nice
[10:15]  * imbrandon wishes those were avail in the US
[10:15] <Supremus> hi all!
[10:15] <persia> Of course, I should upgrade.  Fujitsu (the company) has a new 5" i386 with lots of goodies.
[10:15] <imbrandon> ahh the lifebooks?
[10:16] <imbrandon> err thats sony isnt it
[10:16] <persia> imbrandon: Well, part of the lifebook range.  Yes.
[10:16] <persia> No, Sony is VAIO.
[10:16]  * persia knows too much about Japanese laptop brands
[10:16] <imbrandon> ahh i have seen some of the tiny Fujitsu's here i guess we do have them in the US, just never seen a ARM one
[10:17] <imbrandon> they are ultra expensive here though, like 2.5k USD
[10:17] <persia> imbrandon: Fujitsu didn't have an ARM laptop.  Casio, Sharp, and NEC did.  Casio & Sharp are discontinued, and NEC is just waiting to sell out the inventory due to a special arrangement with NTT.  x86 is (unfortunately) the future.
[10:18]  * Fujitsu would have thought that x86 would have significantly higher power demands.
[10:18] <persia> Fujitsu: Less so with the new smaller low voltage ones.  These are the hardware that will become LPIA when available in other countries.
[10:19] <imbrandon> http://www.microcenter.com/single_product_results.phtml?product_id=0275540
[10:19] <imbrandon> thats the ones we have here in town
[10:19] <imbrandon> other than the 3epc
[10:19]  * persia notes that there are two or three N8xx competitors here, but they no longer use the clamshell form factor
[10:19] <minghua> Are those CPU from Intel or VIA?
[10:20] <persia> imbrandon: That's the big one :)  There's also a 4.9" 1024x600 model here.
[10:20] <persia> minghua: intel
[10:20] <imbrandon> Intel® Ultra Mobile Processor A110
[10:20] <imbrandon> persia: ahh thats the smalest we have localy, i could proably order something smaller
[10:21] <imbrandon> we JUST got the 3epc's 2 or 3 days ago in-store
[10:21] <persia> imbrandon: Maybe.  We get a lot of test products that never get shipped overseas.  Some are nifty, and some annoying.  In this case, I think the slide-out keyboards are winning over clamshells for the pocketable form-factor (I prefer clamshells)
[10:21] <imbrandon> and only the 4GB white ones
[10:21] <imbrandon> heh
[10:22] <imbrandon> yea i like the clamshell or tablet/clamshell mix
[10:22] <persia> imbrandon: I'm happy with convertibles (that is what I have), but I don't like slide-out keyboards for taking notes in meetings.  The balance is wrong.
[10:23] <imbrandon> yea it seems like a big phone at that point
[10:23] <imbrandon> imho
[10:23] <imbrandon> forfactor wise
[10:23] <imbrandon> form* ugh
[10:24] <imbrandon> like the Q*something* ones, are like huge phones or ultra tiny laptops
[10:24] <imbrandon> but they slideout
[10:25] <persia> Exactly.  Considering products like http://www.sharp.co.jp/ws/, I think all the Nxx clones are just over-big, and want a real laptop for a meeting.
[10:27] <\sh> damn..what card is it...
[10:27] <\sh> why can't I search for partno on the damn website
[10:27] <imbrandon> it would be too much like right
[10:29] <\sh> there is really no mention of the product name...
[10:29] <\sh> just serial number and part number, and the last number should be enough to find out the product
[10:31] <jonnymind> pochu: et al, hello.
[10:31] <jonnymind> I don't remember exactly how should I state in copyright the fac that docs are gfdl 1.2
[10:32] <\sh> grmpf
[10:32] <\sh> brb...changing graphics card...
[10:33] <awen_> hi
[10:34] <jpatrick> imbrandon: can you do a main upload for me? :)
[10:36] <awen_> seems we've forgotten something... the apache 1.xx was removed from ubuntu between feisty and gutsy, but all the extra-modules is still present in the repositories for both gutsy and feisty ( libapache-* http://qa.ubuntuwire.com/debcheck/debcheck.py?dist=hardy&list=relationship%2dDepends&arch=EVERY )
[10:37] <awen_> shuldn't they be removed now :-)
[10:37] <persia> awen_: We tried to remove most of them for gutsy.  Let's get rid of the rest for hardy :)
[10:37] <awen_> persia: exactly :)
[10:37] <persia> awen_: If you'd like to help, patches against the packages providing the old modules inhibiting the build of the old modules would be very welcome.
[10:38] <awen_> persia: is that the way to remove them?
[10:39] <persia> awen_: In most cases, yes.  Typically the binary package for the apache1 modules is built by a source package also providing apache2 modules, so removing the source package isn't the ideal solution.
[10:40] <persia> There are some exceptions, in which a source package only builds for apache1, and these are removal candidates, but most of those should already have been tracked down and removed.
[10:41] <awen_> persia: but should it be enough just building against the new modules, or is there other things i should be aware of?
[10:42] <persia> awen_: It's good to test the result to make sure it works with apache2.  It's mostly just changing the build, as you've noted.
[10:43] <persia> awen_: You may also find that some of them have open bugs for these issues, e.g. Bug #145571 for libapache-authensmb
[10:43] <ubotu> Launchpad bug 145571 in libapache-authensmb "[UNMETDEPS] libapache-authensmb has unmet dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/145571
[10:44] <awen_> persia: that was how i discovered them in the first place :-)
[10:45]  * persia is somewhat impressed that the current unmetdeps count for universe is only 116 source packages
[10:46] <awen_> persia: most of them ara debian packages that just is synced (no ubuntu changes)... do we prefer a upload for debian and a sync, or should i just make it a ubuntu patch?
[10:48] <persia> awen_: 10 days ago, the answer would be "Fix it in Debian".  Today the answer is "Fix it in Ubuntu".  For both answers, it's best practice to work with the other distro to make sure the fix gets in there as well.
[10:49] <awen_> persia: okay... so ubuntu patch for the quick fix... and upload to debian also for "the long run"
[10:50] <persia> awen_: Sort of.  Upload to Ubuntu because at this point in release preparations, it's not worth waiting for Debian to apply it before using it: best to just fix it and find the next bug.  Work with Debian because Debian would also benefit from the work, to avoid duplicate efforts.
[10:51] <persia> If there is an Ubuntu upload, then the package becomes Ubuntu maintained, so any fixes will be reviewed during the first six weeks of the next release cycle, and integrated if not yet in Debian.
[10:52] <awen_> persia: okay
[10:54]  * Hobbsee waves
[10:54] <persia> hi Hobbsee.  Body count high today?
[10:55] <Hobbsee> yeah.
[10:55] <Hobbsee> fricking customers
[10:55] <Hobbsee> dear customers.  if your meat is off, you do *not* feed it to your DOG!!!
[10:56] <Hobbsee> and you do not cook your other meat, and then throw it out, and then call up, asking for a refund on both blocks of meat.
[10:57] <Hobbsee> couldn't shoot that one, as it was via phone.
[10:58]  * Hobbsee shakes head at the stupidity of customers, and about their poor pets.
[11:28] <effie_jayx> persia, I have attached the patch. https://bugs.launchpad.net/ubuntu/+source/ghc6/+bug/95985
[11:28] <ubotu> Launchpad bug 95985 in ghc6 "no manpage for runghc / runhaskell" [Wishlist,In progress]
[11:29] <persia> effie_jayx: Great.  At this point, the bug isn't "In Progress" anymore, and I doubt you still want to be assigned, as you're not going to upload :)
[11:29] <effie_jayx> asigned to nobody then?
[11:29] <persia> effie_jayx: Right, and "Confirmed" or "Triaged".
[11:30] <effie_jayx> righto
[11:31] <jonnymind> btw, ppl, it seems I'll have to update the copyright.
[11:31] <jonnymind> I am getting developers :-)
[11:31] <persia> ember: When something is fixed, please set it "Fix Released" rather than "Invalid".  Even if it gets fixed in a different way than you expected.
[11:31] <jonnymind> anyhow, I dind't get very well the thing of shlibs.
[11:32] <jonnymind> I have a package which ships a shlib,
[11:32] <persia> jonnymind: shlibs is defined so that packages that build-depend on your package can have the right dependencies set.
[11:32] <jonnymind> now, I am supposed to say in shlibs what is the package someone should link against that slib.
[11:32] <jonnymind> of coruse... the package!
[11:33] <jonnymind> *what is the package someone depends on if linking to that shlib.
[11:34] <persia> jonnymind: There you go.  That's one of the reasons it's a good idea to make library binary package names match the SONAME: it makes the shlibs file easy to read, and makes transitions easy to see.
[11:34] <jonnymind> Ah, so I can go with:
[11:34] <jonnymind> libfalcon_engine.so 1
[11:34] <jonnymind> and stop, right?
[11:34] <jonnymind> pochu said it wasn't enough...
[11:35] <persia> You could, but I'd encourage you to have the package be named libfalcon_engine1 so that if you ever move to 2, the transition is not as painful.
[11:36] <jonnymind> It should be named 1-ubuntu1 afair
[11:36] <jonnymind> let me see
[11:36] <persia> Further, I suggest you want to list libfalcon_engine.so.X.Y.Z so that it links against a specific SONAME library, rather than a generic symlink.
[11:36] <jonnymind> libfalcon-engine1_0.8.5-0ubuntu1_i386.deb
[11:36] <jonnymind> Oh, may I?
[11:37] <jonnymind> Directions around are confusing.
[11:37] <jonnymind> Actually.
[11:37] <jonnymind> I had the impression they wasn't confusing, they was just confused...
[11:38] <persia> jonnymind: man deb-shlibs.  It's basically <library> <SONAME> <providing package>
[11:39] <jonnymind> the man says:
[11:39] <jonnymind> <library name>        <version/soname>        <dependencies
[11:39] <jonnymind> And the policy doesn't shine for clarity either.
[11:39] <jonnymind> In my mind version and soname are different things, and dependencies are not what should be provided.
[11:40] <jonnymind> So I got a bit confused about the topic...
[11:40] <persia> jonnymind: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#shlibsfile might help.
[11:40] <jonnymind> Ohh, that's much clearer.
[11:40] <jonnymind> Thanks.
[11:41] <jonnymind> in the version field
[11:41] <minghua> persia: A tangent point -- I don't think underscore is allowed in package name.
[11:41] <jonnymind> i.e. "(>= 0.6.1-1)"
[11:41] <jonnymind> should I put 0ubuntu1?
[11:41] <jonnymind> i.e.
[11:42] <jonnymind> (>=0.8.5-0ubuntu1)
[11:42]  * persia defers to minghua, who has actually had someone certify that he knows policy
[11:42] <persia> jonnymind: Right.
[11:42] <jonnymind> Uhm... this means I have to do different versions of the debian/ directory for ubuntu and debian packages...
[11:42] <jonnymind> fine, I have already thought at that.
[11:43] <minghua> jonnymind: No.  The version in the shlib file should correspond to the ABI change, not the current package version.
[11:43] <persia> jonnymind: You could do (>= 0.8.0-0) if you like, to work around that for now, but people in both distributions may find it odd.
[11:44] <persia> minghua: Initial packaging
[11:44] <minghua> There should rarely be a reason you need to put ubuntuY things in shlib.
[11:44] <minghua> persia: Then there shouldn't be a version number.
[11:44] <persia> minghua: Thanks for the clarification.
[11:45] <minghua> (which, BTW, is the default behavior of dh_mkshlibs.)
[11:45] <persia> No manual entry for dh_mkshlibs
[11:45] <jonnymind> Ok
[11:46] <jonnymind> I got the picture, thanks
[11:46] <minghua> dh_makeshlibs, sorry.
[11:46] <persia> Ah.  dh_makeshlibs.  How convenient :)
[11:46] <minghua> persia: ^^
[11:46] <persia> jonnymind: Don't do it by hand.  Use debhelper :)
[11:47] <jonnymind> persia: I would love. But the documentation about its working is limited to "do this, and debhelper will create an uinverse for you".
[11:48] <jonnymind> And all this "use deb-this-that" may be the reason there was so much confusion around about basic topics as creating multiple binary packages and naming shlibs,
[11:48] <persia> jonnymind: When debhelper is installed, it installs heaps of manpages, for all the dh_* utilities.  In this case, take a look at dh_makeshlibs
[11:48] <jonnymind> which are basically both simple and essentials.
[11:49] <jonnymind> I did, persia, I swear. I refer to THOSE docs.
[11:49] <persia> jonnymind: Ah.  I read that manpage as explaining how to autogenerate a shlibs file, but I agree, sometimes one needs to read the source.
[11:49] <jonnymind> Mine is a *constructive* criticism, I swear that too.
[11:51] <\sh> grmpf...I think I broke my aixgl
[11:57] <jonnymind> I rationalized the problem: autotools as debhelper etc. are great tools for the routinary packaging work of the professional packager.
[11:57] <jonnymind> take foreign software, automakebuildinstall it, pack it, done.
[11:58] <jonnymind> You are not going to make a distro without it.
[11:58] <jonnymind> BUT
[11:58] <jonnymind> you have to know the logic behind.
[11:58] <jonnymind> Programming courses are always "first do it the hard way, then use the magic function call".
[11:59] <jonnymind> There's a reason.
[11:59] <persia>  I expect it depends on how you learn.  I started with CDBS over auto-tools, and have been learning down-stack.  For my first work, the logic didn't matter, as I could see the results in testing.  As I learned deeper, I was able to fix more annoying issues.
[11:59] <jonnymind> Doing a multilayered sh- compliant deb packaged is damend easy, and also conceptually clean.
[12:00] <jonnymind> Yes, the point is that the docs around are a bit obscure about this fact.
[12:01] <jonnymind> And when you miss the "context informations", you are 17 times less powerful than when you have them.
[12:01] <\sh> did anybody tried the latest ati drivers with a X300SE card?
[12:01] <jonnymind> (I was in management course once :-)
[12:01] <jonnymind> Ok, enough complaining; I am packing.
[12:20] <jonnymind> I am receiving this message by dput:
[12:20] <jonnymind> Package includes an .orig.tar.gz file although the debian revision suggests
[12:20] <jonnymind> that it might not be required. Multiple uploads of the .orig.tar.gz may be
[12:20] <jonnymind> rejected by the upload queue management software.
[12:20] <jonnymind> Would I be warned in that case or just the package would be silently discarded?
[12:21] <persia> jonnymind: To where do you plan to upload?
[12:21] <jonnymind> revu
[12:21] <minghua> The message is from your local dput, it has nothing to do with what will happen on the server side.
[12:21] <jonnymind> (currently uploading...)
[12:21] <jonnymind> minghua: would I get an error somewhere notified?
[12:21] <persia> jonnymind: Unfortunately, REVU is currently not working properly.  Note that this may not actually work, and if it does, your package may not be available for some times.
[12:21] <minghua> jonnymind: Not for REVU.
[12:22] <jonnymind> IC.
[12:22] <minghua> jonnymind: And if it's a -0ubuntu1 version upload, that warning can be ignored.
[12:22] <jonnymind> minghua: thanks
[12:22] <jonnymind> persia:thanks, in fact the upload hung...
[12:22] <minghua> persia: BTW, does REVU really check for duplicated .orig.tar.gz?
[12:23] <jonnymind> Oh, well, I still have to write the docs and take care of my new developers :-)
[12:23] <persia> minghua: No.  In fact, it needs the duplicated orig.tar.gz to work properly.
[12:23]  * minghua admits ignorance about REVU.
[12:31] <awen_> persia: if the libapache module have never been made apache2 ready, how do i then request a removal?
[12:33] <persia> awen_: You'd file a removal bug, with an explanation of why the package is useless, and references to anything that replaces or supercedes the package, and pointers to some of the unresolvable bugs in the package, and push it to the archive admins.  If you aren't a member of ~ubuntu-dev, you should subscribe ubuntu-main-sponsors or ubuntu-universe-sponsors to get confirmation and the sponsor will forward it to the archive admins.  You can check w
[12:57]  * jonnymind is away: Sono occupato
[13:00] <persia> awen_: Feel free to retitle/redescribe the UNMETDEPS bug (if it exists) when making a removal request.  This reduces bug volume, which is good, and makes sure older bugs fixed get closed, which is good, and notifies interested subscribers as to how it is being fixed, which is good.
[13:01] <awen_> persia: too late ... but i'll remember that, when filing the next one
[13:01] <persia> awen_: No worries.  Only took me a couple extra minutes, but next time would be appreciated :)
[13:02] <awen_> persia: it's noted :)
[13:21] <\sh> guys, when I prepare a new wine package...could someone be so nice and upload it?
[13:23] <white> to debian?
[13:23] <\sh> to ubuntu ;) I think debian uses a totally different packaging :)
[13:23] <joejaxx> :P
[13:23] <white> \sh: well i basically want to use wine from time to time to get stuff running, so make it happen ;)
[13:23] <white> :P
[13:23] <joejaxx> lol
[13:24] <joejaxx> \sh: you are not motu?
[13:24] <\sh> joejaxx, not anymore, yeah
[13:24] <joejaxx> oh
[13:24] <white> \sh: why not, if i may ask?
[13:25] <white> or is that a bad topic?
[13:26] <\sh> white, bad topic...I don't want to boil it up again...there are a lot of stuff on the web because of this...
[13:26] <white> ok
[13:28] <persia> \sh: Stuff it in the sponsors queue.  It might be too big for me to build, but that's the best way to get it uploaded.
[13:29] <\sh> persia, I'll make sure that's building on both main archs...
[13:29] <\sh> we are already far behind the normal releases...
[13:30] <persia> bluekuja: Please unsubscribe when rejecting.
[13:31] <bluekuja> persia, are you talking about the rocklight bug?
[13:31] <persia> bluekuja: Yep.
[13:31] <bluekuja> persia, yea, oki
[13:31] <persia> Also, I wasn't sure about Recommends: xmms vs Recommends: xmms-dev.
[13:31] <persia> Supremus: Any insights as to which would be correct?
[13:31] <bluekuja> persia, same here. It's what I just asked to him
[13:31] <persia> (and why)
[13:31] <bluekuja> in pm
[13:32]  * persia likes to ask in-channel so we can all see, and so other interested parties can share their insights
[13:32] <bluekuja> persia, agreed, Supremus: any idea?
[13:33] <Supremus> persia, i think xmms-dev
[13:34] <bluekuja> persia, Supremus doesn't understand english a lot..
[13:34] <persia> Why?
[13:34] <bluekuja> so he prefer to talk to me in italian
[13:34] <persia> bluekuja: Understood.  If you want to sort it in italian, go ahead, but please share the results
[13:34] <Supremus> sorry...
[13:34] <Hobbsee> heh.  in itallian won't help most others anyway
[13:35] <bluekuja> heya Hobbsee!
[13:35] <persia> Right.  Italian would be off-channel, with summary posted before/after :)
[13:35] <bluekuja> Supremus, why should we move to xmms-dev?
[13:35] <bluekuja> instead of xmms?
[13:36] <Hobbsee> hey bluekuja!
[13:36] <bluekuja> persia, actually I don't know if Daniel posted xmms by error or by purpose
[13:37] <bluekuja> Hobbsee, :)
[13:37] <bluekuja> persia, the link posted in the report talks about xmms-dev
[13:38] <Supremus> persia, in this link http://rimron.co.uk/weblog/2006/02/01/rocklight-rocking-your-thinkpad/ speak about xmms-dev
[13:38]  * persia is reading, skeptically
[13:39] <persia> That only talks about building rocklight "Building rocklight requires you have the xmms-dev package installed".  It shouldn't be required to run it.  On the other hand, rocklight is fairly pointless without xmms installed, so it should Depends; or Recommends: on xmms.
[13:41] <bluekuja> persia, a comment says ". I didn’t have xmms-dev installed. How did you figure out it needed that?"
[13:41] <bluekuja> persia, plus it says "runs indepently from xmms."
[13:42] <bluekuja> persia, so we don't need a recommend on xmms, in my opinion
[13:42] <DarkSun88> Hi MOTUs
[13:42] <persia> bluekuja: Yes.  It runs separately from xmms.  I suspect the comment is about building it.  Maybe Suggests: xmms ?
[13:42] <bluekuja> persia, yeah
[13:42] <\sh> I thought we wanted to get rid of xmms
[13:42] <persia> \sh: We do.
[13:43] <bluekuja> persia, so you would suggest a recommend on xmms-dev and a suggests on xmms
[13:43] <bluekuja> persia, that's the final summary?
[13:44] <persia> bluekuja: Yes, but Supremus has been working with the code, so I'd trust an informed answer over my brief thoughts.  I just wanted an explanation to "why xmms-dev?".
[13:44] <\sh> persia, so xmms-dev is pointing to what nowadays?
[13:44] <persia> \sh: xmms-dev.  We only got it demoted to universe for gutsy.  Removal is likely not until hardy+1.
[13:45] <bluekuja> persia, yeah, let's wait his response then
[13:46] <\sh> persia, thx :)
[13:46] <bluekuja> persia, but reading upstream-only, I would move to a recommends on xmms-dev, but we'll see what to do
[13:46] <bluekuja> if Supremus would mind to explain us "why?"
[13:46] <persia> bluekuja: What is written that makes you think that?
[13:47] <bluekuja> persia, just the intro, I quoted you before
[13:47] <bluekuja> persia, "runs indepently from xmms."
[13:47] <bluekuja> persia, it's not merely focused to its build
[13:47] <\sh> brb
[13:47] <bluekuja> persia, but to the program itself
[13:48] <Supremus> why the documet speaks about xmms-dev not xmms
[13:48] <bluekuja> persia, but, of course, I might be wrong here
[13:48] <persia> bluekuja: Right.  That defends "Suggests".  I just don't understand why xmms-dev vs. xmms.  I'd think xmms would always be sufficient, or there would be a different bug in xmms-dev that it contained something useful for non-developers.
[13:49] <persia> Supremus: I don't know that :)  Does anything in the code depend on anything only provided by xmms-dev to run (not build, just run)?
[13:49] <bluekuja> persia, yep, let's hear Supremus about the code then
[13:49] <bluekuja> brb
[13:52] <Supremus> persia, I don't know...
[13:53] <persia> Supremus: That's what I thought :)  Could you please investigate?  I think there might be a bug in rocklight, but I don't think we should upload a change just because somebody blogged about it.
[13:53] <\sh> re...installing hardy a2 in vbox ;)
[13:54] <Supremus> persia, ok i search info
[13:54] <persia> Supremus: Thank you.
[13:55] <bluekuja> persia, adding a comment
[13:55] <bluekuja> about that and making it incomplete for now
[13:56] <persia> OK.  I already unsubscribed.  Given that Supremus is currently searching info, I suggest "In Progress" as more indicative of the real status.
[13:56] <bluekuja> agreed, commenting
[13:56] <Supremus> persia, done
[13:57] <persia> Supremus: Excellent.  What did you discover?
[13:59] <Supremus> no..
[13:59] <Supremus> persia, I have change the status... :D
[14:00] <persia> Supremus: My apologies then :)
[14:01] <DktrKranz> persia, during these days, I had a little time to test wxwidgets2.8 dfiloni prepared. I didn't notice any issues and it seems functional.
[14:02] <bluekuja> DktrKranz, why don't we wait Debian for it?
[14:02] <dfiloni> persia: do you think that is better to wait debian?
[14:02] <persia> bluekuja: Because Debian hasn't for the past 3 Ubuntu releases :)
[14:02] <persia> DktrKranz: Great.  Works for me as well.  Let's get it in.
[14:02] <bluekuja> persia, yes, but there seems to be some new movements now
[14:02] <bluekuja> persia, and I wouldn't diverge the two packages
[14:02] <DktrKranz> bluekuja, Debian guys seems really motivated now
[14:02] <persia> bluekuja: Yes, but it's past DIF, so I don't care as much.
[14:03] <bluekuja> DktrKranz, yep
[14:03] <DktrKranz> but persia is right, that package did not receive attention for more than a year
[14:03] <persia> dfiloni: Did you get in touch with Vadim?
[14:03] <dfiloni> persia: no...
[14:03] <bluekuja> persia, anyway I don't support the idea of uploading it
[14:03] <persia> dfiloni: Would you?  bluekuja has a very good point that we want to share the same package if possible, and Vadim is upstream, and very easy to work with.
[14:04] <persia> bluekuja: It closes heaps and heaps of bugs.
[14:04] <bluekuja> persia, what about sending a comment about dfiloni's package to debian?
[14:04] <dfiloni> persia: from now to a month I don't have much time...
[14:04] <bluekuja> persia, maybe we won't duplicate work
[14:04] <dfiloni> persia: debian can't use my package?
[14:05] <persia> bluekuja: Because Ron is special.  Better to work with upstream, who may be taking over in Debian anyway, if I read the debian lists correctly.
[14:05] <bluekuja> dfiloni, you should have posted your intention to package it to debian's ML while ago..
[14:05] <bluekuja> persia, yeah, agreed
[14:05] <persia> dfiloni: As long as you're not in touch with Vadim, Debian likely won't use your package.
[14:05] <persia> dfiloni: If you get in touch, Debian will very likely use your package, with the version changed.
[14:05] <DktrKranz> persia, if I read it correctly, upstream is going to maintain new releases, isn't it?
[14:05] <dfiloni> bluekuja: I don't read often debian-devel
[14:06] <persia> DktrKranz: That's the current workaround.
[14:06] <bluekuja> dfiloni, you should definitely...
[14:06] <dfiloni> bluekuja: yes, I know
[14:06] <persia> dfiloni: In this case, where you're working on a package that is being discussed on debian-devel, it's definitely worth it :)
[14:07] <persia> bluekuja: With regards to ITP, wxwidgets2.8 has long been in Ubuntu.  I think it's not a mistake to not report an update plan there.
[14:07] <DktrKranz> wxwidgets has to clear NEW queue in Debian, IIRC
[14:08] <DktrKranz> *wxwidgets2.8
[14:08] <bluekuja> persia, is there an ITP as well?
[14:08] <DktrKranz> it is not available in their archives
[14:08] <persia> DktrKranz: Right.  Last I knew, Vadim's version still had lintian issues.  dfiloni's doesn't.
[14:08] <bluekuja> persia, in Debian
[14:08] <bluekuja> persia, or a wishlist
[14:09] <bluekuja> dfiloni, you should try to contact upstream then as persia suggested
[14:09] <dfiloni> persia: but I'm only learning, I think that I can't help Vadim. I am a newbie
[14:09] <bluekuja> and then report back here
[14:09] <persia> bluekuja: I don't think Matthias filed one.  I conversed with Ron about an update in May, but we didn't get anywhere.  Ron believes 3.0 will be out before lenny, and didn't see the point of 2.8 in the meantime at that point.
[14:09] <bluekuja> ah, that's why the delay is becoming huge
[14:09] <bluekuja> persia, what do you think about that?
[14:10] <persia> dfiloni: You can definitely help.  You have done very good work with that package, and Vadim is busy upstream.  If you help with the packaging, Vadim can focus on bugfixing, and we all get a better package.
[14:10] <bluekuja> persia, should we wait 3.0 or package 2.8 as well?
[14:10] <DktrKranz> so, Ron considered it a "transitional version" ?
[14:10] <persia> bluekuja: We have an outdated and buggy 2.8.  I want dfiloni's updates, but haven't gotten around to adjusting my workstation to build them (or I would have uploaded 2 weeks ago).
[14:11] <persia> DktrKranz: At that time.  I don't know his current thoughts.
[14:11] <bluekuja> persia, well, as far as DktrKranz tested it out
[14:11] <bluekuja> persia, it should be ready for inclusion..
[14:11] <persia> bluekuja: pochu also did some testing, and I (with a local build: not a suitable build test).
[14:11] <bluekuja> persia, the point is: should we wait debian?
[14:11] <DktrKranz> Yes, I did some tests, but I'n not sure to have been that accurate
[14:12] <persia> bluekuja: I don't think so.  Debian will likely get 2.8.7.1 or later anyway, and this is 2.8.6.1, so I don't think there is anything to gain by waiting.
[14:12] <persia> bug #133888 for those not following :)
[14:12] <ubotu> Launchpad bug 133888 in wxwidgets2.8 "upgrade wxwidgets2.8 to the 2.8.6.1 release" [Wishlist,Confirmed] https://launchpad.net/bugs/133888
[14:13] <bluekuja> k, if all the developers, who tested dfiloni's packages out, are comfortable with it
[14:13] <bluekuja> why not pushing it?
[14:13] <bluekuja> ;)
[14:13]  * bluekuja didn't have the time to build/test it
[14:13] <bluekuja> so DktrKranz/pochu should report their thoughts now
[14:13] <persia> bluekuja: I can't do a clean build.  pochu isn't ~ubuntu-dev.  Dktrkranz wanted confirmation before uploading.
[14:13] <dfiloni> persia, bluekuja: I think the package is needed now, because filezilla requires it etc...
[14:14]  * jonnymind is away: Sono occupato
[14:14] <DktrKranz> This is the best period, nobody will notice its upload and we have plenty of time to find a hideout to bury ourselves...
[14:14] <persia> Exactly :)
[14:14] <bluekuja> persia, oki, so let's wait another confirmation then
[14:15] <persia> bluekuja: Whose?  Why?
[14:15] <bluekuja> persia, you told me DktrKranz wanted another confirmation
[14:15] <bluekuja> so I thought he's not comfortable with it enough
[14:15] <persia> bluekuja: DktrKranz: persia, during these days, I had a little time to test wxwidgets2.8 dfiloni prepared. I didn't notice any issues and it seems functional.
[14:15] <bluekuja> but if he does, why not
[14:16] <persia> bluekuja: (23:02:35) persia: DktrKranz: Great.  Works for me as well.  Let's get it in.
[14:16] <dfiloni> persia: DktrKranz said " Yes, I did some tests, but I'n not sure to have been that accurate"
[14:16] <persia> dfiloni: Do you not want it uploaded?
[14:17] <dfiloni> persia: I want the package uploaded but if is certainly good
[14:17] <bluekuja> persia, is the packaging-side correct>?
[14:17] <persia> dfiloni: If it worked in your tests (maybe not complete), and pochu's tests (maybe not complete), and Dktrkranz's tests (maybe not complete), and my tests (maybe not complete), should we not get more testing by putting it in hardy?
[14:17] <DktrKranz> at least, we didn't forget anything from the past
[14:18] <persia> bluekuja: Looks clean to me.  Still some minor issues, but a huge improvement in packaging over the current version in the archive.
[14:18] <dfiloni> persia: I don't know
[14:18] <bluekuja> persia, ok, there seems to be some lintian warnings but we can ignore them
[14:19] <bluekuja> persia, e.g images in a non-canonical directory
[14:19] <persia> bluekuja: Take a look at the list from the current package :)  The new one is better (and yes, not perfect yet).
[14:19] <DktrKranz> persia, probably it's not that harm to upload it, especially if we manage to resync with Debian soon (probably after getting a UVFe)
[14:19] <persia> DktrKranz: No need for UVFe.  I suspect Debian will get something in before mid-February.
[14:19] <DktrKranz> simply GREAT!
[14:19] <bluekuja> persia, yes, agreed then
[14:19] <persia> dfiloni: Please do share your work with Vadim so as to improve the package for Debian as well.
[14:20] <bluekuja> persia, let's move on then
[14:20] <bluekuja> dfiloni, ^^
[14:20] <bluekuja> DktrKranz, ^^
[14:20] <persia> DktrKranz: Please upload.
[14:21] <persia> bluekuja: Agreed.
[14:21] <dfiloni> persia: ok
[14:21] <bluekuja> dfiloni, and congrats for the nice work on it
[14:21] <bluekuja> dfiloni, that package is definitely a huge and hard one
[14:22] <DktrKranz> dfiloni, bluekuja, persia. I'll do a test upload on my PPA to see how it behaves first
[14:22] <persia> dfiloni: That's one of the most annoying and complex packages.  Please realise that your ability to improve it indicates quite a bit of knowledge about packaging.  You should be confident about your work when it is this good :)
[14:22] <bluekuja> oki
[14:22] <dfiloni> bluekuja: it's for you help and for DktrKranz help that the package now is great
[14:22] <bluekuja> dfiloni, glad to help, you know
[14:23] <dfiloni> persia: ok, thanks
[14:23] <DktrKranz> bluekuja, "huge and hard" one is not appropriate. I think the best word is "f*cking"
[14:23] <bluekuja> lol
[14:23] <dfiloni> DktrKranz: lol
[14:23] <bluekuja> looks fine as well
[14:23]  * persia notes the CC, but believes superlatives apply (except maybe for iced-tea, or OOo, which are similar beasts)
[14:24] <persia> s/CC/CoC/
[14:24]  * DktrKranz obtained a CoC exception earlier
[14:24] <persia> heh
[14:34] <DktrKranz> wxwidgets2.8 is the first package by dfiloni, I'm scared when I think when he will move to something more complex...
[14:35] <dfiloni> DktrKranz: wxwidgets2.8 is more complex than wxwidgets2.8
[14:35]  * DktrKranz hides
[14:37] <StevenK> wxwidgets2.8 == wxwidgets2.8
[14:37] <StevenK> How can it be more complex than itself?
[14:37] <persia> StevenK: Only for some values of wxwidgets2.8.  Take a look at the package history :)
[14:38] <dfiloni> StevenK: the new upstream version is more complex than the previous because contains a new editor, Editra. Lintian shows me a lot of new warnings/error
[14:38] <dfiloni> s
[14:38] <persia> For instance, it became a lot more complex when wxwidgets2.6 started to depend on parts of wxwidgets2.8
[14:38] <StevenK> I see.
[14:38] <StevenK> Don't make me run screaming.
[14:38] <persia> StevenK: As long as you never get involved with WX, you can safely keep the portion of your brain that must otherwise be excised.
[14:39]  * StevenK chuckles.
[14:39] <StevenK> persia: And how did your frontal lobotomy go?
[14:39] <persia> Aside from a compulsive need to check to be sure that things were actually completed after completing them, I find that it wasn't really required.
[14:41]  * persia notes that repeated traumatic levels of stress are indistinguishable from frontal lobe damage by current clinical tools, excepting when the damage shows in a MRI or ultrasound investigation.
[14:46] <DktrKranz> dfiloni, have you a local copy of wxwidgets? REVU is down...
[14:46] <DktrKranz> mine is lost somewhere I can't remember
[14:46] <dfiloni> DktrKranz: no, I'm sorry
[14:46] <persia> DktrKranz: There's a diff in the bug.
[14:47] <persia> effie_jayx: Why would I want to sync peercast?  The sync package doesn't appear to have any improvements over the current Ubuntu package.
[14:54] <dfiloni> persia: why wxwidgets2.8 bug is also in Baltix?
[14:55] <persia> dfiloni: Balix is first in the "also-affects" list and gets a lot of extra bugs.  Most bugs in Ubuntu also apply in Baltix.  Baltix is a strange leftover from on older method of handling derivatives: the current practice it to try to share releases.  Baltix will likely inherit your package to fix it.
[14:56] <dfiloni> persia: ok
[14:56] <dfiloni> persia: thanks
[15:22]  * pochu hugs dfiloni, persia, DktrKranz and bluekuja :-)
[15:23] <DktrKranz> pochu, what do you do for christmas? I fear we'll have to escape soon
[15:23]  * bluekuja hugs pochu too
[15:24] <pochu> dfiloni: btw, if you don't want to maintain / take a look at wx2.8 in Debian, that's fine. But still, sending the package to them is a good idea. So they can take it if they want. They will surely appreciate it.
[15:24] <pochu> DktrKranz: I'm staying here at Murcia (Spain).
[15:24] <dfiloni> pochu: I'm wrinting the email whit a perfect english :D
[15:25] <DktrKranz> pochu, we should really keep in touch with them, we should sync wxwidgets as far as possible
[15:25] <DktrKranz> pochu, I'm going to north pole after pushing wxwidgets :)
[15:27] <dfiloni> pochu: I'm writing email to Vadim to inform him about my package
[15:27] <pochu> dfiloni: Great, you ROCK! :-)
[15:28]  * bluekuja applauds dfiloni 
[15:28] <persia> dfiloni: Excellent :)  Thanks for stepping up.
[15:28] <pochu> DktrKranz: woha, make photos for us!
[15:28] <pochu> DktrKranz: and agreed, it would be great if we could simply have the same package and work in Debian when necessary.
[15:29] <bluekuja> I'm leaving, have a great a weekend everyone and have fun this evening/night!
[15:29] <DktrKranz> or at least have minimal deltas
[15:29] <pochu> you too
[15:29] <bluekuja> ty, cya *
[15:38] <Supremus> norsetto, hi!
[15:38] <norsetto> Supremus: hi
[15:52] <bddebian> Heya gang
[15:52] <norsetto> boh!
[15:55] <bddebian> Heh, hi norsetto
[15:55] <norsetto> bddebian: hi there
[15:56] <pochu> bddebian: don't change your nick! ;-)
[15:57] <bddebian> Heh, hi pochu
[15:58] <\sh> hey bddebian
[15:58] <bddebian> Hi \sh
[16:00] <joejaxx> hello bddebian
[16:00] <joejaxx> pochu: what would he change it too :P
[16:02] <\sh> bddebian is now know as TheFlash ,-)
[16:02] <pochu> bddebian: you could be bddebian on Freenode and bdubuntu on OFTC :-P
[16:02] <bddebian> Heya joejaxx
[16:02] <bddebian> \sh:  :)
[16:03] <bddebian> pochu: I tried that, that didn't go over too well either ;-P
[16:03] <\sh> what about \bdf ,-)
[16:03] <pochu> heh
[16:03] <\sh> it's hip, it's cool and it's true ,-)
[16:04] <\sh> and sounds a bit like a digitized copy of a book ,-)
[16:04] <bddebian> How about \bfd? ;-P
[16:04] <\sh> bfd like BeForeDying?
[16:05] <bddebian> No, like Big F**ing Deal :)
[16:05] <\sh> bddebian, no then \bdf...big ducking fool ,-)
[16:06] <bddebian> hah, you got the fool part right :)
[16:07] <\sh> bddebian, You are just promoted...to wine upload dude of the year 2007 ,-)
[16:10] <bddebian> hah
[16:10] <\sh> bddebian, just waiting for the i386 and the amd64 test build on this little system here
[16:12]  * \sh goes and grab one of the old servers to setup ubuntu server on it
[18:16] <\sh> hmmm..if someone wants compile a package for let's say dapper via PPA...the distro tag in changelog needs to be set to dapper, right?
[18:17] <pochu> \sh: yup
[18:17] <Ubulette> shouldn't libboost be all in main ? it's half in universe atm
[18:18] <\sh> pochu, cool :)
[18:44] <awen_> persia: ping
[18:46]  * jonnymind is away: dinner
[18:52] <imbrandon> \sh: or upload it to ~ubuntu/dapper vs ~ubuntu on the ppa and it will build it for dapper no matter what the distro tag says
[18:53] <\sh> imbrandon, yeah, I wanted to test wine backports somehow...so I wanted to use ppas
[18:55] <imbrandon> \sh: yea just use something like ...
[18:55] <imbrandon> [ppa-dapper]
[18:55] <imbrandon> fqdn = ppa.launchpad.net
[18:55] <imbrandon> method = ftp
[18:55] <imbrandon> incoming = ~imbrandon/ubuntu/dapper
[18:55] <imbrandon> login = anonymous
[18:55] <imbrandon> allow_unsigned_uploads = 0
[18:55] <imbrandon> in your dput.cf
[18:55] <imbrandon> obviously changing the username
[18:55] <\sh> imbrandon, hehe..sure
[18:55] <imbrandon> should work for all supported releases
[19:03] <blueyed> Who sponsors uploads to restricted? u-m-s?
[19:12] <pochu> Yep
[19:12] <blueyed> Great. Someone should update https://edge.launchpad.net/~ubuntu-main-sponsors then..
[19:34] <\sh> somehow virtualbox on emt64 trying to install an i386 distro doesn't work :(
[19:50] <txwikinger> who makes th decision to deprecate a package.. or to replace it with a transitional package to point to a different package?
[20:18] <DarkSun88> Hi all
[20:19] <DarkSun88> Any Motu here? I need a check of my patch.
[20:25] <Cytrox> hey all
[20:25] <Cytrox> can anyone here tell me how to get Ubuntu installed on a virtual os?
[20:25] <Cytrox> or virtual HD
[20:25] <Cytrox> soz
[20:29] <txwikinger> !support | Cytrox
[20:29] <ubotu> Cytrox: the official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org
[20:30] <Cytrox> tnx
[21:24] <CyberMatt> https://bugs.edge.launchpad.net/ubuntu/+bug/178165
[21:24] <ubotu> Launchpad bug 178165 in ubuntu "Sync Request inspircd" [Undecided,New]
[21:25] <CyberMatt> tell me i did that right
[21:38] <cbx33> hey hey peeps
[21:41] <joejaxx> hello cbx33
[21:42] <cbx33> hi joejaxx
[21:59] <DarkSun88> http://packages.linuxdc.it/hardy/result/gap_4r4p10-1ubuntu1/gap_4r4p10-1ubuntu1_i386.build
[21:59] <DarkSun88> Any MOTU that can explain me the problem?
[22:00] <\sh> DarkSun88, yepp
[22:00] <DarkSun88> Thanks Stephan :)
[22:00] <\sh> makefile doesn't know anything about DESTDIR foo :)
[22:01] <\sh> looks like that there some install calls which need to know about DESTDIR, or whatever it needs to install those files into the correct location
[22:01] <DarkSun88> Ok.
[22:01] <DarkSun88> Looking..
[22:01] <\sh>  /usr/share/... is not writable for the pbuilder or buildd user in a clean chroot :)
[22:02] <\sh> or it's just missing a make DESTDIR=<whatever> install
[22:02] <DarkSun88> SHELL=/bin/bash
[22:02] <DarkSun88> pkgdocdir=/usr/share/gap/doc
[22:02] <DarkSun88> This is the path in Makefile
[22:03] <\sh> yeah...look at the install target
[22:03] <DarkSun88> 	install -d $(DESTDIR)$(pkgdocdir)/{ref,tut,prg,ext,new}
[22:03] <DarkSun88> This.
[22:03] <\sh>  yepp
[22:04] <\sh> is it in the debian/rules file or in upstream makefile?
[22:04] <DarkSun88> Checking..one moment.
[22:05] <DarkSun88> That path has been included in Makefile upstram.
[22:05] <DarkSun88> upstream*
[22:05] <\sh> oc/Makefile:   install -d $(DESTDIR)$(pkgdocdir)/{ref,tut,prg,ext,new}
[22:05] <\sh> doc/Makefile:   install -o root -g root -m 0644 fullindex.{dvi.gz,pdf} $(DESTDIR
[22:05] <DarkSun88> Right.
[22:05] <\sh> ebian/rules:   $(MAKE) -C doc install "DESTDIR=../debian/gap-doc"
[22:05] <\sh> debian/rules:   $(MAKE) -C debian/doc install "DESTDIR=../gap-doc"
[22:05] <\sh> that's the important call
[22:06] <\sh> DarkSun88, try to change it to this syntax:
[22:06] <\sh> $(MAKE) -C doc install DESTDIR=$(CURDIR)/debian/gap-doc
[22:06] <\sh> the ".." is not always a good idea
[22:06] <DarkSun88> Ok.
[22:07] <\sh> both of them....
[22:08] <DarkSun88> 	$(MAKE) -C doc install DESTDIR=$(CURDIR)/debian/gap-doc
[22:08] <DarkSun88> 	$(MAKE) -C debian/doc install DESTDIR=$(CURDIR)/debian/gap-doc
[22:08] <DarkSun88> Right?
[22:09] <\sh> DarkSun88, yepp:)
[22:09] <DarkSun88> This change I have to do only in debian/rules?
[22:10] <DarkSun88> have I*
[22:10] <\sh> DarkSun88, jepp :)
[22:10] <DarkSun88> Ok, thanks.
[22:10]  * DarkSun88 builds all
[22:47] <cyberix> Revu is offline because it is x-mas?
[22:48] <\sh> nope...because revu admin is ill, and is staying at home, and after all it's x-mas
[22:49] <jpatrick> cyberix: well, most people are out on holidays (taking a break from revuing your packages) ;)
[23:03] <cyberix> :-(
[23:03] <cyberix> :-)