=== RAOF_ is now known as RAOF [00:06] if someone has free time, can please review this? http://revu.ubuntuwire.com/details.py?package=dsss [00:12] goshawk: What is "D" software? [00:13] software written in D? [00:13] d programming language? [00:16] goshawk: So this is a package management system for D software packages? [00:16] it's too, but primaly it's a make-like program [00:16] for D sources [00:16] in d programming language [00:17] in projects [00:17] you do a dsss.cong [00:17] conf [00:17] and it acts like a makefile [00:17] dsss is needed to start [00:17] packaging d packages in the ubuntu world [00:17] and [00:17] dsss has also the "net module" [00:18] that acts like ruby-gems [00:18] or python-eggs [00:18] so [00:18] dsss build: [00:18] look to dsss.conf in a source tree [00:18] and compile it [00:19] dsss net install package: [00:19] downloads sources of "package" [00:19] and run [00:19] dsss build [00:19] and dsss install [00:19] You realize that Debian packagers generally view things like Python ez_install or Ruby Gems as fundamentally evil. [00:19] ScottK-laptop: of course :) [00:19] i know [00:19] but it's minly used [00:20] mainly used [00:20] like make [00:20] i need it [00:20] to package tango library [00:20] which probably will be the standard library for D [00:20] if not [00:20] i've to write a makefile for each D project... [00:20] 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] just do not use the net command [00:21] and it's a make replacemente [00:21] replacement* [00:21] Or at least to notice if something's already installed via the packaging system and use that instead of installing another copy. [00:21] This is what Python ez_install is patched to do in Debian/Ubuntu. [00:22] ScottK-laptop: ah... it installs in ~/d [00:22] by default [00:22] not in /usr/bin [00:22] That's something. [00:22] if you are not root [00:22] are /etc/init.d/* scripts considered conffiles? [00:23] OK, that's one step up on Ruby Gems at the moment. [00:23] Adri2000: Generally. [00:23] damn :( [00:23] Adri2000: In particular it depends on if they are provided by the package or generated in postinst. [00:23] provided by the package [00:23] Adri2000: Init's are almost always provided and are conffiles. [00:23] conffile then. [00:24] goshawk: What if you are root? [00:24] if installs in /usb/bin [00:24] it* [00:25] yep it can be evil [00:25] i know [00:25] but at the end... is the user that decides [00:26] 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] How clear is it to the user before the do the install how much stuff is getting drug in from the net? [00:26] 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] 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] 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] I can't remember for sure, but I helped norsetto solve a similar problem a few months ago. Maybe he remembers. [00:29] nothing more [00:29] no dependency check [00:29] goshawk: So the end user decides, but they don't actually know what they are deciding. [00:29] no. they decide the application. and if they have not the source, dsss will download for them. no more [00:30] Ah, it doesn't grab dependencies? [00:30] at this stage no [00:30] it's not able to for now [00:30] this is why [00:30] Are you involved in the upstream development? [00:30] it's more like a make-like instead of a ruby-gem-like [00:31] ScottK-laptop: i think i'll be envolved soon [00:31] cuz [00:31] Adri2000: if version n's pre-rm fails then version n+1's pre-rm gets to try and fix things up. [00:31] 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] 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] james_w: So each pre-rm uses the old init and both fail. [00:32] Adri2000: fixing it depends on the exact reason for failure, needs to be done carefully. [00:32] ScottK-laptop: yeah, but the new one can know about the problem, and isn't forced to use the init script [00:32] the development will start again i think [00:34] james_w and Adri2000: I think using dh_installinit --error-handler you can solve this problem pretty robustly. [00:36] 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] Unfortunately REVU didn't go very well this cycle. [00:37] Hi guys! [00:37] james_w: ok I see, nothing to do with the init script being a conffile [00:37] hey [00:37] what is FFe? [00:37] Featre Freeze exception. [00:37] 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] We are past Feature Freeze, so new packages are not accepted currently. [00:37] is the process of becoming a MOTU to introduce yourself on the motu-mentors list? [00:37] ScottK-laptop: it's ok for me for Jaunty, but what should i do to make it accepted then? [00:37] Is postinst configure called for only the initial install,or for dpkg-reconfig too? [00:38] james_w: Generally, that's true, but in this particular case he knows that the old init is buggy. [00:38] 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] I need an option that is only called on initial install [00:38] 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] True. It's not ideal. it's a hard spot to get out of. [00:39] Adri2000: is that enough information for you to be able to work up a fix? [00:40] PMantis: What problem are you trying to solve? [00:41] 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] PMantis: What does this command do? [00:42] ScottK-laptop: Make a call to a website to register. It's only useful for my own systems. [00:42] james_w: no, I don't see how I could do that [00:43] 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] 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] PMantis: I'd suggest write a setting in a conffile and check for it's existence. [00:46] ScottK-laptop: ok, thanks [00:47] 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] ScottK-laptop: was that my gnome-control-center request? === foka_ is now known as foka [00:48] james_w: Yes. [00:49] 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] ScottK-laptop: excuse me, but what can i do to make my package be in the next version? [00:49] ScottK-laptop: it won't be a problem soon though hopefully. [00:49] Right. I'm sure it is, but I was hoping you could be helping them straighten it out. [00:51] 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] goshawk: Which next? Intrepid or Jaunty? [00:51] james_w: In the great and glorious future, won't they all be packaging branches? [00:51] jaunty [00:52] 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] ScottK-laptop: Jaunty [00:52] In any case I think this kind of thing should go to UMS, not core-dev. [00:52] james_w: It's because it's owned by core-dev. I can't unsubcribe. [00:52] ScottK-laptop: I will send packaging ones manually in the future [00:53] Is there a document that shows the order in which everything runs when a package is installed, upgraded. [00:53] ? [00:53] james_w: Don't get me wrong, I don't blame you, I think the system is messed up. [00:53] ScottK-laptop: but yes, they should all be packaging branches. It doesn't stop people from pushing to ~ubuntu-core-dev though. [00:53] ScottK-laptop: I understand. [00:53] 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] goshawk: Are you familiar at all with the Debian Python policy? [00:55] Something like that. [00:55] no i don't know debian python policy [00:55] i'll read it then [00:55] 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] ScottK-laptop: it's already implemented [00:56] dsss uses itself to be built like a package [00:56] to do so [00:56] i did a wrapper [00:56] makefile to dsss.conf [00:56] OK, does dpkg know about these? [00:57] no debuild just run makefile, and makefile run dsss [00:57] like a chain [00:57] The trick is to get the files registered with dpkg so conflicts and such can be managed. [00:57] so using this kind of makefile [00:57] Right. [00:57] * ScottK-laptop needs to run and make dinner. [00:57] ok ScottK-laptop [00:57] thanks for all [00:57] see you then :D [01:01] ScottK-laptop: would you be willing to try something for me? I'm interested in what's currently possible. [01:02] 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] 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] though getting interested parties to subscribe directly would be better. [01:05] james_w: It's just ubuntu-core-dev that's subscribed. [01:05] and there's no edit button? [01:06] 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] There's subscribe yourself and subscribe someone else. [01:06] It'd be subscribe/unsubscribe if I had the option to get out. [01:07] * ScottK really goes to make dinner now. [01:07] well, there's "edit" as well for branch subscriptions, as you can get different levels of notifications, but yes, I agree [01:08] 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. === ccheney is now known as calc [01:11] ScottK, james_w: thanks, seems to work using --error-handler [01:11] Adri2000: would you mind if I take a look at the patch? [01:14] james_w: http://paste.ubuntu.com/46455/ [01:14] thanks [01:15] what was the error in the previous version? [01:15] in the previous version of the init script? --oknodo missing [01:18] Adri2000: it looks ok to me. [01:18] Adri2000: however, from the manpage: "The function should be provided in the prerm and postinst scripts" [01:20] 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] if it fails to start then there is probably no harm in trying to stop it [01:22] 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] but if it also has --oknodo for the start action then the snippet shouldn't be called. [01:26] 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] Adri2000: yes, but that doesn't mean that there wasn't an instance started in that time [01:34] well, I'll re-check/test and upload tomorrow. I'm far too tired now [01:35] good night/whatever [01:35] good night === jono__ is now known as jono [02:21] hi all [02:21] i have a question: i found some wrong comments in the package screen-resolution-extra and want to fix them. [02:22] 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] it's my first time i want to do something like that, so i don't know whats better. [02:36] toabctl: It depends a little on the package, but generally debdiff is better. [02:37] ScottK, ok. thx [02:39] 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] But of course it's always better to fix it upstream first. [02:58] Is it possible to pin a version with a specific ubuntu rev? (version-ubuntu1) Does apt stop noticing past the hyphen? [02:59] A package I am packaging gets a lintian warning: binary-or-shlib-defines-rpath [03:00] what is the general consensus: should I fix this? [03:00] It is a KDE image viewer called KSquirrel [03:01] apachelogger: ping [03:04] Elbrus: Please fix it unless you *really* need rpath and know exactly why. [03:04] persia: ok, just checking, because the warning said it might be acceptable [03:05] 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] 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] persia: you know a good place to find the "easiest" way to solve it? [03:09] 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] 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] 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] Elbrus: See http://wiki.debian.org/RpathIssue [03:17] Elbrus: See the link provided, but yes, I probably mean something like that [03:17] * persia tends to shy away from rpath [03:18] 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] 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] 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] 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] peria,ScottK-laptop: Ok, I will try in the mentioned order. THANKS. [03:25] Aha! http://lists.debian.org/debian-devel/2008/01/msg00308.html is hugely enlightening for those experiencing -rpath issues *only* for amd64 [03:26] (or ia64 as well, I suppose, but that doesn't tend to be the default environment for most peope) [03:41] 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] Elbrus: That's core KDE, not extras. [03:42] ScottK-laptop: you mean the KDE developers, or the admin directory that is shared? [03:43] I mean the admin directory is shared in KDE core packages. [03:43] ScottK-laptop: I should say, developers of KDE related software copy the admin directory around [03:43] Not in KDE extras packages. [03:44] 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] ScottK-laptop: I saw that, so should I try to replace/patch my admin directory to use that from kapptemplate [03:44] I didn't say that. [03:45] 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] That is what I thought. [03:46] Ok, I'll just try to fix this here. === jscinoz_ is now known as jscinoz === jscinoz_ is now known as jscinoz [06:59] Anyone in the mood to sponsor some uploads and/or fixs? [07:18] TheMuso: ping? [07:40] Hi. Is it possible for a non MOTU member to help with merges from debian? [07:40] fabrice_sp: Absolutely. See https://wiki.ubuntu.com/MOTU/Contributing [07:43] 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] 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] 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] persia: That's right from where I come from (a bug on dependency that is solved in Debian version) [07:47] persia: I will switch to another bug, then [07:48] 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] 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] persia: yes [07:51] 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] 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] DaD? [07:53] dad.dunnewind.net (I think) [07:53] persia: well, the diff between the upstream packages is huge [07:53] So I'll leave that rdepends on goffice-0-4 in place, and zap it as jaunty opens [07:53] NCommander: All the more reason to be careful. You don't think MoM and DaD contain actual intelligence, do you? [07:53] It's just an automated three-way merge with conflict markers. [07:53] persia: no more than the person who created it :-) [07:55] 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] 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] 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] persia: on what? gnome-chemistry-utils? [07:57] And the rdepends. [07:58] 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] And one more step towards dropping GTK+1.2 [07:59] I've put on my goals list to kill all oldlibs as possible for jaunty [08:39] Good morning folks. [10:25] Does anyone want to ack a sync request for octaviz package? [10:25] Oh, it's bug #269422. [10:25] Launchpad bug 269422 in octaviz "Please sync octaviz 0.4.7-2 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/269422 [10:31] * RAOF grabs it. [10:32] iulian: In return, you don't happen to be familiar with our translation infrastructre, are you? :) [10:32] 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] I'm not sure that's a libtool issue? [10:35] It looks like you're adding autogen.sh in a patch. Is that right? [10:38] autogen is added via quilt, yes [10:38] Can you pastebin it? [10:38] Also, why do you do that rather than simply call the relevent autofoo stuff? [10:40] http://pastebin.ubuntu.com/46564/ [10:41] don't know, debian maintainer's choice [10:45] RAOF: I'm not sure I understand, what do you mean? [10:50] RAOF, it seems not running libtoolize (from autogen.sh) fixes it [10:52] You don't seem to be running automake, either? [10:52] so it seems [10:53] iulian: I mean - gnome-do installs some translations to /usr/share/locale/[lang]/LC_MESSAGES, and this doesn't work. [10:53] Hm, dunno. [10:54] iulian: When I copy that to locale-langpack/[lang]/LC_MESSAGES it works. [10:54] (As in, running LANG=de_DE gnome-do results in various strings being in German) [10:59] RAOF: Ah, right. Sorry, I have no idea what could be the issue. [10:59] iulian: That's fine. Neither do I :)( [11:01] Ah, the speedy compilation of C++... [11:05] * iulian yawns [11:06] It's 11am and I'm still asleep. [11:06] Lies! It's 8pm :P [11:07] Yikes! [11:07] sorry, iulian is right [11:07] OVERRULED [11:08] Heh [11:08] 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] RAOF: go to work instead. it solves everything. [11:14] Hobbsee: Even the most demanding of works can't prevent me emerging into the sunlight at _some_ point! [11:15] RAOF: you expect to get burnt in a couple of minutes? [11:18] Hobbsee: No, but I expect that there'll be days where I won't be working. [11:18] 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] I'm trying to build a package but debian/rules is driving me crazy. [11:18] RAOF: foolish person. [11:18] * Hobbsee doesn't seem to have them. [11:18] if uni counts as work, anyway. [11:19] iulian: cp fileone.py filetwo.py /usr/bin [11:19] ? [11:19] RAOF: get new skin. [11:19] RAOF: Yay! That's all? [11:19] * iulian tries [11:19] iulian: Well, you probably want to rename them so they don't end in .py. [11:20] jml: I keep trying to order the psychochromatic skin, but it seems they can't fill their orders at the moment. [11:21] RAOF: If you want a job that doesn't require you to *ever* see the sun, we have them here :) [11:22] I'm not sure I'd like to go _that_ far :) [11:22] persia: Do you have any understanding of our i18n infrastructure? Any idea about why https://bugs.edge.launchpad.net/do/+bug/256856 happens? [11:22] Launchpad bug 256856 in do "[i18n] Gnome-Do doesn't launch locale file (.mo) in the right directory" [Undecided,New] [11:23] 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] Good thinking, that man! [11:24] Other than that, I'd suggest ArneGotje, as I always get pointed to him when I ask questions about localisation. [11:43] RAOF: It gives me permission denied while copying them to /usr/bin. What am I missing? [11:44] On the other hand I guess that I need to install them also, not only cp. [11:44] Well, this is my first time when packaging a python app. [11:46] iulian: Actually, I'd use dh_install. Sorry, the 'cp' was meant as the minimum you'd need to do. [11:47] Ahh right. Then I create two .install files. Using dh_install it's obsolete, if I'm not wrong. [11:47] If you've got two biniary packages, create two install files, yes. [11:48] 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] It's not that using dh_install is obsolete (it's what reads the install files, after all). [11:48] But using the install file is often easier to see what's happening, because that's the way most packages do it. [11:49] RAOF: Indeed, thanks. [11:49] The build's now 94% complete. Yay C++ [11:50] Erm. dh_install *is* the program that reads the .install files. [11:50] Right. I may have mentioned that ;) [11:51] RAOF: It took me a couple of hours to build. [11:51] Whether to put them in debian/rules or in debian/install is based on what makes the files easiest to read. [12:07] 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] iulian: tar keeps links [12:11] iulian: but beware if it's an absolute symlink [12:13] dh_link can help if you are having issues. [12:14] hi [12:14] for revu and ppa uploads, what distribution-name should be used? (unstable or i.e. hardy) [12:18] persia: Yup, already called. [12:18] handschuh: intrepid [12:19] thanks [12:32] 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] 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] Aha, thanks for telling me. [12:44] the lintian-file of my revu-package tells me, that distribution intrepid is unknown [12:45] handschuh: Ignore that. [12:45] ok, thought so [12:46] an other think i don't understand well is the native-package-with-dash-version-error [12:48] does this mean, that i have to include something like 0ubuntu1 in the package-name? [12:48] handschuh: Generally you ought do so. [12:49] ok, thanks [13:02] 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] handschuh: do you have a diff.gz file? [13:03] no ... ok thant might be tha point [13:03] thanks [13:04] isn't debian switching to dash? [13:07] mok0: isnt the diff.gz generated automatically? [13:07] Not if the source dir is identical to the orig.tar.gz file [13:07] handschuh: probably, you have a debian dir in the tarball [13:08] handschuh: which is what characterizes a native package [13:08] mok0: there is no orig.tar.gz (I am the author of the program) [13:08] directhex: it's a release goal for lenny to make it possible to switch [13:09] directhex: whether or not they switch after that isn't decided I don't think [13:10] handschuh: if it's intended only for ubuntu, then it's a native package [13:10] mok0: not only for ubuntu, but the sources are especially made to run on ubuntu without changes [13:11] handschuh: then you should make a distribution tarball w/o debian/ [13:12] handschuh: you are both upstream and packager, those are two different caps [13:14] mok0: and then include this as orig.tar.gz - ok, thanks!! [13:15] handschuh: yep, and the diff.gz will contain debian/ [13:29] RAOF: Did octaviz build correctly? [13:29] RAOF: On AMD64 of course. [13:48] persia: ping [13:48] slytherin: ? [13:48] persia: I am here 10 minutes before time. :-) [13:49] heh :) [13:49] OK. So, what about 0.28 did you think was worth the upgrade? [13:49] I planned to come earlier but no electricity. :-( [13:49] I've looked at the code myself, but I wasn't sufficiently convinced that it needed an FFe to request one. [13:49] No electricity! What happened? [13:50] nothing, usual load shedding on weekends. [13:50] bleh. You need more local generating capacity. [13:50] a small nuclear reactor would work [13:51] Yes our government knows that for long time. :-P [13:52] 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] 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] slytherin: Which bug? [13:53] persia: bug #258738 It is regression. [13:53] Launchpad bug 258738 in bluez-utils "intrepid regression: bluetooth services without name in tab "Services"" [Undecided,Confirmed] https://launchpad.net/bugs/258738 [13:54] 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] 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] 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] persia: wow. That is good. Let me just once checked what is the state of patch that was taken from fedora. [13:59] slytherin: OK. [13:59] 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] persia: checked fedora CVS. They have dropped the sendto patch in 0.28. [14:04] 0.27 in fact [14:05] 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] Have you already started to prepare the patch? [14:05] Any ideas what could be wrong here http://paste.ubuntu.com/46618/plain/ ? [14:05] persia: No. Since I don't have hardware there was no way I could test whatever I did. [14:07] slytherin: OK. I've hardware to test audio and data transfer. I don't have hardware to test keyboards and mice. [14:09] 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] Unfortunately, the hildon patch cannot be dropped. We're stuck with hildon for another cycle. [14:11] On the other hand, I do have hardware on which I can test both i386 and lpia to see the effects. [14:11] persia: is it possible to setup a VM for lpia? [14:11] Certainly. I run lpia in KVM every day. [14:12] It also runs under qemu, and virtualbox. I don't know about other environments. [14:12] I found a better idea. I can simply check with 800x600 resolution. :-P [14:13] Today's alternate CD was broken though. You'd probably do best with the MID live image. [14:13]