[00:06] <goshawk> if someone has free time, can please review this? http://revu.ubuntuwire.com/details.py?package=dsss
[00:12] <ScottK-laptop> goshawk: What is "D" software?
[00:13] <goshawk> software written in D?
[00:13] <goshawk> d programming language?
[00:16] <ScottK-laptop> goshawk: So this is a package management system for D software packages?
[00:16] <goshawk> it's too, but primaly it's a make-like program
[00:16] <goshawk> for D sources
[00:16] <goshawk> in d programming language
[00:17] <goshawk> in projects
[00:17] <goshawk> you do a dsss.cong
[00:17] <goshawk> conf
[00:17] <goshawk> and it acts like a makefile
[00:17] <goshawk> dsss is needed to start
[00:17] <goshawk> packaging d packages in the ubuntu world
[00:17] <goshawk> and
[00:17] <goshawk> dsss has also the "net module"
[00:18] <goshawk> that acts like ruby-gems
[00:18] <goshawk> or python-eggs
[00:18] <goshawk> so
[00:18] <goshawk> dsss build:
[00:18] <goshawk> look to dsss.conf in a source tree
[00:18] <goshawk> and compile it
[00:19] <goshawk> dsss net install package:
[00:19] <goshawk> downloads sources of "package"
[00:19] <goshawk> and run
[00:19] <goshawk> dsss build
[00:19] <goshawk> and dsss install
[00:19] <ScottK-laptop> You realize that Debian packagers generally view things like Python ez_install or Ruby Gems as fundamentally evil.
[00:19] <goshawk> ScottK-laptop: of course :)
[00:19] <goshawk> i know
[00:19] <goshawk> but it's minly used
[00:20] <goshawk> mainly used
[00:20] <goshawk> like make
[00:20] <goshawk> i need it
[00:20] <goshawk> to package tango library
[00:20] <goshawk> which probably will be the standard library for D
[00:20] <goshawk> if not
[00:20] <goshawk> i've to write a makefile for each D project...
[00:20] <ScottK-laptop> Right, but instead of doing this in an evil way from the start, can dsss be taught the ways of good from the beginning?
[00:21] <goshawk> just do not use the net command
[00:21] <goshawk> and it's a make replacemente
[00:21] <goshawk> replacement*
[00:21] <ScottK-laptop> Or at least to notice if something's already installed via the packaging system and use that instead of installing another copy.
[00:21] <ScottK-laptop> This is what Python ez_install is patched to do in Debian/Ubuntu.
[00:22] <goshawk> ScottK-laptop: ah... it installs in ~/d
[00:22] <goshawk> by default
[00:22] <goshawk> not in /usr/bin
[00:22] <ScottK-laptop> That's something.
[00:22] <goshawk> if you are not root
[00:22] <Adri2000> are /etc/init.d/* scripts considered conffiles?
[00:23] <ScottK-laptop> OK, that's one step up on Ruby Gems at the moment.
[00:23] <ScottK-laptop> Adri2000: Generally.
[00:23] <Adri2000> damn :(
[00:23] <ScottK-laptop> Adri2000: In particular it depends on if they are provided by the package or generated in postinst.
[00:23] <Adri2000> provided by the package
[00:23] <ScottK-laptop> Adri2000: Init's are almost always provided and are conffiles.
[00:23] <ScottK-laptop> conffile then.
[00:24] <ScottK-laptop> goshawk: What if you are root?
[00:24] <goshawk> if installs in /usb/bin
[00:24] <goshawk> it*
[00:25] <goshawk> yep it can be evil
[00:25] <goshawk> i know
[00:25] <goshawk> but at the end... is the user that decides
[00:26] <ScottK-laptop> goshawk: At this point we are past where we normally accept new packages for a release.  Personally, I'm not in favor of giving evil an exception.
[00:26] <ScottK-laptop> How clear is it to the user before the do the install how much stuff is getting drug in from the net?
[00:26] <Adri2000> ScottK-laptop: the problem I'm having here is that an init script is broken in version n, causing the pre-rm script calling invoke-rc.d stop to fail. I fixed it in version n+1, but when upgrading it won't actually use the new version because it is a conffile (that's my guess)
[00:27] <ScottK-laptop> Adri2000: Look at man dh_installinit (I think that's it) and there's an option you can tell it what to do on error.
[00:28] <goshawk> ScottK-laptop: it's not clear at all. if you do dsss net install package, it downloads and do dsss build && dsss install.
[00:28] <ScottK-laptop> I can't remember for sure, but I helped norsetto solve a similar problem a few months ago.  Maybe he remembers.
[00:29] <goshawk> nothing more
[00:29] <goshawk> no dependency check
[00:29] <ScottK-laptop> goshawk: So the end user decides, but they don't actually know what they are deciding.
[00:29] <goshawk> no. they decide the application. and if they have not the source, dsss will download for them. no more
[00:30] <ScottK-laptop> Ah, it doesn't grab dependencies?
[00:30] <goshawk> at this stage no
[00:30] <goshawk> it's not able to for now
[00:30] <goshawk> this is why
[00:30] <ScottK-laptop> Are you involved in the upstream development?
[00:30] <goshawk> it's more like a make-like instead of a ruby-gem-like
[00:31] <goshawk> ScottK-laptop: i think i'll be envolved soon
[00:31] <goshawk> cuz
[00:31] <james_w> Adri2000: if version n's pre-rm fails then version n+1's pre-rm gets to try and fix things up.
[00:31] <james_w> Adri2000: when version n's pre-rm fails version n+1 is not unpacked, so there is no way it could use the new init script.
[00:31] <goshawk> in upstream that code is frozen from 1 year, and if it will got accepted and people will start using it for a make replacement
[00:32] <ScottK-laptop> james_w: So each pre-rm uses the old init and both fail.
[00:32] <james_w> Adri2000: fixing it depends on the exact reason for failure, needs to be done carefully.
[00:32] <james_w> ScottK-laptop: yeah, but the new one can know about the problem, and isn't forced to use the init script
[00:32] <goshawk> the development will start again i think
[00:34] <ScottK-laptop> james_w and Adri2000: I think using dh_installinit --error-handler you can solve this problem pretty robustly.
[00:36] <ScottK-laptop> goshawk: I'd encourage you to consider how to make it work nicely with the packaging system and try for Jaunty Jackalope.  I think the chances of an FFe for something like this are very small.
[00:36] <ScottK-laptop> Unfortunately REVU didn't go very well this cycle.
[00:37] <PMantis> Hi guys!
[00:37] <Adri2000> james_w: ok I see, nothing to do with the init script being a conffile
[00:37] <emet> hey
[00:37] <goshawk> what is FFe?
[00:37] <ScottK-laptop> Featre Freeze exception.
[00:37] <james_w> ScottK-laptop: looking at the implementation I think that doing it by hand may lead to less unexpected behaviour, as the error handler has no idea about which situation it is being called in.
[00:37] <ScottK-laptop> We are past Feature Freeze, so new packages are not accepted currently.
[00:37] <emet> is the process of becoming a MOTU to introduce yourself on the motu-mentors list?
[00:37] <goshawk> ScottK-laptop: it's ok for me for Jaunty, but what should i do to make it accepted then?
[00:37] <PMantis> Is postinst configure called for only the initial install,or for dpkg-reconfig too?
[00:38] <ScottK-laptop> james_w: Generally, that's true, but in this particular case he knows that the old init is buggy.
[00:38] <james_w> ScottK-laptop: so you will have code that could be called when the package gets removed for upgrade to the next version, and it will try and do something that could make things worse
[00:38] <PMantis> I need an option that is only called on initial install
[00:38] <james_w> ScottK-laptop: but I would want to see any implementation of the solution, as it will be hard to get right either way
[00:38] <ScottK-laptop> True.  It's not ideal.  it's a hard spot to get out of.
[00:39] <james_w> Adri2000: is that enough information for you to be able to work up a fix?
[00:40] <ScottK-laptop> PMantis: What problem are you trying to solve?
[00:41] <PMantis> ScottK-laptop: I want my package to call a command from postinst, but ONLY the first time it's installed, not on upgrades, reconfig,etc.
[00:41] <ScottK-laptop> PMantis: What does this command do?
[00:42] <PMantis> ScottK-laptop: Make a call to a website to register. It's only useful for my own systems.
[00:42] <Adri2000> james_w: no, I don't see how I could do that
[00:43] <ScottK-laptop> Adri2000: I'd suggest dh_installinit --error-handler= with the function it points to being a copy of the new init and stop.
[00:43] <james_w> Adri2000: First off I would start by reading http://women.debian.org/wiki/English/MaintainerScripts, it should help you to understand how the various processes work. You are mainly interested in the "upgrade" example at this point.
[00:45] <ScottK-laptop> PMantis: I'd suggest write a setting in a conffile and check for it's existence.
[00:46] <PMantis> ScottK-laptop: ok, thanks
[00:47] <ScottK-laptop> james_w: Since you're the bzr integration guru, can you figure a way it doesn't land in my inbox when you want a branch merged?
[00:48] <james_w> ScottK-laptop: was that my gnome-control-center request?
[00:48] <ScottK-laptop> james_w: Yes.
[00:49] <james_w> ScottK-laptop: sorry about that. I don't know if there is a way to unsubscribe the owner from a branch. It's more of a launchpad thing though.
[00:49] <goshawk> ScottK-laptop: excuse me, but what can i do to make my package be in the next version?
[00:49] <james_w> ScottK-laptop: it won't be a problem soon though hopefully.
[00:49] <ScottK-laptop> Right.  I'm sure it is, but I was hoping you could be helping them straighten it out.
[00:51] <james_w> ScottK-laptop: I'll talk to them. I'm going to make sure it doesn't happen with real package branches, but it may not be possible to do it for normal branches.
[00:51] <ScottK-laptop> goshawk: Which next?  Intrepid or Jaunty?
[00:51] <ScottK-laptop> james_w: In the great and glorious future, won't they all be packaging branches?
[00:51] <goshawk> jaunty
[00:52] <james_w> ScottK-laptop: if there are any that are a major headache for you then you can try going to the branch page and "Edit subscription preferences".
[00:52] <goshawk> ScottK-laptop: Jaunty
[00:52] <ScottK-laptop> In any case I think this kind of thing should go to UMS, not core-dev.
[00:52] <ScottK-laptop> james_w: It's because it's owned by core-dev.  I can't unsubcribe.
[00:52] <james_w> ScottK-laptop: I will send packaging ones manually in the future
[00:53] <PMantis> Is there a document that shows the order in which everything runs when a package is installed, upgraded.
[00:53] <PMantis> ?
[00:53] <ScottK-laptop> james_w: Don't get me wrong, I don't blame you, I think the system is messed up.
[00:53] <james_w> ScottK-laptop: but yes, they should all be packaging branches. It doesn't stop people from pushing to ~ubuntu-core-dev though.
[00:53] <james_w> ScottK-laptop: I understand.
[00:53] <ScottK-laptop> goshawk: Have a solid answer for how dsss plays nice with packages installed via the packaging system and some thoughts on how D packages ought to be packaged
[00:55] <ScottK-laptop> goshawk: Are you familiar at all with the Debian Python policy?
[00:55] <ScottK-laptop> Something like that.
[00:55] <goshawk> no i don't know debian python policy
[00:55] <goshawk> i'll read it then
[00:55] <ScottK-laptop> Even if it's not implemented for your initial package, if you have a vision of working within the official package structure that you're working towards, it'd make me a lot more positive about it.
[00:56] <goshawk> ScottK-laptop: it's already implemented
[00:56] <goshawk> dsss uses itself to be built like a package
[00:56] <goshawk> to do so
[00:56] <goshawk> i did a wrapper
[00:56] <goshawk> makefile to dsss.conf
[00:56] <ScottK-laptop> OK, does dpkg know about these?
[00:57] <goshawk> no debuild just run makefile, and makefile run dsss
[00:57] <goshawk> like a chain
[00:57] <ScottK-laptop> The trick is to get the files registered with dpkg so conflicts and such can be managed.
[00:57] <goshawk> so using this kind of makefile
[00:57] <ScottK-laptop> Right.
[00:57]  * ScottK-laptop needs to run and make dinner.
[00:57] <goshawk> ok ScottK-laptop
[00:57] <goshawk> thanks for all
[00:57] <goshawk> see you then :D
[01:01] <james_w> ScottK-laptop: would you be willing to try something for me? I'm interested in what's currently possible.
[01:02] <james_w> ScottK-laptop: please go to https://code.edge.launchpad.net/~ubuntu-core-dev/gnome-control-center/ubuntu and if there is an "Edit your subscription" link there see what options are on the page it points to
[01:02] <james_w> however, if there is a link and options, then I don't know if it will control what you get, or what the whole of -core-dev gets.
[01:03] <james_w> though getting interested parties to subscribe directly would be better.
[01:05] <ScottK> james_w: It's just ubuntu-core-dev that's subscribed.
[01:05] <james_w> and there's no edit button?
[01:06] <ScottK> There's a bug open asking for the ability for individuals to opt out of a particular bug if they want.  I think this wants something similar
[01:06] <ScottK> There's subscribe yourself and subscribe someone else.
[01:06] <ScottK> It'd be subscribe/unsubscribe if I had the option to get out.
[01:07]  * ScottK really goes to make dinner now.
[01:07] <james_w> well, there's "edit" as well for branch subscriptions, as you can get different levels of notifications, but yes, I agree
[01:08] <james_w> If you want to help when you have a spare 10 minutes the page I have so far that touches on this is https://wiki.ubuntu.com/DistributedDevelopment/Requirements/Sponsorship, any comments would be welcome.
[01:11] <Adri2000> ScottK, james_w: thanks, seems to work using --error-handler
[01:11] <james_w> Adri2000: would you mind if I take a look at the patch?
[01:14] <Adri2000> james_w: http://paste.ubuntu.com/46455/
[01:14] <james_w> thanks
[01:15] <james_w> what was the error in the previous version?
[01:15] <Adri2000> in the previous version of the init script? --oknodo missing
[01:18] <james_w> Adri2000: it looks ok to me.
[01:18] <james_w> Adri2000: however, from the manpage: "The function should be provided in the prerm and postinst scripts"
[01:20] <james_w> is it a problem that this will be called if there is an error when the init script is called with "start" in the postinst?
[01:21] <james_w> if it fails to start then there is probably no harm in trying to stop it
[01:22] <james_w> however, if it fails to start as there is already an instance running then stopping it is probably the wrong thing to do
[01:26] <james_w> but if it also has --oknodo for the start action then the snippet shouldn't be called.
[01:26] <Adri2000> james_w: well, there shouldn't be already an instance running. either the package was not installed yet, or it was and then the pre-rm script was run just before
[01:27] <james_w> Adri2000: yes, but that doesn't mean that there wasn't an instance started in that time
[01:34] <Adri2000> well, I'll re-check/test and upload tomorrow. I'm far too tired now
[01:35] <Adri2000> good night/whatever
[01:35] <james_w> good night
[02:21] <toabctl> hi all
[02:21] <toabctl> i have a question: i found some wrong comments in the package screen-resolution-extra and want to fix them.
[02:22] <toabctl> is it better to fix them in the debian-package (with debdiff at the end) or should i fix the comments directly in the sourcecode of the lp-branch and send a diff to the author?
[02:23] <toabctl> it's my first time i want to do something like that, so i don't know whats better.
[02:36] <ScottK> toabctl: It depends a little on the package, but generally debdiff is better.
[02:37] <toabctl> ScottK, ok. thx
[02:39] <persia> toabctl: The general rule of thumb is that if you're not already talking with someone who requests a branch, you're probably better off with a debdiff.  That said, in cases where it appears one person does a majority of the changes, and there are significant Ubuntu changes, it can sometimes be helpful to speak with them.
[02:40] <wgrant> But of course it's always better to fix it upstream first.
[02:58] <Flannel> Is it possible to pin a version with a specific ubuntu rev? (version-ubuntu1) Does apt stop noticing past the hyphen?
[02:59] <Elbrus> A package I am packaging gets a lintian warning: binary-or-shlib-defines-rpath
[03:00] <Elbrus> what is the general consensus: should I fix this?
[03:00] <Elbrus> It is a KDE image viewer called KSquirrel
[03:01] <Elbrus> apachelogger: ping
[03:04] <persia> Elbrus: Please fix it unless you *really* need rpath and know exactly why.
[03:04] <Elbrus> persia: ok, just checking, because the warning said it might be acceptable
[03:05] <persia> Elbrus: There are exceptional cases in which it's acceptable.  If you're one of those, you'll have to justify it, which means you'll need to learn *exactly* why you need to use rpath.
[03:07] <persia> The most common example is a misbehaving upstream for something not usually supported on linux (e.g. a ported Windows game with lots of expectations of local dlls, and no ABI tracking), but something like a KDE image viewer is unlikely to fall into that category.  There may be other categories of which I am unaware.
[03:07] <Elbrus> persia: you know a good place to find the "easiest" way to solve it?
[03:09] <persia> Elbrus: No.  chrpath is the most common method used, but depending on why th rpath was defined, it may be as simple as changing some build flags.  It definitely requires investigation of the build system and understanding of the relationship between the included libraries.  For many packages, the right solution is to split the package into separate library and application packages.
[03:14] <Elbrus> persia: I have quiet some lines like >> hardcode_libdir_flag_spec_GCJ='${wl}-rpath,$libdir' << I guess that is where you are talking about (I am not a C of C++ programmer)
[03:15] <Elbrus> persia: by the way, this package has already a library package (that got in before this package) but got forgotten... (apachelogger is mentoring, but did not reply to my ping)
[03:16] <ScottK-laptop> Elbrus: See http://wiki.debian.org/RpathIssue
[03:17] <persia> Elbrus: See the link provided, but yes, I probably mean something like that
[03:17]  * persia tends to shy away from rpath
[03:18] <Elbrus> ScottK-laptop,persia: I read that link, but it mentions three ways to solve it, and as I don't know much about rpath I was trying to figure out what would be the best way.
[03:20] <ScottK-laptop> Elbrus: The last one (the sed solution) is the one I've seen people have success with, but this in the realm of whatever works.
[03:21] <persia> Elbrus: They are listed in the order of preference.  Try the first.  If that doesn't work, try the second, and if that also doesn't work, try the third.
[03:21] <persia> Essentially the third just changes the compiled library, but there's no guarantee that it was built to match the system provided libraries, which means that it can sometimes break things.
[03:23] <Elbrus> peria,ScottK-laptop: Ok, I will try in the mentioned order. THANKS.
[03:25] <persia> Aha!  http://lists.debian.org/debian-devel/2008/01/msg00308.html is hugely enlightening for those experiencing -rpath issues *only* for amd64
[03:26] <persia> (or ia64 as well, I suppose, but that doesn't tend to be the default environment for most peope)
[03:41] <Elbrus> persia: following that thread I see a mention of libtool.m4, which is present in my package in admin directory; IIRC apachelogger mentioned that admin directory is shared among KDE developers. So they all expericience the same problem?
[03:41] <ScottK-laptop> Elbrus: That's core KDE, not extras.
[03:42] <Elbrus> ScottK-laptop: you mean the KDE developers, or the admin directory that is shared?
[03:43] <ScottK-laptop> I mean the admin directory is shared in KDE core packages.
[03:43] <Elbrus> ScottK-laptop: I should say, developers of KDE related software copy the admin directory around
[03:43] <ScottK-laptop> Not in KDE extras packages.
[03:44] <ScottK-laptop> No, that's not I think what he meant.  When KDE core is released, each package has the same admin directory in it.
[03:44] <Elbrus> ScottK-laptop: I saw that, so should I try to replace/patch my admin directory to use that from kapptemplate
[03:44] <ScottK-laptop> I didn't say that.
[03:45] <ScottK-laptop> I don't have an opinion on what you should do.  Randomly copying directories from other packages is though, IMO, an unlikely path to success.
[03:45] <Elbrus> That is what I thought.
[03:46] <Elbrus> Ok, I'll just try to fix this here.
[06:59] <NCommander> Anyone in the mood to sponsor some uploads and/or fixs?
[07:18] <NCommander> TheMuso: ping?
[07:40] <fabrice_sp> Hi. Is it possible for a non MOTU member to help with merges from debian?
[07:40] <persia> fabrice_sp: Absolutely.  See https://wiki.ubuntu.com/MOTU/Contributing
[07:43] <fabrice_sp> persia: I know this page, but does it apply also to what you have at http://merges.ubuntu.com/universe.html ? Because I haven't been able to find references on how it works
[07:45] <persia> fabrice_sp: MoM is just a tool that tries to perform merges in a semi-automated fashion.  It's certainly not to be considered an authority on how to merge.
[07:45] <persia> There have been several sessions on merging, and I suspect there's lots of docs in the wiki.  That said, we're not really in a major merge phase right now, more focused on bugfixing (although that includes merges where merges close bugs)
[07:47] <fabrice_sp> persia: That's right from where I come from (a bug on dependency that is solved in Debian version)
[07:47] <fabrice_sp> persia: I will switch to another bug, then
[07:48] <NCommander> persia: is there a way to get MoM to do a merge of a package manually? (it hasn't done goffice-0-6 from Debian, and I'm considering requesting a Feature Freeze Request)
[07:49]  * NCommander has found another oldlibs that can be safely removed :-)
[07:50] <persia> NCommander: I'm not sure what you mean.  Do you mean that there is an update in Debian for which MoM has not yet prepared a merge candidate?
[07:51] <NCommander> persia: yes
[07:51] <persia> Well, you can complain for a MoM admin to update it, check to see if DaD did it, or just do the merge yourself.
[07:52] <persia> Generally, at this point in the cycle, I prefer to do merges myself to reduce the chance of introducing an issue with a merge mistake.
[07:52] <NCommander> DaD?
[07:53] <persia> dad.dunnewind.net (I think)
[07:53] <NCommander> persia: well, the diff between the upstream packages is huge
[07:53] <NCommander> So I'll leave that rdepends on goffice-0-4 in place, and zap it as jaunty opens
[07:53] <persia> NCommander: All the more reason to be careful.  You don't think MoM and DaD contain actual intelligence, do you?
[07:53] <persia> It's just an automated three-way merge with conflict markers.
[07:53] <NCommander> persia: no more than the person who created it :-)
[07:55] <persia> NCommander: Well, check https://launchpad.net/merge-o-matic to see what it does.  While I think it's creator was smart, I'm not sure it's really that smart.
[07:55] <NCommander> persia: to clear the rdepends on goffice-0-4, I need to update gnome-chemistry-utils, and to do that, I need to update two of its rdepends
[07:56] <persia> And to do all that, you ought chat with LaserJock who has been working in Debian SVN to prepare a suitable sync candidate.
[07:56] <NCommander> persia: on what? gnome-chemistry-utils?
[07:57] <persia> And the rdepends.
[07:58] <NCommander> I'll make sure to do that, because then we can remove goffice-0-4 which is one of the older oldlibs that would be nice to zap
[07:58]  * NCommander is filing bugs in Debian as he goes
[07:59] <persia> And one more step towards dropping GTK+1.2
[07:59] <NCommander> I've put on my goals list to kill all oldlibs as possible for jaunty
[08:39] <iulian> Good morning folks.
[10:25] <iulian> Does anyone want to ack a sync request for octaviz package?
[10:25] <iulian> Oh, it's bug #269422.
[10:31]  * RAOF grabs it.
[10:32] <RAOF> iulian: In return, you don't happen to be familiar with our translation infrastructre, are you? :)
[10:32] <DktrKranz> does anyone familiar with libtool ever seen something like this: http://hattory.no-ip.info/intrepid/result/libpam-heimdal_3.10-2/libpam-heimdal_3.10-2.buildlog ?
[10:33] <RAOF> I'm not sure that's a libtool issue?
[10:35] <RAOF> It looks like you're adding autogen.sh in a patch.  Is that right?
[10:38] <DktrKranz> autogen is added via quilt, yes
[10:38] <RAOF> Can you pastebin it?
[10:38] <RAOF> Also, why do you do that rather than simply call the relevent autofoo stuff?
[10:40] <DktrKranz> http://pastebin.ubuntu.com/46564/
[10:41] <DktrKranz> don't know, debian maintainer's choice
[10:45] <iulian> RAOF: I'm not sure I understand, what do you mean?
[10:50] <DktrKranz> RAOF, it seems not running libtoolize (from autogen.sh) fixes it
[10:52] <RAOF> You don't seem to be running automake, either?
[10:52] <DktrKranz> so it seems
[10:53] <RAOF> iulian: I mean - gnome-do installs some translations to /usr/share/locale/[lang]/LC_MESSAGES, and this doesn't work.
[10:53] <RAOF> Hm, dunno.
[10:54] <RAOF> iulian: When I copy that to locale-langpack/[lang]/LC_MESSAGES it works.
[10:54] <RAOF> (As in, running LANG=de_DE gnome-do results in various strings being in German)
[10:59] <iulian> RAOF: Ah, right. Sorry, I have no idea what could be the issue.
[10:59] <RAOF> iulian: That's fine.  Neither do I :)(
[11:01] <RAOF> Ah, the speedy compilation of C++...
[11:05]  * iulian yawns
[11:06] <iulian> It's 11am and I'm still asleep.
[11:06] <RAOF> Lies! It's 8pm :P
[11:07] <iulian> Yikes!
[11:07] <directhex> sorry, iulian is right
[11:07] <directhex> OVERRULED
[11:08] <iulian> Heh
[11:08] <RAOF> There should be some physical law that prohibits getting sunburt, while wearing sunscreen and a hat, in _spring_.
[11:12]  * Hobbsee thinks RAOF is right.
[11:12] <Hobbsee> RAOF: go to work instead.  it solves everything.
[11:14] <RAOF> Hobbsee: Even the most demanding of works can't prevent me emerging into the sunlight at _some_ point!
[11:15] <Hobbsee> RAOF: you expect to get burnt in a couple of minutes?
[11:18] <RAOF> Hobbsee: No, but I expect that there'll be days where I won't be working.
[11:18] <iulian> Does anyone of you happen to know how I am supposed to install a python app (two binaries), without having a setup.py file in the source code. Upstream's telling to make install but there is no Makefile.
[11:18] <iulian> I'm trying to build a package but debian/rules is driving me crazy.
[11:18] <Hobbsee> RAOF: foolish person.
[11:18]  * Hobbsee doesn't seem to have them.
[11:18] <Hobbsee> if uni counts as work, anyway.
[11:19] <RAOF> iulian: cp fileone.py filetwo.py /usr/bin
[11:19] <RAOF> ?
[11:19] <jml> RAOF: get new skin.
[11:19] <iulian> RAOF: Yay! That's all?
[11:19]  * iulian tries
[11:19] <RAOF> iulian: Well, you probably want to rename them so they don't end in .py.
[11:20] <RAOF> jml: I keep trying to order the psychochromatic skin, but it seems they can't fill their orders at the moment.
[11:21] <persia> RAOF: If you want a job that doesn't require you to *ever* see the sun, we have them here :)
[11:22] <RAOF> I'm not sure I'd like to go _that_ far :)
[11:22] <RAOF> persia: Do you have any understanding of our i18n infrastructure?  Any idea about why https://bugs.edge.launchpad.net/do/+bug/256856 happens?
[11:23] <persia> RAOF: I don't :(  Have you tried hunting down a translations channel and asking there?  That's probably the best chance of finding a developer with that knowledge.
[11:23] <RAOF> Good thinking, that man!
[11:24] <persia> Other than that, I'd suggest ArneGotje, as I always get pointed to him when I ask questions about localisation.
[11:43] <iulian> RAOF: It gives me permission denied while copying them to /usr/bin. What am I missing?
[11:44] <iulian> On the other hand I guess that I need to install them also, not only cp.
[11:44] <iulian> Well, this is my first time when packaging a python app.
[11:46] <RAOF> iulian: Actually, I'd use dh_install.  Sorry, the 'cp' was meant as the minimum you'd need to do.
[11:47] <iulian> Ahh right. Then I create two .install files. Using dh_install it's obsolete, if I'm not wrong.
[11:47] <RAOF> If you've got two biniary packages, create two install files, yes.
[11:48] <RAOF> If you've only got one binary package (containing both python scripts), you'll only need one .install file (or, just debian/install)
[11:48] <RAOF> It's not that using dh_install is obsolete (it's what reads the install files, after all).
[11:48] <RAOF> But using the install file is often easier to see what's happening, because that's the way most packages do it.
[11:49] <iulian> RAOF: Indeed, thanks.
[11:49] <RAOF> The build's now 94% complete.  Yay C++
[11:50] <persia> Erm.  dh_install *is* the program that reads the .install files.
[11:50] <RAOF> Right.  I may have mentioned that ;)
[11:51] <iulian> RAOF: It took me a couple of hours to build.
[11:51] <persia> Whether to put them in debian/rules or in debian/install is based on what makes the files easiest to read.
[12:07] <iulian> If a file is linked to another in the source package, is it automatically linked when the package is built or it has to be linked manually in debian/rules?
[12:11] <mok0> iulian: tar keeps links
[12:11] <mok0> iulian: but beware if it's an absolute symlink
[12:13] <persia> dh_link can help if you are having issues.
[12:14] <handschuh> hi
[12:14] <handschuh> for revu and ppa uploads, what distribution-name should be used? (unstable or i.e. hardy)
[12:18] <iulian> persia: Yup, already called.
[12:18] <iulian> handschuh: intrepid
[12:19] <handschuh> thanks
[12:32] <iulian> mok0, persia: You don't have to link it manually if it's already linked in the source package, I mean here it worked fine.
[12:33] <persia> iulian: Right.  It just depends on how it's linked in the source package.  As mok0 said, tar preserves links.  For some packages you need to manually delete the links and use dh_link.
[12:35] <iulian> Aha, thanks for telling me.
[12:44] <handschuh> the lintian-file of my revu-package tells me, that distribution intrepid is unknown
[12:45] <persia> handschuh: Ignore that.
[12:45] <handschuh> ok, thought so
[12:46] <handschuh> an other think i don't understand well is the native-package-with-dash-version-error
[12:48] <handschuh> does this mean, that i have to include something like 0ubuntu1 in the package-name?
[12:48] <persia> handschuh: Generally you ought do so.
[12:49] <handschuh> ok, thanks
[13:02] <handschuh> I am still getting the native-package-with-dash-version error although the packages name has been changed to 0.4.1-1ubuntu4
[13:03] <mok0> handschuh: do you have a diff.gz file?
[13:03] <handschuh> no ... ok thant might be tha point
[13:03] <handschuh> thanks
[13:04] <directhex> isn't debian switching to dash?
[13:07] <handschuh> mok0: isnt the diff.gz generated automatically?
[13:07] <mok0> Not if the source dir is identical to the orig.tar.gz file
[13:07] <mok0> handschuh: probably, you have a debian dir in the tarball
[13:08] <mok0> handschuh: which is what characterizes a native package
[13:08] <handschuh> mok0: there is no orig.tar.gz (I am the author of the program)
[13:08] <james_w> directhex: it's a release goal for lenny to make it possible to switch
[13:09] <james_w> directhex: whether or not they switch after that isn't decided I don't think
[13:10] <mok0> handschuh: if it's intended only for ubuntu, then it's a native package
[13:10] <handschuh> mok0: not only for ubuntu, but the sources are especially made to run on ubuntu without changes
[13:11] <mok0> handschuh: then you should make a distribution tarball w/o debian/
[13:12] <mok0> handschuh: you are both upstream and packager, those are two different caps
[13:14] <handschuh> mok0: and then include this as orig.tar.gz - ok, thanks!!
[13:15] <mok0> handschuh: yep, and the diff.gz will contain  debian/
[13:29] <iulian> RAOF: Did octaviz build correctly?
[13:29] <iulian> RAOF: On AMD64 of course.
[13:48] <slytherin> persia: ping
[13:48] <persia> slytherin: ?
[13:48] <slytherin> persia: I am here 10 minutes before time. :-)
[13:49] <persia> heh :)
[13:49] <persia> OK.  So, what about 0.28 did you think was worth the upgrade?
[13:49] <slytherin> I planned to come earlier but no electricity. :-(
[13:49] <persia> I've looked at the code myself, but I wasn't sufficiently convinced that it needed an FFe to request one.
[13:49] <persia> No electricity!  What happened?
[13:50] <slytherin> nothing, usual load shedding on weekends.
[13:50] <persia> bleh.  You need more local generating capacity.
[13:50] <directhex> a small nuclear reactor would work
[13:51] <slytherin> Yes our government knows that for long time. :-P
[13:52] <slytherin> persia: anyway, back to topic. I don't have any bluetooth adapter. So I can't really test any data transfer. I just tried version from Debian (0.27-1) and it solves at least one bug logged in intrepid.
[13:53] <persia> directhex: The issue is relying on any given source.  There are 17 nuclear reactors in my city, but a few years ago when there was a concern, and they were shut down for servicing, electricity got *very* expensive.
[13:53] <persia> slytherin: Which bug?
[13:53] <slytherin> persia: bug #258738 It is regression.
[13:54] <persia> slytherin: You've convinced me :)  Now when I looked most of the Ubuntu patch seemed to have been accepted upstream.  Does that match your findings?
[13:55] <slytherin> persia: yes that is what I was going to say. The big patch related to hildon seems to have been merged. My idea is that instead of directly updating to 0.28, we merge form Debian at 0.27
[13:56] <persia> I'd rather go with 0.28 if we're going to upgrade.  The upstream change between 0.27 and 0.28 is only a couple lines of bugfix, upstream provides a clean orig.tar.gz that may be used unmodified, and the debian packaging for 0.27 applies cleanly to 0.28, and 0.28 works.
[13:57] <slytherin> persia: wow. That is good. Let me just once checked what is the state of patch that was taken from fedora.
[13:59] <persia> slytherin: OK.
[13:59] <persia> I also mailed the Debian maintainer about this earlier: no plans to use 0.28 there.  Maybe for early squeeze, but probably a migration to BlueZ 4
[14:03] <slytherin> persia: checked fedora CVS. They have dropped the sendto patch in 0.28.
[14:04] <slytherin> 0.27 in fact
[14:05] <persia> Excellent, so 0.28 includes just about everything from Ubuntu, Debian, and Fedora, and is therefore probably the best combination of available bugfixes.
[14:05] <persia> Have you already started to prepare the patch?
[14:05] <iulian> Any ideas what could be wrong here http://paste.ubuntu.com/46618/plain/ ?
[14:05] <slytherin> persia: No. Since I don't have hardware there was no way I could test whatever I did.
[14:07] <persia> slytherin: OK.  I've hardware to test audio and data transfer.  I don't have hardware to test keyboards and mice.
[14:09] <slytherin> persia: That is fine. Can you once get confirmation from someone in mobile team if hildon patch can be dropped. The patch was added for low resolution screens.
[14:10] <persia> Unfortunately, the hildon patch cannot be dropped.  We're stuck with hildon for another cycle.
[14:11] <persia> On the other hand, I do have hardware on which I can test both i386 and lpia to see the effects.
[14:11] <slytherin> persia: is it possible to setup a VM for lpia?
[14:11] <persia> Certainly.  I run lpia in KVM every day.
[14:12] <persia> It also runs under qemu, and virtualbox.  I don't know about other environments.
[14:12] <slytherin> I found a better idea. I can simply check with 800x600 resolution. :-P
[14:13] <persia> Today's alternate CD was broken though.  You'd probably do best with the MID live image.
[14:13] <persia> slytherin: Remember that a hildonisation change only happens under hildon-desktop.
[14:14] <slytherin> persia: any wiki links about how to setup? KVM won't work for me. So I need either qemu or virtualbox instructions.
[14:15] <Adri2000> anyone of motu-sru around?
[14:16] <Hobbsee> they're all too intoxicated to come on irc.
[14:16] <Adri2000> :p
[14:19] <persia> slytherin: OK.  First, install qemu.  Then, install whatever kqemu-source generates (or wait while I finish looking it up)
[14:21] <persia> RIght.  Then install kqemu-source.  This should be DKMSified, so it compiles the right kernel modules to accellerate qemu.
[14:22] <persia> Then, point it at an image with a command line like qemu -hda ubuntu-mid.img -m 512M -monitor stdio
[14:25]  * slytherin starts with installing qemu.
[14:26] <persia> http://cdimage.ubuntu.com/ubuntu-mid/intrepid/20080913.1/ is the latest working lpia image of any sort.  Sorry that the alternate CD is broken :(
[14:26] <slytherin> no issues.
[14:28] <geser> slytherin: norsetto asked me how important the change to openjdk-6 is for intrepid. He prefers to make the current source to work with openjdk-6 instead of pulling in new upstream versions.
[14:28] <geser> slytherin: can you check if javassist needs much patching to work with openjdk-6?
[14:28] <slytherin> geser: Will check.
[14:31] <persia> geser: For many applications, the change to openJDK is fairly important, as if it only works with non-free Java, and we're providing free Java by default, it may cause some applications to not work properly.
[14:32] <persia> That said, it's not necessarily worth pulling new upstream except where required.  Even cherrypicking the API change bits is probably safer.
[14:40] <slytherin> persia: in case of java application, there is a simple rule that applies to 90% apps. "If it compiles without errors and warning, it will run for infinite future" :-)
[14:40] <persia> slytherin: Being someone who used to code Java for AS/400 machines, I know that isn't any more true now than it was then.
[14:41] <persia> That said, if you compile with a JDK targetting a given JRE, it should run on that JRE forever and without problems.
[14:41] <persia> And there's a good chance it will also work for other things.
[14:41] <slytherin> yes, that is why I said 90%
[14:41] <persia> Oh.  I'm having a problem with my margins, and miss some words.  Sorry :)
[14:59] <persia> slytherin: How is qemu coming?  Are you sure you don't want me to test the lpia bits?
[15:00] <slytherin> persia: It is still downloading. The connection is slow. :-(
[15:00] <persia> slytherin: OK.  Let me know if you need anything from this side.
[15:01] <slytherin> persia: Are you preparing package, or should I do it?
[15:01] <persia> slytherin: I was hoping you would, as I think that testing with input devices is more important than comms or audio.
[15:01] <persia> I can prepare if you think that's better.
[15:02] <slytherin> persia: I don't have anything to test.
[15:02] <persia> slytherin: You don't have any input devices?
[15:04] <slytherin> persia: I don't even have bluetooth dingle. I misplaced or lend it to someone about a month back and now can't find it.
[15:05] <persia> slytherin: OK.  Why do you want to upgrade bluez-gnome then?  Just to fix 258738?
[15:06] <slytherin> persia: No. Because I was hoping to buy the device on Friday. I didn't find time from office work.
[15:06] <slytherin> persia: But then if you can wait till tomorrow, I will buy it anyway.
[15:06] <persia> slytherin: OK.  Do you have input devices if you buy a dongle, or do we need more testers?
[15:07] <slytherin> persia: I have sony ericsson phone which would work as limited input device.
[15:07] <persia> slytherin: Hrm.  I think we need someone else.
[15:08] <persia> Does anyone have a bluetooth keyboard or mouse, and run GNOME on Intrepid?
[15:10] <slytherin> persia: send mail on bluetooth team mailing list. I am fairly sure you will find someone.
[15:10] <persia> We have a bluetooth team?  I thought you asked me about it because we didn't have one.
[15:11] <persia> IF we have a bluetooth team, and they haven't been clamouring for an upgrade, I'm suddenly less sure.
[15:15] <slytherin> persia: Yes, it was headed by dholbach at some point and then by tollef in hardy cycle. The problem is the team has more users and less developers.
[15:15] <handschuh> I have a problem creating a watch file: it should fetch something like "package_1.2.3-456.tar.gz" where 1.2.3 is the version and 456 the revision
[15:17] <persia> handschuh: Do you *really* want to name the upstream tarball like that?  It confuses things.  Can it not be 1.2.3.4.tar.gz?
[15:18]  * mok0 agrees with persia
[15:18] <mok0> handschuh: don't use more that (version, release, patchlevel) triplet
[15:18] <persia> Essentially, an upstream tarball should be something like foo-1.2.3.tar.gz, and then the watch file will change it to foo_1.2.3.orig.tar.gz, and the packaging will have foo_1.2.3-17.dsc
[15:19] <mok0> s/that/than
[15:19] <Coper> In harvest if I find a package with fedora patches should there be something done with that package then?
[15:19] <handschuh> it can be changed to one without the revision
[15:19] <persia> Coper: The Fedora patches could be reviewed, and you could determine if any of them would be useful to apply.
[15:20] <persia> IF there are useful patches, applying them is good.
[15:20] <persia> handschuh: That ought make the watch file easier to write.
[15:21] <mok0> handschuh: another reason is that you can't include the tarball release field very well in the package versioning
[15:22] <handschuh> persia: than it should be "http://url.to.the/page/with/links package_(\d+.*)\.tar\.gz" ?
[15:22] <mok0> It would have to be "foo_1.2.3~456-0ubuntu1" or something like that
[15:22] <handschuh> mok0: on the tarball, i strip the revision
[15:22] <persia> handschuh: That looks right to me.  I'd probably use ([\d\.]+), but that's because I don't like using .* in perl.
[15:22] <mok0> handschuh: good boy
[15:23] <slytherin> wow, dkms automatically compiled kqemu module and loaded it.
[15:23] <persia> mok0: One could uversionmangle around that, but yes, it's awkward.
[15:23] <handschuh> persia: thank you
[15:23] <persia> slytherin: Excellent.
[15:24]  * slytherin proceeds with image download
[15:25] <persia> slytherin: Unless you really want to do this tonight, tomorrow's images (generating in ~11 hours) will be ever so much better.
[15:25] <persia> There should be a working alternate CD.
[15:25] <slytherin> persia: I think I can wait. It also late for you. So let's do it tomorrow.
[15:26] <persia> slytherin: OK. I should be around from something like 11:00 or 12:00 UTC.
[15:26] <slytherin> persia: Fine. I will be home then.
[15:27] <slytherin> persia: I will get a package created and uploaded to my or team's ppa sometime tonight. So you can test it if I am not available.
[15:28] <persia> slytherin.  That sounds like a good plan.  If you happen to find some input testers, that would also be good.  I'll test the hildon environment, comms, and audio when I'm available.
[15:29] <persia> Probably a good idea to open a bug to start gathering test reports when you have something ready, for review by the release team.
[15:31] <slytherin> sure.
[15:34] <handschuh> persia: i have changed the files name to package_1.2.3.tar.gz but still package_([\d\.]+)\.tar\.gz is not beeing recognized
[15:35] <persia> handschuh: Try changing _ to -
[15:35] <persia> Also, please paste your watch file.
[15:37] <handschuh> persia: same result, watchfile: version=3 \n http://code.google.com/p/jaolt/downloads/list jaolt-([\d\.]+)\.tar\.gz
[15:38] <handschuh> maybe the files have to be in the same directory, as the html-page?
[15:39] <persia> handschuh: No, it's that "jaolt-([\d\.]+)\.tar.gz" doesn't match "http://jaolt.googlecode.com/files/jaolt_0.4.1.tar.gz"
[15:39] <persia> You want "http://jaolt.googlecode.com/files/jaolt_([\d\.]+)\.tar\.gz"
[15:39] <mok0> handschuh: that's not an underscore
[15:40] <persia> mok0: For upstream, it ideally oughtn't be.
[15:40] <handschuh> persia: thanks - its works now
[15:40] <handschuh> mok0: this was just for testing
[15:40] <persia> Oh, but I used one :)  Oops!
[15:41] <persia> handschuh: Please change _ to - in my regex.
[15:41] <handschuh> persia: done
[15:42] <persia> handschuh: Thanks.  Sorry for mistyping that, and thanks to mok0 for catching me on it.
[15:49] <bluefoxicy> hmm, the new kernel breaks sound it seems
[15:55] <slytherin> persia: where are lpia alternate CD images kept?
[15:59] <persia> slytherin: http://cdimages.ubuntu.com/ports/daily/
[15:59] <persia> The last couple failed, but I know all the right bits got set so that the next one (in ~10 hours) will be generated.
[15:59] <ma10> anyone knows what's going on with hppa builds? a package has been stuck waiting on default-jdk-builddep for 10 days!
[16:00] <slytherin> persia: Cool.
[16:00] <slytherin> persia: and which device do you have by the way for testing?
[16:00] <persia> ma10: There's a bit of a mess with hppa, and it needs a lot of help to figure out in what order things need to be built.  If you have one, and can fix it, all the other users would surely appreciate it.
[16:01] <persia> slytherin: I've a Kohjinsha SR
[16:01] <persia> It's only an A110, not an Atom, but it runs lpia.
[16:02] <ma10> persia: https://launchpad.net/ubuntu/+source/azureus/3.1.1.0-3ubuntu2/+build/708216  this is stuck, but i think it takes an admin to fix it
[16:02] <persia> I wouldn't recommend it as a new lpia purchase if you are looking for one: the Atom is a much better chip.
[16:03] <persia> ma10: No, just someone with give-back permission.  Is default-jdk-builddep published for hppa?
[16:03] <slytherin> persia: I am not looking for anything right now. Am I right to assume that Dell's mini is of same arch?
[16:04] <persia> I'm not sure.  I suspect so, but it's not in the shops here yet.
[16:06]  * Adri2000 is looking for a core-dev
[16:06] <ma10> persia: mhh that's the problem, it failed to build
[16:06] <persia> ma10: OK.  And why did it fail to build?
[16:07] <persia> ma10: Essentially, you'll need to research the tree of build failures until you find one that either should work now, or needs a small patch.  Then, either get the patch applied, or ask for a give-back of the build that should work.
[16:07] <persia> Once that is built, you can move up the stack until you get to azureus.
[16:08] <persia> Mind you, I didn't think there was a very good Java stack for hppa, but I'd be happy to be wrong.
[16:10] <ma10> persia: i'm on it. but what exactly is a give-back?
[16:11] <persia> ma10: It's term used to indicate that the source package is manually given back to the buildd for another try.
[16:11] <ma10> oh ok thanks
[16:11] <persia> If you find a package that *should* build, but didn't because the state of the archive at the time it tried to build wasn't sufficient, a give-back will fix it.
[16:12] <persia> An example would be the azureus build: once you have the build-dependency fixed, it can be given back, and should work without more changes.
[16:13] <ma10> and where do i find the list of ppl with that permission?
[16:13] <persia> ma10: Just ask here if you need something given back in universe, or in #ubuntu-devel if you need something given back in main.  It's a rare time of a rare day that nobody who can do it is watching the channel.
[16:15] <ma10> persia: ok, i'll go through the build logs
[16:15] <persia> ma10: Good luck.
[16:23] <AnAnt> Hello, is Ian Jackson here ?
[16:24] <azeem> doesn't look like
[17:02] <james_w> I want to sync a package that isn't in unstable any more (as of yesterday). It didn't migrate to testing either. However the source is still on ftp.debian.org.
[17:03] <james_w> Can I grab the relevant debdiff and request a sponsor for that, or should I change the version number?
[17:04] <slytherin> james_w: if the package is not in Debian anymore why should it be in Ubuntu?
[17:04] <james_w> slytherin: because it fixes a couple of RC bugs
[17:05] <james_w> however, the Debian maintainer just uploaded a new upstream to unstable
[17:06] <slytherin> james_w: Oh, I thought the complete package was removed. If you can get a FFE on new upstream version, fine. Otherwise you will have to backport particular fixes to Ubuntu package.
[17:06] <ma10> persia: i've found the problem, but i'm not sure how to fix it..
[17:07] <james_w> slytherin: I don't want an FFe, I want the RC bug fixes. I have a Debian package which has all we need, so I don't need to do any work, I just want to know if I can upload it unchanged, i.e. with the same version number and maintainer as it is a "sync", even though it will be done by hand.
[17:08] <slytherin> james_w: Syncs are never manual.
[17:09]  * slytherin is out for some time.
[17:09] <james_w> slytherin: they can be
[17:09] <ma10> persia: java-common does not build on hppa because there is no default jre defined. build-arch is completely skipped and genchanges complains there's no files list file .
[17:14] <slytherin> ma10: talk to doko about it.
[17:14] <ma10> persia: i think the problem is that dh_genchanges is called without dh_gencontrol. but ok we still have no default jre so it's going to be hard to generate stuff like default-jdk
[17:15] <ma10> slytherin: yes i see him in the changelog. thanks. doko, ping.
[17:17] <slytherin> ma10: if you check this announcement there is no mention of hppa. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-July/000460.html
[17:20] <ma10> slytherin: debian/rules in java-common has that exact configuration. so no java for hppa. Not that i care, but no java package will build there. And a failed build means that bugs are not closed etc.
[17:21] <slytherin> ma10: right. But nothing I can help there. May be default java should point to gcj for now.
[17:22] <ma10> slytherin: probably, it may be buggy but at least it wouldn't mess up the archives. we'll wait for doko.
[17:53] <slytherin> ma10: Instead log a bug and attach a debdiff. :-)
[17:58] <slytherin> ma10: looks like java-gcj-compat-dev is not built for hppa for latest version.
[18:02] <james_w> hi, anyone from motu-release around?
[18:03] <james_w> also, anyone willing to test-build a package for me?
[18:05] <crimsun> james_w: for hardy or intrepid?  dsc?
[18:06] <james_w> crimsun: intrepid
[18:06] <crimsun> I'll need to create a chroot, sec.
[18:06] <james_w> http://http.us.debian.org/debian/pool/main/s/solfege/solfege_3.11.3-4.dsc
[18:06] <james_w> it fails for me, but it feels like it might be something specific to me
[18:13] <ScottK> james_w: I'm around (from motu-release).
[18:13] <james_w> hi ScottK
[18:13] <ScottK> Heya.
[18:13] <james_w> a user just pointed me to bug 220717
[18:13] <james_w> the Debian version is said to fix it, but no-one really knows what the fix is
[18:14] <james_w> we could sync and hope that it works, but there are a couple of other changes in there
[18:14] <james_w> I can file an FFe (there's nothing major that I can see), but there's no guarantee of it working.
[18:14] <james_w> would you advise that I go ahead?
[18:14]  * ScottK looks at the bug.
[18:17] <ScottK> james_w: There's no feature changes there, so feel free to ask for sync and seek sponsorship as normal.
[18:17] <crimsun> james_w: dies with "xvfb-run /usr/bin/python test.py" on intrepid/amd64.
[18:17] <james_w> crimsun: same as me, thanks
[18:17] <james_w> I can't get xvfb-run to do anything here, and don't know how to get it to tell me what's wrong
[18:18] <james_w> I'd request a sync of the package otherwise
[18:18] <james_w> ScottK: great, thanks
[18:18] <james_w> is it ok to turn a bug report in to a sync request, or should it be filed separately?
[18:18] <Elbrus> I am trying to build a package which builddepend on libkexif1-dev and kde-devel, but they depend on different versions of kdelibs-dev, (kdelibs4-dev, kdelibs5-dev)
[18:19] <Elbrus> in Intrepid and in Debian-testing it is ok
[18:19] <Elbrus> what should I do, file a bug? where?
[18:20] <azeem> do you know why it does not depend on kdelibs4-dev directly?
[18:21] <Elbrus> which one do you mean, my package?
[18:21] <azeem> Elbrus: the package you try to build
[18:21] <slytherin> does anyone know how to fix this error - ld: unrecognized option '-Wl,-Bsymbolic-functions'
[18:21] <Elbrus> azeem: upstream said it kde-devel should be installed
[18:22] <Elbrus> s/it //
[18:22] <azeem> kde-devel is just a meta-package
[18:22] <james_w> slytherin: I don't think the linker should receive that option, "-Wl" tells gcc to pass the next bit to the linker.
[18:23] <Elbrus> azeem: so I am probably fine to depend only on kdelibs4-dev you mean?
[18:23] <azeem> Elbrus: well, whatever kde development packages you need
[18:23] <slytherin> james_w: Surprisingly Makefile has no such option.
[18:24] <james_w> slytherin: I think that might be one of the default compiler flags now
[18:24] <azeem> slytherin: does the Makefile invoke ld directly?
[18:24] <slytherin> azeem: yes it does.
[18:24] <azeem> that'd be the problem then
[18:25] <james_w> slytherin: it doesn't use $CFLAGS when invoking ld does it?
[18:25] <slytherin> james_w: no
[18:26] <azeem> $LDFLAGS?
[18:28] <slytherin> azeem: it is using LDFLAGS. Any chance LDFLAGS is getting set to something ld didn't expect?
[18:28] <azeem> 19:20 < james_w> slytherin: I don't think the linker should receive that option, "-Wl" tells gcc to pass the next bit to the linker.
[18:28] <azeem> I'm not sure LDFLAGS are supposed to be directly passed to the linker
[18:28] <slytherin> azeem: I will try commenting that part
[18:32] <Elbrus> azeem: I also should depend on libkonq5-dev (the package needs konq_operations.h), but that also depends on kdelibs5-dev
[18:32] <ScottK> james_w: I'd edit it into a sync request.  No point in having an extra open bug you have to go back and remember to close later.
[18:32] <james_w> ScottK: damn, just done the opposite :-)
[18:32] <james_w> ScottK: I'll make sure it's closed appropriately though
[18:32] <ScottK> james_w: It's not a big deal.  Either way works.
[18:33] <ScottK> Elbrus: Is this a KDE3 package or a KDE4 package?
[18:35] <Elbrus> ScottK: I have seen some comments about the difference, but I have no idea. It does build on hardy though (so I would answer KDE3??)
[18:35] <ScottK> In Hardy we have both.
[18:36] <ScottK> If it needs to build-dep on kdelib4-dev and libkonq then it's not going to work in Intrepid.
[18:36] <ScottK> Intrepid only has the KDE4 version of libkonq.
[18:37] <ScottK> So you'd need to make it work with kdelibs5-dev and libkonq-dev.
[18:40] <nellery> what is the intrepid sources.list entry to get the most up to date source?
[18:42] <Elbrus> ScottK: so I builddepend on a package that would not build in Intrepid: libkexif1-dev, should I file a bug against that package than?
[18:42] <slytherin> nellery: what entry do you have?
[18:43] <nellery> slytherin, I'm currently running Hardy
[18:43] <ScottK> Elbrus: What error did you get?
[18:43] <slytherin> nellery: deb-src http://archive.ubuntu.com/ubuntu intrepid main restricted universe multiverse
[18:45] <ma10> slytherin: java-gcj-compat was blocked by gcj-4.3, which is now available. We could give it back and put it as default in java-common.
[18:45] <nellery> slytherin, thank you
[18:45] <Elbrus> ScottK: libkonq5-dev: Depends: kdelibs5-dev (>= 4:4.0.73) but it is not going to be installed
[18:45] <slytherin> ma10: even gcj-4.3 is not built for hppa. Only gcj-4.3-base
[18:46] <Elbrus> unmet dependencies
[18:47] <Elbrus> after apt-get install libkexif1-dev libkonq5-dev (to test)
[18:50] <ScottK-laptop> Elbrus: That's on Hardy?
[18:51] <ma10> slytherin: you're right: "dpkg-genchanges: warning: package gcj-4.3 in control file but not in files list". What a mess.
[18:51] <Elbrus> ScottK-laptop: no, thats on Intrepid
[18:52] <ScottK-laptop> Elbrus: Have you mixed package from Debian in your machine?  According to LP, we never had that version: https://launchpad.net/ubuntu/+source/kde4libs/+publishinghistory
[18:54] <Elbrus> ScottK-laptop: mmm... I am using pdebuild to build in Intrepid. Apparently it is now running without complaining (uptil now).
[18:55] <ScottK-laptop> Elbrus: OK.  In any case your kdelibs5-dev is very old.  We're on 4:4.1.1 now.
[18:55] <ScottK-laptop> Figure out why you aren't up to date and fix that first.
[18:56] <Elbrus> ScottK-laptop: will do that, THANKS
[18:57] <cbx33> hey guys
[18:57] <cbx33> howz it all going
[19:00] <cbx33> do we have a semantic file system yet?
[19:00] <cbx33> or some way to tag files and folders?
[19:03] <ScottK-laptop> NCommander: Did you see the updated NMU proposal for php-clamavlib?  I like his better.  What do you think?
[19:04] <cbx33> oh hey NCommander did you see my reply to your comment on my blog?
[19:35] <Elbrus> ScottK-laptop: my kdelibs5-dev is up-to-date (it was just libkonq5-dev that depended on something higher than that source).
[19:35] <Elbrus>  I still have the problem with dependencies. I put some results at pastebin: my source file: http://paste.ubuntu.com/46680/, the end of the building process: http://paste.ubuntu.com/46681/ and the problem with installing libkonq5-dev: http://paste.ubuntu.com/46681/
[19:36] <Elbrus> the last one should be http://paste.ubuntu.com/46683/
[19:37] <slytherin> is't libc6-dev always installed in a default pbuilder chroot?
[19:38] <geser> slytherin: yes, it belongs to build-essential
[19:38] <ScottK-laptop> Elbrus: It looks like you have a fundamental problem here.  libkonq5-dev is a KDE4 library and libkexif1-dev is still a KDE3 library.  You can't mix them.
[19:38] <Elbrus> ok, but than libkexif1-dev will become useless in Intrepid??
[19:39] <Elbrus> should I file a bug? or isn't this a bug?
[19:39] <ScottK-laptop> Elbrus: I'm guessing your package is a KDE3 that needs libkonq.  That can't work in Intrepid.  You'll need to get a KDE4 version which probaby can't happen until libkexif1-dev is updated.
[19:40] <Elbrus> ScottK-laptop: so should I request that?
[19:40] <ScottK-laptop> Elbrus: If there's an updated version of libkexif1 available from upstream, then filing a bug asking our package to be updated is reasonable.
[19:41] <ScottK-laptop> Elbrus: Currently there are no packages that use libkexif1 in Intrepid.  The one that did in Hardy (showimage) doesn't use it anymore.
[19:42] <ScottK-laptop> Actually showimg was removed.
[19:45] <ScottK-laptop> Elbrus: I'd contact the ksquirrel upstream and ask them if they are working on a KDE4 version.
[19:49] <slytherin> geser: Can you please take a look at line 298 in source http://paste.ubuntu.com/46687/ and figure out what the problem is? I am getting error - storage size of 'cr' isn't known. This is regarding libmatthew-java
[19:55] <ScottK-laptop> Elbrus: libkexif looks pretty dead upstream too.
[19:55] <geser> slytherin: see comment #3 and #4 in bug 239765
[19:57] <Elbrus> ScottK-laptop: upstream doesn't have time at the moment for development, so I doubt that.
[19:57] <ScottK-laptop> Elbrus: OK.  There is no way to make that work on Intrepid then.
[19:58] <Elbrus> ScottK-laptop: well, that's a shame of my  work then :(
[19:58] <ScottK-laptop> Sorry to have bad news for you.
[19:59] <ScottK-laptop> There is a lot of the KDE 3 world that is going to have to get busy and update or get left behind.
[20:00] <Elbrus> ScottK-laptop: so the difference in programming is that big. It can not "easily" be converted?
[20:00] <ScottK-laptop> Elbrus: I think it depends a lot on the application.  There are some conversion tools to make it easier.  I haven't done any myself.
[20:05] <lfaraone|ffm> Hey, is an application that is GPL but uses non-free artwork acceptable?
[20:12] <slytherin> lfaraone|ffm: will the app work withut artwork?
[20:12] <slytherin> without
[20:13] <lfaraone|ffm> slytherin: Sure, it just would have to be replaced with something non-free.
[20:13] <lfaraone|ffm> slytherin: If it was not replaced, the compiler would throw an error.
[20:14] <slytherin> lfaraone|ffm: I think the package should be acceptable in multiverse
[20:14] <ScottK-laptop> lfaraone|ffm: It depends on how non-free the artwork is.  Is there license to distribute it?
[20:31] <lfaraone|ffm> ScottK-laptop: "All images included in this package constitute data and are not licensed
[20:31] <lfaraone|ffm> for you to use under the terms of the GPL. You may not use the images
[20:31] <lfaraone|ffm> included in this package for any reason without first obtaining permission from
[20:32] <lfaraone|ffm> "
[20:32] <lfaraone|ffm> (name not important)
[20:33] <ScottK> lfaraone|ffm: No, that can't go in the archive.
[20:33] <ScottK> It needs to have a license that allow redistribution to get into multiverse.
[20:33] <ScottK> allow/allows
[20:33] <lfaraone|ffm> ScottK: Ok.
[20:34] <lfaraone|ffm> ScottK: which means I can replace the art with something free, and it'd be fine.
[20:35] <ScottK> Yes.
[20:54] <slytherin> geser: does this debdiff look sane to you - http://paste.ubuntu.com/46702/
[21:27] <slytherin> does anyone know why latest python package in intrepid wants to install tcl and tk?
[21:27] <directhex> everyone loves tcl and tk!
[21:29] <james_w> slytherin: it's apparently a bug that will be fixed in a day or two
[21:29] <ScottK> slytherin: Python has some U/I tools that use it.
[21:29] <ScottK> And as james_w says, it's a bug.
[21:30] <slytherin> wow, didn't know that till date.
[21:32] <directhex> why would UI tools for one language be written with another? isn't that admitting defeat?
[21:33] <directhex> especially an ancient inferior cousin
[21:50] <cbx33> hey guys
[21:50] <cbx33> seems to be more people here now
[21:51] <cbx33> do we have a semantic file system available in ubuntu yet?
[21:51] <crimsun> not that I'm aware.
[21:51] <cbx33> :(
[21:51] <cbx33> I have like 40-50 CD-Rs
[21:51] <cbx33> with a tonne of stuff
[21:51] <cbx33> and I want to copy it all onto my server, but I want to kinda organise it
[21:51] <crimsun> there are applications that attempt to move away from the FS, but really they're workflow bandaids and not really "semantic file system"s.
[21:52] <cbx33> yeh
[21:52] <cbx33> I don't like trackerd
[21:52] <cbx33> CPU usage is silly
[21:52] <cbx33> anything similar
[21:52] <azeem> beagle
[21:52] <cbx33> nope
[21:58] <ScottK> Strigi
[22:39] <TheMuso> Is anybody using gnome-terminal in intrepid? Is there a way I can easily disable the shortcut keys alt + 1-0 from switching tabs? I could in hardy, but it appears the options for these keys for tabs in intrepid are not available in the shortcut kes window any more.
[22:39] <ScottK> TheMuso: Up for some FFE ack'ing?
[22:39] <TheMuso> ScottK: In a little while I'll take a look.
[22:46] <ScottK> TheMuso: I had a list, but norsetto seems to be working his way through at the moment.  Maybe there will be something left for you ...
[22:49] <cbx33> ScottK, strigi?
[22:49] <cbx33> is it any good?
[22:51] <ScottK-laptop> cbx33: I don't use any of them myself.  It's the KDE ~equivalent to Tackerd.
[22:52] <cbx33> ahh I see
[22:52] <cbx33> ScottK-laptop, Ideally I want to tag files
[22:52] <cbx33> guess I may have to just write one myself
[22:52] <ScottK-laptop> Dunno what to tell you.
[22:52] <cbx33> heheh
[22:53] <azeem> cbx33: "tag files" and "semantic file system" don't appear to be different things
[22:53] <azeem> eh
[22:53] <azeem> -don't
[22:53] <cbx33> azeem, sure