Re: RFS: chatplus
On Sat, Mar 17, 2007 at 06:17:36PM +0100, Thomas Jollans wrote: to be precise, the source package is both lintian and linda clean, the binaries are not. (Linda has no problem with non-executable scripts though) Just FYI, but if you pass the .changes (instead of the .dsc) to lintian and linda, they will check the source and the binary packages for you. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: backports.org became really shitty for php5-mysql and mysql-server-5.0
On Sun, Mar 18, 2007 at 08:11:15AM +1100, Craig Sanders wrote: well, what did you expect? if you're using backports.org, you may as well be using unstable. That's not quite true. You may as well be using unstable for the packages you are pulling from backports. in fact, you're better off with unstable because there are more people using it, so it is better tested. with backports.org, you can be pretty sure that NOBODY else is using your exact combination of libraries and other packagesso you may be the ONLY person to ever encounter a particular bug. Really? So, he's better off with unstable so that he can potentially be the first user to find it there instead of in backports? So that he can also be potentially bitten by any number of bugs which invariably hit unstable first? IMO, backports.org is just a second-rate way of running 'unstable' for people who are scared by the name 'unstable'. (and 'testing' is a way of running 'unstable' with a long delay for any urgent fixes. although at least it also serves the useful purpose of testing the next release so it's a good thing that some people use it) If an orphaned package is the subject of a security advisory, who fixes it? In stable, it is the security team. In unstable, there is no obligation for anybody to provide security support. Someone on the security team or the QA team may be nice enough to do a QA upload of the new version of the package (as many upstream developers release security fixes by releasing whole new versions), but nobody is obligated to do that. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Legends The Game, new debian package
On Sun, Mar 04, 2007 at 11:51:47AM +0100, Bart Martens wrote: On Sun, 2007-03-04 at 12:15 +0200, Damyan Ivanov wrote: Shouldn't the source package name reflect that it has been re-packaged? Something like legends-0.4.1.42.ds.1 ? It should be documented in debian/README.Debian-source or some similar file. I don't think it's mandatory to give the .orig.tar.gz a special name. I agree, in this case it is probably not necessary to rename. Usually, when a .orig.tar.gz is renamed, it is to indicate that something is missing or added. For example, many packages have .dfsg. in the name since they have had source files or documentation removed because they were non-free. Removing the shipped embedded library does not functionaly change the package, since those components will be substituted by the appropriate library packages in Debian. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Legends The Game, new debian package
On Sat, Mar 03, 2007 at 06:50:35PM +0100, Bart Martens wrote: No, I would keep those in the package, and install them here: /usr/lib/legends/common/client.unf /usr/lib/legends/common/edit.unf /usr/lib/legends/common/server.unf /usr/lib/legends/common/ui.unf /usr/lib/legends/legends/interiors.unf /usr/lib/legends/legends/data.unf /usr/lib/legends/legends/missions.unf /usr/lib/legends/legends/scripts.unf /usr/lib/legends/legends/sounds.unf /usr/lib/legends/legends/voices.unf /usr/lib/legends/show/scripts.unf /usr/lib/legends/show/ui.unf Are those files platform dependent or platform independent? Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Legends The Game, new debian package
On Sat, Mar 03, 2007 at 08:17:16PM +0100, olaf wrote: On Saturday 03 March 2007 19:17, Roberto C. Sanchez wrote: Are those files platform dependent or platform independent? Regards, -Roberto Hi Roberto They are platform independent (at least I think so). *.unf are zip-archives and contain the data for legends (torque-scripts, 3d-models, textures...) You can't have platform independent files in /usr/lib. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Legends The Game, new debian package
On Sat, Mar 03, 2007 at 11:07:04PM +0100, olaf wrote: So, I ve changed now following things: - scripts are now in /usr/games/ - moved binaries to /usr/lib/legends/ and added links to data files which are in /usr/share/games/legends That's good. Todo: solve copyright and license problems I havnt uploaded anything yet and I doubt that I am able to upload the files with suse-linux at my school (no dput?). What shall I do? :( Not sure. Another question: Are shared libraries basically allowed? Legends uses following shared libraries which i ve placed in /usr/lib/legends too : /usr/local/share/games/legends/libogg.so.0 /usr/local/share/games/legends/libopenal.so /usr/local/share/games/legends/libSDL-1.2.so.0 /usr/local/share/games/legends/libSDL-1.3.so.0 /usr/local/share/games/legends/libvorbis.so.0 This will certainly get your package rejected by the ftp-masters. All of those libraries exist in their own packages on Debian, you need to link against those. Embedding libraries like that has been a great source of headaches to the security team, hence the policy. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Legends The Game, new debian package
On Fri, Mar 02, 2007 at 11:26:31PM +0100, olaf wrote: Hi all I have created a new debian package for legends. (I use debian, so I could maintain the package) Aditionally I ve included a manpage, a menu-entry and scripts in /usr/bin to execute the binaries in the directory /usr/share/games/legends/ . Its still only hosted on http://hosted.filefront.com/0laf , but i ll try to upload it to mentors.debian.net. Umm, having binaries anywhere in /usr/share is a policy violation. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: REALLY OT: News Flash
On Sun, Feb 25, 2007 at 01:37:29PM -0800, Tyler MacDonald wrote: Are you suggesting that instead of creating a debian off topic mailing list, we should create a debian-help list instead, specifically mandated on the topic of getting and giving help with debian? debian-user's description is Help and discussion among users of Debian... obviously these two topics need to be separated so that there's a list where debian users can be *productive*. I think that people on this list are plenty productive. The description for debian-devel says that it is for discussion related to the development of Debian and the description for -project says that it is for non-technical issues affecting Debian. That does not stop things from drifting far OT on those lists. Now, if you wanted a moderated list, that might make it slightly more likely to get what you want. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 09:17:37AM +0100, Thijs Kinkhorst wrote: On Mon, 2007-01-22 at 19:51 -0500, Roberto C. Sanchez wrote: I disagree. How do I know that r91 was committed two days ago? This also does not hold for regular, released versions. I don't see why this should be conveyed in the version number of snapshot packages and not for regular releases: how fresh is version 2.1.8 of a package? True. However, when the package goes from version 2.1.8 to version 2.4.3, I have vague idea of how significant the change was, assuming the upstream developers follow half-way sane versioning practices. I know that sometimes a 0.0.1 increment can be a huge change and a major version increase can be something completely transparent to the user. However, with the svn repository version number, I have absolutely no idea of the magnitude of the changes. Perhaps freshness was not the best word. Anyhow, i still maintain that including the date is not at all harmful and can only help end users. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 09:35:38AM +, Neil Williams wrote: As commented elsewhere, normal release numbers do not have any date component and you've still got the problem that multiple svn commits are frequently made on the same day. The date, in this context, is just misleading and would need to be a full UTC timestamp to have any real meaning. The revision number is far more precise and just like a normal I'm sorry, but I think this is bogus. For every one free software project that has a situation where the make multiple *significant* commits in a single calendar day, there are probably 100 which average less then a single commit per day or for which the last commit of the day is the most significant. The case you mention, I believe, is by far the exception and not the rule. 1:2.3.4-5 release string, you would need to refer to the upstream website(s) to determine the date of the release. The advantage of just using the svn 'r' number is that it makes this information available precisely and without duplication. Looking up that 'r' number not only tells you the date - just as looking up a normal release string would do - it also uniquely identifies the point at which the upstream code was packaged - again, just as a release string is intended to do. I see your point. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: native packages
On Tue, Jan 23, 2007 at 10:02:05PM +1100, Andrew Donnellan wrote: So essentially, store debian/ etc in the upstream VCS, but keep it out of releases and only add the directory when building a Debian package? Does this mean I should create a snapshot of everything except the debian files, then copy the debian files in to make a diff? A parallel branch structure might make sense in your case. Then you can just merge trunk changes up to your branch periodically. As long as you use dpatch and don't touch any upstream files, you will never have a conflict. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 12:40:21PM +, Neil Williams wrote: Not true. You cannot reliably ensure that a commit at 11:50:00 -0500 is actually part of your daily snapshot without specifying your timezone in the snapshot date, i.e. creating a full UTC timestamp in the version string. Many free software developers are most active in the evening (in their timezone) so this problem occurs frequently. The svn 'r' system is specifically designed to cope with this inadequacy of CVS - it is, IMHO, crazy to dump it for imprecise and inaccurate 'date' strings. Using a full UTC timestamp is even worse - far too messy. Looking up an 'r' number is as trivial as putting svn r12314 project into google. I really don't see what could possibly be easier. Right. However, I think we are rapidly approaching overkill in this discussion. How about this: * the version string includes the date * the changelog mentions the exact rev No ambiguity. Someone interested in the source would (or should) have the wherewithal to look at the changelog or other documentation if he considers there to be some sort of ambiguity. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: [OT] svn rollback
On Wed, Jan 24, 2007 at 12:05:02AM +1100, Robert Collins wrote: On Tue, 2007-01-23 at 12:34 +0100, Stefano Zacchiroli wrote: Uh? Is rollback (in the sense of undoing a commit) possible with SVN without manually fiddling in the repository at all? If this is *not* the case and you're meaning committing a patch undoing a past change, then the new commit will get a greater revision number. disk crash - restore from backup. Naturally, this is a daily happening for most projects, no? :-) No, there is no api to remove revisions, which is why its an unusual event :). There is wisdom in what the svn devs did. :-) Other VCS's however, allow rollbacks to occur much more easily ;). Yes, like CVS, which encourages admins to manually edit the repository itself. Argh. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 01:59:32PM +, Neil Williams wrote:
On Tue, 23 Jan 2007 08:28:10 -0500
Roberto C. Sanchez [EMAIL PROTECTED] wrote:
Right. However, I think we are rapidly approaching overkill in this
discussion. How about this:
* the version string includes the date
I still see no reason for any package built from svn to include the
date in any version string. It just makes it look like the DD doesn't
understand how SVN differs from CVS.
Right, and I would see it as the DD being superior to the user by
including something that might make no sense to the user.
* the changelog mentions the exact rev
Wrong way around, IMHO. The ChangeLog normally includes dates, as does
debian/changelog ('changelog' is ambiguous in this context) - it may
include svn 'r' strings too but, primarily, ChangeLog uses dates and
debian/changelog does not support anything but dates as timestamps.
I meant as an actual entry. Something like this:
* updated to r4387 from svn
Take a look at gnucash - it outputs the svn 'r' number in the
splashscreen and in the Help:About. A snapshot of gnucash would
definitely need to use 2.0.2~r14542 - there's no place for a date when
the package itself declares itself by means of svn 'r' numbers.
If that is the pattern used by upstream, that is fine. I think lots of
proprietary software packages do that as well. Something like version
2.0.1.5236, where 5236 represents a way to identify the exact revision
in the developer's source control system. Of course, most show the
version without that to avoid confusing users.
It is trivial to retrieve the svn number from the checked out working
copy during the build and therefore make a completely automated
snapshot that incorporates the 'r12356' into any portion of the build.
I don't see how this makes things easier for the end user. By the end
user, I mean someone who is just interested in getting and installing a
package. Somebody wanting to customize/recompile/whatever will be able
to figure it out.
Regards,
-Roberto
--
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 10:40:03AM +1100, Andrew Donnellan wrote: Hi mentors, I'm currently creating a package for the Jabber/VoIP client Jabbin which I requested sponsorship for earlier, however I am redoing the package from scratch and have decided that it is better to package snapshots from SVN rather than the not-exactly-stable releases. What is the preferred versioning scheme for SVN snapshots? On p.d.o I've seen various schemes, including things like 1:01.03.00.99.svn.300, 0.9.2+r1842.20061207 and 0.11.1+svn-r3965. Is it just a matter of personal preference? I guess it depends. If there has been no stable release with a version number, then something like 20070112svn is what I would use for the upstream version. Personally, I would stay away from using rev numbers since they are meaningless to anyone not intimately familiar with development of that package. For something that has had stable releases and you are packaging snapshots between releases, I would do something 1.1.15~20070112svn for the upstream version. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Mon, Jan 22, 2007 at 10:14:50PM -0200, Nelson A. de Oliveira wrote: Hi! On 1/22/07, Roberto C. Sanchez [EMAIL PROTECTED] wrote: I guess it depends. If there has been no stable release with a version number, then something like 20070112svn is what I would use for I would suggest using 0.0.date [1] Good point. I forgot about this one. Regards, Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 11:15:06AM +1100, Andrew Donnellan wrote: So for a snapshot of revision 91 between stable version 2.0 and future version 2.1, would something like: 2.1~20070123svn.r91 be OK? I like that. It is a sort of the best of both worlds approach. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 11:17:53AM +1100, Andrew Donnellan wrote: Another question: is it considered OK to leave .svn directories in the orig.tar.gz when packaging snapshots? Lintian should flag this as an error or a warning. In short, no. You want to export and not simply checkout or packup a working directory. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 01:39:30AM +0100, martin f krafft wrote: also sprach Andrew Donnellan [EMAIL PROTECTED] [2007.01.23.0115 +0100]: So for a snapshot of revision 91 between stable version 2.0 and future version 2.1, would something like: 2.1~20070123svn.r91 Why bother with the date? 2.1~svn-r91 seems much more concise and has the same information, really. I disagree. How do I know that r91 was committed two days ago? I think that having the date in the version gives the end user a good idea of the freshness of the program. Without it, the user would be required to look at the source control upstream to see when it was committed. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: SVN snapshot versioning
On Tue, Jan 23, 2007 at 01:26:09AM +, martin f krafft wrote: Good thinking, you got me there for a second. But it does not seem like this is a worry: lapse:~ dpkg --compare-versions 2.1~svn-r91 gt 2.1~svn-r115 || echo no no I thought would be more appropriate. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: reasons why downgrades are Not Supported
On Sun, Jan 14, 2007 at 01:21:37AM -0500, Justin Pryzby wrote: Package downgrades are not supported. Usually, they will work, since it is often just replacement of a set of files with different ones (often the same names) with different contents. I think if there were always true, downgrades would be no problem (besides the general tendency for higher versions to have more features and less bugs). Some upstreams introduce non-backwards compatible changes in point releases. For things like file formats and the like, it can be a real pain since in many cases programs check for older-styler formats of their own files/whatevers and not newer. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Tone-of-voice used by sponsors
On Sun, Jan 14, 2007 at 08:34:21PM +0100, Andreas Barth wrote: Well, I would recommend that common packaging hints should go to the developers reference, and please only one thing per bug report. (Taste issues however won't go there, different people have different tastes, that's a feature). I agree. However, I think the issue concerns the requirement that someone's preferences be followed. For example, it is one thing to say, I can't sponsor your package because you use cdbs and I don't know anything about it. It is completely different to say, I won't sponsor your package because I don't like the changelog format you used. Now, if something is a legitimate issue, it should be identified by lintian and/or linda in addition to being mentioned in policy and/or the developer reference. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Tone-of-voice used by sponsors
On Mon, Jan 15, 2007 at 04:29:58AM +0800, Thomas Goirand wrote: Daniel many times told me that for example, I shouldn't use 2 blank lines on my debian/rules, don't have empty space a end of line in my copyright, and things like that. I agree it doesn't mater MUCH, but it's still better the way he advise me to correct. And do you really thing it's SO BAD and that it takes SO MUCH time to do those little changes, or to try to comply with what he thinks is good? I think it's all right, and that it helps to have something more clean and easy to read... I also think it's ridiculous to complain about somebody's perfectionism. Right. But are things like two blank lines in debian/rules and blank space at the end of the line policy issues? No. I too am a perfectionist, but I also recongnize that not everyone is. If request sponsorship for a package and the potential sponsor points out issues with the package, then that is fine. If the issues are policy driven or otherwise mandated then I will certainly fix them. I would not seriously expect anyone to sponsor a package of mine with an outstanding issue like that. However, I choose to not change things which are a matter of preference, then that should not impact the sponsor's willingness to sponsor the package. For the potential sponsor to do that would come off as elitist. What if I like two blank lines in debian/rules to break up the sections logically? If I like it that way and the potential sponsor does not, but the policy says nothing about it, then who is right? The same goes for whitespace at the end of a line somewhere? Is it really that important? There are likely hundreds of these little sorts of preference issues out there. I don't think that pointing them out is wrong, but I don't think that someone forcing their view of what they think is right is justified, unless there is something in policy or the developer reference or lintian/linda to provide justification. Regards, -Roberto Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Tone-of-voice used by sponsors
On Sun, Jan 14, 2007 at 09:09:30PM +0100, Daniel Baumann wrote: first, i'm a debian developer without any delegation (especially not for anything mentors related). i'm not even involved in anything with the mentors infrastructure. I applaud your work. There are too few people who are willing and able to lend a hand to get new prospective Debian developers up to speed. second, it is my very freedom to not do something when i don't want to do it. i need neither a legitimation for that, nor do i need to give any justification. every reason, even when given none, is perfectly valid. Yes, but enforcing your preferences on someone makes you come off as elitist. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Tone-of-voice used by sponsors
On Sun, Jan 14, 2007 at 09:57:14PM +0100, Daniel Baumann wrote: Roberto C. Sanchez wrote: I would not seriously expect anyone to sponsor a package of mine with an outstanding issue like that. please read the whole mail about his debian/rules and why i prefere to not sponsor such packages. giving the impression, i wouldn't sponsor packages due to whitespaces or empty lines is not fair. I did not mean to imply that you refused to sponsor someone's packages over whitespace. I was simply trying to say that it is ok to point things out. However, *I* happen to think that it is wrong to refuse to sponsor a package because someone prefers to do something one way and you prefer to see it done differently. As you and a number of other people have pointed out, no one is forcing you to sponsor anyone's packages. You can feel free to require that people make a photograph of themselves in a yellow chicken suit available on the Internet before you will sponsor a package. That is if that sort of thing strikes your fancy, since it is just as arbitrary as having whitespace done a certain way. I think Joey Hess has the right idea in how he points out that it is better to focus on things like security, rather than whitespace. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: RFS: fspanel -- minimalist panel for X
On Fri, Jan 12, 2007 at 06:13:11PM +0100, Daniel Baumann wrote: * the homepage entry should have *two* leading spaces. IIRC, this was dsicussed recently and it is basically a matter of preference. I could be wrontg, though. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bad practice to make a package depend on a specific kernel image
On Tue, Jan 02, 2007 at 01:33:34PM +1100, Robert Collins wrote: Its not -required- that any of the software on a machine be packaged. Users can (gasp) build and run their own $software - e.g. squid, apache, whatever. But - we cannot expect the packaging system to ensure that requirements are met for *any* unpackaged software. I think its a fair and proper assumption that the stack of software is all packaged: its very easy to build a packaged, vanilla kernel - and doing so can generate appropriate information for dpkg. Yes. But enough people build non-packaged kernels that it is not really fair to exclude them. Add to that the fact that the presence of a particular kernel image package in no way guarantees that it is that particular kernel that is running, and you it is plain that it is not necessary to depend on a particular kernel. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bad practice to make a package depend on a specific kernel image
On Tue, Jan 02, 2007 at 01:48:57PM +1100, Robert Collins wrote: Yes. But enough people build non-packaged kernels that it is not really fair to exclude them. Add to that the fact that the presence of a particular kernel image package in no way guarantees that it is that particular kernel that is running, and you it is plain that it is not necessary to depend on a particular kernel. This is true, and irrelevant: the presence of a packaged library version does not in any way guarantee that the files from that will be the ones picked up by the runtime loader, and so on and so forth for executables, dynamic language modules, images etc. It is quite relevant. If someone installs a library package and then changes the files, that is their own problem. You can also in many cases have multiple versions of a library available and have them all be usable simultaneously. With a kernel, you boot A and kernel B is no longer running or accessible. You boot B and A is no longer running or accessible. By accessible, I mean for runtime use. This is not true of a library. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bad practice to make a package depend on a specific kernel image
On Tue, Jan 02, 2007 at 02:05:01PM +1100, Robert Collins wrote: I think you are arguing around the issue. An example may help. Consider an application that needs 'libhello' built with ssl support. i.e. Depends: libhello-ssl0 That installs /usr/lib/libhello.so Now, if I fiddle with the system: change the runtime library path, dpkg-divert /usr/lib/libhello.so, or do other tricks, the application will stop working. Right. But you do those things (which are by no means common occurrences among a significant portion of the Debian user base) yourself understanding that they may cause problems if you don't know what you are doing. The point of packaging is to let things work as well as possible by default. Its not true to say that kernels and libraries are identical in their constraints : and I haven't claimed that. What I have claimed is that in no case is there any guarantee that what dpkg *thinks* is present actually is. Then why bother with dependencies at all? Because in the vast majority of the cases, what dpkg things is present actually is. However, it is extremely common for people to compile their own kernels and install them *without* using Debian packaging. The same cannot be said of most common libraries. But where we can signal to it that something is *not* present, that is useful, as dpkg can then signal to the user that intervention is required. Right. But depending on a particular kernel image is an artificial limitation. If I roll my own kernel without using Debian tools (which is a fairly common practice), why should I have to work around your package's dependencies to get it installed? Simply document what is necessary in the way of kernel support and let me sort it out. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bad practice to make a package depend on a specific kernel image
On Tue, Jan 02, 2007 at 02:24:13PM +1100, Robert Collins wrote: Because the vast bulk of users do *not* roll their own kernels [yes, an assumption, but I'm pretty confident here :)]. I disagree. I think that while it is not the majority, a sizeable portion of the user base installs a home-rolled kernel. Not having any dependency meta-data down to the kernel layer *when there is an actual dependency* makes life harder for the majority of users, and I think its acceptable for you to have a minor inconvenience when you want to install an unpackaged kernel *and* remove all packaged kernels that would meet the dependencies in order to make life much easier for all those users that do not roll their own kernel. So what you are saying is that you want me to be confused. Let's say I have at some point installed a kernel that meets the dependency for your package, though I have never heard of your package. At some later time, I roll my own kernel and use it, however it is not good enough to meet the dependency for your package. Perhaps, I left out some important module or something. Now, I find out about your package and install it. Every indication from aptitude is that everything installs OK. Now, I try and use your package and it *doesn't* work because I am not running the kernel it depends on. What would I do at that point? Personally, without any further documentation or information available, I'd file a bug. If I used reportbug, it would also indicate that I had the correct kernel installed, but not running and you would end up with a bug report along the lines of it doesn't work. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bad practice to make a package depend on a specific kernel image
On Tue, Jan 02, 2007 at 02:59:30PM +1100, Matthew Palmer wrote: On Mon, Jan 01, 2007 at 10:32:21PM -0500, Roberto C. Sanchez wrote: I disagree. I think that while it is not the majority, a sizeable portion of the user base installs a home-rolled kernel. Could you stop that hand of yours from waving around quite so much? Unless you can provide some reasonably respectable numbers to support your position, you're arguing about dancing angels. According to popcon [0], there are 23,144 installations of dpkg. Now, if you add up *all* of the installs for kernel-image and linux-image packages, you have 16,601. That means that if you are *very* optimistic and assume that each and every individual linux-image and kernel-image package represents a unique machine (which is likely not the case, as many people install multiple kernels), then about 71.7% of popcon participants have installed something that *might* satisfy a kernel-image or linux-image dependency. That means that at the most conservative possible estimation, 28.3% of the popcon participating Debian user population has some sort of kernel installed that the package management system knows nothing about. So, to summarize: * my hands are not waving * I am not angry about angels, dancing or any other variety Now, I find out about your package and install it. Every indication from aptitude is that everything installs OK. Now, I try and use your package and it *doesn't* work because I am not running the kernel it depends on. What would I do at that point? Personally, without any further documentation or information available, I'd file a bug. This would be why the init script would, when it determined that you were running an incompatible kernel, would spit out a helpful error message. Then what is the point of depending on a kernel at all? As I have already demonstrated, a sizable portion of the Debian user base does not have any kernel-image or linux-image installed, meaning that they must have acquired a kernel and installed it via some means which dpkg knows nothing about. That being the case, why not just document what the package needs in the way of kernel support and let the user handle it? Apparently a non-trivial percentage of Debian users can handle installing their own kernels outside of the package management system. Regards, -Roberto [0] http://popcon.debian.org/by_inst -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Bad practice to make a package depend on a specific kernel image
On Tue, Dec 12, 2006 at 01:40:47PM -0500, Jerry DuVal wrote: Is it bad practice to make a package depend on a specific kernel image? This might be a loaded question, but I was just trying to get an opinion. All of the boxes using this package are of the same configuration. What if the kernels on those machines are installed by hand? Thus, dpkg won't know about them. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Does a DD become solely responsible for abandonware in Debian?
On Wed, Oct 18, 2006 at 01:50:05PM -0500, Jordi Gutierrez Hermoso wrote: After some email lobbying and many months of waiting, more than may seem evident from the atttached email exchange below, I have managed to convince the authors of LiDIA http://www.cdc.informatik.tu-darmstadt.de/TI/LiDIA/ to finally release their code under the GPL. Woohoo! It's an excellent number theory package that a mere four years ago used to have the cutting edge algorithms for elliptic curves (hello, Fermat's Last Theorem!). Indeed, the reason that it wasn't GPLed earlier is that its authors had hoped to make its algorithms proprietary, but for better or for worse have since lost interest in this endeavour. In fact, hardly any (none?) of the original contributors and coders of LiDIA are working on it anymore. I was nagging its sole maintainer about getting the code GPLed so that it could go into Debian (and hence, hopefully eventually into Ubuntu) in order to give LiDIA a wider audience and hopefully attract some attention and maintainers. My questions are these: is this a good idea? Is it a good idea to try to Debianise a package with no real upstream authors? If I did that, would I or my sponsor become responsible for maintenance? I think that the general consensus is that if you choose to package something that is dead upstream, you essentially accept the responsibility of being the upstream maintainer as well. On the plus side, you are not likely to disagree with yourself about Debian-related things and you are not likely to do things to make the Debian packaging more difficult than it needs to be. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: RFS toshset
On Sun, Oct 15, 2006 at 01:50:16PM +0200, Daniel Baumann wrote: Roberto C. Sanchez wrote: tiCo is working on uploading toshset for me. ^ I don't think so *scnr* I realized that in his last message to me, where he mentioned he would forward it on to his AM. I did not realize that he was still in NM like myself. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
RFS toshset
Would someone kindly upload my new toshset package? http://people.connexer.com/~roberto/debian/uploads/toshset_1.72-1.dsc Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: RFS toshset
tiCo is working on uploading toshset for me. Thanks, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Handling bugs
On Wed, Oct 11, 2006 at 07:38:10PM -0500, Luis Rodrigo Gallardo Cruz wrote: What does one do with an inactive unreproducible important bug? (#368546) Close it? After how long? Last mail from submitter was four months ago. No one else has ever seen it, either in Debian or in upstream mailing list. It depends. If you feel someone else may erroneously report it, tag it unreproducible, mark it wishlist or something and leave it open. If not, then just close it. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Depending on an essential package
On Mon, Sep 18, 2006 at 04:38:28PM +0200, Michael Biebl wrote: Sounds reasonable. Thanks for the explanation. Sometimes I wished lintian would display hints like yours and not only such short one liners. The same explanation that Steve gave is found in the Debian Policy and/or the developer reference. Hopefully, you have read both of those. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto signature.asc Description: Digital signature
Re: Packaging automation - separation of 'debian/' directory
On Thu, Sep 07, 2006 at 02:03:28PM +1000, Ben Finney wrote:
Howdy all,
I've seen many recommendations that the 'debian/' directory should not
be part of the 'foo_X.Y.orig.tar.gz' tarball but should always be
added by the 'foo_X.Y-Z.diff.gz', even in the case of I *am* the
upstream and I prefer to track the 'debian/' directory as part of the
source tree in my VCS.
So that leads to the question: What best practices are there for
creating the Debian sources ('foo_X.Y.orig.tar.gz', 'foo_X.Y-Z.dsc',
'foo_X.Y-Z.diff.gz') automatically from a source working tree that
already contains the 'debian/' directory?
Bonus points for a method that *doesn't* involve getting the source
from version control as part of the package build process. A big part
of (my) testing is attempting a build of the package from the working
copy of the source, *before* committing the latest changes to version
control.
I could, of course, blunder around finding my own method for this, but
I imagine it's such a common requirement that there must be good
examples to work from.
Check out tools like cvs-buildpackage or svn-package, depending on your
chosen VCS.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~roberto
signature.asc
Description: Digital signature
Re: Homepage in debian/control (was: RFS: queuegraph (take two))
On Fri, Sep 01, 2006 at 12:31:56PM +, Sam Morris wrote: A more practical reason not to do it is that the homepage may move, leaving us publishing outdated information for the rest of the stable release. An easy and practical solution to that would be to use redirects from within the debian.org domain. For example, the URL http://homepages.debian.org/?pkg=foobar could be used to redirect to the actual package home page. Additionally, for packages which are dead upstream, this could lead to a page explaining that. The homepages database could be populated and updated as new packages are uploaded to unstable. In fact, this does not even need to be present in the control file. A simple file in the debian/ directory of a package called homepage, with a single line containing the URL to the real homepage for the upstream package would be enough. Then, dpkg, apt, aptitude and other package management front ends could be configured to generate a URL for any package and going to that generated URL will redirect you to the real upstream homepage, assuming the person who created the package included that information. I think the biggest possible problem with this is how to handle third party package repositories. For instance, if some random person creates a package, you don't want the package management system advertising the homepage as being available at http://homepages.debian.org/?pkg=baz as it would imply some form of endorsement by the Debian project. However, if there is a way to tell (by dpkg, apt, aptitude, etc) if a package came from an official repository, then this could work. Regards, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: Digital signature
Re: Huge private Debian repository...
On Mon, Aug 28, 2006 at 02:08:17PM +0200, Michelle Konzack wrote: Hello, since I am Debian GNU/Linux Consultant I have many customized packages or Customer specific Applications. I run my ownRepository and a devel server andnow it give me problems with the administration, because I have too much packages... and releases. I need an archive system like the Debian FTP's for woody, sarge, etch and sid. I was searching the Debian website and the Internet but have not found any HOWTO's or documentations HOWTO install such system. Can anyone point me to the approprieted resources please? Curently I have over 480 packages to custom applications to maintain... You probably want to setup dak. It is now a package officially in Debian and there is an alioth project where development takes place. Regards, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: Digital signature
Re: RFS: python-musicbrainz2
On Sat, Aug 26, 2006 at 09:08:35AM +0200, Luká?? Lalinský wrote: Roberto C. Sanchez wrote: OK. Two more things and I think your package will be ready. Thanks a lot for looking at it. OK. No problem. I will be sponsoring your package. That is, I am near the end of my own NM process and the final task my AM (Alex Wirt) has laid out for me is to choose a package and act as though I were to sponsor it, with him performing the actual final upload. First, the description for python-musicbrainz2 reads: This package is an empty dummy package that always depends on a package built for Debian's default Python version. The problem is that there is no other package on which it depends and it contains all the modules, so it is in fact not empty. Oops, this is a leftover from times when it used the old Python policy. Fixed. Good. Just remember, change is good :-) The second thing is that python-musicbrainz2 should probably recommend or suggest python-musicbrainz2-doc. I've used Suggests, as it's only an API documentation for developers and will not be normally installed together with the main package. OK. Good point. Excellent work on the package. Regards, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: Digital signature
Re: RFS: python-musicbrainz2
On Fri, Aug 25, 2006 at 10:53:21PM +0200, Luká?? Lalinský wrote: Hello, I'm looking for a sponsor for package python-musicbrainz2 (http://bugs.debian.org/370255). It's a simple Python module for using the new MusicBrainz XML web service. I'm mainly interested in this as it's a dependency of MusicBrainz Picard tagger, but it will be also used by the new versions (since 0.5, I think) of player Listen, which is already in Debian. The package is at: http://users.musicbrainz.org/~luks/tmp/deb-python-musicbrainz2/ I checked out your package and here is what I got: $ lintian -viI python-musicbrainz2_0.3.1-1_i386.changes N: Setting up lab in /tmp/GvSvLjRzGB ... N: Processing changes file python-musicbrainz2_0.3.1-1_i386.changes ... N: Processing 3 packages... N: N: Processing source package python-musicbrainz2 (version 0.3.1-1) ... E: python-musicbrainz2 source: build-depends-indep-should-be-build-depends cdbs N: N: The specified package is required to run the clean target of N: debian/rules and therefore must be listed in Build-Depends, even if no N: architecture-dependent packages are built. N: N: Refer to Policy Manual, section 7.6 for details. N: E: python-musicbrainz2 source: build-depends-indep-should-be-build-depends python | python-dev | python-all-dev E: python-musicbrainz2 source: build-depends-indep-should-be-build-depends debhelper E: python-musicbrainz2 source: build-depends-indep-should-be-build-depends python-support (= 0.3) N: N: Processing binary package python-musicbrainz2-doc (version 0.3.1-1) ... N: N: Processing binary package python-musicbrainz2 (version 0.3.1-1) ... N: Removing /tmp/GvSvLjRzGB ... Basically, you should change the mentioned dependencies so that they are Build-Depends instead of Build-Depends-Indep. Regards, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: Digital signature
Re: RFS: python-musicbrainz2
On Sat, Aug 26, 2006 at 12:14:25AM +0200, Luká?? Lalinský wrote: Roberto C. Sanchez wrote: [...] Basically, you should change the mentioned dependencies so that they are Build-Depends instead of Build-Depends-Indep. Thanks, I've changed it to: Build-Depends: debhelper (= 5.0.37.2), cdbs (= 0.4.43), python-support (= 0.3), python-all-dev (= 2.3.5-11) Build-Depends-Indep: python-epydoc, python-ctypes (= 0.9.6) The updated package is again at: http://users.musicbrainz.org/~luks/tmp/deb-python-musicbrainz2/ OK. Two more things and I think your package will be ready. First, the description for python-musicbrainz2 reads: This package is an empty dummy package that always depends on a package built for Debian's default Python version. The problem is that there is no other package on which it depends and it contains all the modules, so it is in fact not empty. The second thing is that python-musicbrainz2 should probably recommend or suggest python-musicbrainz2-doc. Regards, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: Digital signature
Re: RFS: Xindy
On Mon, Aug 21, 2006 at 10:37:43PM +0200, Jörg Sommer wrote: Dear mentors, I am looking for a sponsor for my package xindy. * Package name: xindy Version : 2.2~beta2-1 Upstream Author : Joachim Schrod [EMAIL PROTECTED] * URL : http://www.xindy.org * License : GPL Section : text It builds these binary packages: xindy - index generator for structured documents like LaTeX or SGML xindy-rules - rule files for xindy The package is lintian clean. The upload would fix these bugs: 362584 The package can be found on mentors.debian.net: - URL: http://www.minet.uni-jena.de/~joergs/debian/ - Source repository: deb-src http://www.minet.uni-jena.de/~joergs/debian/ ./ - dget http://www.minet.uni-jena.de/~joergs/debian/xindy_2.2~beta2-1.dsc I would be glad if someone uploaded this package for me. I would like to sponsor this. I will check it out tomorrow and let you know. Regards, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: Digital signature
Re: Help with watch file
Nelson A. de Oliveira wrote: Hi mentors! I have one watch file with the following lines: version=3 ftp://ftp.genetics.wustl.edu/pub/eddy/software/squid-(.*)\.tar\.gz Doing an uscan --verbose, I get: $ uscan --verbose -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: ftp://ftp.genetics.wustl.edu/pub/eddy/software/squid-(.*)\.tar\.gz uscan warning: In debian/watch no matching files for watch line ftp://ftp.genetics.wustl.edu/pub/eddy/software/squid-(.*)\.tar\.gz -- Scan finished I have tried everything to make this watch file works, but without success :-( What is the correct line to get versions from a FTP directory, with files like ftp://ftp.genetics.wustl.edu/pub/eddy/software/squid-1.9g.tar.gz? Thank you very much! Nelson Add debian uupdate (without quotes) at the end of the line in the watch file. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: Help with watch file
On Fri, Aug 04, 2006 at 06:08:50PM -0300, Nelson A. de Oliveira wrote: Hi! On 8/4/06, Roberto C. Sanchez [EMAIL PROTECTED] wrote: What is the correct line to get versions from a FTP directory, with files like ftp://ftp.genetics.wustl.edu/pub/eddy/software/squid-1.9g.tar.gz? Add debian uupdate (without quotes) at the end of the line in the watch file. Still not :-( $ uscan --verbose -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: ftp://ftp.genetics.wustl.edu/pub/eddy/software/squid-(.*)\.tar\.gz debian uupdate uscan warning: In debian/watch no matching files for watch line ftp://ftp.genetics.wustl.edu/pub/eddy/software/squid-(.*)\.tar\.gz debian uupdate -- Scan finished Nelson Interesting. Using version=2 or version=3 with uscan on Sarge works perfectly for me. Regards, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: Digital signature
Re: How can a non-DD fix broken packages?
Bart Martens wrote: On Tue, May 30, 2006 at 12:03:19PM -0700, Steve Langasek wrote: There are no technical measures in place which *prohibit* developers from sponsoring NMUs. Nevertheless, the concept of a sponsored NMU is a broken one, because responsibility for the NMU lies with the uploader, not with the sponsoree. Does that mean that your opinion is that sponsored NMU's should be forbidden? I would regret that. It's not bad that someone in the NM queue also does NMU's to help fixing other packages. And I don't see a problem with responsability if the sponsor is aware of that responsability. But maybe I'm missing something? I would have to agree with Vorlon. Whenever I have wanted to do an NMU (not, I am not yet a DD), I just fix whatever bug and send a patch to the bug. After that, I can announce on IRC or a suitable mailing list for someone to please review the changes, incorporate them and do the NMU. That other person's name goes on the changelog entry, but they always give credit to the originator of the patch (I have not seen a case where it has not been done). In that way, there is a review by a DD and that DD is definitely accepting responsbility, as they are ones patching and uploading. I'm not sure if that is correct, but that is how I have ssen it work. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: RFS: courierpassd
Charles Fry wrote: My fault for copying the paragraph from the webpage focusing on courierpassd, and skipping some important introductory information that also applied to other similar tools (courierpasswd and courieruserinfo). Here is an updated long description, which hopefully underlines the difference between courierpassd and poppassd: Courierpassd works with the Courier mail server user authentication mechanism to allow changing a user's password from across a network. It uses the same protocol as poppassd to obtain user IDs and passwords. This can be used, for example, to allow users to change their passwords from within various webmail programs. . Homepage: http://www.arda.homeunix.net/store/ Said in another way, this package is meant to work with courier-authlib, which may manage passwords in a way that is inaccesible to poppassd. I apologize for the confusion which ensued from my lack of a proper introduction of the package. No problem. I just wanted to make sure that effort was not being needlessly duplicated. Though, the fact that poppassd can use PAM makes it quite flexible, IMO. However, I can understand the need/desire to have a tool specifically designed to interact with a particular mail server. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: SASL2 (Bug#368370)
Russ Allbery wrote: We have an alternative packaging of cyrus-sasl2 that we did internal to Stanford for various reasons; if anyone is interested in that, I can put it up somewhere to look at. I'm not sure if it would be helpful at all, but it's easy enough to make the offer. :) I was the one who ITA'd the bug to begin with (before I knew of the Alioth project). I intend to follow through on this, and join the Alioth project as it were. I will defend my thesis next week, after which I will have some spare time to devote to this task. If you could make your alternate packaging, I would really appreciate it. Could you post the URL to the bug? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: RFS: courierpassd
Charles Fry wrote: * Package name: courierpassd Version : 1.1.0 Upstream Author : Andrew St. Jean [EMAIL PROTECTED] * URL : http://www.arda.homeunix.net/store/ * License : GPL Description : Change courier user passwords using poppassd interface courierpassd is a utility for changing a user's password from across a network. It uses the same protocol as poppassd to obtain user IDs and passwords. This can be used, for example, to allow users to change their passwords from within various webmail programs. My current build of courierpassd can be downloaded from: http://debian.frogcircus.org/packages/ I already have a handful of packages in Debian, so things should be in decent shape to begin with, though this is the first C package that I've created from scratch, so I may need a few pointers. Thanks in advance for any offer of assistance. Charles Are you aware that there is at least already one package that does this? Specifically, poppassd, which can be combined with poppass-cgi to enable changing the password via the web. Your efforts might be better spent contributing to those. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: How to include information about a source package ?
Frank Lanitz wrote: Am Freitag 28 April 2006 23:53 schrieb Frank Gevaerts: On Fri, Apr 28, 2006 at 05:47:46PM -0400, Yaroslav Halchenko wrote: Hi Frank, Isn't debian/README.Debian the one you would like to edit? It might be. However, the included information is (probably) not useful to end users. So why do you want to include them into a package.? Probably in case someone else wants to grab the source and modify it. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: What is stripping in binary compilations ?
Maxim Vexler wrote: Hello everyone. I'm reading the New maintainer's guide. On page 28 (version 1.2.3,18 January2005) the author speaks about `stripping' executable and the dh_strip(1) script. Surprisingly, no where was the reader informed about the purpose of `striping'. Am I supposed to know this as part of basic knowledge ? If so where can I learn more about stripping I've tried to search the Debian developers reference guide and the gcc online documentations, as well as google but no useful information has turned up. Is stripping important when packaging an application for debian ? How can I tell if an application was meant to be stripped by upstream ? Thank you for helping. Stripping is basically the proces sof removing debugging and other symbolic information from the compiled binary. This helps to keep the size down. If you only work with interpreted or byte-code-type languages, then you probably don't need to worry too much about what this is. If you work with regular compiled languages (e.g., C and C++) this is definitely required knowledge. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: How to build packages from tarballs without makefiles
David Liontooth wrote: I occasionally run into tarballs without a makefile. How do I turn those into Debian packages? Here's an example -- otk_lib from http://otk.sourceforge.net/. # tar zxvf otk_lib_0.47.tgz otk_lib/gadget_lib.c otk_lib/letter2vector2.c otk_lib/otk_lib.c otk_lib/Readme.txt otk_lib/gadget_lib.h otk_lib/otk_lib.h I rename the directory libotk-0.47, enter it, and run dh_make -s, getting Currently there is no top level Makefile. The Readme.txt says /* To Compile: Directive in code should detect environment and do the right thing.*/ /* Unix/Linux: */ /*cc -O -c -I/usr/X11R6/include otk_lib.c -o otk.o */ /*Link with:-lGLU -lGL -lXmu -lXext -lX11 */ Do I put these into debian/rules? Where? I was hoping I could make a few changes and run fakeroot dpkg-buildpackage. Dave I would just put those into the debian/rules. There is not enough there to justify a full-blown makefile in my mind. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: howto pack python programs
Bastian Venthur wrote: Hi Mentors, I'm currently working on a program written in python. The source-tree looks like this: foo.py bar.py baz.py ex1.py ex2.py ex3.py where ex*.py are executables and the others not. My question is, where to put all these files and what should I do with the executables? My current idea is: - copy all *.py into /usr/share/$PACKAGE/ - create symlinks like /u/s/p/ex1.py - /usr/bin/ex1.py /u/s/p/ex2.py - /usr/bin/ex2.py /u/s/p/ex3.py - /usr/bin/ex3.py Is the location /usr/share/$PACKAGE OK? Should I create the symlinks without the py-extension, like: /usr/bin/ex1 - /u/s/ex1.py Next problem, lintian is complaining (W) about non-executable scripts in /usr/share/$PACKAGE -- can I ignore this? BTW: I already know and use dh_python. Kind regards Bastian Take a look at my releaseforge packages (in Etch/Sid). You might even be able to rip off the debian/ directory from my package and modify it to fit your needs. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Requesting upload sponsor
Hello, I have updated a few of my packages. Since I have not been able to get a hold of my AM, I would appreciate it if some kind DD would upload the packages here: http://familiasanchez.net/~roberto/debian/uploads/ All of the packages were built in a pbuilder and are lintian clean. Regards, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: Packaging Qemu Launcher, unmaintained but useful software
Quoting Linas Zvirblis [EMAIL PROTECTED]: Hello, One late evening browsing trough requested packages in [1] I came across Qemu Launcher [2]. It is a Perl/Glade front end for QEMU (CPU/computer emulator). It being the only GTK based application of this kind that I know of, I decided to give a try packaging it for Debian. Then I realized that it is fairly outdated and does not support QEMU 8.0 (the latest version). The last version of Qemu Launcher seems to be released somewhere around 3-4 months ago, so I tried contacting the author (about a month ago and again a few days ago), but got no reply so far. There also does not seem to be any activity on the project site. I am still interested in packaging it, but to make it compatible with the latest QEMU, extensive changes need to be made. This includes not only code changes, but possibly also GUI redesign. What I am trying to say, is that after I finish with it, it will be anything but Qemu Launcher 1.5 - basically a fork. I have no problem with doing upstream development, but I am not very keen on forking it. My question is, would such fork be accepted into Debian? If it would, should it be Debian specific, or should I register a new project somewhere? How should I name (or version) it then? Sorry if this post is not strictly mentors list related, but I was hoping that someone at Debian has already dealt with similar situation and would care to share experience. Another alternative to consider is JQemu: http://www.exprofesso.com/jqemu/ I tried packaging last summer, but it required a non-free javac. You may want to give it another shot, since the free java tools have improved greatly in the meantime. Additionally, it has a very active upstream. If you don't, I will probably get around to it this summer. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder and scons
Claudio Moratti wrote: Hi *! I'm working on a package that uses scons... everything goes fine but I find one problem: in order to clean the sources, debian/rules calls /usr/bin/scons -c but pbuilder don't try to install the Unmet build dependencies before the clean... I read, in Debian Policy Manual, that: Build-Depends, Build-Conflicts The Build-Depends and Build-Conflicts fields must be satisfied when any of the following targets is invoked: build, clean, binary, binary-arch, build-arch, build-indep and binary-indep. Is it a bug? cheers full log # pdebuild-etch W: /root/.pbuilderrc does not exist dpkg-checkbuilddeps: Unmet build dependencies: scons kdelibs4-dev W: Unmet build-dependency in source dpkg-buildpackage: source package is kleansweep dpkg-buildpackage: source version is 0.2.1-2 dpkg-buildpackage: source changed by Claudio Moratti [EMAIL PROTECTED] fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp rm -f config.sub rm -f config.guess #-/usr/bin/make distclean /usr/bin/scons -c make: /usr/bin/scons: Command not found make: *** [clean-patched] Error 127 Interesting. I know that in the past, when building packages that use cdbs, I have had to install it on my host system. If cdbs is not installed, the clean does not finish. I think that this is because pbuilder will call clean on the host machine so that it can take a clean source archive into the chroot. Maybe try installing scons on your host machine. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: pbuilder and scons
Paul Wise wrote: As other people noted new and in old threads, this is because pbuilder runs debian/rules clean outside the chroot. To work around it, put a '-' in front of the scons -c line in debian/rules, so that make ignores any errors from that line. An example from one of my packages: clean: unpatch dh_testdir dh_testroot -scons VERSION=$(VERSION) SKIPPLUGINS=System -c -rm -rf .sconf_temp .sconsign.dblite SCons/Tools/crossmingw.pyc build config.log .test dh_clean That is awesome. I have read many docs about make, but never knew that the '-' at the beginning of the line caused make to ignore errors from that command. Maybe I have just overlooked it all this time. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: pbuilder and scons
Justin Pryzby wrote: On Tue, Dec 13, 2005 at 11:30:04AM -0500, Roberto C. Sanchez wrote: That is awesome. I have read many docs about make, but never knew that the '-' at the beginning of the line caused make to ignore errors from that command. Maybe I have just overlooked it all this time. But please don't overuse it. Granularity is a good thing here. -scons means that *every* error is ignored. It would be much better to check for precisely what you need, possibly: [ -e /usr/bin/scons ] scons VERSION=$(VERSION) SKIPPLUGINS=System -c What you want to avoid is the case where execution of scons fails for some other reason. There was a recent discussion about this granularity in error checking, either on -devel list, or in a bug log (probably both); I forget the context, though. Anyway, pbuilder does what it does for a good reason. Why subvert its intent? I don't want to subvert it. Simply, it is a nice thing to know. There are times when you would like to run a command, but you are nto so concerned if the command fails or not. It is just another tool in the tool box. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: Package versioning troubles
On Wed, Nov 23, 2005 at 09:06:53PM +0100, Svata Dedic wrote: Hello, sorry for a newbie question, but: I have patched a little some package (iptraf, in fact) - and created a package with adjusted version number. I added a changelog entry, changing the patchlevel number (the number after dash), so the new .deb's version is 2.7.0-9 (the original version was 2.7.0-8). When I add it to my repository (rebuild Packages.gz), and do apt-get update ; apt-get install iptraf, the original iptraf package version 2.7.0-8 is not upgraded to 2.7.0-9. I really don't know why, and I suspect I am making some very stupid error. For a short play, the repository is at deb http://belgarat.klfree.net/klfree-debian/ testing unofficial Thanks for any help, -Svata Maybe these can help? http://familiasanchez.net/~roberto/howtos/debrepository http://familiasanchez.net/~roberto/howtos/debcustomize -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpwsABuAWrln.pgp Description: PGP signature
Re: Package versioning troubles
On Wed, Nov 23, 2005 at 10:11:17PM +0100, Svata Dedic wrote: Hello, Thanks for the pointers, I have already seen them in the past - and now I hopefully made a proper repository. But to be more specific about the situation: - apt-get update proceeds OK, - aptitude shows the customized package as a version of iptraf (this is OK) - I can do apt-get install iptraf=2.7.0-8.0.whatever_custom_version and it works OK, but when official iptraf (2.7.0-8) is installed, the iptraf package is not recognized as upgradeable to 2.7.0-8.0.whavever_custom_version (which I would like to achieve). So plain apt-get install iptraf will not do anything What is the output of `apt-cache policy iptraf` ? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpdY1YivMuS1.pgp Description: PGP signature
Re: Depends: awk -- Is that required?
On Wed, Nov 09, 2005 at 06:43:51PM -0700, Bob Proulx wrote: I need a clarification because I am confused. If I have a script that uses awk do I need the package to Depends: awk? Or is awk like basename where we are able to assume it is on the system without any explicit dependencies? I see that many packages do Depends: awk. But awk is an alternative and mawk is Priority: required so I would not think so. But gawk provides awk and is Priority: optional but with a higher alternative priority too and so that required mawk is almost never used. (I always install gawk as awk for its better features.) If the package used gawk specific features then the decision would be easy. It would need to depend upon gawk. But it only uses basic awk features and so any of the alternatives is sufficient. Thanks for you knowledge in this. I suspect that it is not necessary: $ apt-cache show mawk |grep Provides\|Priority Priority: required Provides: awk -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpiLD27iIuP3.pgp Description: PGP signature
Re: Packaging freeloader: problem with python gtk module dependency
On Sat, Nov 05, 2005 at 09:22:06AM +0100, Julien Valroff wrote:
Hi,
I'am currently packaging freeloader, a Gnome download manager written in
Python and supporting torrents (http://www.ruinedsoft.com/freeloader/),
but I have a problem with build dependencies.
According the homepage, requirements are:
+ Linux operating system (similar systems may work)
+ python 2.3 or 2.4
+ pygtk 2.6
+ 2 MB install space
+ GTK+ 2.6 or greater
+ BitTorrent python module version 3.4
My build-depends field in control file is:
debhelper (= 4.0.0), imagemagick (= 6), python (= 2.3),
python2.3-gtk2 (= 2.6), bittorrent (= 3.4)
I am not sure about your build problem. However, your depends could use
some work. Change python (= 2.3), python2.3-gtk2 (= 2.6) to either
python2.3, python2.3-gtk2 (= 2.6) or to python (= 2.3), python-gtk2
(= 2.6) so that changes in the default Python version don't break your
package.
I build the package successfully with debuild and dpkg-buildpackage, but
when using pdebuild in a a sid chroot, the configure script cannot find
python gtk module:
/.../
checking for python... (cached) python2.3
checking for main in -lpython2.3... (cached) no
checking for python2.3/Python.h... (cached) no
results of the Python check:
Binary: python2.3
Library: no
Include Dir: no
checking python module: pygtk... yes
checking python module: gtk... no
configure: error: failed to find required module gtk
make: *** [config.status] Error 1
pbuilder: Failed autobuilding of package
/.../
The test from the configure file for the gtk python module is:
echo $as_me:$LINENO: checking python module: gtk 5
echo $ECHO_N checking python module: gtk... $ECHO_C 6
python -c import gtk 2/dev/null
if test $? -eq 0;
then
echo $as_me:$LINENO: result: yes 5
echo ${ECHO_T}yes 6
eval HAVE_PYMOD_GTK=yes
else
echo $as_me:$LINENO: result: no 5
echo ${ECHO_T}no 6
eval HAVE_PYMOD_GTK=no
#
if test -n 1
then
{ { echo $as_me:$LINENO: error: failed to find required
module gtk 5
echo $as_me: error: failed to find required module gtk 2;}
{ (exit 1); exit 1; }; }
exit 1
fi
fi
I checked the packages I have installed on my development machine, but I
cannot see anything more than the build-depends.
When I launch python -v and try to import gtk module, all the objects
come from the /usr/lib/python2.3/site-packages/gtk-2.0/ directory, which
belongs to pythong2.3-gtk2 package.
Could it be linked to the chroot that does not have correct environment
and cannot find the correct path? If yes, how can I fix this problem?
Many thanks in advance for your comments.
Cheers
Julien
If you post the sources for what you have done so far, we might be able
to provide more help.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~roberto
pgp15nZj5AyFx.pgp
Description: PGP signature
Re: More open alternatives to packaging?
Quoting Bram Neijt [EMAIL PROTECTED]: Hi. I was wondering if there's a more open alternative to developing packages? Is there some place I can get the newest packages from non-official developers? A homepage where you can register and start posting and using packages from different people through apt? Currently I could only find a homepage containing source packages, not binaries. So does that place exist? (An a homepage collecting apt sources, but that doesn't help) You mean like apt-get.org or dotdeb.org? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: managing my packages with svn
Quoting Damyan Ivanov [EMAIL PROTECTED]: While dropping dpatch is unthinkable for me (it helps a great deal when reviewing diff.gz for unwanted changes), documenting its usage in README.Debian is indeed a very good idea. Except that README.Debian is not the place for something like that. Only things relevant to the *user* of the package should go there. Things like what build system are used or what additional development tools are user belong in another README that can be put only in the source package but not the binary package. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian/rules: create folder into deb
On Wed, Sep 28, 2005 at 11:26:30PM +0200, nidr wrote: Perhaps you guys have seen some of my other threads over at debian-boot. They are all related to tasksel, as am trying to add my own tasks for personally use. Am grateful for all the help I have got with tasksel so far. But there is still something I do not understand: You see I've been trying to make my own deb out of the tasksel 2.24 source. So I've managed to build a working deb with the dpkg-buildpackage command, but later I found out that I needed to do some more modifications: When I run the dpkg-buildpackage command, the system make this folder ./debian/tasksel/usr/lib/tasksel/packages But this folder has no items inside. So I want to add my package-list item into this folder, so my owm packages list is there, inside the deb. How can I make so the dpkg-buildpackage will move my list program to that folder? I've tried to read some documention about debian/rules, but still I can't manage to do what I want to. Hope someone could help me here. debian/rules is just a Makefile. Of you understand Makefile syntax, that is all you need. Basically, you can place your file somewhere in the debian/ directory. Then after the call to dh_installdirs (I think) you can use a simple mv command to move your file to the desired destination. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpVgj2LmreTn.pgp Description: PGP signature
Re: there was php4-eaccelerator ?
On Tue, Sep 27, 2005 at 07:22:24PM -0300, Jose Carlos do Nascimento wrote: Hi, All I tried to find php4-eaccelerator package using google ,, but I cant find. I make php4-eaccelerator to be used in debian sarge , php4-4.3.10-16 It can be found in http://www.psabs.com.br/debian [] Jose Carlos Jose Carlos, Please read the links I provided. That package will not be accepted. The license issues remain unresolved. It will likely have to wait until the program is rewritten. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpWpAjq48Eg4.pgp Description: PGP signature
Re: RFS: istanbul - Desktop session recorder (ITP: #316503)
On Mon, Sep 26, 2005 at 10:39:03PM +0200, Nicolas Weyland wrote: On Mon, 26 Sep 2005 21:59:42 +0200 Christoph Haas [EMAIL PROTECTED] wrote: - The README.Debian doesn't look very helpful for the end-user. In the maintainer guide it's written that you have to write differences between the normal and the debian version. But if there are important things whiche aren't in the upstream's Readme, can I add them there or will my package be rejected? I would say that README.Debian is the perfect place for such comments. However, if they get to be very long, consider adding another README.something file. For example, take a look at packages like freeciv or flightgear for an idea of how extra README files might be useful. I believe that those packages include the extra README files included by upstream, but there is no reason that you couldn't do it as well. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpr58FGfQRvk.pgp Description: PGP signature
Re: Procedure for reporting translation errors
On Mon, Sep 26, 2005 at 06:38:40PM -0400, Maykel Moya wrote: There is a spanish translation error in gthumb. Is the procedure to report it the same for other bugs ? Yes. If you use the report bug package it will ask you if you want to tag the bug as a localization or internationalization bug. If not, you can look up the proper tag and include it manually. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgp05BP5uJsg0.pgp Description: PGP signature
Re: there was php4-eaccelerator ?
On Fri, Sep 23, 2005 at 10:06:25AM -0300, Jose Carlos do Nascimento wrote: Hi , All I saw that there was php5-eaccelerator package. But and about php4-eaccelerator ? did someone make it , or can I create this package ? Please see the following threads: http://lists.debian.org/debian-mentors/2005/05/msg00148.html http://lists.debian.org/debian-legal/2005/01/msg00130.html http://lists.debian.org/debian-devel/2005/05/msg00681.html Check the news statements for 2005/07/11: http://eaccelerator.net/HomeUk Probably not a possibility. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpw1vFdm8zhP.pgp Description: PGP signature
Re: packages size versus files under dpkg control
On Fri, Sep 16, 2005 at 08:48:08AM +0530, Kapil Hari Paranjape wrote: Hello, We are getting quite out of context here but... On Thu, 15 Sep 2005, Roberto C. Sanchez wrote: Therein lies the beauty of mathematics. There are an uncountable infinity of files whose sum is d41d8cd98f00b204e9800998ecf8427e :-) Actually it is a countable infinity since files are finite in length (you cannot actually compute the md5sum of a stream!). I stand corrected. I hope my Finite Languages professor never sees this thread :-) -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgphGv2S8bM51.pgp Description: PGP signature
Re: packages size versus files under dpkg control
On Thu, Sep 15, 2005 at 05:30:30PM +, Thaddeus H. Black wrote: W. Borgert wrote: Back to your question: I personally hate files that are not under dpkg control, because you cannot check using debsums, dpkg -L, dpkg -S, etc. This raises a topic I do not understand very well. Since we are already on the topic, may I ask for further advice? Suppose that I maintained a package foo. Foo must autogenerate a permanent file during postinst (for example, foo-manual.ps, too big to include prebuilt in the binary package). Because W.B. and I hate files that are not under dpkg control, I want to store this file under /var/lib/foo/, symbolically linking thereto from an appropriate point in /usr/. However, FHS does not seem to recommend such usage. If /var/lib/foo/ is not the right place, then is there a proper canonical place in the filesystem for permanent, postinst-generated files under postinst/prerm control rather than dpkg control? Somehow, storing such files outside /var/ bothers me. Maybe it should not bother me. I don't know. If it should not, then please help me to see the light, so to speak. I see nothing in Policy 6, Policy 10, or FHS which answers the question, so either I am just not seeing it or I am looking in the wrong place. If W.B. or others wish to comment, I would be interested in what they had to say, because I am considering a future package which would pose exactly this kind of problem. Thanks. Would there be a problem with shipping the package with a file of the same name and size 0, then have the postinst generate the file and replace the empty file with the new file? That also helps keeps things consistent as dpkg will automatically remove the generated file on package removal or purge. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpp3NcB8Ezdv.pgp Description: PGP signature
Re: packages size versus files under dpkg control
On Thu, Sep 15, 2005 at 01:37:27PM -0400, Justin Pryzby wrote: On Thu, Sep 15, 2005 at 01:33:20PM -0400, Roberto C. Sanchez wrote: On Thu, Sep 15, 2005 at 05:30:30PM +, Thaddeus H. Black wrote: W. Borgert wrote: Back to your question: I personally hate files that are not under dpkg control, because you cannot check using debsums, dpkg -L, dpkg -S, etc. This raises a topic I do not understand very well. Since we are already on the topic, may I ask for further advice? Would there be a problem with shipping the package with a file of the same name and size 0, then have the postinst generate the file and replace the empty file with the new file? That also helps keeps things consistent as dpkg will automatically remove the generated file on package removal or purge. MD5sum will be incorrect. /var/lib/dpkg/info/*.md5sums Justin An excellent point. Perhaps we can make use of some the recent research in the area of MD5 collisions :-) -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpeStztyNi47.pgp Description: PGP signature
Re: packages size versus files under dpkg control
On Thu, Sep 15, 2005 at 04:03:23PM -0400, Justin Pryzby wrote: On Thu, Sep 15, 2005 at 03:52:31PM -0400, Roberto C. Sanchez wrote: Perhaps we can make use of some the recent research in the area of MD5 collisions :-) Only if you don't mind restricting yourself to files whose md5sum is: d41d8cd98f00b204e9800998ecf8427e :) Therein lies the beauty of mathematics. There are an uncountable infinity of files whose sum is d41d8cd98f00b204e9800998ecf8427e :-) -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpX4qkfxVlMV.pgp Description: PGP signature
Re: RFS: Plash: a shell and restricted environment for running programs with minimum authority
On Sat, Aug 20, 2005 at 03:01:40PM +0100, Mark Seaborn wrote: I'm looking for a sponsor for putting Plash into Debian. The main page is: http://plash.beasts.org and Debian packages are at: http://www.cs.jhu.edu/~seaborn/plash/plash_1.11_i386.deb http://savannah.nongnu.org/download/plash/plash_1.11.dsc http://savannah.nongnu.org/download/plash/plash_1.11.tar.gz (The Debian source package contains a copy of glibc 2.3.3, which is 13Mb, but the source for Plash itself is only 200k.) Why? This is a sure-fire way to make sure a package is not accepted. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpvYa53esX11.pgp Description: PGP signature
Re: RFS: Plash: a shell and restricted environment for running programs with minimum authority
On Sat, Aug 20, 2005 at 11:47:51PM +0100, Mark Seaborn wrote: Roberto C. Sanchez [EMAIL PROTECTED] wrote: On Sat, Aug 20, 2005 at 03:01:40PM +0100, Mark Seaborn wrote: I'm looking for a sponsor for putting Plash into Debian. The main page is: http://plash.beasts.org and Debian packages are at: http://www.cs.jhu.edu/~seaborn/plash/plash_1.11_i386.deb http://savannah.nongnu.org/download/plash/plash_1.11.dsc http://savannah.nongnu.org/download/plash/plash_1.11.tar.gz (The Debian source package contains a copy of glibc 2.3.3, which is 13Mb, but the source for Plash itself is only 200k.) Why? This is a sure-fire way to make sure a package is not accepted. How else am I supposed to do it? It needs the glibc source to build. Is there a way for a source package to use the contents of another source package, such as Debian's existing glibc package? Even if there was, this is not very helpful, because Debian includes glibc 2.3.2. Stable and testing include glibc 2.3.2. Unstable, against which your package would need to build, currently has 2.3.5. I went through something similar when I started trying to package anyterm. It required a private header file that was in the source of a library package. The solution was to ask the upstream for the library to expose those things needed by the anyterm developer so that it could build with only the normal .h and library files. Looking at the plash website, it appears that they actually use a modified glibc, so I am not so sure my suggestion would apply. However, I do remember that recently there was a push to identify packages that included their own versions of libraries which already existed as library packages. Though, to be honest, I am not sure what the reaction to your package will be. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpKut0wMNzMM.pgp Description: PGP signature
Re: RFS: secpanel -- A graphical user interface for SSH and SCP
On Tue, Aug 16, 2005 at 02:21:04PM +0200, pedro silva wrote: * Package name : secpanel Version : 0.5.1-1 Upstream Author :steffen leich [EMAIL PROTECTED] * URL : http://www.pingx.net/secpanel/ * License : GPL Description : a graphical user interface for ssh and scp SecPanel is a graphical user interface for managining and running secure shell (ssh) and secure network copy (scp) connections via OpenSSH. It eases key distribution and other tasks related to using these programs. source available from my repository at: www.ageda.net/debian/secpanel http://www.ageda.net/debian/secpanel sugestions/et al are welcome. It appears that the package is already in Debian, though it has been orphaned. You may want to state that, as I was confused why someone would be requesting a sponsor for a package that already exists. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgplQXRSgVh3E.pgp Description: PGP signature
Re: RFS: libopenspc -- library for playing SPC files
On Tue, Jul 12, 2005 at 02:42:52PM -0400, Ryan Schultz wrote: Oh, this isn't my library... and worse, there doesn't seem to actually be any upstream. The URL I gave is the only place that I have been able to find a source package for this software -- all of the other links on Google are dead! That's not a good indicator of active development :-) -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpD80lLcD0sI.pgp Description: PGP signature
Re: how use dpatch for binary files ?
On Tue, Jul 12, 2005 at 07:51:18PM -0300, Jose Carlos do Nascimento wrote: Hi , all Im making one package using dpatch. I changed some binary files (images) and created one patch in debian/patches When I rum dpkg-buildpackage -rfakeroot -us -uc I receive message below. 10_testpatch.dpatch is a patch for one image. Im thinking use uuencode and uudecode to solve this problem, but I would like to know if have other option to solve it. That is exactly how I put some images into a previous version of releaseforge when upstream left them out. It is version 0.7.1-4, if you care to take a look. http://snapshot.debian.net/archive/2005/06/19/debian/pool/main/r/releaseforge/ -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgphGHXl3ZD1c.pgp Description: PGP signature
Re: Adapting a package for unofficial archive/retrieval via apt-get
On Mon, Jul 04, 2005 at 01:47:55PM -0700, Dennis Carr wrote: I have in my hands a package called 'sclj', of which I wish to include as a deb package on an unofficial archive (a la pine, for instance). I have the current setup at http://chez-vrolet.net/debian/dists/stable/main/binary-i386/ , however I'm unable to get apt to recognize the presence of sclj as a package. What am I missing? Semi-important, I suppose - would this be more appropriate on - developers or somesuch? Check out my HOWTO on creating a Debian package repository: http://familiasanchez.net/~sanchezr/?page=debrepository -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpaZW6bW5EX1.pgp Description: PGP signature
Re: Build-Recommends
On Sun, Jun 12, 2005 at 03:21:54PM +0200, Adeodato Simó wrote: [People from debian-ocaml-mail, please keep -mentors CC'ed.] * John Skaller [Sun, 12 Jun 2005 16:27:21 +1000]: I could use a 'build-recommends' dependency, but I understand 'recommends' is only available for the binary package, not the source. Is this correct? The situation: the packaging machine requires 'ocaml' to make binaries from my source package, but if 'ocaml-native-compilers' is also installed it will do so faster, however that package is not available on all architectures. This isn't an essential feature, but here is a case, possibly isolated, where it could be useful. Normally, one resolves this and similar situations like this: Build-Depends: ocaml-native-compilers [!m68k !mips !mipsel !s390], ocaml [m68k mips mipsel s390] Couldn't you also Build-Depend on 'ocaml-native-compilers | ocaml'? That would look first for ocaml-native-compilers and then if that is not available, for ocaml. Plus, if the ocaml-native-compilers package becomes available for other architectures, it does not require a modification to the Build-Depends to take advantage of it. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpC95LZOnmIX.pgp Description: PGP signature
Packaging of freenx
I asked a while back (on IRC) about packaging the NX components that are under the GPL. Someone pointed me to Fabian's packages in Skole Linux. Anyhow, those packages are 6 months old and probably not going into Debian. Fabian has also not responded to my email. I intend to file an ITP on this in the near future, but I had some questions. The install instructions say to install everything to /usr/NX, but I have a feeling that is not a good idea. Should I just put everything into /usr/lib/NX and symlink to /usr/bin as necessary? As far as the packages from Nomachine. There are 14 source tarballs. Should packages them together in one Debian source or each as its own individual source package? Each individually - Good becuase if one tarball is updated, it is easy to update the Debian version without updating the other 13 components simply to bump the version. Bad because there is lots more packaging overhead. All together - Good becuase it is much easier to package. Bad becuase updating one component will require an new upload of all the associated packages andsubsequently require that users all download new binary packages. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpBrDWcgANDm.pgp Description: PGP signature
Re: Packaging of freenx
On Tue, Jun 07, 2005 at 04:27:58PM +0200, Fabio Tranchitella wrote: On Tue, 07 Jun 2005 at 10:16 -0400, Roberto C. Sanchez wrote: I asked a while back (on IRC) about packaging the NX components that are under the GPL. Someone pointed me to Fabian's packages in Skole Linux. Anyhow, those packages are 6 months old and probably not going into Debian. Fabian has also not responded to my email. See #255850, maybe it could give you some information. OK. No activity in more than a year. The website where the packages were offered early in the thread no longer exists. If there are no objections, I will take over the ITP. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpFTTPWubMe6.pgp Description: PGP signature
Re: Sponsoring of packages
On Tue, Jun 07, 2005 at 09:33:33PM -0400, Jaldhar H. Vyas wrote: On Tue, 7 Jun 2005, Martin Mewes wrote: I thought it would be a good idea to sponsor DDs in this way to keep up the valued work on special things which are of interest for me. Me too. However, we don't want to start a dangerous precedent of maintainers holding their packages for ransom. I suggest you first follow the normal RFP (Request For Package) procedure and only if that fails go the payment route. (If however, you do go down that route, please note that I am available :-) I don't think that it will set a precedent. That is like saying DDs being employed by a company that does any Debian-related or Linux-related work is setting a bad precedent. Most DDs work on Debian in their spare time. It is just that for the right price they are willing to spare *more* time. There is nothing wrong with that. If you need something now, you should be prepared to pay for it. If not, you sould be prepared to wait. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgp79Sw6KLv2T.pgp Description: PGP signature
Re: Request for a sponsor for Felix
On Fri, May 27, 2005 at 10:44:49AM +1000, John Skaller wrote: Felix is a 'free for any use' open source advanced License text [0]: Licence Copyright (C) 2004 John Skaller. Felix is Free For Any Use. Redistribution and use in source and binary forms, with or without modification, are permitted. No offense, but you might want to consider using one of the many licenses out there [1]. They are much more well understood and have been well thought out. Your license may leave out things that become important in the future. Based on what your license is trying to say, you may want to consider the MIT/X license, BSD (w/o advertising clause), or public domain. IANAL, but I have seen enough discussions about license issues becuase someone wrote their own and forgot something to think that it is usually a Bad Idea(TM). -Roberto [0] http://felix.sourceforge.net/current/www/licence.html [1] http://zooko.com/license_quick_ref.html -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpLeqg918ed5.pgp Description: PGP signature
Re: How do I specify a particular version intelligently?
Quoting Marc 'HE' Brockschmidt [EMAIL PROTECTED]:
Roberto C. Sanchez [EMAIL PROTECTED] writes:
I just had a grave bug filed against my releaseforge package.
I have traced the fault to an issue with the version of
pyqt-tools. If the package is compiled with the version
of pyqt-tools in sarge (3.13), it needs to run against
python-qt3 version 3.13. However, if it is compiled against
pyqt-tools from Sid (3.14), it needs the corresponding
python-qt3. What is the correct way to specify the depends
and build depends?
If it compiles with *all* versions of python-qt3, you should use an
unversioned build-dependency. In that case you only need to get the
binary dependency right, which is pretty easy if you use something like
Depends: python-qt3 (= ${python-qt3:Version}).
You then only need to get the version number of the python lib you used
to build the package (either with some package-specific tool or dpkg -l)
and add a python-qt3:Version=1.2.3 to debian/substvars.
OK. How do I get that line to appear in debian/substvars? I know that if
I put ${python:Depends} in the Depends line, then I magically get the
right dependency. But, I don't understand how it works.
What I ended up deciding was to simply build-depend pyqt-tools (= 3.14.1).
This is because .py scripts built with 3.14.1 and newer are compatible with
older versions of python-qt3. However, allowing builds with the older
version ensures that when python-qt3 3.14.1 transitions from Sid to Etch,
anyone that happened to have their package built with pyqt-tools 3.13 will
see it break. Since my package will not make it into Sarge, I don't think
it is a problem to Build-Depend on the newer version. Besides, the Python
maintainers have enough to deal with figuring out how to properly conflict
with all the packages that happened to be built with pyqt-tools = 3.13
and didn't specify a versioned Build-Depends.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How to express dependencies for Java(TM)?
I am trying to package a couple of programs that depend on IBM or Sun JDK (for build) and JRE (for execution). I know that this means the packages will end up in contrib. However, I am not sure what the correct way to express the depends and build- depends. Can someone help me out on this? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: How to express dependencies for Java(TM)?
elijah wright wrote: I am trying to package a couple of programs that depend on IBM or Sun JDK (for build) and JRE (for execution). I know that this means the packages will end up in contrib. However, I am not sure what the correct way to express the depends and build- depends. Can someone help me out on this? do they *really* depend on a non-free jdk, or will they run with kaffe or sablevm? --elijah Yes. All are heavy Swing/AWT apps. TTBOMK, that makes any free java a non-player. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: How to express dependencies for Java(TM)?
Michael Koch wrote: On Sun, May 22, 2005 at 01:22:19PM -0400, Roberto C. Sanchez wrote: elijah wright wrote: I am trying to package a couple of programs that depend on IBM or Sun JDK (for build) and JRE (for execution). I know that this means the packages will end up in contrib. However, I am not sure what the correct way to express the depends and build- depends. Can someone help me out on this? do they *really* depend on a non-free jdk, or will they run with kaffe or sablevm? --elijah Yes. All are heavy Swing/AWT apps. TTBOMK, that makes any free java a non-player. Better try it out before doing such statements. AWT mainly just works. Swing is progressing fast. The above statement depends heavily on the app you wanna run and it should not be just said to try to avoid free software alternatives. Michael Point taken. One I know for certain uses features specific to the Sun JDK (it is for a school project). Eventually I hope to be able to get rid of the Sun-isms. In the mean time, I would like to be able to get the pacakge built properly. Also, are there any good references on getting Java apps to compile with free Java development tools? (No, I have not yet Googled for this info). -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: How to express dependencies for Java(TM)?
Michael Koch wrote: On Sun, May 22, 2005 at 02:19:14PM -0400, Roberto C. Sanchez wrote: Also, are there any good references on getting Java apps to compile with free Java development tools? (No, I have not yet Googled for this info). Most free runtimes provide directly or indirectly a JDK-like environment. So if you use ant just point JAVA_HOME to it. OK. Makes sense :-) I will try that first. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: No debian/ folder in .deb file
Njes Nilsen wrote: After your answerers on this thread: http://lists.debian.org/debian-mentors/2005/05/msg00381.html I tried to edit the tasksel .deb file (just for my own testing purpose atm.) And I extracted the .deb file to a folder using the dpkg -x command. Edited some of the files, and thought I could just rebuild the .deb file. But then I read this one: http://www.debian.org/doc/maint-guide/ I found out that I needed some files (http://www.debian.org/doc/maint-guide/ch-dreq.en.html) to build the .deb So I thought I would find a debian/ folder in tasksel_2.23_all.deb, but I don't. The tasksel_2.23_all.deb is the binary pacakge. If you want to modify the package you need to do 'apt-get source tasksel', which will leave you the complete Debian source of tasksel, including all the package building infrastructure for the package. Why not? Don't you need some of those files to build the .deb in the first place? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
How do I specify a particular version intelligently?
I just had a grave bug filed against my releaseforge package. I have traced the fault to an issue with the version of pyqt-tools. If the package is compiled with the version of pyqt-tools in sarge (3.13), it needs to run against python-qt3 version 3.13. However, if it is compiled against pyqt-tools from Sid (3.14), it needs the corresponding python-qt3. What is the correct way to specify the depends and build depends? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Question on placement and naming of binaries
Greetings mentors, I am packaging webcpp (bug #309723). After having created four other packages, I am beginning to get the hang of this. However, I have come across a situation which I am not sure how to resolve. The install step of the upstream build leaves me with three files in bin/. Namely, scs2scs.pl, web++, and webcpp. scs2scs2.pl is (obviously) a Perl script. However, the install step does not make it executable. How do I accomplish that with dh_* tools? Also, I recall reading the Debian Policy Manual that all binaries should carry no extension. Do I need to manually move the file with a mv in debian/rules? webc++ is a sh script that provides a simple text-based menu for webcpp. It is also not executable. Same question as above. webcpp is an ELF binary that has correct permissions. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: Question on placement and naming of binaries
Roberto C. Sanchez wrote: Greetings mentors, I am packaging webcpp (bug #309723). After having created four other packages, I am beginning to get the hang of this. However, I have come across a situation which I am not sure how to resolve. The install step of the upstream build leaves me with three files in bin/. Namely, scs2scs.pl, web++, and webcpp. scs2scs2.pl is (obviously) a Perl script. However, the install step does not make it executable. How do I accomplish that with dh_* tools? Also, I recall reading the Debian Policy Manual that all binaries should carry no extension. Do I need to manually move the file with a mv in debian/rules? webc++ is a sh script that provides a simple text-based menu for webcpp. It is also not executable. Same question as above. webcpp is an ELF binary that has correct permissions. OK. I just noticed that the package building process fixes the permissions for the files that end up in bin/ -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Renew RFS for cyrus2courier
Debian Mentors, I would like to renew my request for sponsorship of the cyrus2courier program I recently packaged: http://lists.debian.org/debian-mentors/2005/05/msg00245.html -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Question about next step
I am interested in becoming a DD. I have asked for sponsorship for a couple of package I created. chora2, which fulfills an outstanding RFP, was graciously sponsored by Anibal (Thanks, Anibal!). It is now in the NEW queue. My question is what is the next step? I figured that this was probably the right place to ask. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: Question about next step
Richard A. Hecker wrote: Roberto C. Sanchez wrote: I am interested in becoming a DD. I have asked for sponsorship for a couple of package I created. chora2, which fulfills an outstanding RFP, was graciously sponsored by Anibal (Thanks, Anibal!). It is now in the NEW queue. My question is what is the next step? I figured that this was probably the right place to ask. The first thing I would suggest, is to read everything you can at http://nm.debian.org and all the links there. The next thing I would suggest is patience. Thinking in terms of steps can be frustrating. It goes much better when you think of it as a lifestyle issue. What did you do today? What would you like to do tomorrow? Debian thrives when talented people contribute something they think has value. After all the reading, just contribute as if you already were a DD with full access. If you find yourself with too many days without enough time for your projects, the NM queue is not for you. The productive days will make the NM queue seem insignificant. Richard OK. Thanks for the pep talk. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: Question about next step
Greetings DDs, I am interested in becoming a new DD myself and am in need of having my gpg key signed. Your addresses are all listed as being in the Ohio area on the page the Adeodato referred me to below. If any or all of you would be willing to meet me to sign my key, I would appreciate it. I live in the Dayton area and would be willing to travel to meet you. A halfway point would be preferred, but I am flexible. -Roberto Adeodato Simó wrote: * Roberto C. Sanchez [Wed, 18 May 2005 18:03:23 -0400]: I guess that at some point I need to do the identy verification step. How does that go? Do I locate some DDs near me and drop them an email and see if they are willing to sign my gpg key? Yes, that's right. You can check http://nm.debian.org/gpg_offer.php. -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: RFS - cyrus2courier utility to convert mailboxes
Anibal Monsalve Salazar wrote: On Mon, May 16, 2005 at 03:10:24PM -0400, Roberto C. Sanchez wrote: A sponsorship for this package would be much appreciated. Package name: cyrus2courier License: BSD (w/ annoying advertising clause) Description: converts Cyrus mailbox format to Maildir cyrus2courier is a nice little tool to convert a single mailbox from Cyrus-Imap (versions 1.5.x, 1.6.x, 2.0 and 2.1.x) into the Maildir++ format used by the Courier-Imap and Dovecot IMAP servers. Upstream page: http://www.madness.at/projects/ Please put the homepage at the end of the description in debian/control. Done. There is no ITP for cyrus2courier at http://bugs.debian.org/wnpp I keep forgetting that part :-) I filed the ITP and added a changelog entry closing the bug (#309718). You can get the binary and source packages from here: deb http://familiasanchez.net/~sanchezr/debian/ sarge main deb-src http://familiasanchez.net/~sanchezr/debian/ sarge main BTW. I am aware that lintian complains about the presence of the CVS directory in the source package. That is how it came from upstream. Suggestions on how to deal with this would be welcome. Ask upstream to not include CVS directories in source package. OK. I will contact him and ask. New packages available at the above URL. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
