[01:34] <sharms> can anyone point me to documentation about lpia?
[01:34] <sharms> ie what flags it uses, where it sets them
[01:34] <sharms> or is it some secret non documented process
[01:46] <superm1> sharms, lpia is no longer a 'supported' architecture starting with karmic
[01:48] <sharms> superm1: yeah I just have a dell mini 9 with the default dell load, and I was trying to figure out exactly how lpia worked
[01:48] <sharms> unfortunately they didnt document almost anything about it
[01:48] <sharms> but dpkg-buildpackage should tell me what I need to know, its just disappointed
[01:48] <sharms> this stuff should be more open
[01:50] <superm1> sharms, i believe basically gcc should be preconfigured right if you install it
[01:50] <superm1> shouldn't need to worry too much about what flags are needed and what not
[01:50] <ajmitch> superm1: lpia has been dropped from support?
[01:50] <superm1> ajmitch, it's just chugging along in case its needed in the future
[01:50] <superm1> but no media will be generated from it i believe
[01:50] <superm1> there was a session at UDS to discuss this
[01:51] <ajmitch> which are the true 'supported' architectures now ?
[01:51] <sharms> superm1: it is important for me to know exactly how they compile packages.  You would think somewhere on the wiki it would say 'For LPIA we use these compile flags: '
[01:51] <ajmitch> and obviously the majority of us weren't at UDS nor do we have time to dig through 100+ wiki pages
[01:51] <superm1> ajmitch, i386, arm*, and amd64
[01:51] <superm1> ppc chugs along on ports
[01:51] <superm1> i forget what the decision was about hppa and sparc though
[01:52] <ajmitch> "discussed at UDS" does irritate me at times for stuff that could be better communicated :)
[01:52] <ausimage> where's Ncommander? thought he worked specifically on those arches
[01:52] <sharms> I agree, I wish the wiki was used a bit more
[01:52] <superm1> sharms, i'd apt-get source glibc and take a look at the flags that are applied in debian/rules
[01:52] <superm1> they should surely be there
[01:52] <ajmitch> sharms: this is the sort of thing that should have made it to ubuntu-devel-announce
[01:52] <superm1> or gcc - i'm not which is the main source package
[01:52] <sharms> ajmitch: it was sent to devel-announce, but had 0 details
[01:53] <NCommander> ausimage, hrm?
[01:53] <sharms> lwn.net post also didnt have details, just people asking for details
[01:53] <sharms> and obviously no responses
[01:53] <ausimage> lpia switches
[01:53] <NCommander> lpia builds with -Os, and a set of tune flags which I don't remember off hand
[01:53] <ajmitch> sharms: I don't see anything beyond the "community-supported ARM release" on u-d-a
[01:53] <NCommander> however, lpia is completely unsupported (and has never been recommended for general usage)
[01:53] <ajmitch> and hppa eol
[01:53] <sharms> NCommander: right but it shipped on my dell, so I have an interest in it
[01:54] <NCommander> We decided at UDS to leave it building, but remove all kernels and such, so its effectively EOL
[01:54] <NCommander> sharms, that's OSG ubuntu, and not consistant with the main archive
[01:54] <NCommander> sharms, distribution upgrades and the like from machines pre-installed with ubuntu are not supported.
[01:54] <NCommander> *OSG's
[01:54] <superm1> that's not correct - it depends on if there is a custom repo in place
[01:54] <sharms> ok maybe you don't understand.  I am a developer.  I write software.  I am simply looking for information on the LPIA settings
[01:55] <superm1> the dell netbooks that ship intentionally have a custom repo, and upgrades aren't supported
[01:55] <sharms> I do not want support, just transparent development
[01:55] <sharms> get it?
[01:55] <superm1> any other dell machines that ship with ubuntu have standard repos and can do standard upgrades and what not
[01:55] <NCommander> superm1, sharms, for lpia/hardy, then the only difference is we target i686 unless that was changed by OSG
[01:55] <NCommander> superm1, then I'm mistaken. My bad.
[01:55] <NCommander> superm1, but I thought dell shipped i386 on all machines that didn't have custom repos.
[01:56] <superm1> NCommander, which is true, and dist upgrades are supported just fine
[01:56] <NCommander> superm1, right, my mistake.
[01:56] <NCommander> sharms, what model of Dell machine do you have?
[01:56] <sharms> Dell Mini 9
[01:57] <superm1> those definitely ship with lpia and custom repos
[01:57] <NCommander> sharms, right, which runs a customized version of Ubuntu from Dell
[01:57] <sharms> again I dont want support, I just want to know what files where changed to enforce the LPIA compile settings on the distro
[01:57] <NCommander> sharms, there is no change. Hardy i386 and lpia are identicial except the later builds against i686
[01:57] <NCommander> and that might not even be true for OSG's archives or hardy
[01:57] <sharms> and being that I see lpia-wrapper is in karmic, someone has to know what files those are
[01:57] <NCommander> sharms, I wrote lpia-wrapper
[01:57] <NCommander> sharms, it was an experiment in building the archive with -Os for karmic only.
[01:58] <sharms> So they named it lpia, but really its just Ubuntu i686?
[01:59] <NCommander> sharms, no. Originally, lpia was to be optimized for the Intel atom processor, and was bootstrapped with the gutsy cycle
[01:59] <NCommander> sharms, that never happened, so lpia and i386 are functionally equivelent
[01:59] <NCommander> Except for minor incompatibilities caused by the lpia architecture string.
[01:59] <NCommander> (aka, why you can't just install skype without playing on the command line)
[02:00] <ajmitch> sounds like a mess
[02:00] <NCommander> ajmitch, s/sounds like/is/g
[02:01] <sharms> I appreciate the info, can you point me to what file stores the default DEB_BUILD_OPTIONS?
[02:01] <NCommander> sharms, its in /usr/share/ somewhere, but there is no difference for lpia vs i386
[02:01] <sharms> ha ok
[02:02] <ajmitch> so lpia was a vicious lie foisted upon us, and we can drop all those diffs that we carry for packages to make them build on lpia?
[02:02] <NCommander> ajmitch, no, we need those still
[02:03] <NCommander> ajmitch, that's the arch-string incompatibility I brought up before.
[02:03] <StevenK> There isn't many of them left
[02:04] <StevenK> I've been killing lpia-only diffs this go round as I get time
[02:04] <ajmitch> carrying deltas againt debian for an effectively EOL arch does cause some headaches :)
[02:05] <NCommander> ajmitch, its not officially EOL until we kill the port outright, the problem is there is a chance we might actually need the lpia port in the semi-future, hence why it didn't get the ax along with the hppa port.
[02:05] <ajmitch> this is why I bitch about the lack of information beyond "We discussed it at UDS" :)
[02:06] <NCommander> ajmitch, where was that said?
[02:06] <sharms> I havent heard any of this information except right here right now
[02:06] <sharms> no mailing list communication of it, nor wiki
[02:06] <ajmitch> what sharms just said
[02:07] <ajmitch> both you & superm1 replied with "We discussed" or "We decided"
[02:07] <ajmitch> not your fault, just that it hasn't got beyond that point
[02:08] <NCommander> ajmitch, sharms, well, I won't speak for the Hardy/lpia used in the custom Dell repos. I know fairly little about it, so I'm not sure if everything I just said w.r.t. to compiler flags is revelent to it
[02:08] <NCommander> But with Gutsy-Jaunty, lpia was essentially i386 Ubuntu compiled targetting i686
[02:09] <ajmitch> NCommander: I'm not caring about the compiler flags, just about the arch being supported & something to care deeply about fixing breakage one
[02:09] <NCommander> ajmitch, its never been supported in the main archive.
[02:09] <sharms> NCommander: with respect to Ubuntu, not Dell,  Matthias Klose sent a mail to Ubuntu Announce about lpia specifically saying: "uses different optimizations options in the compiler,
[02:10] <sharms> different configuration and build options for some packages."
[02:10] <sharms> but with absolutely no details anywhere else
[02:10]  * ajmitch must have always got the wrong impression that it was then
[02:10] <NCommander> ajmitch, the only reason its supported for PPAs is because you can easily virtualize i386 :-)
[02:10] <sharms> which makes it hard to get involved with understanding it, when the wiki has no info and the mailing lists turn up no results other than people guessing what they are, and some moblin guys suggesting what might be good flags
[02:10] <NCommander> sharms, that was earlier this cycle, right?
[02:10] <sharms> I wouldnt know because further information isnt available except here on IRC :)
[02:11] <NCommander> sharms, most people do development on i386 or amd64, so there isn't a lot of people who would be interested in the i386-lpia differences
[02:11] <NCommander> (or those people could be sadistic like me, and use an ia64 desktop)
[02:11] <sharms> right, but if I want to fix a bug, finding some kind of information would be great
[02:11] <ajmitch> NCommander: I don't envy your power bill
[02:12] <NCommander> ajmitch, the same circuit also powers three sparcs, my laptop, three ARM boards, the powermac, a powerbook, a PReP PPC, the TV, and the XBox 360
[02:12] <NCommander> ajmitch, I'm kinda wondering if the next machine will finally blow the breaker.
[02:12] <ajmitch> 3-phase power? ;)
[02:12] <sharms> NCommander: and someone had to discuss compiler flags, build options and configurations somewhere.  It just wasn't done anywhere in the open that people can reference
[02:13] <sharms> Klose didnt just go off as a lone cowboy and set all that up I am sure
[02:13] <NCommander> ajmitch, the power bill isn't too bad. I make up for it in the heating costs of a weekend.
[02:13] <ajmitch> NCommander: if you know the right people to poke, get lpia renamed to lpia (unnofficial) on https://edge.launchpad.net/ubuntu/karmic
[02:14] <ajmitch>  pages like that are what mislead me
[02:14] <sharms> ajmitch: it is only misleading because you didnt hear the uds discussion :)
[02:14] <NCommander> ajmitch, that probably should also have armel as official :-/
[02:14] <ajmitch> sharms: I obviously needed to stay up until 4AM to listen in on it :)
[02:15] <ajmitch> NCommander: if armel is official, then yes it should be :)
[02:15] <sharms> ha
[02:15]  * NCommander isn't even sure who can flip that switch
[02:15] <NCommander> It requires a duck and that's all I know
[02:15] <ajmitch> sharms: UDS was about 10 or 11 hours behind my timezone, made listening in on anything a bit hard
[02:15] <TheMuso> Wouldn't signalling a port as official require it to be moved to a.u.c?
[02:16] <sharms> yeah it would be cool to see more blog entries etc about technical ideas
[02:16] <NCommander> TheMuso, no, that's just for mirroring reasons. lpia has been marked official since hardy(?), and its on ports.u.c
[02:16] <sharms> so I can atleast google it
[02:16] <TheMuso> NCommander: oh right.
[02:16] <NCommander> sharms, *cough* I have meant to send an email about that, but it slipped off my TODO list
[02:17] <sharms> NCommander: well the info is much appreciated, regardless of date presented :)
[02:17] <NCommander> I probably need a RT ticket to get the (unofficial) flag changed
[02:17] <ajmitch> do the magic, I don't care how :)
[02:18] <NCommander> wow, the last upload to dapper was more than two months ago
[02:19] <ajmitch> I guess the list of critical bugs to get fixed has shrunk a bit
[02:19] <ajmitch> apart from security stuff
[02:20] <NCommander> ajmitch, in dapper?
[02:20] <ajmitch> do dapper-security uploads go through dapper-changes?
[02:21] <ajmitch> because I'm sure there have been things to get fixed in those 2 months
[02:21] <jdstrand> iirc, there is a bug that prevents -security uploads from going to -changes
[02:21] <ajmitch> right, so -changes is underrepresenting the number of uploads, no big problem
[03:18] <ScottK> IIRC it's a misfeature, not a bug but the result is the same.
[03:56] <Andphe> hello everyone, newbiew here
[03:56] <Andphe> I took a debian package and try to port it to ubuntu
[03:56] <Andphe> indeed I put it at my ppa https://launchpad.net/~andphe/+archive/ppa
[03:56] <ScottK> Andphe: What package?
[03:57] <Andphe> v4l2ucp
[03:57] <Andphe> right now I'm trying to add it a menu entry and a icon
[03:57] <Andphe> I read doc about dh_installmenu, but not sure how to proceed
[03:58] <Andphe> this is the rules file
[03:58] <Andphe> http://paste.ubuntu.com/193158/
[03:58] <Andphe> I added the cp line to copy the icon
[03:58] <ScottK> The package is already in Ubuntu in Karmic.
[03:58] <Andphe> but not sure where to put the dh_installmenu
[03:58] <ScottK> You might look at that version.
[03:58] <Andphe> ScottK really ?
[03:58] <Andphe> that is a great and bad news
[03:59] <ScottK> v4l2ucp | 1.3-0ubuntu1 | karmic/universe | source, amd64, i386
[03:59] <Andphe> because the package is in karmic but I wasted my time
[03:59] <Andphe> well
[03:59] <Andphe> thank you
[03:59] <ScottK> No problem.
[03:59] <Andphe> I'll take a look
[03:59] <Andphe> ;(
[03:59] <ScottK> I'd guess you likely learned something in the process, so I doubt it was a waste.
[03:59]  * Andphe going to cry to another place
[04:00] <Andphe> yep I learned something :)
[04:00] <Andphe> figthing with the menu issue
[04:00] <Andphe> thanks again
[04:00] <Andphe> bye
[04:00] <ScottK> Bye.
[04:08] <Andphe> get back
[04:09] <Andphe> the karmic one doesn't have a menu neither
[04:09] <Andphe> nor a icon
[04:14] <ausimage> Andphe: at least for gnome the menu item is .desktop file... and the format is fairly simple
[04:15] <Andphe> ausimage: as I understand having a v4l2ucp.menu file the dh_installmenu helper would do the trick
[04:15] <Andphe> right ?
[04:15] <Andphe> having this rules file http://paste.ubuntu.com/193158/
[04:16] <Andphe> where should go the dh_installmenu line ?
[04:16] <ausimage> not sure... but creating the a desktop file to be included is quite easy
[04:16] <ausimage> I personally just place the desktop file where it is supposed to be
[04:16] <Andphe> I see
[04:17] <ausimage> though I am just learning all the ropes too :)
[04:17] <Andphe> finally found a example
[04:17] <Andphe> http://www.togaware.com/linux/survivor/rules.html
[04:17] <ausimage> http://paste.ubuntu.com/193168/ <== my desktoop
[04:17]  * Andphe trying
[04:17] <Andphe> Thanks for share
[04:17] <ausimage> *er my desktop menu file...
[04:18] <ausimage> yw
[04:42] <ausimage> anyone know why dch is not picking up my version changes?
[04:42]  * ausimage thinks hand edits were far simpler to manage at this rate :/
[04:43] <lifeless> ausimage: dch edits the changelog, it doesn't look at diffs or anything
[04:43] <ausimage> lifeless... I thought it would advance my versions automatically...
[04:44] <ausimage> I am now stuck with a cli editor to write a new stanza... :(
[04:45] <ausimage> should it not at least check the version info in the directory name itself?
[04:46] <lifeless> no
[04:46] <lifeless> you tell dch what you want it to do
[04:46] <lifeless> dch --help
[04:47] <ausimage> I looked...
[04:47] <ausimage> :/
[04:47] <ausimage> could not tell which switch advances the versioning
[04:48] <ausimage> a nice gui editor.... select copy paste click click done.... ;)
[04:51] <bddebian> dch -i, dch --nmu, dch --qa will all advance the version
[04:52] <ausimage> which does the app versioning?
[04:52] <bddebian> ???
[04:53] <ausimage> the way I read the switches they only affected the package versioning
[04:53] <bddebian> Unless it is a native package, of course
[04:53] <bddebian> Upstream does the app versioning
[04:53] <ausimage> I am the upstream... for the package...
[04:54] <bddebian> Then you set the version :)
[04:54] <ausimage> and when I use dch I would expect to see the version in the directory :/
[04:54] <ausimage> directory name
[04:54] <bddebian> No, dch will never adjust an upsteam version
[04:54] <bddebian> Nor does it change the dir name afaik
[04:55] <ausimage> it did I think once for me
[04:55] <bddebian> Well unless it is a native package I should say.
[04:55] <bddebian> Was it a native package?
[04:56] <ausimage> um that time it was I think... only cause it can't seem to realize the taz.gz is still in the parent dir :/
[04:58] <ausimage> bddebian and last few package turns I made with my package it has wanted me to -0ubuntu in addition to the orig for the tarball...
[06:03] <ausimage> I was wondering if someone could tell me why my package builds on jaunty but not karmic...
[06:03] <ausimage> it is in revu here http://revu.ubuntuwire.com/details.py?upid=6023
[06:04] <ausimage> I did nothing to the package 'cept change karmic to jaunty :/
[06:05] <ausimage> from my ppa log of the karmic build it claims a dir path is missing :/ from soovee-common
[06:05] <persia> ausimage, Do you have a karmic buildlog?
[06:06] <ausimage> https://edge.launchpad.net/~ausimage/+archive/soovee/+build/1069853/+files/buildlog_ubuntu-karmic-i386.soovee_1.07.2-0ubuntu-1~jaunty~ppa1_FAILEDTOBUILD.txt.gz
[06:06] <ausimage> persia is that ok?
[06:07] <StevenK> dh_install: soovee-common missing files (debian/tmp/usr/lib/python2.6/dist-packages/soovee_app/pages/*), aborting
[06:07] <StevenK> I guess Python in Karmic is putting them somewhere else
[06:07] <ausimage> yup... but it does not complain about it with jaunty
[06:07] <ausimage> oh ahh :/
[06:07] <StevenK> Hard coding python version is bad, too
[06:07] <StevenK> You know, things are allowed to change from Jaunty to Karmic?
[06:08] <ausimage> yeah... but I was not aware of what did
[06:08] <ausimage> and I did not know how else to set the *.install lists
[06:09] <persia> I think you'll want to play with dh_install --list-missing
[06:09]  * ausimage has already been accused of using a bigger tool than necessary when it comes to packaging ;)
[06:09] <StevenK> Bigger *hammer*
[06:09] <ausimage> with the changelog pointing at karmic ?
[06:09] <persia> But you might also want to try to find someone who has experience splitting python packages: there may be an especially good way to do things in an automated fashion.
[06:10] <ausimage> oh yeah that would be nice...
[06:10] <persia> Doesn't matter what the changelog says.  It matters what you build against.
[06:10] <persia> Also, you ought to delete debian/souvee.install: it's a useless file.
[06:10] <ausimage> k that I can do...
[06:11] <persia> changelog.sch.save looks like a leftover as well.
[06:12] <ausimage> cleaned that up
[06:14] <StevenK> dh 7 needs to support applying patches and then cdbs can completly die
[06:14] <ausimage> persia it looks like dh_install needs me to build first :/
[06:14] <persia> StevenK, dh --with-quilt
[06:15] <ausimage> cause it does not seem to find the dir eitherway...
[06:15] <persia> ausimage, Just add --list-missing in your rules file, build, and examine the build log.
[06:15] <StevenK> persia: ARGH
[06:15] <StevenK> persia: But Quilt BURNS
[06:15] <ajmitch> StevenK: what don't you like about it?
[06:15] <persia> StevenK, Then write a --with addon for your favorite patch system :p
[06:15] <StevenK> ajmitch: It's a sledgehammer of a patch system
[06:15] <ausimage> same thing persia...
[06:16] <StevenK> And I invariably break my kneecaps while swinging it
[06:16] <persia> ausimage, Yes, the error is expected.  It's the other information in the log that will tell you what you aren't installing.
[06:16] <StevenK> Having to quilt new ; quilt add ; edit ; quilt refresh ; quilt omg-it-hurts ...
[06:17] <persia> You ought only need to push -a, add, pop -a.
[06:17] <StevenK> If I'm modifying a patch that is at the top of the stack, yes
[06:18] <ausimage> i thought install got its files after building :/
[06:18] <StevenK> It requires too much workflow to use effectively
[06:19] <persia> Different definitions of "build".  There's "build" in the sense of converting source into the target format (usually just copying stuff around for python), and "build" in the sense of creating binary packages.
[06:19] <persia> StevenK, Then write more addons.  It oughtn't be hard to create a dpatch add-on.  simple-patchsys probably requires a bit more effort.
[06:20] <ausimage> i think it is convert source into target part....
[06:20] <StevenK> What?
[06:21] <ausimage> k that is wierd... i did a dpkg-build package with it set as karmic build and it built
[06:22] <ausimage> though I know not to put weight in that
[06:22] <ausimage> :S
[06:24] <ausimage> I guess I need to ask another python packager for help on this....
[06:24] <ausimage> anyone know who qualifies?
[06:24] <persia> StevenK, Debian bug #527255 probably contains sufficient guidance if you're actually going to do it...
[06:27] <ausimage> persia it seems that pythoncentral might be borked :/
[06:27] <ausimage> it shows the files in lib.linux-i686-2.6lib.linux-i686-2.6
[06:28] <ausimage> i meant lib.linux-i686-2.6 not python-2.6
[06:30]  * ausimage is overtired and might be reading that right :/
[06:31] <persia> ausimage, I can't tell you what is right, because I don't know.  I can only point you at tools that can help you figure out what might be right.
[06:32] <ausimage> ah sorry...
[06:33] <persia> No need to be sorry.  I just didn't want you to think I was ignoring you :)
[06:34] <dholbach> good morning
[06:38] <fabrice_sp> hey dholbach ! Good morning
[06:38] <dholbach> hi fabrice_sp
[06:40] <fabrice_sp> dholbach, did you see my answer in #384936?
[06:40] <fabrice_sp> bug #384936
[06:40] <dholbach> no not yet
[06:40] <fabrice_sp> ok
[06:41] <dholbach> fabrice_sp: I hope the Debian maintainers adopt the change
[06:41] <dholbach> nhandler: great work on getting the perl session on the schedule!
[06:44] <fabrice_sp> dholbach, we can wait, as I can't get the gmerlin-avdecoder merge sponsored, so no new openmovieeditor that will make use of that lib... :-(
[06:44] <ajmitch> morning dholbach
[06:47] <dholbach> hiya ajmitch
[06:51] <porthose> dholbach: good mourning, when you have time, can we talk about bug #385066?
[06:51] <dholbach> porthose: sure
[06:52] <porthose> I think the change in src/main.c should have been applied with a patch sytem
[06:52] <porthose> but it wasn
[06:52] <porthose> wasn't
[06:53] <dholbach> porthose: icon-slicer doesn't use a patch system in Ubuntu right now, so it seems that the maintainer was happy to directly patch the source
[06:54]  * fabrice_sp remembers a similar discussion :-)
[06:55] <porthose> but I thought all changes outside of the debian directory should be applied with a patch system?
[06:55] <dholbach> porthose: that depends on the preference of the maintainer
[06:56] <dholbach> porthose: there are lots of packages that directly apply patches (especially native packages or packages that have the full source in a version control system)
[06:57] <porthose> ok, guess I need to do some more detective work, thanks ;-)
[06:57] <dholbach> no worries
[06:57] <dholbach> fabrice_sp: I'll take a look at gmerlin-avdecoder in a bit
[06:57] <dholbach> (sorting out some other stuff right now)
[06:58] <fabrice_sp> porthose, that's quite easy to detect: just have a look at debian diff file. If it contans change to the source, no patch system needed :-)
[06:58] <porthose> that's what I am doing right now :)
[06:58] <qiyong> may i ask an apt-mirror question?
[06:59] <dholbach> fabrice_sp, porthose: or run "what-patch" from the ubuntu-dev-tools package :)
[06:59] <fabrice_sp> dholbach, thanks! :-) As it's a new package from Debian Multimedia, it's not so easy to find someone willing to look at it :-)
[06:59] <fabrice_sp> !ask | qiyong
[07:00] <qiyong> how can I get apt-mirror to mirror two arch's ?
[07:00] <StevenK> List them in the config file
[07:00] <qiyong> set defaultarch i386 amd64
[07:00] <qiyong> ^doesn't work
[07:01] <qiyong> set defaultarch i386, amd64
[07:01] <qiyong> ^neither
[07:01] <StevenK> My apt-mirror manual page doesn't list defaultarch at all?
[07:01] <persia> fabrice_sp, porthose: Note that debian/README.source, if present, should provide detailed advice on how a package is to be patched.  Also, be aware that in some cases there will be a mix of patch systems and non-patch systems, for annoying reasons related to how the some of the patch systems work: in these cases, use the patch system if possible.
[07:03] <StevenK> qiyong: http://ubuntuforums.org/archive/index.php/t-599479.html
[07:04] <fabrice_sp> persia, in general, I use the existing patch system (basically, if there is a patches directory in debian), otherwise, look at the diff file to see if some files has been modified
[07:04] <qiyong> StevenK: so?
[07:04] <fabrice_sp> what is Nuku-Nuku? a bot?
[07:05] <persia> fabrice_sp, In most cases, that ought work.
[07:05] <qiyong> StevenK: i want to mirror both amd64 and i386
[07:05] <StevenK> qiyong: I refuse to spell it out for you, read the documentation.
[07:06] <Hobbsee> fabrice_sp: yeah, it's a bot
[07:06] <qiyong> StevenK: i get it :)
[07:06] <qiyong> StevenK: deb-arch
[07:07] <persia> Hobbsee, I can't seem to remember the right syntax.  Can you make it go away again, unless you know it to be an approved bot?
[07:09] <Hobbsee> persia: it's lucidfox's - the best way to get it gone is to probably request it not be here.  I'm not sure why it's here to start with
[07:10] <persia> Hobbsee, Oh, suddenly I have a reasonable path to solution.  Thanks.
[07:10] <Hobbsee> persia: you're welcome
[07:10] <persia> I can't complain about a bot, given the somewhat indirect nature of my own access, but I do intend to complain about the annoying responses I get all the time.
[07:12] <Hobbsee> persia: yeah, it certainly shouldn't be triggering on ! and should be changed.
[07:13] <Hobbsee> or at least, if it wants to stay in ubuntu land
[07:13] <persia> Right.  non-triggering bots for various purposes (personal logging, intermediation of access, etc.) seem reasonable, so long as they are mostly indistinguishable from normal users.
[07:14] <persia> Active bots seem to violate the "no bots" policy fairly clearly.
[07:14] <Hobbsee> indeed.  I think ! is the standard, so it's probably just an oversight.  I'll point it out, or you're welcome to - you'll probably see LucidFox first
[07:15] <persia> Perhaps.  I'm at least motivated, as I've been becoming increasingly annoyed by that bot for the past several weeks.
[07:17] <nixternal> so what are we talking about in here that has the screen all filled up?
[07:18] <dholbach> fabrice_sp: is there a reason the debian-multimedia folks don't use those build-deps?
[07:20] <dholbach> fabrice_sp: it ftbfs for me - I just added a comment to REVU
[07:22] <Stupendoussteve> dholbach: Are you around?
[07:23] <dholbach> Stupendoussteve: yes
[07:24] <fabrice_sp_> dholbach, I'll check. Thanks
[07:25] <fabrice_sp_> Oh: it FTBFS because of a change in karmic. I have to check the correct changes
[07:26] <Stupendoussteve> dholbach: In your comment on bug #374350 you asked why I updated config.sub to 2008. I actually don't really know. That is to say, the a previous Ubuntu delta updates config.sub to a 2007 version without it being mentioned in any changelog
[07:26] <dholbach> Stupendoussteve: some packages will automatically update config.{sub,guess} if available and that's fine
[07:27] <dholbach> Stupendoussteve: I just wasn't sure if there was a reason why you mentioned it :)
[07:27] <dholbach> ... if there was a specific reason
[07:27] <Stupendoussteve> I see. Is it something that I shouldn't bother doing myself in a merge?
[07:27] <dholbach> Stupendoussteve: if the package builds as expected without updating, I wouldn't bother
[07:28] <persia> It's not usually done as part of a merge, although some packages auto-update at source-build time (which I personally find to be the *most* annoying of the three possible times to update)
[07:28] <Stupendoussteve> I see, I'll remove that part when I work on the other changes
[07:28] <dholbach> Stupendoussteve: let me know when you updated it and I'll take a look again
[07:28] <Stupendoussteve> That package was confusing. If I used mergemaster the deb-ubuntu diff was 80KiB, but the diff from previous to new Ubuntu versions ended up being like 4KiB, something fishy
[07:44] <iulian> Erm, how do I stop the update-manager from popping out?
[07:46] <slytherin> iulian: check release notes of jaunty
[07:48] <iulian> slytherin: Aha! Got it, thanks.
[08:08] <Stupendoussteve> dholbach: Patch in bug #374350 looks better now
[08:11] <fabrice_sp_> dholbach, gmerlin-avdecoder is in the NEW queue of Debian (http://ftp-master.debian.org/new/gmerlin-avdecoder_1.0.0-1.html). How long does it  take to have it accepted? automatic merge would do the trick
[08:12] <fabrice_sp_> (and by the way: debian added the same build dependency, except libmjpegtools :-) )
[08:13] <dholbach> fabrice_sp_: nice... no idea how long it will take, but I think it's fine to merge from NEW... or something
[08:17] <dholbach> Stupendoussteve: good work - uploaded
[08:17] <persia> NEW isn't public, so it's non-trivial to merge and guarantee matched orig.tar.gz
[08:17] <persia> Better to wait until closer to DIF.
[08:19] <fabrice_sp_> let's wait, then. It has been uploadded by the same guy as gmerlin, so I think it should go fast
[08:20] <fabrice_sp_> 2 days ago
[08:22] <fabrice_sp_> another question: when dealing with bug #383825, I found a FTBFS in koffice. Is it better to open a new bug report, attach the debdiff, and subscribe main sponsors??
[08:25] <persia> fabrice_sp_, If you can fix more than one thing in a single bug, that's a win.  Save the bug numbers, as there is a limited supply.
[08:26] <fabrice_sp_> persia, ok. I'll attach the debdiff to this one, then. Thanks for your answer!
[08:26] <persia> fabrice_sp_, Thanks for fixing the bug :)
[08:26] <fabrice_sp_> :-D
[08:27] <persia> Don't forget to mention everything in the changelog entry though: the sponsors will be checking to make sure your changelog matches the changes, even if you fix a few extra bugs along the way.
[08:34] <fabrice_sp_> sure
[09:29] <cjwatson> sharms: I don't know if it was explicitly stated by anyone in the discussion last night, but just to be clear, there's no "secret" buildd magic involved in lpia - it's entirely in packages, so for example you can just look at the gcc-4.3 etc. source package to see the default compiler flags. There is no default setting of DEB_BUILD_OPTIONS on lpia or any other architecture.
[09:34] <persia> Well, there's DEB_BUILD_OPTIONS=parallel=n+1, but that's true for every architecture.
[09:34] <persia> (and only on the buildds)
[09:40] <savvas> is this line ok in debian/install with debhelper >= 7: data/etc/ ./
[09:42] <persia> savvas, Yes, but it's awfully odd.  What is it intended to do?
[09:43] <savvas> hm.. you're right
[09:43] <savvas> I guess conffiles should be better :)
[09:43] <persia> savvas, What are you trying to accomplish?
[09:44] <savvas> I have some configuration files that need to be installed
[09:44]  * persia glares at "amd64 not in arch list: amd64 arm armel hppa i386 powerpc sparc kfreebsd-i386 kfreebsd-amd64 ppc64 lpia -- skipping"
[09:44] <savvas> http://paste.ubuntu.com/193311/
[09:45] <persia> savvas, You want "data/etc/* etc/" (assuming such a glob won't have false matches)
[09:47] <savvas> that's better, thanks!
[09:47] <savvas> er.. just for the record, debian/conffiles isn't the place for such files?
[09:50] <persia> I generally don't put anything in debian/conffiles, and trust debhelper to just mark anything I stick in /etc as a conffile (although I forget which bit of magic does this)
[09:51] <savvas> I heard that too, thanks again :)
[09:52] <savvas> heard or saw, can't remember actually :P
[09:52] <persia> Ah, it's dh_installdeb.  "In V3 compatibility mode and higher, all files in the etc/ directory in a package will automatically be flagged as conffiles by this program, so there is no need to list them manually in package.conffiles."
[09:58] <cjwatson> debian/conffiles never caused files to be installed anyway
[09:58] <cjwatson> it simply flagged files that had already been installed by some other method
[10:07] <huayra> hi, does the MOTU mono team have a channel or shall I just ask here?
[10:07] <huayra> I am working with package of a mono app (iFolder)
[10:07] <huayra> and will need sponsoring from you guys
[10:07] <huayra> :)
[10:08] <huayra> to get it into Karmic
[10:08] <james_w> hi huayra
[10:08] <james_w> your best bet is #debian-mono on OFTC
[10:08] <huayra> if anyone here knows about mono apps package, please point me towards sn.exe
[10:09] <huayra> I thought debian used to hang @ freenode
[10:09] <james_w> they used to
[10:09] <james_w> they moved a few years ago
[10:09] <huayra> been hanging so long with Ubuntu that I hardly catch debian news anymore...
[10:09] <huayra> thanks james_w :-)
[10:09] <huayra> one question though.,
[10:10] <huayra> We should try to get it into debian first?
[10:10] <james_w> yup
[10:10] <james_w> especially for mono packages
[10:10] <huayra> what if we do it the other way around?
[10:10] <huayra> I don't believe we will get it into karmic if we do it through debian
[10:10] <james_w> because those involved with mono in Ubuntu tend to work through Debian
[10:11] <james_w> so they will just encourage you to do that anyway
[10:11] <huayra> but, it is possible to do it the other way, isn't it?
[10:11] <james_w> well, start with talking to them
[10:11] <huayra> I mean, theoretically?
[10:11] <james_w> you can work on the packaging with them, get review
[10:11] <huayra> k
[10:11] <james_w> and they know how to get it quickly in to karmic if needded
[10:11] <huayra> thanks
[10:34] <slytherin> huayra: you can talk with directhex here but I believe he is also part of Debian pkg-mono team.
[11:02] <Laney> huayra, james_w: It's #debian-cli @ OFTC now, fyi
[11:03] <james_w> oops, thanks Laney
[11:03] <Laney> no worries
[11:25] <slytherin> are the autosyncs stopped currently?
[11:28] <persia> Might be off for the Alpha2 Freeze.  Ought be running again by the end of the week.
[11:28] <persia> (and it's only kinda semi-automatic anyway: there's this script the archive-admins run)
[11:31] <Laney> I replied to that mail, but it got held for moderation as I picked the wrong from address
[11:33] <slytherin> Laney: which mail?
[11:33] <Laney> the one where the guy asked about autosync
[11:33] <slytherin> persia: Can't it be added to a cron job?
[11:34] <persia> slytherin, I suppose.  It might even be in a cron job sometimes.  I still think that if it's off now, it's because of Alpha 2.
[11:34] <persia> One of the reasons I believe it not to be in a cron job is that I suspect the script sometimes has errors, and it's useful to have a human check the results.
[11:34] <slytherin> Right. I thought same but considering that pycaml is in universe I was wondering why universe is frozen for alpha 2
[11:35] <persia> I don't think the script differentiates.  I also prefer the freezes to be *everywhere* because there are several universe flavours.
[11:36] <slytherin> hmm
[11:56] <ivoks> maybe a stupid question...
[11:56] <ivoks> is there a reason why one package would conflict with it self?
[11:56] <persia> ivoks, versioned conflicts maybe, as a result of some sequence of package name changes over time.
[11:57] <ivoks> without version
[11:57] <ivoks> like this:
[11:57] <persia> But that would just be cruft.
[11:57] <ivoks> Package: libopenais3-dev
[11:57] <ivoks> Conflicts: libopenais3-dev
[11:57] <ivoks> :)
[11:57] <persia> No, that's just wrong.
[11:57] <ivoks> i thought so...
[11:57] <ivoks> that should've been:
[11:58] <ivoks> Conflicts: libopenais2-dev
[11:58] <persia> I suspect there was once a libopenais3-n-dev that (correctly) conflicted with libopenais3-dev, and then the -n- was dropped, but the Conflicts wasn't dropped.
[11:58] <persia> That would make more sense.
[11:58] <ivoks> how about conflicting lib-dev and providing lib-dev?
[11:58] <ivoks> while package is libX-dev
[11:59] <ivoks> that would make sense if we would like to replace lib-dev with libX-dev, right?
[11:59] <persia> ivoks, That's permitted, and not uncommon when transitioning from libfoo-dev to libfooN-dev
[11:59] <ivoks> right...
[11:59] <persia> But "Conflicts" and "Provides" play funny.  I forget precisely how the overrides work.
[12:00] <persia> (in other words, do a test install as a dependency of something just to make sure)
[12:00] <ivoks> right...
[12:10] <maxb> A package never conflicts with itself, therefore "Provides: foo; Conflicts: foo" ensures that only one package doing that can be installed at a time
[12:10] <ivoks> yeah, that's normal
[12:11] <ivoks> this one is conflicting it self :)
[12:11] <ivoks> anyway, i fixed it
[12:45] <nhandler> Has anyone ever gotten "internal error: command failed with error code 123" with lintian before?
[12:52] <joaopinto> hello
[12:52] <joaopinto> I am using a cdbs debian/rules, and calling dh_desktop from the install/package rule, however my postinst script is empty
[12:52] <joaopinto> any ideas ?
[12:53] <soren> What did you expect to be in there?
[12:53] <joaopinto> I do have the #DEBHELPER# on debian/postinst
[12:53] <joaopinto> the script calling update-desktop-database
[12:53] <joaopinto> that was supposed to be inserted by dh_installdeb
[12:54] <soren> Well, dh_desktop is a no-op these days.
[12:54] <persia> joaopinto, dh_desktop was replaced by a trigger: man dh_desktop
[12:55] <soren> What's the package?
[12:55] <joaopinto> persia, this is a package for jaunty, wasn't that trigger included on karmic ?
[12:55] <joaopinto> soren, not on the repositories
[12:55] <soren> joaopinto: That's not what I asked :)
[12:55] <joaopinto> my man dh_desktop does not metion a triger
[12:56] <joaopinto> solarion, acetoneiso
[12:56] <joaopinto> ops, soren
[12:56] <persia> joaopinto, Yes, in jaunty it still does something.
[12:59] <joaopinto> this package is for jaunty :\
[12:59] <joaopinto> I must be missing something
[13:01] <persia> Are you defining a MIME type in your .desktop file?
[13:01] <persia> If not, dh_desktop doesn't do anything.
[13:02] <joaopinto> I know, I am
[13:02] <joaopinto> MimeType=application/x-iso
[13:03] <directhex> yay, /me just prepared a new package
[13:03] <joaopinto> hum reading on some ML mentions that the cdbs gnome class is expected to add the call
[13:03] <joaopinto> but reading from the example file comments, it should be added by dh_installdeb
[13:04] <persia> Erm, no.
[13:05] <persia> dh_desktop is the only bit that adds stuff to the postinst.
[13:05] <persia> the GNOME CDBS class calls dh_desktop.
[13:05] <joaopinto> I am calling it on install/package:
[13:06] <persia> And in your buildlog, is that early enough?  Perhaps you could add "cat debian/foo.postinst" after your dh_desktop call in rules, and check that build log.
[13:07] <joaopinto> well, it does not change debian/postinst it is expected to change debian/package/DEBIAN/postinst , it does not
[13:07] <persia> It should change debian/foo.postinst, which then gets copied to DEBIAN/postinst.
[13:08] <joaopinto> hum ? isn't #DEBHELPER# expected to be ketp untouched ?
[13:08] <persia> Anyway, `cat` is a great tool to use in rules files to understand the state of the build during the build.
[13:08] <persia> joaopinto, #DEBHELPER# is used as a placeholder for dh_foo to add stuff at build time.
[13:09] <persia> (or maybe it does happen in dh_installdeb: now I'm confused)
[13:09] <joaopinto> persia, right, but isn't that just for the final posinst ?
[13:09] <joaopinto> it does not make sense it being changed during building, since it works as a build input file
[13:10] <joaopinto> as far as i understand, the #DEBHELPER# is expected to be replaced only on debian/package/DEBIAN/postinst, not on the original postint
[13:11] <joaopinto> and it does, it is replaced by an emptry string, and nod the dh_desktop script as expected
[13:11] <joaopinto> not
[13:12] <persia> Hrm.  Well, try with DH_VERBOSE, perhaps.
[13:14] <soren> joaopinto: At the time dh_desktop is called, where exactly is the .desktop file?
[13:15] <joaopinto> soren, hum, good question
[13:15] <soren> joaopinto: It needs to be in $tmp/usr/share/applications
[13:15] <soren> If you're copying it in there at a later stage, that's your problem.
[13:15] <soren> If dh_desktop doesn't find a .desktop file in there with a MimeType key, it doesn't do anything.
[13:16] <soren> I'm looking at acetoneiso's SVN, and I don't see a Makefile, so it's a bit for me to guess when it gets installed.
[13:16] <joaopinto> ok, dh_desktop is beeing called before dh_install that is probably my problem
[13:16] <joaopinto> solarion, you need to call qmake to get the Makefile
[13:16] <joaopinto> ops, soren
[13:17] <soren> I'm looking at the websvn thing, so I'm out of luck.
[13:17] <persia> Rather, if it doesn't find a .desktop file IN /usr/share/applications.  It ought be a bit more flexible, honestly, but the complaint was that it was running too often, and the corner cases where it doesn't work are often masked by it running several times during an installation run.
[13:17] <soren> ..but you seem to have identified the problem now.
[13:17] <joaopinto> now I just need to find the cdbs post-install rule name :P
[13:17] <soren> persia: Isn't that what I said?
[13:18] <persia> Hrm.  I should read better.  There's other valid places to put .desktop files to have them show up in the menus, and those don't work correctly.
[13:19]  * soren wouldn't know
[13:20] <joaopinto> according to CDBS doc,  install/package should be post-install actions, however it's called before the debhelper specific install rule
[13:23] <joaopinto> perl -pe 's~#DEBHELPER#~qx{cat debian/acetoneiso.postinst.debhelper}~eg' < debian/postinst > debian/acetoneiso/DEBIAN/postinst
[13:23] <joaopinto> can anyone translate this to english :P ?
[13:24] <cjwatson> "read debian/postinst; replace '#DEBHELPER#' string with contents of debian/acetoneiso.postinst.debhelper; write result to debian/acetoneiso/DEBIAN/postinst"
[13:24] <joaopinto> nice, it worked, just had to move the dh_desktop call to binary-package/app:
[13:24] <joaopinto> cjwatson, tks
[13:24] <cjwatson> perhaps you were running dh_desktop and dh_installdeb in the wrong order
[13:24] <joaopinto> soren and persia, tks, it was the dh_desktop call place
[13:25] <cjwatson> dh_installdeb must be run after anything that produces autoscript fragments
[13:25] <joaopinto> I was, because according to the CDBS docs the install/* is a post-install rule, and it's a pre-post-install :P
[13:26] <joaopinto> the problem was with dh_install being called after dh_desktop
[13:26] <joaopinto> it's fixed now, tks :)
[13:47] <joaopinto> is there a page where you can see package versions for multiple debian based distros/repositories ?
[13:48] <Hobbsee> an output of rmadison?
[13:48] <Hobbsee> actually, i think there is somewhere
[13:49] <joaopinto> rmadison only works with a single db, right ?
[13:49] <cjwatson> depends on what server it's talking to
[13:50] <cjwatson> we set it up to talk to madison-lite; you can instruct madison-lite to look at whatever archives you want
[13:50] <cjwatson> all you need is the Packages and Sources files in the appropriate layout
[13:50] <joaopinto> the db backend is just a Packages/Sources parser, os is it a real db ?
[13:52] <persia> joaopinto, https://launchpad.net/multidistrotools could help you construct a nice page from multiple distributions, if you like.
[13:52] <cjwatson> joaopinto: just a Packages/Sources parser with a bit of caching
[13:53] <cjwatson> persia: mdt was replaced by chdist, wasn't it?
[13:53] <joaopinto> I am developing a generic apt2sql tool, maybe it would be interesting to have cross debian-derivated distro view
[13:54] <cjwatson> joaopinto: http://manpages.ubuntu.com/manpages/karmic/en/man1/madison-lite.1.html
[13:55] <persia> cjwatson, Indeed it was: that explains why we lost track of upstream.  Thanks for the pointer.
[13:55] <persia> wgrant, ^^
[13:56] <persia> joaopinto, If you're looking for tracking stuff in SQL, you may also find http://wiki.debian.org/UltimateDebianDatabase interesting
[13:57] <wgrant> persia, cjwatson: That didn't do HTML output, last time I checked.
[13:57] <joaopinto> ah, so there is such db already
[13:57] <persia> joaopinto, I'm not sure that UDD has information on the versions for all derivatives, but at least the structure might be useful.
[13:58] <cjwatson> wgrant: no, but it's reasonably machine-parseable so I'm sure it'd be easy to transform
[13:59] <cjwatson> wgrant: assuming you mean madison-lite
[13:59] <wgrant> cjwatson: I meant chdist, actually.
[13:59] <joaopinto> http://udd.debian.org/schema/udd.html#public.table.packages <- It misses XSBC-Original-Maintainer
[13:59] <RainCT> Heya
[13:59] <cjwatson> wgrant: oh, I never used the old mdt so I don't know
[13:59] <wgrant> It just seems to be a Perl rewrite of the core bits of mdt, minus the fairly long and messy versions2html.
[14:00] <persia> cjwatson, http://qa.ubuntuwire.com/mdt/main.html is an example of the mdt output.
[14:00] <joaopinto> I was thinking on a generic table, allowing to associate random fields to a package, to avoid changing a detailed table when a new field is included on the format
[14:02] <joaopinto> hum, is UDD expected to have public external read access ?
[14:05] <persia> joaopinto, You can download a snapshot of the DB contents from udd.debian.org (dunno about external public access)
[14:06] <joaopinto> perl cgis, yuck :P
[14:07] <joaopinto> i'll continue the apt2sql python script
[14:15] <ttx> dholbach, ara: finished my packaging training session, posted logs. Should I clean up the "upcoming sessions" area in https://wiki.ubuntu.com/Packaging/Training as well ?
[14:15] <ara> ttx: I can do it, don't worry. Thanks a lot ttx!
[14:16] <ttx> ara: my pleasure.
[14:16] <dholbach> thanks ttx, you're a java packaging rockstar!
[14:16] <dholbach> a general rockstar even
[14:16] <ttx> dholbach: I prefer that :)
[14:24] <geser> jpds: I'm thinking about what's the best way to add some cacheing to lp/functions.py (from udt): do it in a class (which I prefer) (and move it to an own file) or do it on module level in functions.py. What's your opinion?
[14:26] <jpds> geser: Class sounds go, I think Laney wanted to OOP program everything too, go for it :)
[14:27] <jpds> good*
[14:27] <Laney> jpds: ref?
[14:28] <jpds> Laney: Didn't you say you wanted to OOP bits of u-d-t?
[14:28] <Laney> yeah, I mean what did geser propose?
[14:28] <RainCT> Laney: < geser> jpds: I'm thinking about what's the best way to add some  cacheing to lp/functions.py (from udt): do it in a class (which  I prefer) (and move it to an own file) or do it on module level  in functions.py. What's your opinion?
[14:29] <Laney> aha
[14:29] <geser> Laney: I'm thinking about adding some cacheing to lp/functions.py to not refetch everytime objects from LP
[14:29] <Laney> yes that's a good idea, and my thought was to encapsulate it in a class
[14:30] <geser> that was my idea too
[14:31] <RainCT> btw, does someone know if there are any plans to update libmotif?
[14:33] <mterry> Is there an easy way to search if any Ubuntu package puts files in a given directory?  packages.u.c only lets me search on filenames, not directory names.
[14:33] <cjwatson> it lets you search on parts of filenames too, doesn't it?
[14:33] <cjwatson> or you can use apt-file, or grep the Contents files in the archive directly
[14:34] <Laney> RainCT: It looks to be QA, so that plan could come from you!
[14:34] <Laney> although someone did ITA it a while ago
[14:37] <geser> RainCT: the thread about it on http://lists.debian.org/debian-devel/2009/05/msg00656.html is known to you? I've just seen on the PTS page for it that a new version is laying around on mentors.d.n (since nov 2007)
[14:37] <directhex> oh arses, i wanted to see the java session
[14:38] <directhex> could have been educational
[14:38] <mterry> cjwatson: Yeah, parts of filenames, but that doesn't include the directory path.  I'll try your other suggestions.  Thanks!
[14:38] <persia> directhex, irclogs.ubuntu.com has the log, and the speaker is likely still available to answer questions in #ubuntu-java
[14:39] <RainCT> Laney, geser: thx
[14:40] <mterry> cjwatson: apt-file works like a charm
[14:44] <persia> mterry, Only trick with apt-file is that sometimes either Contents is out of sync, or it's not being generated for a given release.  Be aware of this if you're planning to rely upon it.
[14:44] <mterry> persia: Sure
[14:46] <directhex> ttx, one thing i didn't see asked: do java packages get their binary deps tracked automatically? i.e. if i have foo, which build-depends libbar-java, do i need to manually specify the binary dep on libbar-java?
[14:47] <ttx> directhex: it's not tracked automatically.
[14:47] <persia> There's some work towards doing that, but it's still in it's infancy.
[14:48] <persia> (at this point, it's lucky if a given non-libary package can set it's own classpath correctly without a wrapper script)
[14:48] <ttx> directhex: usually it's up to the Java program to pull the required libs
[14:48] <ttx> directhex: rather than up to libs to pull potentially-required runtime dependencies
[14:48] <ttx> but I've seen both approaches in the wild :)
[14:49] <directhex> ttx, and do you anticipate java 7 bringing any major changes to the field?
[14:50] <ttx> directhex: I'm not a Java expert, I'm a Java victim. So I don't know.
[14:50] <directhex> ttx, if nothing else, that statement there earnt you a lol ;)
[14:51] <ttx> my vague understanding was that they dropped from Java 7 all the work that was kinda going in that direction
[14:51] <directhex> ...
[14:51] <directhex> *golf clapping*
[14:52] <devfil> asac: ping
[14:53] <directhex> ttx, and java libs don't have anything resembling an ABI version or SONAME, which is why you unversion the package names & simply cross fingers in package deps where versions are concerned?
[14:54] <asac> devfil: ?
[14:54] <asac> (contentless ping?)
[14:54] <ttx> directhex: welcome to my daily nightmare
[14:55] <directhex> ttx, i don't envy you, from the picture you're painting
[14:55] <devfil> asac: I'm using swiftweasel right now to test it and it seems to be faster than Ubuntu firefox, the source code contains the patch applied to firefox to enable somethings to make it faster, why Ubuntu firefox package doesn't have these changes?
[14:55] <ttx> directhex: it's not as bad as it sounds. But it will become more difficult as we add more Java software to Ubuntu
[14:56] <devfil> asac: there is also http://brainstorm.ubuntu.com/idea/18058/
[15:02] <bddebian> Heya gang
[15:04] <geser> Hi bddebian
[15:05] <asac> now he is gone
[15:07] <directhex> ttx, well, good luck with it
[15:08] <devfil> asac: I'm here again :)
[15:10] <asac> devfil: good. so thats not new and we are working on PGO
[15:10] <asac> for karmic
[15:10] <asac> but in general swiftweasel is not really famous for making sane things ;)
[15:11] <asac> so whatever the answer is, swiftweasel is unlikely to have the answer ;)
[15:12] <devfil> asac: so in karmic we will have firefox 3.5 (as decided to UDS) + PGO... great! About swiftweasel, it is only an example for "wow, firefox in linux can be faster too :)"
[15:12] <bddebian> Heya geser
[15:13] <asac> devfil: most likely we will get PGO with xulrunner 1.9.1 PGOed and if it really helps also ffox 3.5 PGOed (though all bin code is in xul)
[15:13] <asac> devfil: so swiftweasel does PGOed builds?
[15:15] <devfil> asac: I don't know how PGO works, in the patch there are only somethings enabled (pipelining), however the about window reports "Swiftweasel version 3.0.10 PGO", so I think yes
[15:16] <asac> devfil: yeah pipelining is one of the things that are not sane ;)
[15:17] <asac> but it should really not matter that much anyway
[15:17] <asac> so i guess its really PGO
[15:17] <asac> which gives hope that this will give a noticable boost
[15:17] <asac> though it might be a bit tricky because we cannot PGO firefox ... nistead xulrunner
[15:18] <devfil> asac: why can't we PGO firefox?
[15:18] <asac> because firefox does not have many binary bits
[15:18] <asac> its just 1MB of size (the package)
[15:19] <asac> but technical details. i have to write a spec about it i guess
[15:22] <devfil> asac: firefox package is a metapackage, I mean the real firefox source
[15:36] <asac> devfil: firefox-3.5
[15:36] <asac> is 1mb and does not have much binaries
[15:36] <asac> anyway. no need to discuss on these details ;) we are on it.
[15:37] <devfil> asac: great, thanks :)
[15:39] <andrew_sayers> Is it considered bad manners to propose a new feature by sending an unprompted merge request?
[15:40] <persia> andrew_sayers, Depends on the project, really.  Do you have context?
[15:41] <andrew_sayers> persia: in this case, I proposed adding code to Ubufox that would work around Flash not setting the screensaver...
[15:42] <persia> Ah.  For that, I'd suggest filing a bug with an attached branch, rather than just a merge request, and asking about it on #ubuntu-mozillateam.
[15:43] <superm1> ooh i'm curious on this code
[15:43] <persia> (but I may be incorrect in my understanding of how the mozillateam likes stuff: I just remember hearing about multiple review cycles for some people's first patches)
[15:43] <superm1> checks when flash is active on a webpage and inhibits the screensaver?
[15:44] <geser> jpds, Laney: I've commited a singleton for LP API access to trunk: using it makes e.g. calling buildd --help from ~5sec to < 0.1 sec
[15:44] <andrew_sayers> persia: fair enough, will do.
[15:44] <andrew_sayers> superm1: currently inhibits when there's Flash anywhere on any open page.
[15:45] <superm1> cool
[15:45] <andrew_sayers> Cleverer solutions are worth looking at if the code's actually likely to get used :)
[15:45] <persia> Personally, I'd be against that.  I often have a page or two with some silly flash ad minimised (or even at the front) when I step away.
[15:46] <persia> Something that only inhibited for current focus, or similar would be nicer.
[15:46] <persia> (although I tend to end up with my screen locked in the process of stepping away, so perhaps I'm not the best example user for this use case)
[15:47] <Laney> geser: cool, that's a good start. Next up is full-on sexy encapsulation
[15:47] <andrew_sayers> persia: yeah, I wouldn't be surprised if the answer was "we'd merge that if it inhibited in X, Y and Z conditions".  I'm mostly looking to see if there's interest right now.
[15:50] <superm1> i think maybe the better solution is to offer an interface from firefox to cause an inhibit, and then flash should start using said hook
[15:50] <superm1> since likely the reason it doesnt happen now is that flash is sandboxed from calling out to apps on the system
[15:51] <RainCT> persia: ever heard about adblock-plus? :)
[15:51] <persia> superm1, But *when* should flash call that hook?
[15:52] <superm1> when video playback is active
[15:52] <andrew_sayers> superm1: Flash could easily inhibit the screensaver if it wanted - it's just a matter of sending a DBus message.  They've had a bug report open for about 6 months now, and no sign of activity.
[15:52] <persia> RainCT, I don't mind viewing advertisements.  At one point in the past, a significant chunk of my income came from others viewing advertisements.  Sometimes they are even useful to me (albeit rarely).
[15:52] <superm1> i suppose i dont know flash internals perfectly, but i would think that video playback is some type of standard call
[15:53] <superm1> can you send a dbus message from a firefox plugin though?
[15:53] <andrew_sayers> No, but you can run a Python script...
[15:53] <persia> hrm.  Be nice if that was possible to differentiate.
[15:53] <superm1> again matter of being able to shell out to the system, or I suppose linking against dbus
[15:54] <andrew_sayers> If you're really interested, the merge request is at https://code.launchpad.net/~andrew-bugs-launchpad-net/ubufox/flashsaver/+merge/6768
[16:06] <jpds> geser: Awesome :)
[16:22] <persia> Could a pbuilder user tell me where I would put pbuilerrc.config?
[16:27]  * persia digs at docs more, and discovers more pitfalls to bind_mounting /home when fiddling.
[16:27] <hyperair> persia: ~/.pbuilderrc
[16:28] <persia> hyperair, Yeah.  I discovered that one, but that's not throwaway.  I'm trying with /etc/pbuilderrc, although I'm unsure if it will work for my use case (playing with qemubuilder).
[16:28] <hyperair> aah
[16:28] <hyperair> qemubuilder eh..
[16:29] <hyperair> it's good for x86 and x86_64, but powerpc... *shudder*
[16:29] <persia> But in a LVM-hosted schroot, so I don't want to dirty my local area.
[16:29] <hyperair> O_o
[16:29] <hyperair> i see
[16:29] <persia> Speed is not the issue :)
[16:31] <hyperair> persia: i don't really care about speed either, but setting up qemubuilder for powerpc is hell.
[16:31] <hyperair> persia: you need the kernel, and you can't apt-get install it without a powerpc machine because you can't chroot into a powerpc installation
[16:31] <hyperair> ugh
[16:32] <persia> Well, that's just a matter of wget + dpkg -x.  More annoying is probably that one has to somehow get an Ubuntu build of openhackware (which can't build due to a quirk in Soyuz).
[16:39] <nixternal> persia: with backports, in this case amarok 2.1, it would require a new package that was separated out of the previous releases, what is the policy if there even is a policy? can you add a *new* package to backports?
[16:39] <nixternal> and who keeps moving developer documentation to help.ubuntu.com/community?
[16:40] <nixternal> JontheEchidna: ^^ do you know the process since it seems you are working on it?
[16:41] <persia> nixternal, I don't know.  Ask one of the backporters.  I think it's discouraged, at least.
[16:41] <JontheEchidna> I've not actually done one before but I have read to docs and one point last week :P
[16:42] <JontheEchidna> basically just show that it builds/intalls/runs on the target distro, while attachign a debdiff of the changes
[16:42] <JontheEchidna> and then one throws it at ScottK :P
[16:43] <nixternal> JontheEchidna: ya, but the qtscriptengine though, that isn't in jaunty at all
[16:43] <JontheEchidna> right
[16:44] <JontheEchidna> It looks like I'll have to rewrite the totally non-backportable packaging for qtscriptgenerator (the official package in karmic)
[16:44] <JontheEchidna> v.v
[16:44] <persia> Also, one has to be careful about anything with rdepends.  Dunno if any of the listed ones would break.
[16:44] <nixternal> fun
[16:44] <nixternal> JontheEchidna: what about the jaunty builds of it that are in the ppa? you can just use that
[16:44] <nixternal> ditch the changelog of course ;p
[16:45] <JontheEchidna> that would be a new package (qtscriptbindings is the name in the package of the ppa)
[16:45] <nixternal> ya....we might just have to stick with ppa in this case
[16:46] <JontheEchidna> but amarok upstream really wants 2.1.0 in -backports :(
[16:46] <JontheEchidna> maybe we could just take the packaging for qtscriptbindings and rename it qtscriptgenerator? :D
[16:46] <nixternal> people in hell want ice water too
[16:46] <JontheEchidna> they are the same thing, except for the packaging differences
[16:49] <persia> Just find a couple backporters, and offer tasty bribes.
[17:11] <joaopinto> a theorical question
[17:11] <joaopinto> deb http://pt.archive.ubuntu.com/ubuntu/ jaunty universe
[17:11] <joaopinto> is there any convention for the /ubuntu/ part ? should it match the Origin value on the Release field ?
[17:15] <persia> It's fairly flexible, although it's nice when it carries recognisible branding of some sort.
[17:15] <persia> (e.g. ports.ubuntu.com uses /ubuntu-ports/ )
[17:36] <cjwatson> persia: and the reason for *that* is so that a mirror can easily carry both /ubuntu/ and /ubuntu-ports/ if it wants to
[17:38] <persia> cjwatson, That makes an incredible amount of sense.  Is it normal to do things like that, or would the guideline of following Origin be better?
[17:38] <cjwatson> persia: I think just something identifying is fine
[17:39] <joaopinto> there is an odd thing, the ports related archictures are listed on the "ubuntu" root Release file
[17:39] <joaopinto> despite them not being available on that archive
[17:40] <joaopinto> I mean http://archive.ubuntu.com/ubuntu/dists/jaunty/Release
[17:41] <joaopinto> I guess main/binary-amd64/Packages , etc should not be listed there
[17:41] <joaopinto> opd, I mean't armel
[17:41] <joaopinto> ops
[17:46] <cjwatson> joaopinto: yes, that's because the split only happens at mirroring time and it can't edit the Release file because it's already signed
[17:46] <cjwatson> joaopinto: just ignore it
[17:46] <cjwatson> i.e. the archive publication process just publishes one giant archive, part of which gets mirrored out to /ubuntu/ and part of which gets mirrored out to /ubuntu-ports/
[17:47] <joaopinto> ok, I am checking for the arch specific Release file availability before trying to import it
[17:49] <fabrice_sp_> Hi, Is the status of this bug report correct bug #383825 ? I always thought merge rshould be Confirmed, and not In progress..
[17:49] <fabrice_sp_> not this one
[17:50] <fabrice_sp_> this one: Bug #385476
[17:54] <directhex> hm. jcastro?
[18:08] <binarymutant> if anyone has any free time to spare, http://revu.ubuntuwire.com/p/pidgin-mbpurple , needs advocation :P
[18:22] <joaopinto> cjwatson, is the ubuntu archive managed with reprepro ?
[18:25] <joaopinto> on my repository reprepro is setting the arch's Release file "Archive:" to the codename of the base Release file, I see that -security and -updates have the "Archive:" set to the "Suite:" name
[18:34] <persia> joaopinto, It'S not.  It's managed by Launchpad.
[18:34] <joaopinto> ok, so it's a reprepro issue
[18:34] <joaopinto> Debian also uses the base suite name as the archive name
[18:46] <Id2ndR_> Hello. didrocks is here ?
[18:48] <didrocks> Id2ndR_: yes, I'm here :)
[18:48] <Id2ndR_> didrocks: great ! That's difficult to be here at same time as you're
[18:49] <Id2ndR_> didrocks: I think there is something quite easy I'd be able to do with https://bugs.launchpad.net/bugs/373167
[18:49] <didrocks> Id2ndR_: timezone rules ;) But I'm always on IRC, so, you can drop a message and I can read it later
[18:50] <maxb> joaopinto: Have you found anything that actually cares about the content of those architecture Release files?
[18:51] <Id2ndR_> didrocks: that's true, but this is not very usefull to get answers
[18:51] <joaopinto> maxb, I am developing such a thing, I care
[18:51] <maxb> joaopinto: APT doesn't seem to download them.... why does your thing care?
[18:51] <didrocks> Id2ndR_: (I'm reading)
[18:52] <joaopinto> maxb, APT does also care, but it only cares about a specific view, your system architecture
[18:53] <didrocks> Id2ndR_: ok, I'm not sure that it's something we will change now, as we are changing the way "default application" are setted up. So, this will have an impact on this bug
[18:53] <maxb> joaopinto: I know APT cares about the dists/XXX/Release file - I'm not certain that APT even downloads the dists/XXX/component/binary-arch/Release files
[18:54] <joaopinto> maxb, well, they are on the archive, if they are not required they should not be there in the first place :P
[18:55] <maxb> I agree :-)
[18:55] <joaopinto> either I rely on them, to establish a unique key, or I just ignore them and rely on the base Release file
[18:56] <LucidFox> @leave
[18:56] <Id2ndR_> didrocks: Ok so you think that it is nopt usefull to work on this, that's it ?
[18:57] <didrocks> Id2ndR_: yes, as the way we handle prefered application will change in karmic release
[19:00] <slytherin> persia: if a package fails to build with openjdk but builds fine with gcj (probably because bug in gcj), should I change build dep or fix the package? I have to yet confirm that there is a bug in GCJ.
[19:00] <Id2ndR_> didrocks: Ok. I think I haven't do anything since I'm in the programm. So what do you think I shoud work on ?
[19:00] <persia> slytherin, Hrm?  It's a bug that the package builds?
[19:00] <maxb> joaopinto: As I said, I'm 99% sure that APT completely ignores them, so you probably should too
[19:01] <maxb> and what apt uses as "Archive" for the purpose of "release a=foo" policy definitions is the Suite field
[19:02] <joaopinto> ok, tks
[19:03] <joaopinto> I will just use (origin, suite, version, architecture)
[19:03] <slytherin> persia: there is a enum declared which members having non-ascii names. I believe gcj does not yet handle enum type as defined by java 1.5 but rather handles it as defined by 1.4. So it builds with GCJ but fails to build with openjdk because of non-ascii names.
[19:04] <persia> slytherin, Hrm.  I'm unsure whether that's a bug in gcj or in the 1.5 spec.
[19:04] <persia> I'd "fix" the package, just to avoid the gcj dependency, but I think it's a suboptimal solution.
[19:05] <slytherin> persia: ok. is this a unicode letter - å ?
[19:06] <persia> slytherin, 'Q' is a unicode letter, but 'å' is not an ASCII letter.
[19:07] <maxb> There are restrictions on characters of allowed enum values beyond those applied to java identifiers in general? Really?
[19:07] <slytherin> persia: the naming rule for variables is this - an unlimited-length sequence of Unicode letters and digits, beginning with a letter, the dollar sign "$", or the underscore character "_". So I guess a variable starting containing å is not correct.
[19:08] <slytherin> maxb: no separate restrictions for enum. same as variables.
[19:08] <maxb> That rule relies on the ambiguous definition of "letter"
[19:08] <persia> slytherin, How is "letter" defined.  I suspect that's vague.  Is 'は' a "letter"?
[19:09] <maxb> What's the package? I'd like to see what sun java makes of that source
[19:09] <slytherin> persia: not sure. I am just reading this from standard java tutorial.
[19:09] <slytherin> maxb: libjaudiotagger-java. I think sun java will also fail to build it.
[19:09] <persia> slytherin, Right.  That's my point.  THe spec is unclear.  It ought define the set of codepoints that are acceptable as "letter"s.
[19:10] <persia> I suspect they mean the alphabetic characters with ASCII values between 33 and 89.
[19:10]  * maxb hunts the JLS
[19:11] <slytherin> I too think the same. But then I wonder why gcj does not fail on this.
[19:12]  * slytherin goes to dinner
[19:12] <maxb> The Java letters include uppercase and lowercase ASCII Latin letters A-Z (\u0041-\u005a), and a-z (\u0061-\u007a), and, for historical reasons, the ASCII underscore (_, or \u005f) and dollar sign ($, or \u0024).
[19:12] <maxb> slytherin: ^
[19:12] <persia> gcj is GNU.  GNU eats unicode for breakfast (something about people getting whiny and submitting patches)
[19:13] <slytherin> maxb: thanks, where did you find that?
[19:13] <persia> maxb, Ah, great.  Thanks for finding the glossary.  It is a bug in gcj then.
[19:13] <maxb> JLS3e
[19:13] <maxb> http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.8
[19:14]  * slytherin goes for dinner
[19:34] <slytherin> maxb: that paragraph is also confusing. There is also a statement about allowing programmers to use identifiers in native language.
[19:35] <maxb> slytherin: what is confusing?
[19:36] <slytherin> why does it talk about identifiers in native language when they are not allowed.
[19:39] <maxb> oh, point
[19:39] <maxb> it says "include" not "is"
[19:40] <slytherin> anyway i am for now patching the package
[19:41] <slytherin> got to go. battery low, no electricity.
[19:41] <maxb> I will figure out the real answer later....
[19:44] <persia> maxb, When you do, please file a bug against whichever of gcj or openjdk is buggy :)
[19:47] <geser> Laney: looking at the LP API doc and the canUploadPackage in functions.py (udt): do you think it's sufficient to check the archive_permissions for a person and compare the component of it with the component of a source package instead of iterate over all uploaders?
[19:49] <Laney> geser: I don't know how that will work for per-package uploaders though
[19:49] <Laney> but it could be good for shortcutting in the majority of cases
[19:51] <geser> and use isPackageUploader for the other cases
[19:52] <Laney> geser: we should try to avoid leaking LP API objects out
[19:52] <Laney> all calls should go through the wrapper
[19:52] <geser> isPerPackageUpload is from functions.py
[19:53] <geser> but I need to rewrite both functions to use the new LpApiWrapper class
[19:53] <Laney> hmm
[19:54] <Laney> most of those functions should move inside the wrapper
[19:54] <geser> I've already started moving some of them to the new wrapper class and marked the old functions as deprecated
[19:55] <geser> so nothing will break till all scripts are moved to the wrapper class
[19:55] <geser> (see my latest commits to udt)
[19:57] <Laney> good stuff
[19:57] <Laney> so all I worry about is not leaking details of lplib out to clients
[20:01] <geser> I'll try to do my best to avoid it (but don't on the other hand to write a function just to access an attribute of an LP object in one script in one place)
[20:04] <RainCT> niice, VoxForge now has enough phonemes to recognize the word «computer» :P
[20:22] <RoAkSoAx> ivoks, Why is openais-legacy FTBFS in the Ubuntu-HA repo?
[20:22] <ivoks> it's not anymore :)
[20:22] <ivoks> i removed it
[20:23] <ivoks> there's no need for it in ppa
[20:23] <ivoks> cause we have it in karmic repository
[20:23] <ivoks> i've sent pacemaker to ppa, so that it rebuilds with openais-legacy from repository
[20:24] <RoAkSoAx> ivoks, ok cool
[20:25] <RoAkSoAx> ivoks, though the one in the PPA was 20090606
[20:26] <ivoks> that's 14 days diff
[20:26] <ivoks> for version that's not being developed, right?
[20:26] <RoAkSoAx> ivoks, yeah but i has a patch on the init script
[20:27] <ivoks> well, apply it
[20:27] <ivoks> don't change version of package
[20:27] <ivoks> only revision
[20:27] <RoAkSoAx> ivoks, here's the changelog: http://pastebin.ubuntu.com/193688/
[20:28] <ivoks> well, ok
[20:28] <ivoks> once that version gets into debian, we'll sync
[20:28] <RoAkSoAx> ivoks, that would be better then
[20:28] <ivoks> and rebuild pacemaker
[20:30] <RoAkSoAx> ok cool
[20:31] <ivoks> don't worry
[20:32] <RoAkSoAx> ivoks, I just want to be helpful :)
[20:32] <ivoks> i know ;)
[20:33] <ivoks> grrrrrrrrrr
[20:33] <ivoks> it failed to build
[20:33] <ivoks> why now
[20:34] <ivoks> ah...
[20:34] <ivoks> grrrr
[20:34] <ivoks> init script
[20:35] <RoAkSoAx> ivoks, ohh I remember.. that's why I uploaded the openais-legacy package from Madkiss
[20:35] <ivoks> yeah :/
[20:35] <ivoks> i give up for today
[20:35] <RoAkSoAx> ivoks, you gonna fix that package or should I upload openais-legacy again or should I just apply the changes?
[20:37] <ivoks> go ahead, upload the openais-legacy 20090606
[20:37] <RoAkSoAx> ivoks, ok.
[20:37] <ivoks> i just did a 24 hours circle
[20:38] <RoAkSoAx> ivoks, that's awful.. you need to get some sleep
[20:38] <ivoks> that's true
[20:39] <ivoks> take care...
[20:39] <RoAkSoAx> u too
[20:39] <Nafallo> hmmm
[20:40] <Nafallo> what's the difference between bzr import and bzr merge-upstream ?
[20:40] <Nafallo> anyone know by any chance?
[20:52] <savvas> Nafallo: try #bzr (or #bazaar - I forgot), but have you checked the help messages? bzr import --help; bzr merge-upstream --help
[20:53] <Nafallo> savvas: yes. didn't help much.
[20:54] <Nafallo> lifeless: question for you a few (read about 14, including join/parts) lines up :-)
[20:54] <persia> #bzr is the place to go then.
[20:54] <persia> (and it's likely too early for lifeless at this hour, although I could be mistaken)
[20:55] <Nafallo> persia: of course it is. thank god irc is async ;-)
[20:55] <persia> but someone in the right channel might know now :p
[20:56] <Nafallo> persia: well. considering both those commands are in plugins... :-)
[20:56] <Nafallo> (and I don't need to know now. I'll just import as usual ;-))
[20:57] <Nafallo> AAAAAAAAAAA. silly tarball!
[20:58] <Nafallo> it removed my tree and added a subdirectory with the name of the program-version.
[20:58] <Nafallo> thank god I branched it before.
[20:59] <Nafallo> *FACEPALM*
[20:59] <jpds> Nafallo: Thanking yourself?
[20:59] <Nafallo> how am I supposed to use this as orig.tar.gz
[20:59] <Nafallo> I need to rebuild the damn thing :-(
[21:05] <Nafallo> ehrm. ignore me. I'm on crack.
[21:05] <Nafallo> but something else it broken I reckon.
[21:09] <ausimage> Are there any knowledgeable python packagers available to help with http://revu.ubuntuwire.com/details.py?upid=6023?
[21:10] <ausimage> It is python app I am coding and attempting to package for karmic...
[21:10] <ausimage> I was also attempting to package it in pieces too
[21:11] <ausimage> and that is where I am stuck perse.... at least the karmic buildd on LP is :/
[21:11] <ausimage> It is just not finding a file from soovee-common.
[21:23] <fabrice_sp> ausimage, when I have a problem with this kind of things (splitting a package in several pieces), I build the package from within a schroot, and see what files are created where
[21:23] <fabrice_sp> I'm just having this issue (files in a wrong place), and I'll build the package in a chroot
[21:23] <ausimage> k... then I need to learn how to do that I guess :/
[21:24] <fabrice_sp> it's easy :-)
[21:24] <fabrice_sp> lt me check the wiki for the page
[21:24] <ausimage> k
[21:24] <fabrice_sp> you have a pbuilder installed?
[21:24] <ausimage> fabrice_sp: that is one item on my punch list
[21:24] <ausimage> no
[21:24] <fabrice_sp> oh
[21:25] <ausimage> the other is that I am being requested to change the name of the package to add 0ubuntu as well as orig to the original tarball
[21:25] <fabrice_sp> ausimage, https://wiki.ubuntu.com/DebootstrapChroot for dchroot
[21:26] <fabrice_sp> and you'll find all the tools info here: https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases
[21:26] <fabrice_sp> to add 0ubuntu1 to the version, you just have to change the version in debian/changelog
[21:27] <ausimage> not that... when a I got to build source in order include original I need soovee-0ubuntu.orig.tar.gz....
[21:27] <fabrice_sp> ?!
[21:28] <ausimage> not soovee.orig.tar.gz
[21:28] <fabrice_sp> you need soovee-<version>.orig.tar.gz
[21:28] <fabrice_sp> you miss the version
[21:28] <ausimage> the version too yeah
[21:28] <ausimage> but I have include -0ubuntu in the name too
[21:28] <fabrice_sp> actually, it's sovee_<version>.orig.tar.gz
[21:28] <fabrice_sp> with a _ not a -
[21:29] <ausimage> not here... if I have the the file as you suggest it says it is not there
[21:30] <fabrice_sp> check your changelog: the version should be the same
[21:30] <ausimage> the current is soovee_1.07.2
[21:30] <ausimage> http://revu.ubuntuwire.com/details.py?upid=6023
[21:30] <ausimage> is the current package
[21:31] <ausimage> fabrice_sp: I did try without... the -0ubuntu in the original and it would not locate the tarball
[21:31] <fabrice_sp> the version is wrong
[21:31] <fabrice_sp> 1.07.2-0ubuntu-1 should be 1.07.2-0ubuntu1
[21:32] <fabrice_sp> that's why it's requesting you to have -0ubuntu in orig
[21:32] <fabrice_sp> have to go. Sorry.
[21:32] <ausimage> duh... guess my brain is not withit to catch that :/
[21:32] <fabrice_sp> bye
[21:32] <ausimage> laterz
[21:50] <geser> does someone with per-package upload rights need sponsoring for sync requests? I assume no
[21:58] <persia> geser, Ideally they oughtn't, but I'm not sure the archive-admins have a view as to who can upload what.
[21:59] <persia> (might be handy to have a script that checked a sync bug to see if it was approved, if that's parsable by comments)
[22:05] <Nafallo> so... who do I need to cuddle for this SRU? ;-)
[22:06] <joaopinto> can the simple fact that the software contained  package is not working justify justify an SRU that will introduce a new upstream version ?
[22:07] <persia> joaopinto, Only if a fix can't be backported for some reason.
[22:09] <joaopinto> why backporting a specific fix instead of doing an upstream upgrade, based on the fact that the current version was never tested/working during the entire development cycle, what is the advantage of using a fix versus new upstream ?
[22:10] <persia> I don't have a good answer, and have found myself in that position previously.  That's the policy though.
[22:13] <joaopinto> well, I am not going to spend time that may be wasted on a policiy block, i'll just try to get it fixed for Karmic, since it's still broken there
[22:15] <persia> Getting it fixed in karmic first is a requirement for SRU anyway.
[22:17] <joaopinto> ah :\
[22:23] <rawler> whenever someone's got a minute or two, I've got a package needing sponsoring..
[22:23] <rawler> just don't really test it for too long.. it's kindof addictive.. :)
[22:23] <rawler> http://revu.ubuntuwire.com/details.py?upid=6025
[22:34] <joaopinto> persia, what is the recommended procedure, should I contact the debian maintainer asking for the update on Debian first ?
[22:35] <joaopinto> this is a python2.6 transition related issue, I am not sure it affects debian at the same extent
[22:37] <persia> joaopinto, getting an update in Debian always makes it nice because we don't have to care as much.  Depending on how upstream distributes the source, it may even be essential to get it into Debian first.  If that is taking a long time, and you want to pursue the SRU, and there's no worries about the orig.tar.gz, don't let Debian delay you.
[22:38] <bulletxt> hi, is someone kind enough to package and include AcetoneISO for ubuntu Karmic, it's about 2 years there's a launchpad ticket but no one ever picked it up and do the work
[22:38] <joaopinto> I already built a package for myself, if no one missed it yet on jaunty I will not care about it, I will try just emailing Debian maintainer first
[22:39] <joaopinto> it is a minor release upgrade from the debian version perspective
[22:40] <persia> joaopinto, Right.  It sounds like it's mostly important in terms of being missed in the jaunty update.
[22:54] <ingenthr> i have a question about packaging for Ubuntu I hope someone can point me in the correct direction on
[22:54] <ingenthr> it's not immediately for Universe, but may like to get it there some day so I want to do things correctly
[22:55] <Cry__Baby> hello
[22:55] <Cry__Baby> what is Karmic Koala ?
[22:56] <persia> ingenthr, Ask away.  The faster you learn, the faster it can get in, and the more users wil be happy :)
[22:56] <persia> Cry__Baby, It is the development release of Ubuntu, scheduled to be released as Ubuntu 9.10 in october.
[22:56] <Cry__Baby> cool
[22:56] <Cry__Baby> what is the main objective of this channel, and who are the people that visit here?
[22:57] <ingenthr> persia: thanks; i've looked at the wiki(s) and the debian policies, and what i'm not sure about is what namespace a package should live in... it looks like it should be /opt/${provider} but it could be /usr/local too
[22:57] <persia> The objective is suitable for debate.  On-topic discussions include packaging, coordination of packages in universe, Ubuntu development discussions, and related topics.
[22:58] <ingenthr> persia: though it looks as if /usr/local is really for the syadmin if building from source?  the whole thing gets more confusing if looking to the LSB and the LANANA
[22:58] <persia> ingenthr, For something to be part of the distribution, it should be in neither of those places.  It belongs in /usr
[22:58] <persia> My personal opinion is that /opt is for non-free software, and /usr/local/ is for special bits added by the sysadmin.
[22:59] <ingenthr> persia: where in /usr if it's a system daemon?
[22:59] <ingenthr> persia: i work with the memcached project and some of my colleagues and I have a new project we'd like to get a number of people to be able to easily use
[23:00] <persia> ingenthr, binaries in /usr/bin, libraries in /usr/lib, resources in /usr/share/${package}, configuration in /etc, state files in /var/lib/${package}, cache in /var/cache/${package}, logs in /var/logs/${package}.
[23:00] <joaopinto> Cry__Baby, reading the topic also helps :)
[23:00] <persia> ingenthr, Then get it packaged, and get it distributed :)
[23:00] <Cry__Baby> joaopinto, true :)
[23:01] <joaopinto> ingenthr, you might want to look how for a similar daemon already packaged
[23:04] <ingenthr> joaopinto: true enough...  :)  will do... i'm a bit of a n00b here and trying to follow the docs...
[23:05] <joaopinto> someone already submited a debdiff for the package I was talking about, bug 368855
[23:07] <joaopinto> it's one month old, let's hope it will not become one of those left behind until the release
[23:08] <persia> joaopinto, Is the debdiff good?  Does it fix the problem?  Should I upload it?
[23:08] <joaopinto> hum, I'll check
[23:08] <joaopinto> it introduces changes which are not required
[23:09] <joaopinto> like debhelper version bump
[23:11] <joaopinto> oh, the debdiff is based on jaunty's version, it was before the synch
[23:14] <ingenthr> one other question: if you want to create a binary package for different versions, should one build it on the oldest version?
[23:15] <joaopinto> depending on library changes you may need different build rules/package versions for each ubuntu release
[23:16] <persia> ingenthr, That's often safest.  Build on the old version, and copy forward.  Distro policy forbids insertion of new packages into old releases though, so one does that starting from now.
[23:18] <joaopinto> well, that debdiff is not fine, the fix for the python2.6 compability is a one liner, but I still think it's best to go with the new upstream version, I will wait for the debian feedback
[23:18] <ingenthr> joapinto: my only external dependency is libevent, and i'll certainly test with newer releases
[23:18] <joaopinto> ingenthr, ok :)
[23:19] <ingenthr> joapinto: have been building on 8.0.4 to be safe
[23:19] <persia> joaopinto, Could you comment on the bug detailing how the debdiff isn't fine, and why it's better to wait?  That ought save anyone else from having to investigate.
[23:20] <lifeless> Nafallo: hi
[23:21] <lifeless> Nafallo: bzr import is built into bzr
[23:21] <lifeless> bzr merge-upstream is a bzr-builddeb command and knows about packaging metadata
[23:22] <joaopinto> that debdiff makes sense if it's aiming for the SRU with a new upstream
[23:25] <persia> joaopinto, And it has a MOTU-SRU ACK.  Does it belong in jaunty-proposed?
[23:26] <joaopinto> hum, I have justed in packages.*
[23:27] <Nafallo> lifeless: hmm. thanks :-).
[23:27] <Nafallo> lifeless: I reckon my memory is just bad (rather than import having changed)
[23:28] <joaopinto> persia, it is not available on jaunty-proposed...
[23:28] <ausimage> K... karmic build is really wierd :S
[23:28] <persia> joaopinto, Yes, but I can put it there.  I'm distracted by many things, and you have been investigating this, so I'll take your advice, if well argued and well-grounded.
[23:28] <nhandler> If a file says it is available under the BSD license, what keyword (http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=196#Keywords) should I use? BSD-3 ?
[23:29] <joaopinto> persia, oh wait, let me test it, I didn't test the build, was just reading the debdiff
[23:29] <persia> joaopinto, OK.  Let me know.
[23:30] <ausimage> instead of placing the files in debian prior to packaging... it places them in build... with a lib.linux-i686-2.6 and scripts-2.6 directories
[23:30] <persia> nhandler, If a file claims to be under the "BSD" license, it isn't.  quote the license.  (all actual BSD-licensed code has the proper BSD license in the code, and is copyright The Regents of the University of California)
[23:31] <ausimage> hows it know where they end up when they are all lumped like that  :?
[23:33] <lifeless> Nafallo: you may be thinking of import-dsc
[23:34] <binarymutant> if somone could review and possibly advocate http://revu.ubuntuwire.com/p/pidgin-mbpurple , I would be forever grateful :)
[23:35] <nhandler> persia: It is a Perl module which says "You may use this module under the terms of the Artistic, GPL, or the BSD licenses."
[23:35] <persia> nhandler, Hrm.  That's tricky.  Artistic allows that usage.
[23:36] <Nafallo> lifeless: doesn't look like it I'm afraid. :-)
[23:36] <Nafallo> lifeless: more likely that I'm getting old ;-)
[23:39] <joaopinto> persia, it does not build, I have commented on the bug report
[23:40] <ausimage> I figured it out!!
[23:40] <ausimage> jaunty use dist-packages and karmic uses site-packages
[23:40] <ausimage> :/
[23:40] <persia> joaopinto, Thanks.  I'll unsubscribe the sponsors.  Since it has MOTU-SRU ACK already, if you can fix it (perhaps in collaboration with the patch submitter), it can be done.
[23:40] <ausimage> in an install file can I use *-packages for that directory?
[23:41] <ausimage> or is it too big a tool again :/
[23:43]  * ausimage picks up the tool and attempts to swing it at his package for karmic
[23:45] <joaopinto> persia, question, a debdiff is expected to be applied over an base source+base bioçd diff right ?
[23:45] <joaopinto> I believe he just dif a diff between both debian/*, so the debdiff would apply if I used a new upstream orig
[23:46] <joaopinto> I mean, the patches would apply
[23:46]  * ausimage does jig in his small space :D
[23:47] <persia> joaopinto, I don't usually make that much fuss about the format of the supplied debdiff, as long as I can be confident that what I'm producing matches what the submitter had locally.
[23:48] <persia> joaopinto, You may want to track down kklimonda when next available, and chat about it to resolve any confusion.
[23:48] <joaopinto> ok
[23:49] <ausimage> persia is it ok to have install file with.... somedir/*partial/* ?
[23:50] <persia> ausimage, I think there's likely a more subtle way to do it, but I'm not sure.
[23:50] <ausimage> this issue with my karmic package is distutils I think....
[23:51] <ausimage> they changed their destination directory subtly from *dist to *site :/
[23:53] <lifeless> Nafallo: import-dsc would import a dsc and grab the orig for you, it would output the right paths