[00:23] <pwnguin> imbrandon: it builds against the changelog release. you could hit feisty if you wanted
[00:57] <siretart> bddebian: are you icognito on oftc?
[00:57] <bddebian> siretart: I was forced to change my nick :-)
[00:58] <siretart> oh?
[00:58] <bddebian> Yeah, marga wouldn't sponsor my uploads if I didn't change my nick
[01:00]  * slangasek snorts
[01:00] <TheMuso> ug
[01:00] <bddebian> slangasek: ?
[01:02] <slangasek> bddebian: the ircnick sponsoring requirement
[01:02] <bddebian> Ah
[01:03] <siretart> yes, espc. debian-women's seems to have very strong feelings about ubuntu
[01:03] <siretart> no idea why, though
[01:03] <bddebian> Well I changed it to fuckari but she didn't like that nick any better it seems ;-)
[01:04]  * bddebian erases that
[01:17] <LNX_opensrc8> hello
[01:22] <LNX_opensrc8> afternoon every body
[01:29] <bddebian> Boy do I know how to kill a conversation :-)
[01:29] <bddebian> Hello LNX_opensrc8
[01:29] <LNX_opensrc8> hello
[01:29] <LNX_opensrc8> its a bit quiet here
[01:32] <bddebian> Aye it's all the darn foreigners they're going to sleep ;-P
[01:32] <bddebian> Or are asleep
[01:32] <persia> What!  It's still morning here, and I'm sure I'm not in the same country as you.
[01:35] <bddebian> :-)
[01:35] <bddebian> Actually it's only 8:35pm here
[01:36] <bddebian> OK wok builds locally.. WTF build-dep is it missing..
[01:38] <persia> bddebian: pastebin the error from sbuild/pbuilder
[01:42] <bddebian> persia: http://pastebin.com/m5157402c
[01:43] <persia> bddebian: And that works locally?  Hrm...
[01:43] <bddebian> Aye, strange eh?
[01:44]  * persia wishes aptitude silently ignored the ',' character in package names
[01:46] <persia> bddebian: Could you include a bit more of the log?  I'm curious about the gcc ... sound.c ... line.
[01:47] <persia> looking at my local log, it spits a warning only...
[01:47] <bddebian> persia: Aye, I'll post a build log, give me a minute
[01:51] <bddebian> persia: http://www.bddebian.com/packages/debian/wok/wok_build.log
[01:52]  * persia needs to learn objdump better
[01:54] <bddebian> objdump -T /usr/lib/libfoo.so |grep get_foo ;-)
[01:54] <bddebian> So do I as you can see :-)
[01:56] <persia> bddebian: So what I don't understand is why it builds locally.  I can't even find ov_raw_seek by hand.  It's in the header, but I don't see it in the library...
[01:57] <bddebian> It's not in libvorbisfile.so?
[01:58] <bddebian> It is locally
[01:58] <persia> bddebian: Umm..  Yes.  Apparently aptitude can parse dependencies better than I :)
[01:58] <bddebian> :-)
[01:59] <bddebian> Took me a while to figure that out too :_)
[02:01] <persia> Now this is interesting.  It even builds locally in a clean snapshot chroot.
[02:02] <bddebian> wth
[02:02] <bddebian> Hmm, it seems miriam is obsessed with Kenta Cho :-)
[02:04]  * persia points at http://www.miriamruiz.es/weblog/?p=107
[02:07] <bddebian> Oh, that's Baby. Hmm, then who is mruiz?
[02:10] <persia> bddebian: http://paste.ubuntu-nl.org/41461/ shows touched libraries in a local link (post-debuild)
[02:12]  * persia doesn't understand why this doesn't work in an automated build
[02:12]  * bddebian either
[02:22] <nenolod> wow. the internal description for edgy was "fire up the crackpipes"?
[02:33] <pwnguin> well that was a wierd video lecture to nap through...
[02:33] <nenolod> napping through a webinar. tut tut.
[02:33] <pwnguin> heh
[02:34] <pwnguin> well, i havent gotten my wiimote set up to control multimedia yet
[02:34] <nenolod> wiimote? :P
[02:34] <pwnguin> but when i went to sleep, he was talking about graph theory and how shortest string superset isnt appropriate for genomic sequences
[02:35] <pwnguin> when i woke up, he was talking about hypervisors
[02:36] <pwnguin> at least when you nap through a google video, you know you didnt wake up in the next class
[02:36] <pwnguin> yes, wiimote
[02:37] <pwnguin> #ubuntu-effects redirects to compiz-fusion now?
[03:11] <bddebian> persia: Did you say you were testing teg?
[03:13] <fernando_> bddebian, thank you very much.
[03:15] <bddebian> fernando_: NP
[03:46] <Da_Clover> hey
[03:48] <persia> good evening Da_Clover
[03:50] <bddebian> hello Da_Clover
[03:50] <bddebian> persia: Did you say you were testing teg?
[03:50] <persia> bddebian: It's a daily thing :)
[03:51] <bddebian> ahh :-)
[03:51]  * persia looks for bug reports to justify the claim...
[03:51] <bddebian> Well it shouldn't be including config.{sub,guess} :-)
[03:54]  * persia finds 10 other real bugs with more impact than autofoo hackery, but promises to look at that while chasing the others
[03:54] <bddebian> :-)
[04:11] <Da_Clover> hello
[04:11] <Da_Clover> i', back =P
[04:12] <Da_Clover> i heard from a budy that ubuntu is pretty impressive
[04:12] <Da_Clover> i havnt tested it myself
[04:13] <Da_Clover> hmm i guess its just me and me
[04:20] <Da_Clover> i think v7 has too many colors
[04:21] <rob> Da_Clover, this isn't really a general discussion channel, try #ubuntu-offtopic instead :)
[04:21] <Da_Clover> rob: thanks ;)
[04:21] <rob> no probs
[04:22] <Da_Clover> i'm a newbie here so whate is motu?
[04:22] <rob> Masters of the Universe, they look after the Ubuntu universe repository
[04:32] <Da_Clover> oic ty
[07:41] <jessie> help?
[08:55] <ramvi> Hi! I learned how to program in C++ at collage and would like to contribute. Ive read a lot on the ubuntu wiki, but I cant seem to find a "how to start" kind of thing. What application should I use to develop in C++ and what application should I use to make the GUI?
[08:57] <TheMuso> ramvi: `This channel is for development related to Ubuntu packaging, and not for application development.
[09:00] <ramvi> Oh, so I will not get an answer? Is glade the default application in ubuntu for making the front end?
[09:37] <norsetto> what is the policy for changes to ubuntu-dev bzr branches?
[09:46] <geser> there is a policy?
[09:55] <nxvl> ubuntu has a meeting like debconf?
[09:57] <norsetto> geser: you mean, do as much damage as you like as soon as you clean it up afterwards?
[10:00] <Treenaks> nxvl: I've never been to a DebConf, but is the UDS what you're looking for?
[10:01] <nxvl> Treenaks: ah?
[10:01] <nxvl> ah ok, i understand now
[10:02] <nxvl> i meen a huge developers meeting
[10:04] <nxvl> with conferences, hackatons, etc..
[10:07] <ajmitch> UDS isn't really like that, since it's focused on discussions & producing specifications
[10:07] <nxvl> but not on conferences
[10:08] <nxvl> stuff in the UDS is a part of the debconf
[10:08] <Amaranth> err, no
[10:08] <Amaranth> UDS is more like...a bunch of meetings
[10:09] <norsetto> geser: really, is there some kind of guide, or I just do my little hack, commit and push?
[10:10] <Amaranth> norsetto: well, you need to update the changelog
[10:10] <norsetto> Amaranth: he, I figured that much :-)
[10:10] <Amaranth> norsetto: and one nice thing to do is to set the release to UNRELEASED or something so people know they can add to that version
[10:11] <norsetto> Amaranth: ah, thx for that
[10:11] <Amaranth> then right before someone uploads the package they change it to gutsy or hardy or whatever
[10:17] <Kmos> Can someone nuke this one? - http://revu.tauware.de/details.py?upid=363
[10:17] <norsetto> Kmos: any particular reason?
[10:17] <Kmos> http://revu.tauware.de/details.py?upid=362
[10:17] <Kmos> and tihs one too
[10:18] <Kmos> norsetto: it will be released at debian, and the second has a debdiff attached to the bug report
[10:20] <norsetto> kmos: I just archived them, just in case. Can you pls. confirm in a week?
[10:20] <Kmos> http://revu.tauware.de/details.py?upid=363 -> it will be relased under debian, i asked seb128 because he's the maintainer there
[10:21] <Kmos> tellico don't be released at debian, but it's waiting for nixternal =)
[10:21] <Kmos> when hardy opens
[10:22] <norsetto> kmos: kmos, if we nuke, they are gone for good, so, I would wait until galculator is released before nuke it, and tellico is fix released before nuke it
[10:23] <norsetto> kmos: unless tellico should not actually be in REVU (which I wonder ....)
[10:26] <Kmos> :-)
[10:26] <Kmos> ok
[10:31] <norsetto> kmos: actually, I think tellico should be in REVU, and I guess nix asked you to do the debdiff because he wanted to check out what the delta was
[10:32] <Kmos> i've put it in revu first
[10:32] <norsetto> kmos: I indeed see changes not reported in the changelog
[10:33] <norsetto> kmos: are these carry over from previous ubuntu changes?
[10:37] <norsetto> kmos: also look at the way nix did the changelog, you notice he carried over all the ubuntu changes?
[10:38] <Kmos> norsetto: yes. i start from latest diff in ubuntu
[10:39] <norsetto> kmos: well, as I said there are changes there not in the changelog, and they don't appear to be from previous versions (at least looking at the changelog)
[10:39] <hellboy195> morning :)
[10:39] <Kmos> norsetto: I need to check that out
[10:40] <norsetto> kmos: please make sure also that you roll over all the previous ubuntu chnages in the changelog 9the way nix did it)
[10:42] <Kmos> norsetto: ok
[11:54] <lamego> hello
[11:55] <lamego> I would like to submit a patch, to -updates, I should use the sponsorship process, correct ?
[11:55] <lamego> erm, -proposed, whatever :)
[11:55] <norsetto> lamego: yes
[11:57] <lamego> this patch was provided by upstream, I am not an user of this application, should I create a LP bug record anyway ?
[11:57] <Hobbsee> yes
[11:58] <norsetto> afternoon Hobbsee
[11:58] <Hobbsee> hiya
[11:59] <norsetto> no wait, its evening, time flies so fast in oz
[12:09] <sebastian^> good morning folks
[12:57] <bluefoxicy> is it even possible to make deb patches or something?
[12:58] <bluefoxicy> someone just updated openoffice.org-kde (I'm not on kubuntu) and I'm getting like a 200MB update for it that's not actually changing anything on my system except the installed version number
[13:20] <persia> bluefoxicy: It's possible, but not trivial (and as yet, an unsolved problem).  One thing to consider if you are looking through existing work to implement such a thing is preserving the ability to verify the installed files from the md5sums, while also verifying the files to be installed from their md5sums.
[13:22] <bluefoxicy> persia:  deb-v1 -> deb-v2, keep the md5sums and install paths from deb-v2 but discard the binary-identical files, check the files installed through dpkg (via the alternatives system or whatever if the package manager has moved them)
[13:23] <bluefoxicy> persia:  more interesting, source produces 50 debs; how about if you make a trivial change that impacts one deb, the others don't get updates >.>
[13:23] <bluefoxicy> https://bugs.launchpad.net/bugs/153132 for example updated openoffice.org-kde but I'm not using that package.  I had to re-install all of OpenOffice.org
[13:23] <ubotu> Launchpad bug 153132 in openoffice.org "Openoffice splash screen includes Ubuntu logo" [Medium,Confirmed]
[13:23] <Hobbsee> ah yes, someone's already filed a bug on that too.  yay
[13:24] <persia> bluefoxicy: The second is more interesting, but given that the changelog is distributed with each binary package, the package will have differed, so you still need to have sub-package updates.
[13:24] <bluefoxicy> mn
[13:25] <bluefoxicy> persia:  this is hammering the mirrors and annoying 128K ISDN line users I'm sure ;)
[13:25] <persia> bluefoxicy: For some aspects of the regular update, there has been some progress (e.g. http://www.debian-administration.org/articles/439), but it's an ongoing issue.
[13:26] <persia> Oh, I'm sure it's not ideal, I just wanted to stress some of the difficulties.  If you can find a good solution, including a sane algorithm to determine when one wants a diff, and when one wants a new download (in terms of local processing as well as bandwidth), it would be a huge win for all .deb distributions.  It's just hard.
[13:27] <bluefoxicy> mmn
[13:29] <persia> bluefoxicy: http://www.tjansen.de/debiff/ might be a starting point, although that was not received well in http://lists.debian.org/debian-dpkg/2000/12/msg00000.html
[13:30] <persia> bluefoxicy: Another trick you might try is attempting to find a way to rsync a local package cache (prepared with an apt proxy), thereby only downloading differences, yet not requiring adjustments to the core tools.  Of course, this only works for you, but...
[13:30] <bluefoxicy> persia:  having a control file to manually create something may be iffy; automatically generating such diffs shouldn't be a difficult problem once you have a format
[13:31] <lamego> Traceback (most recent call last):
[13:31] <lamego>   File "/usr/local/bin/requestsponsor", line 37, in <module>
[13:31] <lamego> anyone used the requestsponsor script ?
[13:32] <persia> lamego: That happens sometimes :)  You can also do it manually with the "subscribe someone else" link.
[13:32] <lamego> "that happens sometimes" :P ? What about fixing it ?
[13:32] <persia> bluefoxicy: The other aspect to consider is mirror size & bandwidth requirements.  As I said, if you can find a good solution after looking at previous work and commentary on this problem, it would be good for everyone.
[13:33] <lamego> persia, what is the role of the script ? subscribe a team to the LP bug ?
[13:33] <persia> lamego: I don't actually understand the cause (and don't like requestsponsor for other reasons).  If you understand the problem, a patch would be welcome.
[13:34] <persia> lamego: It attaches a debdiff to the bug, and subscribes a team.
[13:34] <bluefoxicy> persia:  mirror size is a question of administration, as is bandwidth
[13:34] <bluefoxicy> persia:  I can diff from every previous version of anything, but eventually first + all 99999999 diffs > snapshot in terms of bytes.
[13:35] <persia> bluefoxicy: Right.  It has also been previously proposed that to reduce mirror size for diffs, they be generated at request time, but this requires mirror compute cycles.
[13:36] <lamego> persia, I don't care about the script neither, I was just using because it was on the primary instructions
[13:36] <lamego> I should subcribe ubuntu-universe-sponsors to the bug ?
[13:36] <bluefoxicy> persia:  Out of the air, I would say a possible strategy may entail having a flat .deb as version 0 on release day; a flat .deb on a major (i.e. large-diff) release; a flat .deb when the total deb-diff size approaches m% of a flat .deb size; and a flat .deb after (n) diffs
[13:36] <persia> lamego: If the package is in universe, yes.
[13:37] <bluefoxicy> persia:  with a diff being generated each time except for the case where a release produces a deb-diff almost the size of the debs
[13:38] <bluefoxicy> persia:  this would, generically, mean that on a MAJOR update (deb-diff the size of the debs) everyone gets a package; otherwise, those mostly up-to-date can get diffs, while those significantly behind can get a recent deb and step up with a few diffs
[13:39] <bluefoxicy> Of course, this means you have to figure out a -good- way to make diff debs :)
[13:39] <persia> bluefoxicy: That may work for some things.  Something else to consider is that lots of updates usually only happen during a development cycle, and it's not rare for users to miss revisions in their upgrade plans.  For stable releases, the updates go to the -updates repositories, so the original .deb files aren't present for the first update.
[13:39] <bluefoxicy> (which is the hard part)
[13:40] <bluefoxicy> persia:  irrelevant.  Nothing says that a repository has to hold original .deb files in the first place.
[13:40] <bluefoxicy> persia:  This concern only brings to light a specific design consideration.  :)
[13:40] <Hobbsee> bluefoxicy: you want to speak to sladen, iirc.  he was looking into this for gutsy
[13:40] <bluefoxicy> Hobbsee:  he missed :)
[13:41] <Hobbsee> well, obviously.  commit good code, and see if you hit :)
[13:41] <persia> bluefoxicy: Right.  I'm just trying to share some of the previous objections I've seen.  If you've a better design, please propose it.
[13:42] <bluefoxicy> persia:  nods.
[13:44] <persia> bluefoxicy: Also consider that there are alternatives for users with significant bandwidth constraints (e.g. tools that allow offline updates (even such tools for foreign operating environments)).  Further, aside from the -updates issue, using rsync to keep a local mirror up-to-date (fits on a single hard drive) isn't necessarily very bandwidth intensive, so it's really only the desktop user with the slow connection who is affected.
[13:45] <bluefoxicy> mmm.
[13:46] <bluefoxicy> persia:  yet with those same alternatives, the same process could apply.  aptoncd could get a bunch of diffs, and then could burn an OpenOffice.org update to a 50MB CD ;)
[13:46] <persia> Aside from needing a good design, and good code, a proposed solution needs to solve a problem for a signficant portion of the userbase to be implemented on the entire mirror network.  Perhaps this meets that criteria, but some hard numbers would help.
[13:46] <bluefoxicy> Main advantage being that it puts less stress on the repository.
[13:46] <sladen> bluefoxicy: delta debs
[13:46] <bluefoxicy> sladen:  hi :)
[13:47] <bluefoxicy> sladen:  Hobbsee said you have been working on such.  How are you with that?
[13:47] <persia> bluefoxicy: Right.  Smaller updates for aptoncd might be good as well.  Choose the right problem, design the right solution, target the right userbase, and you'll have a win.
[13:47] <sladen> bluefoxicy: read up  http://archive.fosdem.org/2007/schedule/events/debian_delta_upgrades  (there's video)
[13:48] <sladen> bluefoxicy: video from another talk I did to the UK network operators forum:  http://www.zepler.tv/rss/uknof06.xml
[13:48] <bluefoxicy> persia, sladen:  another consideration is bzdiff(?) thing that can diff out a patch from a binary file ... making a 1 line change a few bytes instead of a 1.5K file, but that's nit-picking (unless you updated something in a header that changed like 15K in a 200MB code base in random files)
[13:49] <bluefoxicy> sladen:  nice.
[13:49] <bluefoxicy> aha you got the bsdiff issue already :)
[13:49] <sladen> bluefoxicy: watch the videos and get yourself up to speed with all the corner-cases/side cases, then it will be easier to have a worthwhile discussion
[13:50] <persia> bluefoxicy: the tricky bit with bsdiff/xdiff/etc. is that it makes md5sum verification of the to-be-installed files pre-installation processor-intensive.  For some applications, this is not preferred.
[13:51] <bluefoxicy> (this would beat the hell out of RPM too)
[13:51] <persia> bluefoxicy: Well, the RPM people are looking at the same thing (with the same current lack of success).
[13:53] <bluefoxicy> persia:  how does verification become processor intensive in that situation though?  It seems to me to add a patch phase (patch a copy of the old file, verify)... is that processor intensive itself?
[13:53] <sladen> bluefoxicy: go read up
[13:53] <sladen> bluefoxicy: then come back with questios
[13:53] <bluefoxicy> (verification of the old file can be safely skipped if you want to trust sha1sum and md5sum to do what you think they do)
[13:54] <bluefoxicy> sladen:  that video is giving me a black screen >.> <.< guess I can't view it with totem-mozilla
[13:54] <persia> bluefoxicy: Right.  The target machine needs to pre-apply the patch in RAM, compute the md5sum with the preapplied patch, and then proceed with the next file.  Once it's all done, it can proceed with unpacking.  For people with 256MB RAM & a slower processor, that can be very painful.
[13:54]  * bluefoxicy downloads for viewing
[13:55] <bluefoxicy> persia:  in RAM?  Temporary files...?
[13:55] <persia> bluefoxicy: You don't want to skip verification of the old file.  What if the user modified it?  You need to at least warn them that you are overwriting.
[13:55] <persia> bluefoxicy: If temporary files, where do they go?  Does everyone have enough space in /tmp to dist-upgrade?
[13:55] <sladen> bluefoxicy: (1) right click download  (2) totem
[13:56] <bluefoxicy> persia:  I'm thinking if you md5/sha1 a post-patched file to test it BEFORE replacing the old file with it, it should verify.  It'll not verify properly if the user modified it, or else the hash algorithm you're using is far too easy to create collisions in
[13:57] <bluefoxicy> persia:  single file at a time.  I can't keep the whole of openoffice.org-core in memory either @_@  (well I can, but it's going to trash my disk cache and push some stuff out to swap)
[13:57] <persia> bluefoxicy: Sure, but you still need to do that for every file in the package prior to applying any of them.
[13:58] <bluefoxicy> persia:  i could ask if everyone has enough space in /tmp to burn a CD, but we've already seen this problem with DVD burning in nautilus :)
[13:58] <persia> bluefoxicy: What happens if the 432nd file is corrupted?
[13:58] <persia> Sure, but not everyone needs to burn a CD.  Everyone needs to apply security updates.
[13:59] <bluefoxicy> persia:  that's a good question.  I guess while we're considering CPU power as a problem this isn't a solution; but you can roll the files back by reverse-patching them (creating a reverse patch on-the-fly with each replacement if you can't just bsdiff -R like with patch)
[13:59] <bluefoxicy> unless of course the user races and alters the newly-patched file ;)
[13:59] <persia> bluefoxicy: That might be less painful.  processor-intesive though.  If nothing else, it needs to be optional.
[13:59] <sladen> bluefoxicy: n² problem;  diff from every version to every version is alot of patches.
[14:00] <bluefoxicy> and of course, since this whole process takes a while, the user might open the program while some of its files are being replaced; but that's just a longer window version of the same race condition you get with any patching process.
[14:00] <persia> bluefoxicy: Just in case it's not obvious, neither sladen nor I is attempting to discourage you, just to help input things into your design :)
[14:00] <sladen> no, becaues you build the .deb and install it
[14:00] <bluefoxicy> sladen:  got the vid
[14:02] <sladen> bluefoxicy: first 15minutes is mvo talking about the status quo and pdiff;  rest covers possible solutions
[14:04]  * persia notes that pdiff is really annoying for people with no bandwidth constraints
[14:05] <bluefoxicy> nort point nine?
[14:05] <bluefoxicy> what?
[14:08] <lamego> is anyone familiar with mandvd ?
[14:09] <bluefoxicy> sladen:  reverse rsync?
[14:13] <sladen> bluefoxicy: -> watch
[14:18] <bluefoxicy> sladen:  nineteen inch?
[14:18] <sladen> bluefoxicy: my consultancy
[14:18] <bluefoxicy> ah.
[14:20] <bluefoxicy> sladen:  Canonical isn't publicly traded so it's fair game to pull my NOVL stock right before the next release right ;)
[14:20] <bluefoxicy> (NOVL's stock dropped on release day of Gutsy; Google marked that with a news tag for Gutsy's release)
[14:21] <sladen> bluefoxicy: I think Googles algorithms are all automatic
[14:21] <bluefoxicy> sladen:  I'm really looking forward to seeing how this works though, in any case.  I'm more than tired of having to download huge updates for one-line changes in one package that comes from some source that forces me to bring in 50 other non-updated packages :x
[14:22] <bluefoxicy> or things like "... fixed build flags on SPARC"
[14:22] <bluefoxicy> sladen:  yeah, it was a joke.  I was amused at Google's explanation is all.  :)
[14:44] <sladen> SCOX is doing well, +20% today.  Invest quick
[14:45] <imbrandon> lol
[14:46] <imbrandon> mmm Optimus Prime replica selling for 50k on eBay , heh
[14:46] <imbrandon> that would be a nice ride to own
[14:46] <nixternal> hahahaha
[14:46] <nixternal> I could see you driving through KC with that
[14:46] <imbrandon> hell yea, with a missouri kubuntu lic plate
[14:47] <imbrandon> http://www.comnetslash.com/2007/10/21/optimus-prime-truck-is-going-for-50k-on-ebay/
[14:47] <nixternal> oh that is a sharp truck
[14:47] <nixternal> 55,400
[14:47] <nixternal> bid on it bad boy :)
[14:47] <imbrandon> heh if i had 50k i would
[14:48] <nixternal> http://tinyurl.com/yomam2
[14:48] <nixternal> that is the one I am watching
[14:48] <nixternal> I want another one, and for $2k, I am all over that
[14:48] <sladen> think how many summer of code/bounties you could finance with 50k
[14:49] <nixternal> hehe
[14:49] <imbrandon> sladen: think how many tween age kids i could preach about ubuntu to when i pull up in optimus
[14:49] <nixternal> imbrandon: we started doing a CPUZ knock off dubbed CpuX, but it has been in limbo for a while because everyone working on it has been super busy
[14:49] <nixternal> that, and I am not the big Python fan just yet
[14:50] <imbrandon> cat /proc/cpuinfo ?
[14:50] <nixternal> no, tying in with lm_sensors and such
[14:50] <imbrandon> i actualy thought about using c# and the new qt bindings
[14:50] <imbrandon> to do just that
[14:51] <imbrandon> the rock your socks thing about cpuz though is its a small ( under 1mb ) self contained binary, no deps and no installation
[14:51] <imbrandon> kinda hard to do in c# or python
[14:51] <nixternal> plus dmidecode provides more than cat /proc/cpuinfo and such
[14:52] <nixternal> oh no, time to go...back later...install fest and release party time
[14:52] <imbrandon> l8tr
[15:24] <norsetto> geser: ping
[15:25] <norsetto> greetings and salutations to bddebian
[15:25] <bddebian> Heya gang
[15:25] <bddebian> Hi norsetto
[15:34] <geser> Hi bddebian
[15:34] <geser> norsetto: pong
[15:35] <norsetto> hey geser, was wondering if you did the transition package subject of bug 155341
[15:35] <ubotu> Launchpad bug 155341 in sylpheed-claws-gtk2 "Package will not install because of "unmet dependencies"" [Low,In progress] https://launchpad.net/bugs/155341
[15:35] <bddebian> Hi geser
[15:36] <norsetto> geser: don't get it, if its a bug with apt-get or we need a versioned conflict
[15:39] <geser> norsetto: claws-mail should produce transitional packages
[15:39] <norsetto> geser: it does indeed, but installing the transitional packages do not install claws-mail
[15:42] <norsetto> geser: see that claws-mail conflicts and replaces sylpheed-claws-gtk2, so installing sylpheed-claws-gtk2 should install claws-mail only
[15:43] <norsetto> geser: the conflict is not resolved as per spec, thats why I say it is perhaps a bug with apt-get, now I'm trying to version the conflict to see what happens
[15:43] <geser> norsetto: yes
[15:44] <geser> the current debian package has the same replace/conflict
[15:47] <norsetto> geser: have you got a sid chroot? I've got one and could try to install it there
[15:48] <geser> norsetto: no
[15:50] <geser> norsetto: could you check it?
[15:51] <norsetto> geser: yes, as soon as I finish this build
[15:51] <geser> thanks
[15:53] <geser> norsetto: I move that bug from sylpheed-claws-gtk2 to claws-mail
[15:54] <norsetto> geser: versioning the conflict works, let me check in sid now
[16:02] <norsetto> geser: just upgrading, its few weeks I don't use it, I hope its over soon
[16:22] <norsetto> geser: do you see the point in this (<< ${source:Version}.1~)? I mean, now its 2.10.0-3ubuntu3.1 so that would become << 2.10.0-3ubuntu3.1.1~
[16:27] <geser> norsetto: it tries to depend on the same version as the sylpheed-claws-gtk2 package but allows bin-NMUs (bin-NMUs are only used in Debian)
[16:27] <norsetto> geser: yes, thats why I'm asking, should we get rid of that?
[16:28] <geser> no, unless it's causing a problem (keep the delta small, especially for -proposed/-updates uploads)
[16:28] <norsetto> geser: right
[16:29] <fbond> Hi, what is the correct procedure to get an updated package into hardy.  This package was originally uploaded via revu.  I am the maintainer.  Should I put the package back into revu?
[16:29] <fbond> I only have small changes, really, to fix a few bugs.
[16:30] <norsetto> geser: at least versioning the Conflicts works, its not elegant but it does the job (leaving the transitional package installed, oh well)
[16:30] <norsetto> fbond: the package is already in hardy I understand?
[16:31] <geser> fbond: create a bug with the debdiff, subscribe ubuntu-universe-sponsors and wait till hardy opens for uploads
[16:31] <geser> norsetto: does sid have the same problem?
[16:31] <fbond> geser: Should I simply attach a debdiff to an existing bug, or should I create a new bug?
[16:31] <norsetto> geser:still upgrading, but its almost finished
[16:32] <geser> fbond: if there is already one for the issue you can attach it there
[16:32] <fbond> geser: thanks!
[16:34] <geser> StevenK: I guess you got also a mail from the Debian maintainer for twinkle (it's about bug #155249)
[16:34] <ubotu> Launchpad bug 155249 in twinkle "twinkle fails at missing shared library" [Undecided,New] https://launchpad.net/bugs/155249
[16:34] <StevenK> That rings a bell
[16:37] <StevenK> geser: It seems the Depends are missing - if you look at comment 2
[16:38] <norsetto> geser: same problem in sid
[16:38] <StevenK> geser: I can sort out what is going on when I wake up if you wish - I think I know what is going on
[16:39] <geser> StevenK: I don't know where the second linkage to libccgnu2 comes from (I guess it's indirect)
[16:39] <geser> StevenK: thanks
[16:39] <StevenK> Oh, if it's indirect linkage, than my thought won't solve it
[16:39] <StevenK> In which twinkle may need some -Wl,--as-needed love
[16:39] <geser> I tried it on amd64 but there it didn't mention that missing libccgnu2
[16:40] <geser> StevenK: I tried running ldd on the twinkle binary in a i386 chroot (only extracted the deb, not installed, so the depends were missing) and didn't see it there
[16:41] <geser> norsetto: will you report a bug about it to Debian?
[16:42] <StevenK> geser: In which case indirect linkage looks to be it
[16:42] <norsetto> geser: sure, but to me it is a bug with apt
[16:42] <StevenK> I think it's in a bug in twinkle
[16:44] <geser> StevenK: I've checked yet if it happens in my i386 chroot (didn't want to install KDE there) and which lib it is which pulls the second libccgnu2 in
[16:45] <StevenK> geser: At this point, I'm about ten seconds from being comatose, so I will fiddle after I wake up
[16:46] <geser> StevenK: ok, sleep well
[17:20] <neversfelde> can somebody explain "1:1.0.1-1build2" to me. The "build" extension is for packages, which are only rebuild in ubuntu and nothing is changed for the rest, or not?
[17:23] <bddebian> Typically those are for packages rebuilt against newer libraries
[17:23] <bddebian> buildx versions should get ignored and are synced automagically, where ubuntuX versions need manual merging
[17:24] <bluefoxicy> so I can't find the .torrent files on the download site
[17:25] <neversfelde> bddebian: ok, thx. and what about this 1: at the beginning?
[17:25] <bluefoxicy> instead of "Please choose a location" maybe it should say "Download via bittorrent" and just pick a random mirror (the torrent is small); or maybe there should be a checkbox "get via bittorrent" or something (that seems pointless considering the .torrent is small)
[17:26] <bluefoxicy> Who knows.  I just manually browsed the mirror for the file.
[17:30] <bddebian> neversfelde: That is an epoch and really ugly.  I'm not sure I could explain it well.  You should probably check out Debians New Maintainer Guide.  Essentially it is a way of re-versioning a package if a mistake is made or if upstream changes versioning schemes
[17:31] <neversfelde> bddebian: I will give The New Maintainer Guide a closer look. Thank you
[17:31] <bluefoxicy> sladen:  you about?
[17:31] <bddebian> neversfelde: NP
[17:32] <sladen> bluefoxicy: I'm always around
[17:34] <norsetto> bddebian: I though the 1: was linked to the soname somehow
[17:36] <bddebian> Not that I know of but I'm kinda dumb ya know ;-)
[17:36] <norsetto> bddebian: well, you explained it pretty well
[17:37] <bluefoxicy> sladen:  Something completely unrelated to earlier
[17:38] <bluefoxicy> sladen:  Downloading from the Internet is slow, and taxes the mirrors.  Microsoft has this WSUS server that manages updates...
[17:38] <bluefoxicy> In theory, Ubuntu could deploy an apt-proxy server for a centralized management server
[17:38] <bluefoxicy> But, who needs to manage stuff?
[17:39] <norsetto> bddebian: in the policy it says: "it is not intended to cope ... with silly orderings (1.1, 1.2, 1.3, 1, 2.1, 2.2, 2, etc.)" :-)
[17:39] <bluefoxicy> Let's say for a moment a home user has 5 computers on his network (laptops etc).  Avahi is open by default; why not have a service that publishes whichever deb packages are still cached by a computer via mdns, so if anyone on the local net has a package you just grab it.
[17:40] <sladen> bluefoxicy: blueprint it.
[17:40] <bluefoxicy> sladen:  that's not quite delta debbing, and it's (more importantly) not a replacement; this kind of thing, where useful, could stand on its own or supplement delta debs.  But, do you think it's any useful to begin with?
[17:40] <bluefoxicy> sladen:  mm, guess that's an answer :)
[17:41] <sladen> bluefoxicy: reflecting out updates to other computers on the local network would actually be useful
[17:41] <sladen> localised bittorrent
[17:42] <bluefoxicy> yes
[17:42] <ScottK> norsetto: I don't think your sylpheed-claws change is SRU worthy.  I'd just document the process to fix it in the bug and move on.
[17:42] <bluefoxicy> sladen:  bittorrent-like swarming may be non-useful.  If they're on the local net there's no bandwidth advantage, unless they have slower-than-network disks
[17:43] <bluefoxicy> sladen:  well, no, wait, I'm wrong.
[17:43] <norsetto> scottK: well, the fix is very simple, you just install claws-mail and thats it
[17:43] <bluefoxicy> If they all update at once, due to using a switch, multiple nodes can access other nodes with isolated circuits, which may isolate bandwidth use and overall increase effective bandwidth.
[17:44] <bluefoxicy> sladen:  thanks!  :D
[17:44] <norsetto> scottK: its for people that are clueless if they 1) don know sylpheed has been deprecated 2) don't know how to solve the conflict
[17:45] <norsetto> scottK: what really bugs me, is that the bug seems to be on the apt side of things
[17:47] <norsetto> scottK: btw, this may lead to dist-upgrade failing too
[17:47] <bluefoxicy> sladen: http://rafb.net/p/BiAJSc67.html just happened to have this on hand in tomboy somewhere
[17:48] <bluefoxicy> sladen:  THAT particular set of notes was for a separate "package distribution" type concept based on the same idea, except it tracked installed files from packages and allowed a (much smaller) piece of extra data to be kept around to re-create the package.  Something I was going to try for the XO laptop
[17:49] <bluefoxicy> Won't work for debs though.  Not without modifying dpkg to change how digital signature verification works.  But scouring the local network for debs will work.  :)
[18:35] <blueyed> Can I influence the order in which apt/dpkg install and configure packages? (bug 153819)
[18:35] <ubotu> Launchpad bug 153819 in virtualbox-ose-modules "Cannot change owner vboxusers for device /dev/vboxdrv" [Undecided,Confirmed] https://launchpad.net/bugs/153819
[18:35] <blueyed> I've tried Depends and even Pre-Depends, but it did not work out.
[18:40] <geser> blueyed: it you usually work. What exactly did you tried out?
[18:41] <geser> s/you/should/
[18:41] <blueyed> geser: I've made the -modules package Depend (and later also Pre-Depend) on the virtualbox-ose package
[18:41] <blueyed> I guess the problem is that virtualbox-ose already Depends on the -modules package.
[18:42] <geser> Pre-Depends should do it, if I'm not mistaken
[18:42] <ScottK> norsetto: Please look at the SRU criteria and tell me which one you think this meets
[18:43] <blueyed> geser: with or without an a Depends (in -modules)?
[18:43] <imbrandon> ScottK: breaking dist-upgrades seems like a "major regression/bug"
[18:44] <blueyed> geser: sorry, the right version does not appear to be in my PPA, so I've not really tested it yet..
[18:44] <norsetto> scottK: I would say "Bugs which represent severe regressions from the previous release of Ubuntu"
[18:45] <ScottK> imbrandon: I don't think that can happen.  This is only if you install the transitional package after you upgrade.
[18:45] <norsetto> scottK: unable to use claws-mail, unable to upgrade, isn't that enough?
[18:45] <ScottK> norsetto: Except I don't see that it's that
[18:45] <ScottK> norsetto: That didn't seem to be the what was going on.
[18:45] <norsetto> scottK: as I said, if its not failing dist-upgrade, than its not worth an sru
[18:46] <ScottK> OK.  I misread what you said.
[18:46] <norsetto> scottK: thats what I wrote in the bug report btw
[18:46] <ScottK> I don't think it will based on what's in the bug.
[18:46] <ScottK> OK.
[18:48] <geser> sylpheed-claws-gtk2 is a transitional package, so it will affect people who used sylpheed-claws-gtk2 to claws-mail
[18:48] <norsetto> scottK if I have sulpheed-claws-gtk2 in feisty, and I dist-update, will this not fail (since it will  try to install the transitional package)?
[19:07] <ScottK> norsetto: That's right.  The only time it's a problem is if you try to install the transitional package new on Gutsy.
[19:08] <ScottK> geser: The transition bits work.  It's only if you install the transitional package fresh.
[19:09] <ScottK> norsetto: I'd say if you can figure a way to fix it so you can install the transitional package fresh and not leave it behind, then it's a good fix for Hardy (we need the transitional package for Hardy for Dapper --> Hardy).
[19:10] <hellboy195> ScottK: I have gutsy and pbuilder is set up with gutsy. would something happen if I "upgrade" to hardy now?
[19:10] <geser> ScottK: interesting, I didn't expect it to work if you have the package already installed and do an upgrade
[19:10] <imbrandon> a new toolchain
[19:10] <ScottK> hellboy195: I'd say yes, but nothing good.
[19:11] <ScottK> Wait until the toolchain is built and stable at least.
[19:11] <hellboy195> ScottK: stable means in 6 months?
[19:11] <geser> you can already upgrade a pbuilder to hardy?
[19:12] <hellboy195> geser: dunno
[19:12] <imbrandon> hellboy195: no , generaly when the archive for it "opens"
[19:12] <imbrandon> geser: yes, but not really a point
[19:12] <hellboy195> imbrandon: hardy is open!?
[19:12] <imbrandon> hellboy195: not for uploads
[19:13] <ScottK> hellboy195: No.  A week or two.
[19:13] <hellboy195> imbrandon: ah ok. hmm but I don't want to upload something. just to upgrade "ubuntu" and package with pbuilder still gutsy packages
[19:13] <hellboy195> ScottK: k
[19:26] <bluefoxicy> is there any gpg signature verification for Packages (the package list)?
[19:27] <bluefoxicy> Ah, nvm, I see.
[19:32] <bluefoxicy> sladen:  https://blueprints.launchpad.net/ubuntu/+spec/apt-avahi
[19:33] <bluefoxicy> sladen:  if you have a spec for delta debs... based on my understanding (custom version, between any version, etc) of what you're trying to do, it should be possible to copy individual files from a package back and forth and then use delta deb stuff to retrieve whatever's left?
[19:34] <bluefoxicy> (this could become a future component)
[19:35] <hellboy195> hey guys. are there any plans for gutsy-commercial ??
[19:37] <sladen> bluefoxicy: yes, in theory;  except that if you're having to reconstruct the gzip compression, it has to be done in one go
[19:37] <sladen> bluefoxicy: but those chunks/files could come from anywhere
[19:38] <bluefoxicy> sladen:  nods.  Well you have my thoughts in the matter.  Good luck with the delta debs, I'm looking forward to that at least.
[19:39] <bluefoxicy> I of course am about to move to 64-bit ubuntu, because gnash works and I'm going to put it to the test.  :)
[19:40] <ScottK> hellboy195: It's called 'partners' now.
[19:40] <bluefoxicy> sladen:  also:  If you have a different version of gzip (say it gets a little bit better compression due to improvements in the lz search algorithm that spit out the same data format), that whole idea is gonna break ;)
[19:41] <sladen> bluefoxicy: re: https://wiki.ubuntu.com/AptAvahi  I don't think hobbsee is going to be having any kids at the moment ... let alone seven.
[19:41] <bluefoxicy> sladen:  they're completely ficticious scenarios!  O:)
[19:42] <bluefoxicy> sladen:  edit as needed?  :>
[19:43] <hellboy195> ScottK: great. thx :)
[19:43] <bluefoxicy> (no, really, I just thought it'd be funny, especially if Hobbsee read it)
[19:45] <jdong> bluekuja: I've been thinking about Azureus..... what if we just freaking demote the stupid thing to multiverse and compile it with the Sun JDK stack?
[19:46] <jdong> bluekuja: I don't think this whole FOSS Java stack for Azureus thing is working out all that well...
[19:46] <hellboy195> ScottK: a friend from me must use Xp now. how can he download the vmware-server debs from this repo? any ideas?
[19:46] <geser> bluefoxicy: LongPointyStick is here, so I guess she will read it when she wakes up
[19:47] <ScottK> I think they are in the partners repo, but don't know for sure.
[19:47] <bluefoxicy> geser:  hah
[19:47] <jdong> ScottK: not in Gutsy
[19:47] <jdong> ScottK: Feisty had it in partners...
[19:47] <jdong> -commercial rather
[19:48] <geser> jdong: afaik you can't use the sun java jdks on buildds as there is no way to skip the license question
[19:48] <jdong> hellboy195: in my experience the vmware .tar.gz installers are well behaved and "clean"
[19:48] <jdong> geser: goodie :-/
[19:48] <jdong> hellboy195: I usually install it from the .tar.gz
[19:49] <hellboy195> jdong: ok
[19:53] <bluekuja> jdong, yeah, I agree with you on this
[19:55] <jdong> bluekuja: I really want to see Azureus to work.... my last idea with the current stack is to toss all of our packaging and rebase from Fedora 8... if that fails I simply don't see any alternative...
[19:55] <ScottK> norsetto: Do you have anyone on the hopefules/mentees list who could use a relatively easy merge?
[19:55] <bluekuja> jdong, same here, azureus is having great problems atm, and I cant have it working herer
[19:56] <bluekuja> *here
[19:56] <jdong> bluekuja: we know that Sun Java compiled and sun JVM run = good, Sun Java compiled + GCJ run = good, GCJ compiled + * = bad, except under Fedora 8 and Dapper when GCJ + GCJ = good but GCJ + Sun = bad.
[19:56] <hellboy195> bluekuja: azureus afaik had always problems on ubuntu ^^
[19:56] <jdong> hellboy195: not always
[19:56] <jdong> hellboy195: in Dapper packaging it worked fine if you run it with GCJ
[19:56] <jdong> but if you try to run Ubuntu package with Sun JVM, it crashes Hotspot
[19:57] <hellboy195> jdong: yes but i mean with sun
[19:57] <geser> jdong: have you tried the icedtea java packages with azureus?
[19:57] <jdong> geser: I have not...
[19:57] <jdong> geser: I wonder if that's what Fedora 8 uses?
[19:58] <geser> icedtea is java7
[19:58] <hellboy195> when will sun java will be open enough to put it into main?
[19:58] <geser> icedtea is already in universe
[19:59] <bluekuja> jdong, geser: we should try to run it with azurues then
[19:59] <norsetto> scottK: the best would be to tag the bug packaging/bitesize and assign it to you as a mentor
[19:59] <jdong> indeed
[19:59] <ScottK> norsetto: It's a merge, so there's no bug.
[20:00] <norsetto> scottK: make it then
[20:00] <norsetto> scottK: if its too much work tell me the package and I'll do it myself
[20:00] <bluekuja> jdong, if it doesnt work, we have a problem :)
[20:01] <bluekuja> I would say a big problem
[20:01] <jdong> bluekuja: I can give a quick try to run az with icedtea.. i don't have the time right now to build it from ground up with it
[20:01] <ScottK> norsetto: Gramps.  Sorry.  I got about a million things going on today.  Thanks.
[20:01] <norsetto> ScottK: np
[20:02] <bluekuja> jdong, that's ok. At least we can have a first try about having jave7 plus azureus
[20:02] <bluekuja> *java
[20:03] <bluekuja> jdong, and if everything seems to run we can move to start up packaging it
[20:03] <jdong> Caused by: java.lang.ClassNotFoundException: org.eclipse.swt.widgets.Display
[20:03] <jdong> blargh
[20:03] <bluekuja> crashed?
[20:04] <jdong> yeah :(
[20:04] <bluekuja> darn :/
[20:04] <jdong> Hmm I wonder if I can quickly hack the packaging
[20:04] <jdong> what I'm afraid is that it'll require that we compile all the b-d's with GCJ too
[20:04] <jdong> err icedtea*
[20:04] <jdong> which is not an option
[20:05] <norsetto> scottk: bug 155487. You have to offer mentorship yourself, I can't do it for you
[20:05] <ubotu> Launchpad bug 155487 in gramps "Please merge gramps (2.2.9-1) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/155487
[20:05] <ScottK> norsetto: Sure.
[20:05] <imbrandon> jdong: does debian use gcj for it ?
[20:06] <jdong> imbrandon: quite sure the new-style non-contrib packaging does
[20:06] <imbrandon> huh ?
[20:07] <imbrandon> 2.5.0.4-1 in unstable
[20:07] <jdong> yeah, those ones
[20:08] <ScottK> norsetto: Done.  Thanks.
[20:08] <jdong> the stable release version was the "old style": where they just uploaded a binary package
[20:08] <norsetto> scottK: I'll publicise it in motu-mentors
[20:08] <ScottK> OK.
[20:08]  * jdong builds the debian one for kicks
[20:15] <bluekuja> jdong, results?
[20:16] <jdong> bluekuja: one sec, wrestling with deps, silly differently named swt junk :)
[20:16] <bluekuja> hehe, ok :)
[20:16] <jdong> bluekuja: while I have this set up anyway, I'll humor myself and see if I can force icedtea to bve the compiler :D
[20:16] <hellboy195> so. off. cya
[20:16] <bluekuja> cya hellboy195
[20:17] <bluekuja> jdong, I just hope we can get a working azureus package
[20:17] <jdong> bluekuja: likewise, I really want it
[20:18] <bluekuja> jdong, a lot of ppl use it, so it's a priority atm
[20:18] <jdong> bluekuja: hmm got a FTBFS that eclipse swt cannot be resolved... which almost IDENTICALLY matches up with one of the tracebacks in the bug report....
[20:19] <jdong> bluekuja: I'm beginning to wonder whether or not our own package build successfully in gutsy final.
[20:19] <bluekuja> damn
[20:19] <jdong> lol
[20:19] <lamego> anyone with an nvidia card that could do a test ?
[20:19] <bluekuja> jdong, lol
[20:19]  * bluekuja checks build logs on lp
[20:19] <bluekuja> :P
[20:19] <jdong> bluekuja: same version since feisty, IIRC
[20:19] <jdong> bluekuja: which could explain... a lot.
[20:20] <bluekuja> jdong, what's new in the latest debian package?
[20:21] <jdong>   * New upstream release. Closes: #406914.
[20:21] <jdong>   * Disable auto-update. Closes: #405997.
[20:21] <jdong> nothing.
[20:21] <jdong> bluekuja: we really diverged though
[20:21] <jdong> bluekuja: their packaging even uses a different build stack than us...
[20:21] <bluekuja> jdong, that's pretty bad, would be nice to have a package close to debian one
[20:21] <jdong> bluekuja: ours seems to build correctly
[20:22] <jdong> bluekuja: I'm gonna whip the debian pkg to compile, hopefully
[20:22] <bluekuja> jdong, debian one failed to build?
[20:22] <ScottK> jdong: To quote (IIRC it was StevenK) Azureus is evil.  I think everyone has been afraid to touch it.
[20:22] <bluekuja> jdong, unstable one?
[20:23] <jdong> bluekuja: right, it couldn't located swt libs, despite the build-dep being installed
[20:23] <jdong> bluekuja: I'll investigate that one a bit more
[20:23] <bluekuja> ScottK, that's true
[20:23] <jdong> ScottK: I have a reputation for stupidly trying to fix what everyone else avoids
[20:23] <bluekuja> the only good soul is the proud jdong
[20:23] <bluekuja> atm^^
[20:23] <jdong> OH DEAR LORD this build is RAM heavy!
[20:23] <bluekuja> lol
[20:24] <ScottK> jdong: Go build eclipse.  It took RAOF 18 hours to build it on a 1 gb box due to thrashing.
[20:25] <bluekuja> jdong, I tried azureus one week ago. I took a torrent, pushed it on the queue and everything crashed
[20:25] <jdong> 21545 root      18   0  923m 651m 4016 D    2 64.5   0:51.92 jc1
[20:25] <jdong> shesh!
[20:25] <bluekuja> and now it's unusable
[20:26] <bluekuja> that's why my bugmail is full of those crashes
[20:26] <tiagoboldt> Hi there, I would like to solve this bug https://bugs.edge.launchpad.net/ubuntu/+source/gramps/+bug/155487
[20:26] <ubotu> Launchpad bug 155487 in gramps "Please merge gramps (2.2.9-1) from Debian unstable (main)" [Wishlist,Confirmed]
[20:26] <ScottK> Have you done merges before?
[20:26] <jdong> bluekuja: lol shall we just give up on GCJ altogether and see if we can go the icedtea route?
[20:26] <bluekuja> tiagoboldt, you should wait hardy first, then you can start merging
[20:26] <bluekuja> (if you know how)
[20:27] <ScottK> The first thing to do is assign the bug to yourself so others know not to work on it.
[20:27] <tiagoboldt> I have no experience, but I'm a fast leaner :D
[20:27] <bluekuja> jdong, lol
[20:27] <tiagoboldt> I've already assigned the bug to me
[20:27] <bluekuja> jdong, seems the only working way to have damn working package
[20:27] <ScottK> OK.  Do you understand what a merge is?
[20:27] <jdong> bluekuja: no kidding... *aborts build*
[20:27] <bluekuja> :D
[20:28] <tiagoboldt> I guess so, I have to get it from debian and build it for ubuntu, wrong?
[20:28] <ScottK> Close.
[20:28] <ScottK> The current Ubuntu package is different that Debian's.
[20:28] <ScottK> Debian has a new package.
[20:28] <bluekuja> jdong, debian package builds in gutsy?
[20:29] <superm1> tiagoboldt, you may want to read a little on this wiki page: https://wiki.ubuntu.com/MOTU/Merging
[20:29] <ScottK> In a merge, you look at Debian's new package and incorporate the Ubuntu unque stuff that is still required.
[20:29] <jdong> bluekuja: not yet.... I'm gonna now see which is easier to adapt to icedtea, gutsy or debian packaging...
[20:29] <ScottK> Also, please - anyone else feel free to jump in and help tiagoboldt.  I offered to mentor this, but I'm also doing 3 other things right now too.
[20:30] <bluekuja> tiagoboldt, if you need an hand, just let me know
[20:30] <tiagoboldt> yes, since it's my first time, every help is welcome :D
[20:30] <bluekuja> jdong, ok. That's the first step to try out
[20:30] <bluekuja> jdong, if you have the chance to have debian package built in gutsy
[20:30] <bluekuja> jdong, would be nice to try it out
[20:30] <bluekuja> jdong, and see if it works/not works and so on
[20:31] <jdong> bluekuja: ok, I'll  try to hack the debian pkg to build
[20:31] <bluekuja> jdong, sounds great. When done, ping me, so we can test it out a bit
[20:31] <bluekuja> and take a decision
[20:32] <tiagoboldt> bluekuja, I'm reading about merging, in this case, I should get the package from debian? or merges.ubuntu.com?
[20:32] <bluekuja> tiagoboldt, it depends...do you want to merge it manually or using a small tool?
[20:33] <bluekuja> tiagoboldt, mom uses a nice tool
[20:33] <bluekuja> for merging stuff from debian
[20:33] <bluekuja> tool name is grab-merge.sh
[20:33] <bluekuja> you can play with it a bit
[20:33] <tiagoboldt> I'm want to do it in the best way possible :D
[20:33] <bluekuja> :D
[20:33] <tiagoboldt> I'll go take a look at it :)
[20:34] <bluekuja> tiagoboldt, great. wget it and grab the package you need
[20:37] <tiagoboldt> it's downloading using the script:)
[20:37] <bluekuja> great
[20:38] <tiagoboldt> it's downloading two versions
[20:38] <jdong> bluekuja: I see half the problem
[20:39] <pochu> Can we already go merging?
[20:39] <ScottK> That's normal tiagoboldt
[20:39] <tiagoboldt> by merging, what will I do exactly? upgrade the package version in ubuntu?
[20:39] <jdong> bluekuja: our JAVADIR is fractured half into /usr/lib/java and half into /usr/share/java
[20:39] <ScottK> pochu: Sure.  We just can't upload them yet.
[20:39] <jdong> bluekuja: and our azureus package has sinful hackjobs to work around that
[20:39] <pochu> ScottK: ty
[20:40] <tiagoboldt> I've got all the files of the two versions and two scripts :D done :D
[20:40] <bluekuja> jdong, understood. Is there a way to have it working on debian?
[20:40] <jdong> bluekuja: yes, some makefile mods
[20:40] <pochu> Ubuntu Masters of the Universe: https://wiki.ubuntu.com/MOTU | Gutsy Gibbon released - start working on Gutsy SRUs (gutsy-proposed is open for motu-uvf approved uploads). | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | http://ubuntu.joejaxx.org/ - TOP 10 Uploaders/Packages | Go Merging! http://dad.dunnewind.net/universe.php
[20:40] <pochu> woops
[20:40] <tiagoboldt> is there any tutorial I can follow? I could do it more on my own that way..
[20:40] <bluekuja> tiagoboldt, I guess superm1 linked you it
[20:40] <bluekuja> jdong, true. We need to hack makefiles a bit
[20:41] <bluekuja> jdong, and we get it done
[20:41] <joejaxx> hmm
[20:41] <jdong> bluekuja: well it's building pretty well so far with a 1-liner :D
[20:41] <joejaxx> time to change the stats to hardy
[20:41] <bluekuja> tiagoboldt, https://wiki.ubuntu.com/MOTU/Merging
[20:41] <jdong> bluekuja: watch me curse it with that optimistic statement
[20:42] <bluekuja> lol
[20:42] <bluekuja> jdong, going for a bath, need to relax a bit
[20:42] <jdong> bluekuja: what I like about the Debian package is that it's java implementation agnostic.... switching to sun or icedtea should be a simple build-dep reordering
[20:42] <tiagoboldt> I'm reading it, thanks :D brb with success our doubts :D
[20:43] <jdong> bluekuja: enjoy, I'll test this package, if ti deosn't work I'll switch it over to icedtea pronto
[20:43] <bluekuja> jdong, great, gonna ping you later for results
[20:43] <jdong> ok
[20:43] <bluekuja> have fun in the meantime
[20:43] <bluekuja> :P
[20:44] <bluekuja> off
[20:51] <norsetto_> tiagoboldt: pls. mark bug 155487 as "In Progress" if you are working on it
[20:52] <ubotu> Launchpad bug 155487 in gramps "Please merge gramps (2.2.9-1) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/155487
[20:52] <tiagoboldt> ok
[21:19] <jdong> bluekuja: ok, Debian Azuureus compiled in Ubuntu does NOT run in sun Java with identical error messages, seems run in GCJ but at snail-slow paces (on the factor of 60-100x slower than Sun) -- I have waited 30 minutes for a logo screen and it's still using 100% CPU
[21:19] <jdong> bluekuja: at this point I'm going to investigate building with icedtea
[21:20] <bluekuja> jdong, no logo screen for more than 30 mins with 100% CPU, crazy...
[21:20] <bluekuja> jdong, ok fine
[21:21] <jdong> bluekuja: well Debian GCJ build does not activate the native compiling thing, so it's interpreted bytecode, not JIT
[21:21] <jdong> bluekuja: it's entirely plausible to be on the order of 500x slower than regular Java or precompiled Java
[21:22] <jdong> bluekuja: icedtea compile is currently going.... Sun's compiler is at least triple the speed of GCJ so far....
[21:22]  * jdong keeps azureus GCJ loading on the second core just to humor himself
[21:22] <bluekuja> :D
[21:23] <bluekuja> jdong, if we cant make it working using icedtea, what should we do?
[21:24] <jdong> bluekuja: I don't see how that could happen, unless Java7 is not compatible with Java6 enough to run azureus (which I guess, fine, is possible...)
[21:24] <jdong> bluekuja: then our solutions are (1) rebase from Fedora 7, (2) find some way of building with sun-java5/java6 and demote to multiverse
[21:25] <bluekuja> jdong, which solution would you take?
[21:26] <jdong> bluekuja: the latter
[21:26] <bluekuja> jdong, that's whay I thought
[21:26] <bluekuja> *what
[21:26] <bluekuja> jdong, it will be the cleanest way to have a working package
[21:30] <jdong> bluekuja: grr even pure icedtea one is dying across the board... I suspect something wrong with our SWT....
[21:30] <bluekuja> jdong, failed to build? or unusable?
[21:30] <jdong> bluekuja: builds but fails to run
[21:31] <bluekuja> darn, same as before then
[21:31] <jdong> bluekuja: oh wait I see a problem
[21:32] <bluekuja> jdong, where?
[21:33] <jdong> bluekuja: the launcher script doesn't seem to be executing the same java commandline, investigating...
[21:35] <norsetto> geser: I have a contributor which is looking for a mentor to help him with bug 150876. Could you possibly help him?
[21:35] <ubotu> Launchpad bug 150876 in xen-meta "English error in description" [Low,Confirmed] https://launchpad.net/bugs/150876
[21:36] <tiagoboldt> so, I've started working on a merge, I've downloaded the sources and diffs with the script available at mom and built the package with pbuilder, is that it? what else?
[21:36] <Kmos> tiagoboldt: a merge must include ubuntu changes, not only debian ones
[21:37] <bluekuja> norsetto, is an upload worth for just a small fix?
[21:37] <Kmos> and that means all changelog from both
[21:37] <ScottK> Kmos: Not necessarily and as he said already, he used the mom script to get the package.  It does that for you.
[21:37] <norsetto> bluekuja: from an educational pov, yes.
[21:38] <ScottK> tiagoboldt: My advice is to avoid advice from Kmos.  In my experience it's rarely correct.
[21:38] <bluekuja> norsetto, fine then
[21:38] <tiagoboldt> I'm new, please keep my out of the hostilities :P
[21:38] <ScottK> tiagoboldt: What you need to do now is look at the Ubuntu changes (looking in debian/changelog for the entries previous to the Debian update will tell you what they are)
[21:38] <ScottK> Sure
[21:38] <bluekuja> norsetto, maybe he should find out something to fix along with that bug
[21:39] <tiagoboldt> anyway, after that, I've got the files in pbuilder cache directory, what now?
[21:39] <bluekuja> norsetto, so we have a full upload
[21:39] <ScottK> So once you see the changelog entries for Ubuntu changes, you need to see if they are still needed (hint: at least one of the gramps ones is not).
[21:39] <norsetto> bluekuja: I leave it to the guy that mentors him on that bug, which could possibly be you if you agree
[21:39] <bluekuja> norsetto, yeah, fine
[21:40] <ScottK> You should also look in the REPORT file the script downloaded and see if it reports any conflicts.  If it does, you'll need to sort those too.
[21:40] <bluekuja> norsetto, gonna help him to provide a debdiff
[21:40] <norsetto> bluekuja: cool, just assign yourself as the mentor then
[21:40] <tiagoboldt> ohh, so I should have done that before building it, right ScottK ?
[21:41] <jdong> bluekuja: found the culprit,it's our swt.jar
[21:41] <ScottK> tiagoboldt: Yes, but no matter.  You'll just build it again after.
[21:41] <jdong> bluekuja: replacing ours with Azureus's somehow causes it to load
[21:41] <tiagoboldt> sure:)
[21:41] <jdong> bluekuja: now to see why
[21:41] <jdong> -rw-r--r-- 1 root root 708K 2007-09-14 04:30 /usr/lib/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_3.2.2.v3236.jar
[21:41] <jdong> -rw-r--r-- 1 jdong jdong 1.7M 2007-10-18 08:39 swt.jar
[21:41] <jdong> bluekuja: our SWT is 1/3 the size of theirs!
[21:42] <norsetto> jdong: mine is 5 times their, so there
[21:42] <geser> norsetto: sure (that xen-meta bug)
[21:42] <jdong> lol
[21:42] <norsetto> geser: ah, ok, apparently bluekuja volunteered in the meantime
[21:43] <bluekuja> jdong, 0_0
[21:43] <bluekuja> geser, if you want to take it, no problem
[21:43] <jdong> bluekuja: ok, I am reasonably certain I understand the surface of the problem now
[21:43] <geser> bluekuja: you can have it
[21:44] <jdong> bluekuja: we use SWT built through Eclipse; Debian/Azureus use SWT built from http://packages.debian.org/source/sid/swt-gtk source package similar to that
[21:44] <bluekuja> jdong, having it fixed, can avoid the latter option?
[21:44] <jdong> bluekuja: they must not be compatible
[21:44] <bluekuja> jdong, we decided before?
[21:44] <norsetto> bluekuja, geser: as long as one of you two take it, because it is still free ......
[21:44] <jdong> bluekuja: I don't know enough about eclipse to know why we went for one over the other...
[21:45] <jdong> bluekuja: the obvious dirty workaround is to make a separate swt package for azureus, but if we can avoid that it's for the best :)
[21:46] <jdong> is there some way to explore the API provided by a JAR?
[21:46] <Treenaks> jdong: A jar is just a zip with a bunch of .class files in it (basically)
[21:46] <jdong> Treenaks: ok, recursively, I mean any way of exposing the API of a .class?
[21:47] <Treenaks> jdong: libbcel-java - Analyze, create, and manipulate (binary) Java class files
[21:47] <tiagoboldt> ScottK, is there anyway were I can read about the changes needed to be done to those files? The documentation is a bit messy everywhere :\\
[21:47] <ScottK> Understand.
[21:48] <Treenaks> jdong: "yes, but it's not trivial@
[21:48] <ScottK> Did you see the previous Ubuntu changes in debian/changelog?
[21:48] <tiagoboldt> yes
[21:48] <tiagoboldt> and there is one that has been done in the upstream
[21:48] <bluekuja> norsetto, done, was finishing something so sorry for the delay
[21:48] <tiagoboldt> (I guess I've used the correct terms :D)
[21:49] <ScottK> I think so.
[21:49] <jdong> bluekuja: ok, more specifically, our SWT is missing the org.eclipse.swt.widgets.Display class
[21:49] <jdong> bluekuja: in fact, the entire .widgets namespace
[21:49]  * jdong adds this to the bug report
[21:49] <bluekuja> jdong, which is there on debian?
[21:50] <jdong> bluekuja: right because their SWT sources come from a different origin
[21:50] <ScottK> tiagoboldt: So the ubuntu-2 change from the current debian package has been incorporated already and is no longer needed, but the ubuntu1 changes have not, correct?
[21:50] <jdong> bluekuja: I bet that eclipse demands its own SWT to be the one that's in /usr/lib/java
[21:50] <bluekuja> jdong, true, it's something impossible to use the same SWT sources as debian?
[21:51] <jdong> bluekuja: so I think instead we should slot-install SWT from Debian?
[21:51] <tiagoboldt> ScottK, true, that's it!
[21:51] <jdong> bluekuja: well if we just directly replace them, I'm sure Eclipse itself will blow up
[21:51] <bluekuja> jdong, slot-install as you said then
[21:51] <bluekuja> (from debian)
[21:52] <ScottK> So the ubuntu1 changelog entry you are doing should look the same as the last ubuntu1 changelog entry.  Let's get that right and then we'll check and make sure it's true after.
[21:52] <jdong> bluekuja: actually, an interesting side effect, ours is "libswt3.2-gtk-java" while Debian's is "libswt-gtk-3.2-java"
[21:52] <ScottK> tiagoboldt: Why don't you take a stab and that and pastebin the result.
[21:52] <jdong> bluekuja: so aside from utter confusion, we could just directly pull that package over!
[21:52] <tiagoboldt> ok :D
[21:52] <bluekuja> jdong, why the name got diverged that way?
[21:53] <jdong> bluekuja: I don't know
[21:54] <bluekuja> jdong, would be possible to have the name synced with debian again?
[21:54] <jdong> bluekuja: it would break all the reverse deps....
[21:54] <bluekuja> jdong, to prevent any dep mess up
[21:54] <bluekuja> yea
[21:54] <bluekuja> jdong, but if a package comes from debian with that dep name
[21:55] <bluekuja> should be merged everytime
[21:55] <bluekuja> to prevent every ftbfs
[21:55] <jdong> bluekuja: if a package comes from debian with that dep name it probalby wouldn't run under ours anyway
[21:55] <jdong> bluekuja: our SWT seems VERY eclipse specific
[21:55] <bluekuja> oh ok, that explains it
[21:55] <tiagoboldt> ScottK, I've did it, and I've also added some changes that I'm not sure that should be included, http://pastebin.ca/744844
[21:56] <bluekuja> norsetto, why the bug is already assigned?
[21:56] <bluekuja> norsetto, you said the contributor (I guess era on LP) decided to do it
[21:56] <jdong> eclipse-rcp: usr/lib/eclipse/plugins/org.eclipse.swt_3.2.2.v3236b.jar
[21:56] <norsetto> bluekuja: because he wants to work on it?
[21:56] <jdong> jesus how many SWT's do we have???
[21:57]  * ScottK looks
[21:57] <bluekuja> norsetto, yeah, I thought the contributor name was "era"
[21:57] <norsetto> bluekuja: no, the contributor who asked for help is miguel ruiz
[21:57] <bluekuja> kk, fine then
[21:57] <bluekuja> norsetto, sorry for bothering, was unclear
[21:58] <norsetto> bluekuja: hey, np
[21:58] <ScottK> tiagoboldt: Close.  I'll edit for you.
[21:59] <tiagoboldt> k
[21:59] <jdong> bluekuja: oh god, I feel like a total moron now
[21:59] <ScottK> tiagoboldt: One quick point: Always spaces, never tabs in debian/changelog
[21:59] <bluekuja> jdong, y?
[21:59] <jdong> bluekuja: I somehow had a corrupt swt.jar.
[21:59] <jdong> bluekuja: *former XFS user*
[21:59] <tiagoboldt> how many for a tab? 4?
[21:59] <jdong> bluekuja: shoot me :)
[21:59] <bluekuja> jdong, :/
[22:00] <bluekuja> jdong, :D
[22:00] <jdong> bluekuja: now, to retry IcedTea build
[22:00] <ScottK> tiagoboldt: 4 in this case.
[22:00] <bluekuja> jdong, I feel better now
[22:00] <bluekuja> ^^
[22:00] <bluefoxicy> https://bugs.launchpad.net/ubuntu/+source/gnash/+bug/155412  is this improper?
[22:00] <ubotu> Launchpad bug 155412 in gnash "gnash plays SML 3 video poorly" [Undecided,New]
[22:01] <bluefoxicy> I noticed there's a lot of gnash bug reports on launchpad, I didn't know if I should dump all the "video X plays like shit" "Web site feature Y does not work properly" bugs into the same bug or not
[22:01] <ScottK> tiagoboldt: http://pastebin.ca/744854 - Also you need to put your information in line 11 and update the date/time.
[22:03] <jdong> bluekuja: ok,
[22:03] <jdong> bluekuja: debian packaging still hates Ubuntu
[22:03] <bluekuja> jdong, what happened?
[22:04] <tiagoboldt> did it ScottK, Now I should do each of that changes to the code, right?
[22:04] <jdong> bluekuja: it can't find the org.eclipse.swt.widgets.Display class
[22:04] <ScottK> tiagoboldt: You should find that the merge script did it for you.  What you need to do is verify that.
[22:04] <bluekuja> jdong, during build?
[22:05] <tiagoboldt> ok : )
[22:05] <jdong> bluekuja: during execution
[22:05] <jdong> bluekuja: I'm investigating how it finds it during build
[22:05] <bluekuja> jdong, using icedtea?
[22:05] <jdong> bluekuja: using any java runtime
[22:05] <bluekuja> jdong, yeah, we should see how does it detect it during build
[22:06] <bluekuja> jdong, and hack the package a bit, to have it working
[22:06] <bluekuja> jdong, I'm going to sleep, need to wake up early tomorrow
[22:06] <bluekuja> jdong, please let me know everything about this
[22:07] <bluekuja> jdong, tomorrow if you have a chance to be around
[22:07] <jdong> bluekuja: ok; well I think the core of the problem is debian has az 2.5.0.4 while w're still working on 2.5.0.0
[22:07] <jdong> bluekuja: could be a new dependency introduced in the later Azureus
[22:08] <bluekuja> jdong, ping me tomorrow when you get online
[22:08] <jdong> bluekuja: oh oh you might wanna stay up for 3 more minutes.....
[22:08] <bluekuja> jdong, so we can continue discussing this out
[22:09] <bluekuja> jdong, lol
[22:09] <bluekuja> jdong, if you have good news, why not
[22:09] <tiagoboldt> ScottK, the control file has a first part with ubuntu related info, and a second one, inconsistent with the first, with the debian infos, should it be kept?
[22:09] <jdong> CAN I GET A HELL YEAH?????
[22:10] <bluekuja> xD
[22:10] <jdong> bluekuja: Debian Azureus + icedtea-jdk + icedtea+jre + Ubuntu /usr/bin/azureus launcher = SUCCESS
[22:10] <bluekuja> woooooooohoooooooo
[22:10] <bluekuja> :D
[22:10] <jdong> bluekuja: now to figure out why the heck that combination is magical
[22:10] <ScottK> tiagoboldt: pastebin me the part of the control file you are wanting to know about.
[22:10]  * bluekuja starts dancing
[22:12] <bluekuja> jdong, did you change every B-D from debian?
[22:12] <tiagoboldt> ScottK, http://pastebin.ca/744866
[22:12]  * ScottK looks
[22:12] <bluekuja> jdong, and added icedtea stuff?
[22:13] <jdong> bluekuja: yeah, just added icedtea-java7-jdk as the first javac dep, and voila
[22:13] <ScottK> tiagoboldt: What of those difference relate to what you have already said you would be different from Debian on in debian/changelog
[22:13] <bluekuja> jdong, maybe you did something magic while building :P
[22:14] <tiagoboldt> ScottK, that's not very clear, sorry
[22:14] <jdong> bluekuja: lol let me clean all this junk up and reproduce build success :)
[22:14] <bluekuja> jdong, perfect. If everything goes fine, I go to sleep happy
[22:15] <ScottK> tiagoboldt: Look at your debian/changelog entry we already made.  Some of the differences in the part of debian/control are listed there.  If we've said we want Ubuntu to be different from Debian, then we keep the Ubuntu version.  If not, we keep the Debian version.
[22:15] <tiagoboldt> my only doubt in there is, should the debian part be kept? where there's the info about the debian mantainer and all, bellow the [22:16] <ScottK> tiagoboldt: Change it the way you think it should be and pastebin it.  I need to get in ~15 minutes.
[22:18] <superm1> jdong, did you really just fix azureus?
[22:18] <superm1> you're crazy.
[22:18] <tiagoboldt> ScottK, i think that it should stay like this http://pastebin.ca/744875
[22:18] <jdong> superm1: sure looks that way :)
[22:18] <bluekuja> superm1, jdong is a magic guy
[22:18]  * ScottK looks
[22:18] <superm1> jdong, sounds like it's in need for an SRU to me then :)
[22:19] <bluekuja> jdong, leaving. Ping me when online tomorrow
[22:19] <jdong> superm1: unfortunately the fix is in no SRU-able state
[22:19] <bluekuja> jdong, I hope with good news
[22:19] <superm1> jdong, mind you its fairly broken in gutsy/universe right now.
[22:19] <ScottK> tiagoboldt: Remove the blank line 4.  Why did you remove the Homepage field?
[22:20] <bluekuja> good night everyone
[22:20] <tiagoboldt> my bad
[22:20] <jdong> bluekuja: ok, I'll clean up packaging :)
[22:20] <ScottK> jdong: Why not SRUable?
[22:20] <norsetto> bluekuja: nighty nighty
[22:20] <jdong> ScottK: the "fix" is the build with icedtea
[22:20] <jdong> ScottK: and in order to build with icedtea we have to strip out all GCJ-specific packaging elements in the package
[22:20] <superm1> jdong, icedtea made it to universe for gutsy though didn't it?
[22:21] <ScottK> OK.  Does the package work at all now?
[22:21] <jdong> superm1: yes but the fix is too invasive IMO
[22:21] <jdong> ScottK: nope
[22:21] <jdong> ScottK: zero, zilch, nada
[22:21] <jdong> ScottK: GCJ hangs running it, all Sun-based VM's segfault
[22:21] <ScottK> So what's the downside risk of doing this as an SRU?
[22:21] <norsetto> jdong: per niente
[22:21] <jdong> ScottK: I don't know, do you think SRU team will buy it?
[22:21] <tiagoboldt> ScottK, done, final one: http://pastebin.ca/744879
[22:22] <jdong> ScottK: actually the simplest fix is to sync Debian's 2.5.0.4 packaging  with like a 5-line debdiff I am preparing
[22:22] <ScottK> jdong: It's universe, right?
[22:22] <jdong> ScottK: it is universe indeed
[22:23] <ScottK> jdong my son, you have my motu-uvf blessing (we don't have an SRU team anymore).  Make a debdiff and if you can talk a MOTU into uploading it to gutsy-proposed.  Go for it (document I said it was OK in the bug)
[22:23] <ScottK> tiagoboldt: Looks good to me.
[22:24] <tiagoboldt> nice, than that's all
[22:24] <tiagoboldt> now rebuild it, right?
[22:24] <jdong> ScottK: ok, here's the deal though.... We have an oddly repacket 2.5.0.0 package using debhelper GCJ specific stuff everywhere, along with a BUNCH of patches from Fedora 6 ish for making Azureus build under GCJ
[22:24] <ScottK> norsetto: I have to leave in a minute.  Could you pick up with helping tiagoboldt?  I think he needs to build his package, test it, make a debdiff, and attach it to the bug.
[22:24] <jdong> ScottK: IMO this is a huge fscking mess and totally unnecessary; Debian's 2.5.0.4 package uses a simple 10-line Makefile, identical to upstream source tarball, and zero patches
[22:24] <norsetto> ScottK: I'm going to bed soon, but I'll do my best
[22:24] <ScottK> jdong: It's sufficiently ancient and broken that I don't think we need to care.
[22:25] <ScottK> norsetto: Thanks.
[22:25] <jdong> ScottK: it's less "invasive" to just import Debian's 2.5.0.4 in my opinion
[22:25] <tiagoboldt> ScottK, tks than, norsetto I think that this is almost done :)
[22:25] <ScottK> jdong: Great for Hardy, but I doubt for Gutsy.
[22:25] <tiagoboldt> norsetto, I've downloaded the files using the script from mom's, I've already got a control and changeog file updated
[22:25] <norsetto> tiagoboldt: let me catch up with it
[22:25] <jdong> ScottK: ok, so I need to massively strip out the build system in Gutsy azureus then? :(
[22:27] <jdong> ScottK: you think it's strictly impossible to import a new-upstream-version into gutsy-updates? :(
[22:27] <ScottK> jdong: It's not strictly impossible.  I'd say lets wait until Hardy opens and then raise it with the archive admins then.
[22:28] <jdong> ScottK: ok, sounds good, I will prepare the necessary debdiff to get it to compile and run under Hardy with icedtea
[22:28] <ScottK> Great.
[22:28] <ScottK> I've got to run so have a good $TIMEOFDAY all of you.
[22:29] <tiagoboldt> ScottK, ty ;)
[22:29] <tiagoboldt> norsetto, can I give you any info, I think I should generate the diff file ou dsc file now, right?
[22:33] <jdong> WHOO
[22:33] <jdong> bluekuja: package even runs with GCJ java!
[22:36] <norsetto> tiagoboldt: so, what was the delta between the old ubuntu and the new debian?
[22:37] <tiagoboldt> delta as in 'the changes'?
[22:37] <tiagoboldt> most of it was made by mom, I've only had to upgrade de debian control and changelog files
[22:37] <tiagoboldt> I've then entered the src folder and debbuild -S in there
[22:38] <norsetto> tiagoboldt: you should always check anyhow, don't take for granted that mom did a perfect job
[22:38] <tiagoboldt> and I'm now building the package with pbuilder to see if everything goes alright
[22:38] <tiagoboldt> norsetto, and I've did checked everything altered in the changelog that should have be done automatically, everything looked ok
[22:39] <norsetto> tiagoboldt: I'm quite sure you did, thats why I would like to know too
[22:41] <tiagoboldt> then I should install the package and test it, right? if everything looks ok, I should add the generated .dsc to the bug, right?
[22:41] <norsetto> tiagoboldt: can we go back a bit?
[22:42] <tiagoboldt> sure, where?
[22:42] <norsetto> tiagoboldt: to tell me what is the delta
[22:42] <tiagoboldt> delta==changes?
[22:42] <norsetto> tiagoboldt: yes
[22:43] <tiagoboldt> ok, well, there are some bugs and features added, one bug that was corrected in an ubuntu correction was done
[22:44] <tiagoboldt> still, some changes from the previous versions still had to be done(mainly in the debian directory)
[22:45] <norsetto> tiagoboldt: can you paste in a pastebin these changes?
[22:45] <tiagoboldt> sure, w8
[22:46] <tiagoboldt> changelog: http://pastebin.ca/744900
[22:46] <nxvl> ScottK: ping
[22:46] <tiagoboldt> control file: http://pastebin.ca/744901
[22:47] <tiagoboldt> anything else norsetto ?
[22:49] <norsetto> tiagoboldt: did you check rules too?
[22:50] <tiagoboldt> yes, there were some changes there mentioned in the changelog, they were all ok
[22:51] <norsetto> tiagoboldt: ok, so you build your source package already?
[22:51] <tiagoboldt> yup
[22:52] <tiagoboldt> debuild -S in the source folder and pbuilder --build xxx-new-dsc
[22:53] <norsetto> tiagoboldt: ok, in the mom REPORT, it is mentioned a conflict in src/Spell.py what was it?
[22:53] <tiagoboldt> ohh &%$#
[22:53] <tiagoboldt> forgot that :X
[22:54] <tiagoboldt> big ups
[22:54] <tiagoboldt> so, correct that, debuild -S and pbuilder again
[22:54] <tiagoboldt> ok
[22:54] <tiagoboldt> doing it
[22:55] <tiagoboldt> hum, is it only the comment?
[22:55] <tiagoboldt> only 5 lines, I'll past it here
[22:55] <nxvl> tiagoboldt: are you working on 155487?
[22:56] <tiagoboldt> nxvl, yes
[22:56] <tiagoboldt> trying to:P
[22:56] <nxvl> :(
[22:56] <nxvl> tell me if i can helo
[22:56] <nxvl> help*
[22:56] <tiagoboldt> nxvl, sure, it's my first time
[22:56] <nxvl> mine too
[22:56] <tiagoboldt> I'll be glad to work with you
[22:57] <nxvl> what has been made so far?
[22:57] <tiagoboldt> norsetto, here's the problem in spell.py:
[22:57] <tiagoboldt>     else:
[22:57] <tiagoboldt> <<<<<<< gramps-2.2.8-1ubuntu2 (ubuntu)
[22:57] <tiagoboldt>         tv = gtk.TextView()
[22:57] <tiagoboldt>         gtkspell.Spell(tv).set_language(lang)
[22:57] <tiagoboldt> [22:57] <tiagoboldt>         #work around gtkspell bug with tv
[22:57] <tiagoboldt>         tv = gtk.TextView()
[22:57] <tiagoboldt>         gtkspell.Spell(tv).set_language(lang)
[22:57] <tiagoboldt> >>>>>>> gramps-2.2.9-1 (debian)
[22:57] <tiagoboldt>         success = True
[22:57] <tiagoboldt> how should I keep it? it's the same but with the comment, right?
[22:58] <norsetto> tiagoboldt: you know what that is?
[22:58] <tiagoboldt> guess so, in 2.2.8 it was the part before [22:58] <tiagoboldt> after [22:58] <tiagoboldt> is that it?
[22:58] <nxvl> tiagoboldt: have you succesfully download the motu-tools?
[22:59] <norsetto> tiagoboldt: I mean, why there is this "conflict"
[22:59] <tiagoboldt> norsetto, guess not :\
[22:59] <norsetto> tiagoboldt: well, you should understand this before uploading, shouldn't you?
[23:00] <norsetto> tiagoboldt: its not difficult, just look at the changelog(s)
[23:02] <tiagoboldt> sorry, not getting it :\\
[23:02] <norsetto> tiagoboldt: what is in the last ubuntu version and this version that can cause a conflict? It must be a specific ubuntu change, right?
[23:02] <nxvl> tiagoboldt: what is the problem
[23:03] <tiagoboldt> ohh
[23:03] <tiagoboldt> right:)
[23:03] <jdong> bluekuja: bug 57875 updated with debdiff wrt debian, status update, AND testing gutsy .deb. cheers!
[23:03] <ubotu> Launchpad bug 57875 in azureus "Azureus hangs or crashes showing splash screen at start" [High,Confirmed] https://launchpad.net/bugs/57875
[23:04] <nxvl> in these days there is a lot of this bugs since the first days of hardy, didn't it?
[23:04] <tiagoboldt> one problem was corrected both in the upstream and the ubuntu release
[23:04] <norsetto> tiagoboldt: :-)
[23:04] <tiagoboldt> so the code is duplicated
[23:04] <norsetto> tiagoboldt: could this be it? whats in the changelog?
[23:04] <tiagoboldt> I just have do delete one of the entries, the on from ubuntu to keep it as it is from the upstream code :D
[23:05] <norsetto> tiagoboldt: yes, you have to delete the ubuntu one
[23:05] <tiagoboldt> :D
[23:05] <tiagoboldt> and then do the debuild -S and pbuilder again, right?
[23:05] <norsetto> tiagoboldt: one small point first
[23:06] <norsetto> tiagoboldt: can you type this comman in a terminal "man dh_iconcache" ?
[23:06] <norsetto> tiagoboldt: s/comman/command
[23:06] <tiagoboldt> done
[23:06] <norsetto> tiagoboldt: and?
[23:07] <tiagoboldt> since it is called, there will be an icon added
[23:07] <tiagoboldt> right?
[23:07] <norsetto> tiagoboldt: are you on feisty still?
[23:07] <tiagoboldt> nop
[23:08] <tiagoboldt> gutsy for the last 2 months
[23:08] <norsetto> tiagoboldt: ok, so read it carefully
[23:08] <norsetto> tiagoboldt: remark this "This script is going to go away."
[23:08] <tiagoboldt> it calls dhicons
[23:08] <tiagoboldt> yes, so I should switch it with dh_icons?
[23:09] <norsetto> tiagoboldt: yes, you could have seen it if we had run lintian
[23:10] <tiagoboldt> so I should change the changelog and switch that for dh_icons, doing it
[23:10] <norsetto> tiagoboldt: remember that you need to update the changelog
[23:10] <norsetto> tiagoboldt: yes
[23:12] <tiagoboldt> DONE
[23:12] <tiagoboldt> done*
[23:12] <tiagoboldt> debuild -S?
[23:13] <norsetto> tiagoboldt: please prefix it with norsetto: otherwise I may miss it
[23:14] <tiagoboldt> prefix what?
[23:14] <norsetto> tiagoboldt: ok, now build the source and the binaryes, and check that they install and run
[23:14] <tiagoboldt> E: gramps_2.2.9-1ubuntu1_source.changes: bad-ubuntu-distribution-in-changes-file hardy
[23:14] <tiagoboldt> W: gramps source: debian-rules-ignores-make-clean-error line 23
[23:14] <tiagoboldt> W: gramps source: diff-contains-substvars debian/substvars
[23:14] <tiagoboldt> lintian returns that..
[23:14] <norsetto> tiagoboldt: prefix when you want to talk with me
[23:15] <norsetto> tiagoboldt: yes, we should pass these to debian for them to correct
[23:15] <norsetto> tiagoboldt: not the hardy one, thats ok
[23:15] <tiagoboldt> so I'll build it then :D
[23:17] <norsetto> tiagoboldt: ok, now build the source and the binaries, and check that they install and run
[23:20] <tiagoboldt> norsetto, to build the source is it done with pbuilder also?
[23:20] <norsetto> tiagoboldt: debuild, or dpkg-buildpackage
[23:26] <Da_Clover> is anybody haveing some network difficulties with ubu-univ
[23:26] <norsetto> tiagoboldt: gotta go now, once you built, installed and run succesfully you should prepare two debdiffs
[23:26] <tiagoboldt> norsetto, after verifying that everything is ok, what shuold I do?
[23:27] <norsetto> tiagoboldt: one old-ubuntu -> new-ubuntu; and the other new-debian -> new-ubuntu
[23:27] <norsetto> tiagoboldt: you know what a debdiff is?
[23:27] <tiagoboldt> i do
[23:27] <tiagoboldt> create them from what? whole source? .dsc files?
[23:28] <norsetto> tiagoboldt: from the .dsc
[23:28] <tiagoboldt> ok
[23:28] <tiagoboldt> :D
[23:28] <tiagoboldt> than add it to the bug report, assign it to who?
[23:29] <norsetto> tiagoboldt: check the one new-debian->new-ubuntu; old the cnahges in there MUST be reflected in your changelog
[23:29] <norsetto> tiagoboldt: s/old the cnahges/all the changes
[23:29] <tiagoboldt> ok
[23:29] <tiagoboldt> they are
[23:30] <norsetto> tiagoboldt: you don't assign it, you mark it confirmed, unassign yourself, and subscribe ubuntu-universe-sponsors
[23:30] <tiagoboldt> ok :D
[23:30] <norsetto> tiagoboldt: good :-) gotta go now, sleep well
[23:30] <tiagoboldt> I'l finish this and do that afterwards
[23:30] <tiagoboldt> hope it's all ok
[23:30] <norsetto> g'night all
[23:30] <tiagoboldt> thank you so much
[23:30] <tiagoboldt> :D
[23:31] <tiagoboldt> night'
[23:31] <norsetto> tiagoboldt: don't dream debdiffs tonight ....
[23:31] <tiagoboldt> xD
[23:32] <tiagoboldt> that was the other night, otherwise I won't be doing this now=P