=== StevenK_ is now known as StevenK
[00:17] <pochu> persia: thanks for the feedback! Much appreciated. :-)
[00:17]  * pochu heads to bed. Night all!
[00:17] <ion_> Nyghte
[00:30] <alvinc> Question:  Who works on the partner programs?
[00:30] <alvinc> Meaning, what is contact info for the folks who are trying to get other companies to partner with Ubuntu/Canonical?
[00:33] <persia> alvinc: https://launchpad.net/ubuntu says it's https://launchpad.net/~canonical-partner-dev but that's the developers: may not be the interface people.
[00:39] <alvinc> persia:  thanks
[00:39] <alvinc> I'm kind of heartbroken right now
[00:39] <alvinc> My company was deciding a distro strategy in a meeting an hour ago
[00:39] <alvinc> I very strongly urged to go with Ubuntu
[00:40] <alvinc> The rest of the team decided on CentOS
[00:40] <alvinc> I'm taking it pretty hard.  :(
[00:44] <zul> alvinc: canonical is pretty much closed down for the holiday break
[00:45] <alvinc> zul:  thanks.  good to know.
[00:46] <alvinc> Question:  Are any of you other folks systems administrators?
[00:50]  * Hobbsee waves
[00:50]  * ion_ integrates the wave
=== LongPoin1yStick is now known as LongPointyStick
[00:58] <zul> alvinc: by day
[00:58] <zul> hey Hobbsee
[00:59] <Hobbsee> hiya zul
[01:00] <zul> how goes it?
[01:00] <Hobbsee> it goes, ish.
[01:00] <imbrandon> alvinc: yes , thats what i do by day
[01:01] <zul> hey imbrandon
[01:01]  * persia is suspicious of imbrandon's claim of "by day"
[01:02] <zul> persia: imbrandon is more like a mole he doesnt like the daylight so go figure
[01:02] <imbrandon> heh well actualy by day and night ( ubuntuwire too )
[01:02] <persia> zul: True :)
[01:02] <imbrandon> heya zul and persia
[01:38] <crimsun> I suppose I should fix configure.ac to accept TLS or SSL as parameters instead of hard-coding TLS.  Hmph.
[01:48] <pwnguin> i wish the lp users mailing list didnt get so much translations traffic
[01:48] <pwnguin> the only language i speak is C
[01:49] <Hobbsee> pwnguin: i've long been wishign for that
[01:49] <Hobbsee> pwnguin: but it appears they wanted to keep it as one list - they had a separate translation list for a while
[01:50] <Hobbsee> persia: nice comment, btw.
[01:52] <pwnguin> i suppose i could unsubscribe
[01:52] <pwnguin> since ppas are out of beta
[02:02]  * persia wonders why rhythmbox keeps launching without a request
=== n3xu is now known as nexu
=== stdin_ is now known as stdin
[02:28] <pwnguin> persia: keyboard keybinding spuriously hit?
[02:30] <persia> Maybe.  I didn't think I had a keybinding, and it usually happens when I'm typing in a command shell or in IRC.  Maybe I mistakenly set a keybinding.  Thanks for the pointer.
[02:52] <bddebian> Heya gang
[02:53] <bddebian> persia: You around?
[02:53] <persia> bddebian: Hi.
[02:53] <bddebian> persia: Hi.  OK, I got it to build with wx2.6 but, of course, it segfaults :-(
[02:54] <persia> ctsim?
[02:54] <bddebian> Sorry, jugglemaster
[02:54] <persia> bddebian: Got a stacktrace with dbgsym?
[02:55] <bddebian> Debug? What is that? :-)
[02:56] <persia> bddebian: Install pkg-create-dbgsym in your build environment.  This will generate -dbgsym packages.  You should be able to use this with the stacktrace to get a symbolic info.
[03:08] <persia> bddebian: I can't find a proper reference, but https://wiki.ubuntu.com/AutomatedProblemReports is the spec about generating the -dbgsym packages, and https://wiki.ubuntu.com/DebuggingProgramCrash talks about how to use them if you have them.
[03:09] <bddebian> persia: Don't I have to add a debug package flag in rules or some such?
[03:09] <persia> bddebian: Nope.  The pkg-create-dbgsym package puts a wrapper around dh_strip to generate the debugging symbols in a nice handy package for separate management.
[03:10] <bddebian> Hrm
[03:11] <minghua> Hope you package doesn't strip symbols before dh_strip is run. :-P
[03:12] <persia> minghua: Does anyone do that?  That would be annoying, and would be a valid variance in Ubuntu.
[03:12] <bddebian> Hmm, debian doesn't seem to have that :-(
[03:13] <persia> bddebian: Hrm.  Tricky there.  Maybe test in Ubuntu, and when it doesn't segfauly, feed back to Debian?
[03:13] <bddebian> Heh
[03:13] <minghua> persia: I think I've seen such packages.  Can't remember what it was though.
=== dmb_ is now known as dmb
[03:32] <Forbr4d3> hello
[03:45] <imbrandon> some kde packages used to do that, but i think most are fixed now
[03:45] <imbrandon> persia minghua ^^
[03:47] <persia> imbrandon: Most being fixed is good :)
[03:53] <pwnguin> imbrandon: when was that event you had planned?
[04:40] <imbrandon> pwnguin: hrm not really sure yet
=== tritium_ is now known as tritium
[05:05] <minghua> Hmm, so the libstdc++6 installation problem that plagued buildds affects normal systems as well?
[05:06] <persia> minghua: Some specific systems.  Use aptitude :)
[05:07] <minghua> Nice.  I just abandoned the custom of using aptitude on Debian systems...
[05:07] <minghua> persia: Thanks.
[05:07] <blueyed_> imbrandon: why have you removed the "Packages in Universe/Multiverse" block from https://wiki.ubuntu.com/StableReleaseUpdates? Is there no special procedure (apart from the few inline differences) for universe anymore?
[05:07] <persia> minghua: To what did you switch?
[05:07] <persia> blueyed_: That would be correct.
[05:07] <blueyed_> Especially: do we not send an email to the ubuntu-motu ml anymore?
[05:07] <minghua> update-manager and synaptic, which are the recommended tool, aren't they?
[05:08] <blueyed_> also the verification-motu-(done|needed) tags are gone?
[05:08] <persia> blueyed_: Right.  This is now handled by the ~motu-sru team.  On the other hand, there might be a useful place for ~universe-sru-verification.
=== blueyed_ is now known as blueyed
[05:09] <minghua> persia: Nah.  Aptitude doesn't work either.
[05:09] <minghua> "E: Internal Error, Could not perform immediate configuration (2) on libstdc++6
[05:09] <minghua> A package failed to install.  Trying to recover:
[05:09] <persia> minghua: Odd.  Worked for me.
[05:10] <blueyed> persia: so I would subscribe universe-sru-verification?
[05:10] <persia> blueyed: That team doesn't actually exist.  Which bug?  At what point are you in the process?
[05:11] <minghua> persia: What arch is your system, i386 or amd64?  Also what is your highest libstdc++6 version?
[05:11] <blueyed> persia: bug 127325 - it waits quite long for verification already and I've noticed that I've missed to send the email then.
[05:11] <ubotu> Launchpad bug 127325 in libphp-phplot "No graphs after upgrade to Feisty" [Medium,Fix committed] https://launchpad.net/bugs/127325
[05:11] <persia> minghua: amd64 + 4.2.2-4ubuntu3.  I had each of 4.2.2-4ubuntu2 and 4.2.2-4ubuntu1 for a while.
[05:12] <minghua> persia: I have 4.2.2-4ubuntu3 as well, currently installed is -4ubuntu2.  It's i386 though.
[05:13] <persia> minghua: Interesting.  When I was looking at a broken buildd chroot and could reproduce, it was with i386.
[05:14] <minghua> Now aptitude segfault for me, wonderful...
[05:14] <persia> segfault!  Please post a backtrace.
[05:15] <minghua> ... and apport says "the crash report is damaged and can't be processed"...
=== bigon is now known as bigon`
[05:16] <persia> blueyed: It looks like you got caught in the gutsy release madness, and the package was missed.  It would have been appropriate to have sent a testing request in October.  At this point, I recommend subscribing ~motu-sru (the package is in universe).  Further, since the activity level is low, you might ask here if a ~motu-sru member could take a look.
[05:16] <persia> minghua: Can you manually get anything?  Be nice to understand where it broke.
[05:17] <minghua> persia: The aptitude crash, or the upgrade failure?
[05:17] <persia> minghua: The aptitude crash.
[05:17] <minghua> persia: I wouldn't worry about the crash, it happens.
[05:17] <persia> minghua: Yes, crashes happen, but I like to fix them.
[05:17] <minghua> persia: I don't know how to reproduce.  But I generally get an aptitude crash once in one or two weeks.
[05:18] <blueyed> persia: actually it has been approved already (what ~motu-sru would do AFAICS). I'll change the verification-motu-needed tag to verification-needed and subscribe sru-verification instead, correct?
[05:18] <minghua> persia: Just one second...
[05:19] <persia> blueyed: That doesn't sound right, as that's the main verification team.  Best to get input from a member of ~motu-sru.  Maybe you still send an email.  I don't know.
[05:19] <minghua> persia: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352278 looks similar, have (at least) one recent backtrace, in case you are interested. :-)
[05:19] <ubotu> Debian bug 352278 in aptitude "aptitude: crash when marking a package for purge" [Important,Open]
[05:20] <blueyed> persia: Ok. But then the new SRU wiki page is wrong (I'm refering to point 3)
[05:21] <persia> blueyed: Right.  That's why I suggest you want input from a member of ~motu-sru.  I suspect you may have a special case, due to the process change between the upload to -proposed and any test reports.
[05:22] <blueyed> jdong: ^^ What's the process when a universe package is in -proposed already to get it verified?
[05:22] <persia> minghua: There are several backtraces in that bug, for completely different issues, and none of them include the current state of installed packages, and the Packages.gz files from the cache, so it's annoying to hunt them.  Thanks though.
[05:25] <minghua> persia: Yeah.  (I think) I just reproduced the crash, I'm installing -dbg packages now.
[05:27] <minghua> persia: Okay, have a backtrace now.  Want a bug report?
[05:28] <persia> minghua: Just pastebin it.  Either I can see the problem, and it's worth a bug for a patch, or I can't, in which case, a bug wouldn't help :)
[05:31] <minghua> Hmm, pastebin doesn't have syntax highlighting for backtraces. :-P
[05:31] <minghua> persia: http://paste.ubuntu-nl.org/49931/ -- thanks.
[05:36] <persia> minghua: Which package were you tagging?  Looks like an issue with Homepage: parsing.
[05:37] <minghua> It's an "U" action, as mass-upgrade, so it's operating on many packages.
[05:37] <minghua> persia: All three crashes I triggered tonight are mass-operations.
[05:37] <persia> minghua: Hrm.  The crash appears to be in parsing a single package.  I wonder which is the culprit, or if there is a race condition.
[05:39] <minghua> persia: I can give you a list (not very long) if that helps...
[05:39] <persia> minghua: Sure.  If you want to try to upgrade one-by-one to see if any of them cause the issue by themselves, that'd be even better.
[05:39] <minghua> Let me get the list out first...
[05:41] <minghua> persia: http://paste.ubuntu-nl.org/49932/
[05:43] <minghua> persia: Nah, playing with packages on-by-one doesn't seem to trigger the crash.
[05:44] <persia> minghua: Sorry.  I don't understand "Files[Ver.File()->ID]->Jump(Ver);" well enough to be able to figure it out.  Based on your success with single files, I'm guessing it's an issue with an array operator, but don't really understand array operators.
[05:46] <persia> Maybe the mass-file array definition code is funny?
[05:46] <minghua> persia: No need to be sorry.  So... uhh... we'll call it done and forget about it?
[05:46] <persia> minghua: Unless you understand array code, and can tell me what that is trying to do, so I can go find out how to fix it :)
[05:47] <minghua> persia: No, I haven't even _heard_of_ array operators.
[05:48] <persia> minghua: Then nothing to do :)  A bug could be submitted, but for this kind of thing, it's difficult to trace without an affected system to query for issues, and most people don't like to keep affected snapshots around.
[05:50]  * minghua decides it's better to save the effort elsewhere...
[05:53] <minghua> Although on a second thought, I do know about array operators, but no in the C++ context. :-)
[05:53] <minghua> This is off-topic for the issue at hand, of course.
[06:13] <persia> blueyed: Good model for solution.  Thanks for sending the post.
[06:15]  * blueyed is glad to not have missed something obvious then
[06:15] <blueyed> s/have/having/ :)
[06:17] <persia> s/having/have/ :)
[06:17] <blueyed> oh yeah.. :p
=== lucifaint_ is now known as lucifaint
=== luka74 is now known as Lure
=== blueyed_ is now known as blueyed
=== LucidFox is now known as Sikon_DeathNote
=== Sikon_DeathNote is now known as LucidFox
[11:03] <wraund> hey guys its me, just installed xubuntu on my new dual core 64bit machine, slight problem is that i chose to install grub onto hda which the system recognised as my IDE harddrive which contained things i wanted to bring over to my new machine. After a few modifications I havea  working system but the IDE drive now has 'unallocated space' shown in gparted, however i believe htat grub just screw about with the allocation table or fil
[11:07] <minghua> wraund: I agree with your diagnosis, but this doesn't seem to be the right channel.
[11:10] <wraund> minghua: holy heck you are right, sorry irssi split window is to blame
=== \sh_away is now known as \sh
[12:49] <\sh> moins...
[12:49] <\sh> is anyone working on a new upstream version of opensync? ours is still 0.19 and this is really old
[12:50] <kenkku> good afternoon (or more like morning)
[12:50] <DktrKranz> \sh is opensync intended to connect mobile devices?
[12:50] <kenkku> I'm just wondering, where is ${misc:Depends} set or what sets it?
[12:50] <\sh> DktrKranz: yepp
[12:51] <\sh> DktrKranz: used with plugins for syncing mobile devices...like my new N73 from nokia
[12:51] <persia> kenkku: That's documented in the debhelper manpage
[12:52] <DktrKranz> \sh, not aware of any official efforts, but a couple of italian users were intrested and prepared something in the past
[12:52] <kenkku> persia: ok, thanks, I had no idea where to look, except google
[12:52] <\sh> DktrKranz: well, I'll start packaging 0.35 and the needed plugins...testing it on gutsy and hardy...just need to sync ma contacts to this new toy I got yesterday
[12:54] <wraund> im running a 64bit machine ubt need the 32bit libopenal.so.0 file, anyone know where it is?
[12:54] <wraund> cos i cant find on the repo
[12:54] <Lure> \sh: you should probably talk with lifeless: he is debian maitainer and had some reasoning not to go with newer versions
[12:55] <\sh> Lure: k
[12:55] <\sh> lifeless: holiday ping opensync...I need N73 syncing capa for gutsy and hardy ,-) I need >0.19 ,-)
[13:05] <\sh> Lure: I can imagine why he didn't upgrade to latest releases..
[13:05] <\sh> Lure: a change from autofoobar to cmakefoobar
[13:06] <geser> wraund: you can't mix 64bit and 32bit that easy. Why do you need the 32bit version of libopenal?
[13:07] <wraund> geser: Rigsofrods, a driving, boat and plane sim
[13:07] <wraund> i got that fixed now
[13:07] <wraund> i need to get this
[13:07] <wraund> wraund@morpheus:~/RoR-0.33d-linux$ ./RoR
[13:07] <wraund> ./RoR.bin: error while loading shared libraries: libIL.so.1: cannot open shared object file: No such file or directory
[13:07] <wraund> wraund@morpheus:~/RoR-0.33d-linux$
[13:07] <persia> wraund: You really don't want to run the 32bit openal on 64bit: it will segfault, as the MMX instructions enabled in the 32bit binary don't work on x86_64.
[13:10] <wraund> persia: segfault or not i need those libraries
[13:10] <geser> wraund: if this is a 32bit binary you will need all the needed libraries in 32bit (recursive down to libc6)
[13:11] <persia> wraund: It really won't work at all.  I promise.  You'd need to disable the MMX for i386 and make a special binary.
[13:11] <wraund> :/
[13:12] <geser> persia: doesn't amd64 run mmx code with a 32bit chroot?
[13:13] <persia> geser: It breaks in a chroot too.  It needs the 32-bit kernel to keep the processor in emulation mode.  There's a chance it might work under certain conditions if it's not an SMP environment, but it will eventually fail as the number of simultaneous sound sources exceeds a certain value, and the nearest source is at identity.
[13:13] <Lure> \sh: maybe he was waiting for new series (did not want 0.2x series)
[13:15] <Lure> \sh: I am using these packages http://opensync.gforge.punktart.de/repo/
[13:15] <Lure> \sh: 0.2x works for my E60
[13:16] <azeem> \sh: opensync-0.34 is in debian experimental
[13:17] <azeem> I haven't synced it to hardy yet because I didn't have much luck with the plugins
[13:19] <Lure> azeem: yep, 0.3x is pretty incomplete still. you should either use 0.2x or wait for 0.4x
[13:19] <azeem> waiting for 0.4x probably means missing hardy
[13:19] <Lure> azeem: since current 0.19 is not much good anyhow, it my be useful to sync to 0.3x anyhow
[13:20] <azeem> well, I don't want to deal with the flood of "doesn't work" bug reports right now
[13:20] <azeem> I'm going to upload 0.35 to debian experimental over the next few days, if somebody wants to sync it and take care of the bug reports, fine
[13:21] <\sh> azeem: just throw the 0.35 stuff including obex plugins etc. as source in a ppa for gutsy and hardy...I'll test here with N73...which doesn't work somehow with 0.19 on gutsy
[13:23] <\sh> azeem: btw...am I a cmake noob or is CMAKE_INSTALL_PREFIX the same as --prefix in configure or more DESTDIR in make?
[13:26] <Lure> \sh: 0.19 never worked for my nokia, just use 0.2x packages for feisty
[13:28] <\sh> Lure: on gutsy? or should I recompile them?
[13:30] <azeem> \sh: it's the same as --prefix I think
[13:31] <Lure> \sh: fesity packages just worked for me (afair I did not build them myself)
[13:33] <\sh> Lure: well, this guy has now 0.32 in it's repos with strange new soname change...
[13:34] <Lure> \sh: there is still 0.2x repo there
[13:34] <azeem> don't use the 0.3x packages from there
[13:35] <\sh> azeem: I won't
[13:38] <wraund> geser: persia:  sudo apt-get install ia32-libs ia32-libs-gtk linux32 lib32asound2
[13:38] <wraund> doing that on my 64bit system..
[13:38] <wraund> what would the side effects be..
[13:39] <persia> wraund: That works fine.  It doesn't include openal, but everything else should work perfectly.
[13:39] <wraund> persia: ok can you give me a run-down on what linux32 would do
[13:39] <wraund> that the kernel?
[13:40] <geser> wraund: no, linux32 sets only the kernel personality to a 32bit kernel
[13:40] <wraund> cos my intention is to boot into my 64bit kernel and then run the 32bit game which needs the 32libs
[13:40] <wraund> ah..
[13:40] <wraund> i want 64...
[13:40] <persia> wraund: As long as you're not trying to use openal, or have made a special openal, that should work fine.
[13:41] <geser> wraund: linux32 sets it only for to be executed process. Compare "uname -m" and "linux32 uname -m".
[13:42] <wraund> :/
[13:42] <wraund> well the people who make this thing are working on a 64bit version, i am wondering about not running this and just waiting for their version to come out
[13:58] <persia> wraund: Probably better to either help with the port testing or to boot into a 32-bit clean environment.
[14:00] <man-di> who is responsible for http://qa.ubuntuwire.com/multidistrotools/? I would like to get an additional listing there ("all java related packages").
[14:01] <persia> Do you have a filter that would produce those?
=== asac_ is now known as asac
[14:02] <man-di> persia: a good start (but not a complete list) is to search for "Debian Java mantainers"
[14:02]  * persia looks at the filter definitions
[14:02] <man-di> persia: unfortunately not all java packages are from Debian Java mantainers in Debian
[14:03] <persia> man-di: It also drops all the packages that get Ubuntu variations, which makes it perhaps not so useful :(
[14:03] <man-di> the filter could look at XS-Original-Maintainer too
[14:04] <man-di> if that is possible
[14:05] <persia> man-di: The existing definitions are things like "mdt dist-grep-dctrl-sources sid -n -s Package -F Section -e electronics > sid-electronics".  If you can find a good grep-dctrl line, it may well be able to be added.
[14:05] <persia> (I am not the ubutuwire mdt maintainer, but think a patch would be easier to get applied than a open request)
[14:05]  * pochu wants a python filter :)
[14:05] <persia> pochu: Define one :)
[14:05] <pochu> Every python module
[14:06] <pochu> as in Section: python
[14:06] <persia> pochu: section python could work :)
[14:06] <pochu> \o/
=== bigon` is now known as bigon
[14:06] <persia> pochu: Actually, doesn't it miss all the python applications?  I would guess that more than just libraries would be interesting.
[14:07] <pochu> Yes, but it would be harder to get python apps.
[14:08] <pochu> Some of them would be found looking at {XSBC-Original-}Maintainer: Python Applications Packaging Team
[14:08] <pochu> (or in Uploaders)
[14:08] <pochu> but that's only a small part.
[14:09] <wraund> persia: i think i will help with the port testing,
[14:09] <wraund> thanks for all the info persia geser
[14:10] <persia> wraund: No problem.  Thanks for helping.  When the port is out, please bring it back: it would be great to get more good games.
[14:10] <man-di> persia: grep-dctrl filter is simple
[14:11] <wraund> persia: well the next new years version i will hopefully be making a debian binary anyway :)
[14:13] <man-di> persia: grep-dctrl -s Maintainer,XSBC-Original-Maintainer "Debian Java" < /var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_main_binary-amd64_Packages -s Package
[14:13] <man-di> oops
[14:14] <man-di> I meant: grep-dctrl -s Maintainer,XSBC-Original-Maintainer "Debian Java" -s Package < ...
[14:14] <persia> man-di: Excellent :)
[14:16] <man-di> persia: the filter is still wrong
[14:16] <man-di> :-U
[14:16] <man-di> the first -s should be -F
[14:17] <man-di> and you probably want -q too
[14:17] <man-di> aeh
[14:17] <persia> Oops.  Let's hope the forwarded request gets corrected, or the mdt maintainer reads the backscroll carefully.  I suspect it's also more complicated due to being the mdt call rather than normal grep-dctrl.
[14:17] <man-di> I mean -n
[14:17] <man-di> I should really drink some coffee
[14:18] <man-di> persia: thanks for forwarding
[14:20] <persia> man-di: No problem.  Eventually, I'd like that site to be a centralised resource for all our QA needs.  Not necessarily hosting everything, but that it's a single place developers can go for QA stuff, to avoid the confusion we've had before as to whose list is correct.  Note that this would be different than qa.ubuntu.com, which would be more user-focused QA tools, according to the current spec (https://wiki.ubuntu.com/QATeam/Specs/QAWebsite)
[14:22] <man-di> persia: I'm currently setting up http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi for pkg-java on alioth.debian.org for Debian Java maintainers team
[14:22]  * persia notes that https://qa.stgraber.org/ is an excellent set of exceedingly useful resources that is quite distinct from http://qa.ubuntuwire.com/
[14:24] <persia> man-di: That looks quite useful.  Personally, I don't think Ubuntu should be tracking upstream so closely (expect for ubuntu-local or orphaned packages), but it does seem nice for Debian.  On the other hand, how is it better than http://dehs.alioth.debian.org/maintainer.php?maint=pkg-java-maintainers%40lists.alioth.debian.org&Display=Submit+Query, aside from being easier on the eyes?
[14:26] <persia> s/expect/except/
[14:41] <man-di> persia: it tracks SVN, and tells which packages are ready for upload and which ones are work in progress, etc, not only upstream versions
[14:42] <persia> man-di: Ah.  I missed that.  Tracking SVN is much more powerful than only tracking the archive :)
[14:42] <man-di> persia: it tracks SVN, archive and upstream
[14:42] <man-di> so one can easily see status of team packages
[14:43] <persia> Right.  I misunderstood "Repository" when I first looked.  What do the little numbers in parentheses mean?
[14:44] <man-di> that means changes in the SVN repo which are work in progress (using distribribution UNRELEASED)
[14:44] <stgraber> persia: My current plan with qa.ubuntu.com is to move the qa tracker and idea modules from qa.stgraber.org to qa.ubuntu.com an also some of the bugstats we currently have on people.ubuntu.com. I'll add some links to the qa.ubuntuwire.com pages on the main qa.ubuntu.com page (to be reworked)
[14:44] <man-di> that is useful when you have changes in SVN but package is not ready for upload yet
[14:46] <persia> stgraber: That matches my understanding.  I think I'd like just a single link each way, qa.u.c <-> qa.uw.c, so that both the distro QA team and the dev QA team can safely add new pages and features without needing notification.  While some people will use both, I think most people will likely default to one or the other, and they should see the new tools that interest them immediately.
[14:48] <persia> man-di: You've definitely caught my interest.  Are there instructions for setting this up for a team somewhere?
[14:50] <man-di> persia: not really, I just checked that out from pkg-java SVN on altioh. There is a small README
[14:50] <man-di> but its far from simple
[14:50] <man-di> I have this currently running for pkg-java on my local machine
[14:50] <man-di> I want to move my setup to alioth too
[14:51] <persia> man-di: Hmm.  I'll have to go read more alioth docs then :)  Thanks for the pointer.
[14:54] <man-di> persia: if you have problems/questions, just ask me
[14:55] <persia> man-di: Thanks.
[15:00] <DarkSun88> DktrKranz: Ping
[15:00] <DarkSun88> \sh: Ping
[15:01] <\sh> yepp
[15:01] <DktrKranz> pong
[15:02] <DarkSun88> Then, what do you think about this package?
[15:02] <DktrKranz> Summary: malone 178973, there's need to keep ubuntu deltas?
[15:02] <ubotu> Launchpad bug 178973 in atlas-cpp "Merge atlas-cpp 0.6.1 (universe) from Debian (unstable)" [Undecided,New] https://launchpad.net/bugs/178973
[15:03] <\sh> DktrKranz, DarkSun88: I don't think so...
[15:03] <man-di> DktrKranz: IMO no (speaking as Debian atlas-cpp maintainer)
[15:03] <DktrKranz> \sh, I did a quick test on Debian performing a etch => sid upgrade and it went good
[15:03] <DktrKranz> different SONAMEs, and no conflicts at all
[15:04] <man-di> DktrKranz: this was a bug with the wrong file in the library package and not in the -dev package
[15:04] <DktrKranz> man-di, I supposed
[15:05] <\sh> I set the different -dev package name to the correct one...and someone added C/Rs to 0.6-0c2a...I think we can drop this delta now with a 0.6-1
[15:06] <DktrKranz> \sh, I think so. I did a dapper => hardy upgrade test too and no errors were raised
[15:08] <DktrKranz> gutsy has 0.6-1 too, no upgrade path will lead to some conflicts
[15:08] <DktrKranz> DarkSun88, given that, mind adjusting your bug to reflect a sync?
[15:08] <DarkSun88> Yes, for me there isn't problem.
[15:09] <man-di> DktrKranz, DarkSun88: thanks for taking care of this.
[15:09] <DarkSun88> man-di: No problem. :)
[15:09] <DktrKranz> man-di, thanks for your feedback :)
[15:10] <man-di> DktrKranz: feedback? from me? no. ;-)
[15:10] <DktrKranz> man-di, the above one
[15:12] <man-di> hmm, I think I should schedule a tomcat5.5 fixing day...
=== nuu is now known as nu
=== nu is now known as nuu
[15:43] <kenkku> where can I find a list of sections I can use in debian/control when uploading a package (to PPA)?
=== hsitter is now known as apachelogger
[15:52] <bddebian> Heya gang
[15:52] <geser> Hi bddebian
[15:52] <bddebian> Hi geser
=== \sh is now known as \sh_away
[15:53] <pochu> grep-dctrl -F Section "python" -s Package </var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_main_source_Sources | sed -s 's/Package: //g'
[15:54] <pochu> persia: that's for source package, should it be for binary ones?
[15:54] <pochu> And does anyone happen to know who maintains multidistrotools? liw?
[15:58] <kenkku> pochu: is there any EASIER way? how do packagers usually find it out?
[15:58] <kenkku> whoa
[15:58] <kenkku> that wasn't for me :P
[15:58] <kenkku> I suck. sorry.
[16:02] <geser> kenkku: see the chapter about section in the Debian policy for a list of sections
[16:03] <geser> pochu: I don't know if mdt has a maintainer, afaik Fujitsu runs the one on qa.uw.com
[16:03] <kenkku> geser: I did. it doesn't answer my question
[16:04] <kenkku> geser: it says the three sections are main, contrib and non-free
[16:04] <kenkku> geser: the real meaning I'm looking for is only briefly mentioned
[16:04] <geser> kenkku: that are components
[16:05] <geser> kenkku: for sections see http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections: "At present, they are: admin, base, comm, contrib, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, non-free, oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11."
[16:05] <kenkku> geser: finally, thank you
[16:06] <pochu> geser: thanks
[16:06] <kenkku> geser: the basic packaging guide just mentions that sections exist and say nothing more, not even the real name
[16:06] <kenkku> oh, it was the POLICY. damn it, I was looking at the new maintainers' guide
[16:06] <pochu> Fujitsu: would it be possible to add a python section to http://qa.ubuntuwire.com/multidistrotools/ ? grepping for Section "python" should be ok.
[16:12] <wraund> a game i have needs some 32bit sound libraries but i am on 64bit, for example the 32bit of libopenal.so.0:
[16:12] <wraund> atm it complains error while loading shared libraries: libopenal.so.0: wrong ELF class: ELFCLASS64
=== Skiessl is now known as Skiessi
=== Sepheebear_ is now known as Sepheebear
[16:33] <DktrKranz> pochu, gst-plugins-bad0.10 needs a rebuild for new libdirectfb, are you going to upload a new revision or can I look at it?
[16:43] <wraund> how would i go about getting  libopenal.so.0 for 32bit machines on a 64bit computer
[16:47] <Kmos> wraund: try #ubuntu channel for support
[16:49] <andrea-bs> hi, which one I have to follow? http://wiki.debian.org/DebianPython/NewPolicy    http://www.debian.org/doc/packaging-manuals/python-policy/
[16:50] <Kmos> !packaging | andrea-bs
[16:50] <ubotu> andrea-bs: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[16:50] <andrea-bs> thanks Kmos
[17:10] <pochu> DktrKranz: feel free to do it.
[17:11] <DktrKranz> pochu, thanks. I'm sure you'll be able to do it yourself next :)
[17:11] <pochu> :)
[17:37] <Kmos> In file included from /usr/include/glib-2.0/glib.h:74, from PlatGTK.cxx:11:
[17:37] <Kmos> /usr/include/glib-2.0/glib/gtestutils.h:25: error: extra ';'
[17:37] <Kmos> /usr/include/glib-2.0/glib/gtestutils.h:121: error: comma at end of enumerator list
[17:37] <Kmos> /usr/include/glib-2.0/glib/gtestutils.h:218: error: comma at end of enumerator list
[17:37] <Kmos> /usr/include/glib-2.0/glib/gtestutils.h:243: error: extra ';'
[17:37] <Kmos> something wrong with glib-2.0 ? at gtestutils.h ?
[17:37] <Kmos> in hardy
[17:37] <CheGuevara> Kmos: i just submited a patch for that
[17:38] <CheGuevara> http://launchpadlibrarian.net/11089726/glib.debdiff
[17:38] <Kmos> CheGuevara: which is the bug ?
[17:39] <CheGuevara> bug 179119
[17:39] <ubotu> Launchpad bug 179119 in glib2.0 "glib 2.15 not clean with -pedantic" [Undecided,In progress] https://launchpad.net/bugs/179119
[17:43] <Kmos> CheGuevara: ncie
[17:43] <Kmos> nice
[17:44] <CheGuevara> trying to get someone to upload :P
[17:45] <jpatrick> CheGuevara: up the importance level :p
[17:46] <jpatrick> CheGuevara: and subsribe ubuntu-main-sponsers
[17:47] <jpatrick> and, already done
[17:48] <CheGuevara> yeah asac is gonna do it I think
[17:48] <CheGuevara> don't have privs to change importance anyway :P
[17:52] <asac> so far glib looks good ... will sponsor once i can verify that it fixes moz issues
[17:53] <CheGuevara> :)
=== Sikon is now known as LucidFox
=== dmb_ is now known as dmb
=== jekil2 is now known as jekil
=== LucidFox is now known as Sikon_DeathNote
[18:41] <limac> hey, dumb question but how do u collect the source for a bug
[18:41] <limac> ?
[18:42] <limac> :P
[18:42] <pochu> the source package?
[18:42] <limac> yeah
[18:42] <limac> pochu ^^
[18:42] <pochu> apt-cache showsrc $package will tell you
[18:43] <pochu> or apt-cache show $package | grep Source
[18:43] <limac> pochu: what replaces $package?
=== ember_ is now known as ember
[18:47] <CheGuevara> Kmos: 2.15.0-0ubuntu2 uploaded
[18:48] <pochu> limac: the binary package where you found the bug
[18:48] <limac> ah
[18:48] <pochu> This is assuming you know the binary package but don't know the source one ;)
[18:54] <Kmos> CheGuevara: nice.
=== \sh_away is now known as \sh
[19:25] <\sh> re
[19:28] <limac> pochu thanks
[19:30] <\sh> looks like I need to take a look at wine 0.9.52
[19:32] <Kmos> \sh: it's already on debian.. :-)
[19:32] <\sh> Kmos: but not the version we need ,-)
[19:33] <Kmos> 0.9.52
[19:33] <Kmos> so you need to merge :)
[19:33] <\sh> people need to know that out upstream is not debian in this wine corner case :)
[19:33] <\sh> Kmos: there is no merge from debian..please...I pushed wine from winehq to ubuntu...so I know what to do :)
[19:34] <Kmos> \sh: i think we can do it.. :-(
[19:34] <Kmos> \sh: i'm sure you know..
[19:34] <Kmos> :)
[19:34] <\sh> Kmos: we shouldn't ...
[19:34] <rexbron> gah, I need help writing a for loop in a rules file
[19:35] <\sh> rexbron: what's the difference between a shell loop and a debian/rules loop?
[19:35] <rexbron> perhaps I should look into that first then :p
[19:35] <man-di> rexbron: you need '\' at the end of each line, otherwise make starts another shell for each line
[19:37] <\sh> hmmm...I'm sure we had some examples for that in one of the motu packaging recipes
[19:40] <\sh> hmm..anyone has a clue if it's ok to use bzip2 compression for binary deb package building?
[20:11] <nixternal> imbrandon: no qyoto support for kdebindings because mono is busted apparently
[20:11] <Tilllinux> how to build your own .deb package? ;)
[20:17] <andrea-bs> I'm trying to upload a package to my PPA but it always reject it saying "MD5 sum of uploaded file does not match existing file in archive" and "Files specified in DSC are broken or missing"
[20:17] <andrea-bs> can someone help me?
=== [Supremus] is now known as Supremus
[20:57] <rexbron> would anyone beable to help me with a line in a rules file?
[20:58] <rexbron> for item in ${list}; do foo ${item}; done
[20:59] <rexbron> except  make is attempting to replace $item with a global varriable (which does not exist)
[20:59] <rexbron> rather than the iterable item
[20:59]  * rexbron is spoiled with high level languages like python
[21:03] <objarni> noob question i guess: where do I check/wish for mono1.2.6 runtime to be included into next ubuntu release?
[21:09] <objarni> hello?
[21:10] <rexbron> objarni: First check packages.ubuntu.com to see what version is in the hardy archive
[21:10] <RainCT> objarni: check in packages.ubuntu.com if it's already in Hardy and in packages.debian.org if it's in Ubuntu
[21:10] <RainCT> if it isn't in neither of them you can file a bug in Launchpad asking for it
[21:10] <objarni> thx
[21:11] <RainCT> np
[21:12] <objarni> yup mono 1.2.6 will be included, great news. thanks for your support
=== \sh is now known as \sh_away
[21:45]  * jonnymind is away: dinner
[21:45] <ion_> Thanks a lot for the information!
[21:46] <RainCT> lol
[21:46] <jpatrick> what? the dinner?
[21:47] <shonen_> mmm dinner
[21:47] <ion_> jpatric: Yeah. Everyone of us is obviously interested of what he’s doing right now.
=== shonen_ is now known as shonen
[21:57] <Kmos> can someone look at this bug 179296 ?
[21:57] <ubotu> Launchpad bug 179296 in gnome-chemistry-utils "Please merge gnome-chemistry-utils 0.8.4-4 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/179296
=== _czessi is now known as Czessi
=== Kmos_ is now known as Kmos
[23:20] <Ng> I'm guessing everyone is going to be off enjoying the holidays, but nonetheless, I have a quick question. I've packaged a python tool (probably very badly) - what do I need to do next to get some feedback on it?
[23:22] <StevenK> Ng: (Hi!) Do you have a REVU account?
[23:22] <Ng> StevenK: hey :)   nope
[23:23] <StevenK> Then again, I never used REVU ... :-)
[23:23] <Ng> StevenK: do I need to pester siretart about that?
[23:24] <StevenK> Ng: If you're part of the ubuntu-universe-contributors team on LP, and then get the keyring sync'd (or wait a day), you should be able to upload it to REVU.
[23:24] <warp10> Ng: https://wiki.ubuntu.com/MOTU/Packages/REVU
[23:24] <StevenK> Oh. I didn't know about that page. :-)
[23:25] <Ng> I'm not part of said team, but I just asked to me :)
[23:25] <Ng> -m+b
[23:25] <warp10> StevenK: well... now you know :)
[23:26] <Ng> so if there is anyone about who can sync the keyring, that would be awesome, otherwise I'll wait :)
[23:42] <jwill> Are new packages in hardy automatically backported to gutsy or is it on a package-by-package basis?
[23:43] <Fujitsu> jwill: The latter.
[23:56] <Kmos> jwill: https://help.ubuntu.com/community/UbuntuBackports
[23:57] <jwill> Kmos: thx
[23:59] <awen_> if a binary package is removed from source (aka removed from debian/control) and the source is uploaded, shouldn't the binary package disappear from the archive?