Re: Fwd: Sage/SIngular: static vs dynamic
* Jerome BENOIT g62993...@rezozer.net [150102 19:26]: I am currently packaging Singular (the real target being Sage); I am finalizing. Note that I am not familiar with this particular CAS. Are you starting from scratch or are you building on top of http://anonscm.debian.org/cgit/debian-science/packages/singular.git/ ? I have just realised that the Singular CLI is built static (by default): I am very surprised because I expected a (regular) dynamic built. Does anyone know the reasons for building a static version rather than a dynamic version of the Singular CLI ? May Debian provide both ? Linking binaries against other libraries from other sources should usually be dynamic (unless there is a good reason for the opposite). Linking against libraries from the same source does not really matter. Producing libraries gets more complicated. (And AFAIR sage actually needs a dynamic library of singular). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150103081430.ga2...@client.brlink.eu
Bug#756034: #756280: please don't claim other people wrote or maintain software they do not
Upstream Author : Bernhard R. Link brl...@debian.org While I somtimes no longer remember what features I've already added to some code a long time ago, I think I would at least remember if I had written a whole program. In other words, please make sure to look up the correct upstream author. | ircii (20131230-1.1) unstable; urgency=low | * Non-maintainer upload. | * New upstream release (Closes: #747700) | | -- Denis Rodrigues Ferreira denis...@gmail.com Fri, 18 Jul 2014 13:34:53 +0100 ircii is orphaned. You cannot do an non-maintainer upload because there is no maintainer. Please either adopt it and do an MU or do a QA upload instead. (also the empty line after the first line is missing, which makes this uneccassary hard to read.) | Source: ircii | Section: net | Priority: optional | Maintainer: Bernhard R. Link brl...@debian.org | Build-Depends: debhelper (= 9), autotools-dev, libncurses5-dev, quilt | Standards-Version: 3.9.5 | Homepage: http://www.eterna.com.au/ircii/ | Vcs-Git: git://anonscm.debian.org/collab-maint/ircii.git | Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/ircii.git;a=summary Thanks for volunteering me to maintain this package. But if I take over a package I'd like to decide that on my own. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140728164833.ga2...@client.brlink.eu
Re: add additional -D from the debian/rules file?
* Paul Elliott pelli...@blackpatchpanel.com [130815 11:52]: What is the official way to add additional -D definitions to the gcc command line from the debian/rules file? Is it DEB_CFLAGS_MAINT_APPEND ? DEB_CPPFLAGS_MAINT_APPEND, as -D is for the C PreProcessor and not the Compiler itself. Make sure it is in the environment of the dpkg-buildflags actually called (usually you need a export there). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130815100352.ga4...@client.brlink.eu
Re: proper value for --version-info
* Paul Elliott pelli...@blackpatchpanel.com [130815 16:24]: version 1.78.00 which was never released, added a new symbol beginning swe_ but it did not change the meaning of any of the old ones so the --version-info for that version should be 1:0:1 I built and checked that version privately, so I consider it a virtual release. Version 1.79.00 does not add any new swe_ symbols at all over 1.78. But new #define preprocessor constansts are added, and the old functions produce new results for these constants. Adding new functionality to a function is the same as adding new functions (only difference is that the failing if the wrong version is used is uglier). In addition some of the 1.78.00 behavior was a bug. It produced the wrong answer. This has been fixed so that the 1.79.00 gives the correct documented answer. If you consider 1.78.00 never released then it should not matter. Otherwise even a bugfix can be considered a incompatible change, but only in extreme situations (programers rarely rely on documentation but on the actual implementation. If someone considered that a bug in the documentation and wrote programs that work with the previous implementation but not the new one, that *can* make a case for it being a incompatible change). Under these conditions what is the proper value for 1.79.00 --version-info? I'd guess either 1:0:1 or 2:0:2 depending on whether you want to cound 1.78.0 or not. The reason for my confusion is this section of Libtool: [...] The following explanation may help to understand the above rules a bit better: [...] 2. Programs using the previous version may use the new version as drop-in replacement, but programs using the new version may use APIs not present in the previous one. In other words, a program linking against the new version may fail with unresolved symbols if linking against the old version at runtime: set revision to 0, bump current and age. [...] The first part of 2) is true: Programs using the previous version may use the new version as drop-in replacement, but programs using the new version may use APIs not present in the previous one. but the second part of 2) is not true: In other words, a program linking against the new version may fail with unresolved symbols if linking against the old version at runtime This is not true because the linker never sees the new interface. It is hidden by new behavior on calls with new #define in constants. Indeed, that additional explanation is missing the case. It's only a explanation, though. I always update the debian/libsweX.symbols file for a new release. In this case it shows no new symbols. If a symbol extends it behaviour, you need to manually increase the minimum version of that symbol. So in this case you need to set the minimum version of all those symbols to the current version that get new additional functionality. (Otherwise you will get wrong dependencies for a program depending on the new behaviour). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130815205339.ga3...@client.brlink.eu
Re: shlib-calls-exit and the flex-generated function yy_fatal_error
* Russ Allbery r...@debian.org [121102 19:29]: I'm starting to think that we should drop this tag entirely. There are a lot of legitimate reasons why shared libraries call exit(), plus there are legitimate reasons why shared library source includes a call to exit() that isn't reachable (something that Lintian cannot detect), such as this one. Is this actually not reachable? This quite looks like a true-positive (only taking into account what was written in this thread, without looking at the actual code). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121102200426.ga23...@client.brlink.eu
Re: Renaming files, patching, renaming files, unpatching, and 3.0 (quilt)
* Jasmine Hassan jasmine.a...@gmail.com [121010 04:45]: For instance, I'm packaging Compiz 0.8.8, for MATE desktop. This, at least initially, requires a lot of code substitutions, and quite a few file/dir renaming. (ex.: gnome - mate, gconf - mateconf, metacity - marco, etc.) I use a home-brewed migration script to generate actions for that. Now, doing `quilt add files_to_rename new_filenames; mv files_to_rename new_filenames; quilt refresh`, alone, would make a huge, unnecessary patch. I might as well modify the upstream tarball and use that as the orig, which, of course, is not proper. I think the solution is simple: either do your own .orig.tar or do not rename files. Either you are doing a full fork and everything on your own, then creating your own release tarballs is more logical anyway. Or you want to do some minimal changes via patches, then renaming files does not really make much sense anyway. But, if I could rename the files just after patching, and rename back just before unpatching, then I can keep a *much* smaller sized debian/patches/*, and also generally more portable. With 3.0 (quilt) there usually is no unpatching (except if you use some explicit options). So if you need to revert the names, that would be done in the clean target instead. But I really do not see the point of renaming files if you want to stick close to the original. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121010075659.ga13...@client.brlink.eu
Re: Re: Renaming files, patching, renaming files, unpatching, and 3.0(quilt)
* Jasmine Hassan jasmine.a...@gmail.com [121010 20:31]: Bernhard R. Link brl...@debian.org writes: With 3.0 (quilt) there usually is no unpatching (except if you use some explicit options). So if you need to revert the names, that would be done in the clean target instead. But I really do not see the point of renaming files if you want to stick close to the original. Actually, if you're building source package (besides binary), after dpkg-genchanges, `dpkg-source --after-build` unapplies every single patch that was applied. It should only do this if the patches were not applied when dpkg-source --pre-build had applied them. (Which never happens in a normal build, but is only there to support special maintainer-specific workflows like not storing the source directory but the source directory without patches in some version control system. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121010211222.ga18...@client.brlink.eu
Re: [Uploaded] RFS: jquery-jplayer/2.1.0-1
* Adam Borowski kilob...@angband.pl [120514 14:54]: Typically it's XCF or PSD files that are the preferred form of modification for images, That depends heavily on what data there is. A XCF without any layers or more colors or anything else but pixel information is as good as any pixel format for storing, so any format having all that information is as good a source as XCF. It's a bit like a C file or a postscript file. Both can be source or can be not source, depending what they contain and what the source is. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120514143049.ga2...@client.brlink.eu
Re: Modifications of the changelog.
* Arno Töll a...@debian.org [120421 11:51]: The whole point of a changelog is a time dependent frozen point of view at your package. Once you released a version of a package, you should consider it untouchable I strongly disagree. First of all, a changelog is there to see what has changed when, i.e. it is a documentation of what important changed where done and when (i.e. which package version) they were done for. There is normally no reason to change older entries as most details get less important over time, but if there is anything importing misleading in them, something important incorrect or something important enough missing, then not correcting the changelog is not acceptable in my eyes. The new changelog should be about what was changed since the version before (that might be some hint that the older changelog was corrected if you prefer), but import changes in the old package should be in the part of the changelog for the old package. as it would confuse people _a lot_ if you force them to read a full backlog of changes every time they upgrade because you /could/ have modified more than the latest entry. Exactly the opposite is true in my opinion: If you already have the last package, then the new changelog entry should only contain the changes since then. But if you forgot to mention an important enough change in an older version, and so not advertise that change there, then people might use the wrong version because they get the wrong picture of where which change was done. (When considering switching from package version A to version B, it should be enough to read the the changelog entries A and = B). Generally speaking it may be ok-ish in important cases to change previous entry if you restrict yourself to spelling fixes and formating changes, but it is completely unacceptable [to me, at least] to reformulate entries, add entries, remove entries and such. If an old entry contains wrong information (either things claimed that are not true, or changes missing that might be important, or worded in a way that people to misunderstand) that is about things important enough that a user could be mislead, I'd rather consider it unacceptable to keep the wrong claims or omissions there. There are of course several reason why not modifying old changelogs or rather erring towards not changing it when being unsure is a good idea: - the changelog format attributes each part of a changelog to a person. So modifying them should make sure one does not misrepresent those changes to changelog. (and if a change is small enough that making that clear would make it harder to read usually means it was not important enough to change it anyway). - any change can introduce new bugs, even in documentation. If the changelog was from someone else (or from yourself from long enough ago), one should be sure enough about what one does. (For the thing triggering this whole discussion: That appears to be simply some needless contentless change in a NMU not related to the NMU, so is quite unrelated to the is editing old changelogs acceptable discussion.) Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120422124855.ga2...@client.brlink.eu
Re: Automatic maintenance of the file .symbols for libraries
* Innocent De Marchi tangram.pe...@gmail.com [120401 09:11]: I have adopted a package with a library [0]. It must be frequently updating the package to update the symbols file Strikes me that the file .symbols not be generated automatically when in compiling the package: Is it not possible that the compilation of the package system will generate the updated file? This would save much work and constant updates. Whats your opinion? The symbols file cannot be generated automatically as no computer program can decide what the contents should be. It needs a human to know which symbols changed ABI and which did not. (The only think a computer program can do is check if symbols vanish or if new symbols appeared). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120401100716.ga2...@client.brlink.eu
Re: Re: Automatic maintenance of the file .symbols for libraries
* Innocent De Marchi tangram.pe...@gmail.com [120401 13:08]: The symbols file cannot be generated automatically as no computer program can decide what the contents should be. but in the compilation of the package (for example with pdebuild), a report of differences is generated if there are changes. That's a list of added symbols (and warning about removed ones). Sometimes those changes are all you need, but a computer cannot decide if those are enough. You need to take a look at how the library changed to determine if any symbol changed it's ABI. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120401114057.ga15...@client.brlink.eu
Re: Bug#662632: RFS: libaio-ocaml/1.0~rc1
* Goswin von Brederlow goswin-...@web.de [120311 19:51]: git-dpm? http://git-dpm.alioth.debian.org/ http://wiki.debian.org/PackagingWithGit/GitDpm That would still make git think that your upstream branch is based on your master branch and thus has the modification remove debian/ in it which git will want to merge with any debian changes in the upstream branch once you merge the two. That was the merge. After that there is nothing more to merge. And the next merge will do the same git-import-orig + merge -s ours trick. But how do you get a new upstream code into master? If you try to update upstream and merge it in master, it will think you want to remove debian/ Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120312110006.gd2...@client.brlink.eu
Re: Bug#662632: RFS: libaio-ocaml/1.0~rc1
* Goswin von Brederlow goswin-...@web.de [120311 08:10]: I tried creating the upstream branch from the master branch and then removing the debian dir. But then on the next merge git complains about a merge conflict (modify/delete) when any file in debian/ was changed. git is directed in that regard, if a child node has something different from the parent node this is supposed to be a willful change that is supposed to be preserved. I googled a bit but couldn't find any hint on how to tell git to always (and only) ignore changes to the debian dir on merge. Any ideas? There is no explicit option, but that is doable by using some git primitives. (The core of git-dpm is basically some special merge that takes debian/ .git-* and file deletions from the debian branch and everything else from the patched branch (based on the upstream branch)) So I switched to the fallback option of using git-import-orig. But as you say then the upstream and master branch aren't based on each other. Since in my case all the history is in the master branch I then merged the master branch into the upstream branch using: % git checkout upstream % git merge -s ours master All the upstream changes are already there from git-import-orig so the -s ours only ignores the debian dir. I think that should give the right history for the upstream branch. At least it looks nearly right in qgit. That would still make git think that your upstream branch is based on your master branch and thus has the modification remove debian/ in it which git will want to merge with any debian changes in the upstream branch once you merge the two. If you want to have the debian branch containing the upstream branch (and do not insist on the upstream branch having much history) it might make more sense to merge the upstream branch in the debian branch. (Even if you want the upstream branch to have the whole history and create the upstream branch on top of the old debian branch, it would make sense to merge that upstream branch into the debian branch again once manually without deleting the debian/ dir so that future merges no longer think debian/ should be removed). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120311103258.ga32...@server.brlink.eu
Re: Explain to me any all
* Paul Elliott pelli...@blackpatchpanel.com [120226 02:03]: The new standard allows any all in the Architecture field. Please explain this new feature. What does it do and under what circumstances should it be used? It's for the Architecture field of the .dsc. As that field is automatically generated, you don't use it normally. As maintainer you usually edit the debian/control field. There every binary package has an Architecture list. This Architecture in the .dsc is the merged list of all those architectures. If one package is e.g. architecture i386 and one is architecture any, then those are merged to any (as there is a package to be generated on any architecture, it does not matter that on i386 there are even more packages to generate). What is changed is what happens if one .deb is architecture any and one .deb is architecture all. Former versions of dpkg merged that to any and policy reflected that. The problem with this is that it loses information whether there are architecture all packages to be built. As architecture all packages were never built by the buildds, this was no actual problem, so only fixed recently. Current versions of dpkg merge this to any all, and policy was changed to reflect this. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120226110207.ga2...@client.brlink.eu
Re: How to convince maintainer to use --as-needed?
* Dmitry Smirnov only...@member.fsf.org [120211 02:50]: But sometimes an innocent call to library causing package to inherit the whole hierarchy of needless dependencies. And this affect not just obvious things like slower start-up and installation Once one library is actually needed, the whole hierachy is still pulled in at run-time recursively. (And as those are dependencies of the dependencies, they are installed anyway, so no benefits at installation time). Package maintainers can surely track problems to --as-needed if that's the case and here we have hope because many packages using it already for years successfully. How many package maintainers know all the functions of their applications and regularily test all of them? Unless you are entangled in libraries ignoring usual best practises and ignoring library borders in their headers (libglib, libboost), there might be better solutions than --as-needed. I'd like to learn more about --as-needed alternatives. Could you suggest any resources/guidelines, please? --as-needed is used mostly a solution used against uneeded libararies linked against. It can make more sense to fix the build system or work around it to cause the reason instead of the symptoms. There are mostly 6 cases: 1) No symbols of the library are needed, but it's initialisation code does things (like enabling extra functionality and the like). In this case --as-needed break things. 2) a program is linked against a library without any reason here just removing the -l is all that is needed to do. 3) a program is linked against a library as another program created from the same build system needs it. This might need bigger modernisations in the upstream build system (like not using the outdated generic LIBS with autoconf but instead export that as special variable). As this has direct benefits for the generated binary that is usually easy to get upstream. 4) libraries linked against because they are dependencies of libraries needed. This is usually done so that it is also possible to link programs statically. Getting this fixed upstream is usually not that easy. 5) libraries sometimes needed and sometimes not needed, depending whether something is inlined or not. This can be harder to fix upstream. It might be fixable locally if that is the same on all debian architectures. Here --as-needed has the biggest advantages, though it can make sense to limit it to one library. (-Wl,--as-needed -lm -Wl,--no-as-needed). 6) libraries whose headers make the program call functions from other libraries. Those may look like 4) but one can never know which libraries are actually used, so it is not easily fixed. So here there might be no other solution that --as-needed, but it's effects are also limited, as those libraries will not likely change incompatibly independently (at least not the dependet on without the depending library and if they do a recompile might still be needed as the used headers might no longer be compatible). Note that many build systems can be modified without needing patching by giving them make variables. This can be easy with case 4 (just overriding the variable containing the libs with less libs), but in most cases impossible for case 3 (as everything is in one variable). Surely there must be software incompatible with --as-needed. But what are the chances to experience it? How to identify situation when --as-needed is likely to cause troubles? The likely causes of trouble I can think of are: - libraries needed only for their initializers - libraries where order matters because of their initializers (like libXaw) - a program inlining stuff incompatible with a different library loaded Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120211125006.ga23...@client.brlink.eu
Re: How to convince maintainer to use --as-needed?
* Dmitry Smirnov only...@member.fsf.org [120210 07:18]: Because in their eyes I have neither expertise nor reputation I couldn't convince them that benefits are outweight risks. (--as-needed removes dozen of packages from Depends) I've been asked to provide a document or a quote from reputable DD regarding using --as-needed as recommended practice in Debian, if such. I personally strongly recommend against using --as-needed unless you understand very well what it does. It may change the runtime behaviour of a program without any signs at link time. Unless you are entangled in libraries ignoring usual best practises and ignoring library borders in their headers (libglib, libboost), there might be better solutions than --as-needed. That is not to say there might not be cases where --as-needed is the best solution, but it is definitely not something one should apply blindly. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120210121522.gb2...@client.brlink.eu
Re: Help with architecture not supporting SSE (Was: Bug#656755: libhmsbeagle FTBFS on everything except amd64)
* IOhannes m zmölnig zmoel...@iem.at [120122 19:46]: this basically means: disable building for SSE instructions on all platforms (apart from amd64, if you care about it) For libraries where SSE matters and where there is no way to make the library detect availability itself and only use it when available there is also another trick: Build and install the library multiple times once with SSE and once without and let the dynamic linker chose the right one. In /usr/lib there should be the one working on all system supported by Debian for that architecture, while there are some subdirectories where an version with more intructions used can be placed and used at runtime when supported. (LD_LIBRARY_PATH=/lib:/usr/lib LD_DEBUG=libs /bin/true will show you a list of paths looked at at you computer, finding out which of those allows what intruction sets might be more complicated and require reading the ld.so source code and the kernel code responsible for /proc/cpu unless there is finally some information about this somewhere in the net). Though that only makes sense if the speed increment is worth the additional afford at build time, the bigger packages and the more fragmented user base. And you have to make sure the code also works without SSE anyway... Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120122195139.ga1...@server.brlink.eu
Re: How mature is Pkg-format 3.0 (git), yet?
* Adam Borowski kilob...@angband.pl [120119 02:29]: On Wed, Jan 18, 2012 at 03:47:11PM +0100, Goswin von Brederlow wrote: There is a lot of different opinions about wether the format is sane at all. A problem with the basic idea/design of 3.0 (git) as opposed to the maturity of the implementation. It is strictly better than 3.0 (quilt). For every set of tree+patches representable by quilt, you can produce a shallow git repository that contains exactly the same bits of data and nothing more. This depends how you define better. A source format is my eyes a way to communicate with our users and the overall comunity. A source format that only has the advantage of not caring if modifications to the upstream source are not easily reviewable[1] and makes it harder for the overall community to see our part[2] is not better. It is worse. To avoid me repeating too much, see also http://lists.debian.org/debian-devel/2011/09/msg00484.html Bernhard R. Link [1] If you have a set of disjoint modifications or of modifications that do not need some additional magic merging is trivially translateable to a quilt series. [2] I once for some package looked what changes other distributions had, never had I had that many different VCSes installed. Even if upstream uses some vcs, there surely will be some day a better one comes out or upstream changes for other reasons, so not even using the same as upstream helps to avoid that. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119115652.ga28...@server.brlink.eu
Re: Overwriting binary files when building a package
* Thomas Weber twe...@debian.org [111212 22:29]: The problem is really that debian/rules clean doesn't give the same as dpkg-source -x. As far as I understand Stefano in http://www.mail-archive.com/debian-ocaml-maint@lists.debian.org/msg22803.html, I have no guarantee that a buildd will actually run the clean target before building the package. There is indeed no formal guarantee, so a package should not assume clean is run. But that is only a problem if debian/rules build would behave differently if clean would not have been called. If upstream build scripts recreate the pdf files anyway, there is no danger. (Though if you want to be sure, you can also delete the generated files at the start of the build target). To summarize some old discussions (I am too lazy to dig out decade old mailing list discussions): Your working directory should be the same regardless which of the following sequences is called: debian/rules clean debian/rules build debian/rules clean debian/rules clean debian/rules build debian/rules clean And your package should build the same files regardless of: debian/rules build debian/rules clean debian/rules build debian/rules clean debian/rules build debian/rules clean debian/rules build debian/rules clean debian/rules build debian/rules build Though I assume there is a number of packages where a missing clean will skew the build, as in practise it is always called before. Not being able to build two times in a row is also a not uncommon bug. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111213112159.ga2...@server.brlink.eu
Re: Overwriting binary files when building a package
* Thomas Weber twe...@debian.org [111211 22:08]: my upstream ships documentation in PDF format in the normal sources. Upon build, I re-create those files[1]. The newly generated PDF files differ from the originally shipped ones. So, I have a problem asserting that debian/rules clean gives me the same source tree as dpkg-source -x which seems to ask for trouble To get dpkg-source happy is easy: Just remove the files in debian/rules clean. dpkg-source will then assert those files do not need representation in the .diff (or in a patch). It will print a little notice which files were treated that way and otherwise just behave the way you want it. In fact, we already see some issues when using git-buildpackage right now. git-buildpackage might be some other issue. As this seems to be the only think to give you troubles here, you might want to explicitly ask for git-buildpackage help. (Your mail read like you have some building problem, so people knowing git-buildpackage might not have read far enough.) I don't know how this works with git-buildpackage, with git-dpm you just git rm those files in the debian branch. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111212112508.ga14...@server.brlink.eu
Re: How to pass CFLAGS to upstream's Makefile with debhlepler ?
* Nicolas Bourdaud nicolas.bourd...@gmail.com [14 15:25]: On 14/11/2011 14:32, Bernhard R. Link wrote: Without -Wall you won't get some of the most critical warnings. A package should really not be built without at least -Wall. I understand, and I think it is a pity that some software produce way too many warnings when compiled with -Wall and -Wextra. However is it not already too late to catch those warnings when the package is being built? IMO, they should have been taken care in upstream. While it might be to late for this package, it is not yet too late for the next version of a package. Or to use the informationen when looking for the cause of bugs. Especially when looking for bugs only showing up on some architectures (like working on 32 bit but failing on 64 bit) and the like. Or do you consider to *massively* patch the source to fix the warnings? Depends on the type of warnings. But there are definitely cases where that is called for. (And hopefully those warnings accepted upstream if there still is a upstream). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2016081741.ga32...@server.brlink.eu
Re: How to pass CFLAGS to upstream's Makefile with debhlepler ?
* Nicolas Bourdaud nicolas.bourd...@gmail.com [14 12:29]: I believe, the reason is that -Wall is really useful only the developer, not the one who build the package. In addition, not all upstream projects are really warnings free (some developer never use -Wall -Wextra). So using them by default when building the package would generate a lot of noise that might hide more critical warnings. Without -Wall you won't get some of the most critical warnings. A package should really not be built without at least -Wall. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2014133218.ga21...@server.brlink.eu
Re: RFS: screenkey - utility to display pressed keys in screencasts
* Paul Wise p...@debian.org [111007 16:46]: This depends on python-gtk2, which has been obsoleted upstream by python-gobject and the GObject introspection therein: http://article.gmane.org/gmane.comp.gnome.gtk%2B.python/15449 Given that python-gobject with gtk support is not yet available in squeeze (not even in backports) and PyGObject's online documentation recommends to use python-gobject only with gtk3 as GTK2 still has a lot of breakage with PyGI, I can imagine that upstreams might yet not be very comfortable to port their applications. Thus this obsoletion indicate that one should look for active upstreams or otherwise might likely end up with some work in the future. But nothing else yet. Please let me know if anything of the above is not correct. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111007154047.gb4...@server.brlink.eu
Re: RFS: leechcraft (closes ITP bug)
* Boris Pek tehnic...@mail.ru [111003 02:00]: It builds those binary packages: leechcraft - Core executable of LeechCraft leechcraft-aggregator - RSS/Atom feed reader for LeechCraft [] None of the short descriptions make any sense to me without knowing what leechcraft is. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111003104207.ga2...@server.brlink.eu
Re: Shared libs dependencies
Not using symbols files will give you almost always too strict dependencies,
usually forcing users to also upgrade libraries without need, but
everything dpkg will not complain about will work (assuming a sane
upstream not breaking ABI without changing sonames).
Using symbols files means the dependencies are less tight, one gets some
basic checks against upstream failing to keep ABI, but the burden is on
the maintainer to know when the ABI changed backward-compatible but not
forward-compatible in existing symbols.
* Sven Joachim svenj...@gmx.de [110924 10:43]:
Erm, this will also happen if you don't have symbols files. In fact,
using symbols files together with dpkg-gensymbols -c4 catches this
kind of mistake.
The real problem with using symbol files without understandin them is
something like the following examples:
--- example 1
liba 1.0.0:
/usr/include/a.h:
enum command {
command_start,
command_stop
};
extern void do(enum command);
liba 1.1.0:
/usr/include/a.h:
enum command {
command_start,
command_stop,
command_restart
};
extern void do(enum command);
someprog:
checking for command_restart in configure and then in the source
#ifdef HAVE_COMMAND_RESTART
do(command_restart);
#else
do(command_stop);
do(command_start);
#endif
There is no symbol changed in liba, so the symbols file for liba 1.1.0
will still say 1.0.0 for do. But if you compile someprog with the newer
liba, it will give 2 to do, which the older liba does not understand,
so the symbols file is incorrect.
--- example 2
I think I've already seen a scheme like the following somewhere:
libb 1.0.0:
/usr/include/b.h:
struct data {
size_t size;
void *value;
};
#define init_data(d) ({ d.size = sizeof(d); d.value = NULL; })
void do(struct data *);
libb 1.1.0:
/usr/include/b.h:
struct data {
size_t size;
void *value;
bool reverse;
};
#define init_data(d) ({ d.size = sizeof(d); d.value = NULL; d.reverse =
false })
void do(struct data *);
A scheme like this (the #define is only here to show how it is used,
that might also be part of documentation) is a nice way to support
adding fields without breaking the ABI: a program compiled against the
old value gives the old size, the new library can cope with that and
does not need to change the soname. But of course if something is
compiled with the new version, it gives a value the old version cannot
handle.
But again dpkg-symbols can see no difference, so if just applying the
patches dpkg-symbols generates means the symbols file will still think
libb 1.0.0 is enough when only calling do.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110924100441.gb...@server.brlink.eu
Re: Shared libs dependencies
* Paul Wise p...@debian.org [110924 12:42]: On Sat, Sep 24, 2011 at 6:04 PM, Bernhard R. Link wrote: The real problem with using symbol files without understandin them is something like the following examples: Do you know if the abi-compliance-checker program/package copes with this case? I don't know, but I'd rather be suprised. If it is good, it will most likely report a compatible extension of the library's ABI in those cases (i.e. the same with those changes that dpkg-symbols handles perfectly automatically). To distinguish this case (a compatible extension of ABI where just applying the patch suggested by dpkg-gensymbols can lead to incorrect dependencies) from the case where dpkg-gensymbol's output is enough, I guess it would explicitly have some tests written with dpkg-symbols' case in mind. (Otherwise I see no reason to warn louder about those changes not adding symbols in a path to use them than against those that do). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110924175312.gc2...@server.brlink.eu
Re: Depends on -dev package
* Russ Allbery r...@debian.org [110823 22:49]: I agree with your line of reasoning, but I'd rather be explicit about such things rather than relying on everyone separately coming to the same conclusion. I think one has to be careful about what special cases to describe, as every special case mentioned makes it either harder to decide other special cases, or opens the door for many other special cases. Should we then also list -data packages not usually depending on the non-data package and not the other way around. How about documents depending on viewers but not viewers depending on documents? And so on and so forth... (My inclination would be to write an explicit exception into Policy saying that C -dev packages do not have to declare dependencies on any package that's part of build-essential.) build-essential is quite big. I'd really hate to see this. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110824082948.ga16...@pcpool00.mathematik.uni-freiburg.de
Re: Depends on -dev package
* Russ Allbery r...@debian.org [110824 19:34]: Should we then also list -data packages not usually depending on the non-data package and not the other way around. -data packages *should* depend on the non-data package in an ideal world, and the only reason why they don't is because circular dependencies are a bigger problem. But -data packages are generally unusable without the corresponding main package, so indeed, this is a special case (and has been discussed as such on debian-devel). Usually data packages should not depend on anything. They are data and usually need nothing to be data. Something else might be using them. Saying a data package should depend on a package needing it is like saying a library package should depend one something using the library. That has nothing to do with the relatively new extended hate for circular dependencies. The latter doesn't make sense to me; why would a viewer depend on any specific package containing documents? The viewer is fully usable without any packaged documents to view documents that don't come with Debian (and, indeed, that's probably the most common use). Of course it does not make sense. It makes no sense the same way it makes no sense to have a -dev package depend on a compiler or a libc-dev (The only difference is how often people are to use packaged libcs and compilers). It makes no sense to have a file viewer depend on virtual-package-for-packages-having-that-format | virtual-package-for-anything-that-can-download-stuff | virtual-package-for-anything-generating-that-format, even though it is hard to get a file in that format without anything like that. (My inclination would be to write an explicit exception into Policy saying that C -dev packages do not have to declare dependencies on any package that's part of build-essential.) build-essential is quite big. I'd really hate to see this. What packages in build-essential do you think C -dev packages should be required to declare explicit dependencies on? dpkg-dev is the only one that seems like it could pose any problem, and it's going to be pretty rare for that to be any sort of issue since C -dev packages aren't likely to care about dpkg-dev one way or the other. dpkg-dev and it's dependencies are feeled about 90% of what gets pulled in by installing build-essential. If anything it makes sense it explicitly list the rest. (And I fear that would lead to people packaging something equivalent for fortran could think they should depend on a fortran-compiler, which I consider to be definitely a bug). Note that I explicitly said, and meant, part of build-essential, not in the transitive closure of build-essential's dependencies. If you want to say this, please say things in the Depends: field of build-essential. As the Depends of build-essential are not part of the build-essential package either. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110824183703.ga17...@pcpool00.mathematik.uni-freiburg.de
Re: Depends on -dev package
* Russ Allbery r...@debian.org [110822 21:47]: There are not, so far as I know, any exceptions for -dev packages from the normal requirements for Depends, which say simply: The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. and given that C -dev packages are unusable in general without libc6-dev installed, that would, on the surface, seem to qualify. I think this is the old general discussion what useful is. A pdf viewer is not useful without a pdf file to view, still a pdf viewer should of course not depend on some package with pdf files in it. I think some good heuristic is usually looking at what you need and if it is needed anyway in the process of using something. If you compile a program, you will usually need libc development files anyway, so having them around is not really a new requirement (just like having a compiler). There is also not really a way to express what you need, as there are so many of them, you either need libc6-dv or libc0.1-dev or libc0.3-dev or libc6.1-dev or perhaps of the multilib files and so on. So not being able to express what you need and missing a realistic use case where only using this -dev package introduces the requirement, I think it is rather clear that this dependency is not needed. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110823095737.ga12...@pcpool00.mathematik.uni-freiburg.de
Re: Depends on -dev package
* Russ Allbery r...@debian.org [110822 19:59]: Paul Elliott pelli...@blackpatchpanel.com writes: That's a fascinating point. I have never done that with any -dev package, since essentially every -dev package would require that, which seems rather silly. (There are almost no non-trivial C libraries that don't include standard C headers.) But there's no obvious reason why that shouldn't be required given the current Policy wording. Which wording are you talking about? Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110822181434.ga6...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: aescrypt
* Benoît Knecht benoit.kne...@fsfe.org [110804 23:03]: Bernhard R. Link wrote: * Benoît Knecht benoit.kne...@fsfe.org [110804 20:54]: I've seen that, but they need to make that perfectly clear in the license header of each file in the tarball. An email sent to you and reproduced in the debian/copyright file is not enough. There is nothing special about the source files. There is a need to have a license, there is no need that this license statement must be in the files itself or even in the tarball. I don't get what you mean by there is no need to have a license. Where does this no come from? A software distributed without a license is always presumed to be non-free. I do agree that the license doesn't have to be in the file itself, but then there should at least be a license file in the tarball stating what the license of all the included files is; and if there is a license statement in the file (as it is the case now), it should state all the rights granted to the user. Right now, the header says you're free to distribute these files, and somewhere else one of the copyright holder (in a private email, as far as I can tell) says you can do pretty much whatever you want with those files. I don't think that's an acceptable license grant; it's confusing at best. It's indeed confusing and not ideal. But if all the permissions were properly given then this would be no show-stopper. The problem in this example (apart from debian/copyright being incomplete and apperently getting some number wrong) is that the mail given is not so clear to give this additional permissions and that the author of that mail might not be able to give permissions for all the code (due to there being multiple authors, as you pointed out). There are three contributors (according to debian/copyrigh, not all of them are copyright holders, it's not clear why) listed in aescrypt.c for example, so we'd need a statement from all the copyright holders, preferably somewhere publically accessible. I still think it's way easier to get upstream to fix the license headers. It's easier for everyone involved except the one who has to explain upstream what exactly we want in those files, convince them to add that and then repeat those two steps till it is done... Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110805095511.ga11...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: aescrypt
* Benoît Knecht benoit.kne...@fsfe.org [110804 20:54]: I've seen that, but they need to make that perfectly clear in the license header of each file in the tarball. An email sent to you and reproduced in the debian/copyright file is not enough. There is nothing special about the source files. There is a need to have a license, there is no need that this license statement must be in the files itself or even in the tarball. (Though it definitely extremly recommendable to have the license clearly stated in every file and the postamble of the GPL recommending this has definitely be counted as one of the best things the FSF ever did). It is crucial that they fix this _upstream_, you can't simply add a note in the debian packaging about that. As long as debian/copyright contains something giving us and the users a license by people authorized to do so everything is fine. And again, if they want to make sure that the license they're using is free, they should use one of the well known free software licenses such as the 3-clause BSD or the Expat license; if that's still too restrictive for their taste, they could use a public domain license such as CC0. While it is definitely recommendable to use something already existing to avoid common pitfalls, that does not mean everything else is impossible. And please, if you're discussing these licensing issues with upstream, don't forget to also remind them about including a copy of the GPL along with the source; it _is_ a license violation not to do so. This is definitely something that is needed. (Or replacing the code with code unter other licenses, at least for sha256 there is less restrictive code flowing around). To get to the real problems: debian/copyright is not giving the license statement from those files. (the message it quotes does refer to something not quoted, I guess the statement found in the files). The original license statement as far as I see mostly misses the explicit permission to modify and distribute modified and to give others the same permission (or it should be clear that it gives those permissions to eveyone). The message quote in debian/copyright starts with describing what this license is supposed to do and then continues with I’ll go further in saying Here it is unfortunately not very clear if this is a addional grant of license or a wrong description about the one found in the files. I think this needs improvement (having that in the upstream files would of course be nice, but as long as you can a explicit permission of the copyright holder that everyone may use, copy and/or modify and state this grant in the file that would be enough). And the files are GPL-2, how do you get to the GPL 3 in seem to be debian/copyright? Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110804203700.ga9...@pcpool00.mathematik.uni-freiburg.de
Re: Adding symbols files to the tango package.
* Michael Tautschnig m...@debian.org [110801 11:15]: Indeed symbol ordering may vary, but also there is no reason for dpkg-gensymbols to guarantee a particular ordering. Although dpkg-gensymbols produces a diff, this is surely not meant for you to apply directly as a patch: each change requires proper manual inspection to understand whether this is an intended change. The symbols file is not to be understood as a mere documentation/dumb list, rather it is a contract: as a package maintainer you guarantee that the listed symbols are provided. And that they did not change their meaning. For example if some function now extends functionality by giving meaning to an additional value (for example in an enum), then the version of the corresponding symbol has to be updated manually. dpkg-gensymbols cannot determine that, it can only see if symbols were added or removed, not if anything behind them changed. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110801144142.ga...@pcpool00.mathematik.uni-freiburg.de
Re: Workflow with debian/ in VCS
* Enrico Weigelt weig...@metux.de [110724 05:44]: I really wonder, why you don't just track everything in a VCS like git, set the Debian changes (to the source tree) ontop the upstream release tag and simply add the control files ? And when a new upstream release comes, simply rebase. - Git cannot track rebasing branches. To effectively use git to share stuff you need fast-forwarding branches. - Rebasing loses history, so one wants to 'merge' the old state somehow, so the old state is part of the history (which can than also solve the previous point). - To use git as the better quilt, i.e. to manage a transparent reviewable set of modifications not (yet) found upstream you need to rebase (especially rebase -i). - Git's rebasing does not work if the branch rebased contains older history (it wants to reapply every commit not already in the ancestors of the commit to be rebased to), so rebasing and keeping history of the same branch does not work. In Git-dpm I have the following approach to work around this incompatibilty: Each project/project branch consists of three git heads: An upstream branch, a patched branch and a debian branch. Only the debian branch needs to be public and contains everything else, especially all the history and is fast-forwardable. The upstream branch is something similar enough to the contents of the .orig.tar contents and it's commit-hash is recorded together with the name and checksum of the .orig.tar file in the debian-branch's debian/.git-dpm file to be able to do the other operations. The patched branch only exists as git head temporarily. It is not supposed to be published (except as ancestor of the debian branch and a tag for released versions), but the head is created on the fly and after something in it is changed, it is merged back into the debian branch (and the debian/patches/ directory updated from the commits it contains). This way the patches are rebased git commits, easily reviewable and always ready to be taked from upstream/sidestream, while the whole project can just be pushed/pulled around in the normal git way, the repository is after pull/clone directly dpkg-buildpackage'able and one gets a nice 3.0 (quilt) style source package also showing the patches in the patch-tracker. (Compare for example http://patch-tracker.debian.org/package/xbuffy/3.3.bl.3.dfsg-8 with http://anonscm.debian.org/gitweb/?p=users/brlink/xbuffy.git;a=shortlog;h=refs/tags/patched-3.3.bl.3.dfsg-8 ) Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110724122104.gb10...@pcpool00.mathematik.uni-freiburg.de
Re: Nitpicking: you are doing it wrong
* Leo costela Antunes cost...@debian.org [110708 23:41]: Please use dh/cdbs/whatever other means necessary to make your packaging work easy to read and understand. Don't make the packaging more complex for other people just because you want to know what's going on. But please also do not use anything you do not understand. I my eyes the normal dh_* scripts are a good middle ground in being high level enough to not hide the big picture in details while still being transparent enough to know what's going on. Especially having the calls to upstream's build system in such files explicitly listed makes it easy to check they are called the proper way. Using dh or cdbs means it needs quite some knowledge to be sure it is done right. You never know who might have to NMU it, make QA uploads, etc and even you yourself might find it pretty hard to remember why you did something in this particular fashion, when it actually could just as well be done in a more common way. In my experience with modifying packages locally cdbs and dh are quite a pain, as too many things are done automatically so that small changes can require quite a big diff. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110709110910.ga2...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: flush (updated package)
* Fabrizio Regalli fab...@fabreg.it [110707 21:22]: I am looking for a sponsor for the new version 0.9.10-1 of my package flush. Some 'LDFLAGS += -Wl,-z,defs -Wl,--as-needed' should help to get the depedency list a bit shortened. Ok, I can add this flags. Please do not add -Wl,--as-needed unless you are sure you understand what it does. --as-needed can change the runtime behaviour of programs. Unless you are confident there can be no such problems or you will be able to detect bugs introduced by it, please think twice about it. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110708104130.ga14...@pcpool00.mathematik.uni-freiburg.de
Re: LC_MESSAGES=C in debian/rules
* Daniel Stender dan...@danielstender.com [110429 10:37]: is it best practice to set LC_MESSAGE=C in debian/rules to prevent things like test suite breaking when building within non-English locales? If you want to set something, set LC_ALL. Otherwise a user-set LC_ALL will override it. (and it also sets LC_CTYPE, which is even more likely to cause problems than LC_MESSAGES). I'd say a proper test-suite already sets LC_ALL=C itself unless it's locale independent, so if you have a test-suite not doing this please also report this upstream. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110429084804.gc23...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: frei0r (updated package)
* Peter Pentchev r...@ringlet.net [110429 11:55]: Yes, if you put LP: #459940 in your changelog (just as you would put a Closes: #NN for a Debian bug), then the next time your package is synced with Ubuntu, the bug will be closed in their LaunchPad system. Will it? At least it did not in the past. (I always assumed for that to have an effect it would need something like the -v to dpkg-buildpackage needed on Debian's side for a Closes in a previous version not uploaded to have an effect.). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110429100531.gb24...@pcpool00.mathematik.uni-freiburg.de
Re: Copyright of a costumized pixel map image
* Mats Erik Andersson mats.anders...@gisladisker.se [110331 20:12]:
Now I have discovered that the background is black, so I would like
to modify this image by making it into a PNG image with transparent
background. This in order to blend better for desktop usage.
Why not simply change the .xpm. xpm is a very nice textual and easily
patched format:
--- rgb/usr/share/pixmaps/rgbpaint.xpm.orig 2011-03-31 20:26:03.0
+0200
+++ rgb/usr/share/pixmaps/rgbpaint.xpm 2011-03-31 20:26:32.0 +0200
@@ -2,7 +2,7 @@
static char *icon_xpm[] = {
32 32 32 1,
A c #FF,
-B c #00,
+B c None,
C c #C8,
D c #E4,
E c #85,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110331182832.ga5...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: tdc
* Michael Lustfield mtecknol...@ubuntu.com [110227 22:12]: It builds these binary packages: tdc- Tiny Dockable Clock (tdc) is a simple and tiny dockable clock. tdc-dbg- Tiny Dockable Clock (tdc) Debugging Symbols. Does this really justify a debug package? I'd rather guess not. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110228131813.ga15...@pcpool00.mathematik.uni-freiburg.de
Re: Init scripts as conffiles
* Jesús M. Navarro jesus.nava...@undominio.net [110215 20:40]: Anyway, my position would be that init script shouldn't have to be config files. For this to be true these steps should need to be worked on: 1) See for boot dependencies not being stablished in the init script itself (a sourced directory under /etc/defaults?) 2) All init scripts whose related daemon accepts params on start or that define any kind of global variable (i.e.: not strictly related to Debian internals) should source an /etc/default-related file. 3) *Maybe* think about a general way for any init script to source from some file/dir if it exists. 4) Once developers are comfortable that the vast majority of init script honour these previous points, deprecate init scripts as being considered config files and file as a bug any time a sysadmin really needs to still edit one of them. A sysadmin never has the edit any of those files. If they need to do something special they can always change the kernel to patch the init system to change what the script can do in arbitrary ways. /sarcasm While such scripts should allow all reasonable and forseeable configuration settings be applyable outside, there are still all the unreasonable and unforseeable changes that happen every day. (execute some additional clean-up or preparational command just before, run something two times or differently, ...). If a admin is not able to do those, it's a crap system. So at least every script should be overrideable by some script the admin supplies. So what is the advantage of not having those files in /etc? (In /etc/ they should be config files (ideally conffiles). If they are not conffiles, they do not belong in /etc). The advantage of having them in /etc are: - every user understands how to change them (no need to find out where to copy a script so it overrides the distribution suplied one). - if there are changes the usual conffile handling make sure one notes if the original file changes Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215195933.ga21...@pcpool00.mathematik.uni-freiburg.de
Re: CFLAGS in d/rules (and Debian policy) [Was: Re: RFS: mpg321 (updated package, 2nd try)]
* Paul Gevers p...@climbing.nl [110212 11:24]: - The CFLAGS in d/rules overrides flags set by dpkg-buildflags, which makes it more difficult to rebuild the package with different default flags (see man dpkg-buildflags). I see that the example in the Debian policy on build options [1] also overrides the flags set by dpkg-buildflags. So is this an example how it should NOT be done and should this be changed as well? I try to add some option to the CFLAGS, but seem not to be able to do it properly without specifying my own CFLAGS. My idea would be that you just use CFLAGS+=some_option_here in your d/rules, but trying this out just gives me a CFLAGS with only my some_option_here. So this can not be correct. It seems that d/rules does not have any CFLAGS available before I set them to any value. I must be overseeing something, so can you give an example, in mail or web page link, on how to properly implement adding options to CFLAGS in d/rules. debian/rules should ignore the contents of CFLAGS from the calling environment. CFLAGS is an environment variable a normal user may have set for normal development, so a package should not look at them. Using dpkg-buildflags should be done from debian/rules, dpkg-buildpackage setting those flags is just a workaround so that broken packages get some sane defaults of flags. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110212190225.ga4...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: free42
* Jean Schurger j...@schurger.org [110106 15:40]:
I am looking for a sponsor for my package free42.
Looking at debian/changelog, that is not quite helpful:
| free42 (1.4.66-1) unstable; urgency=low
|
| * Upstream release
| * Closes: #606358
|
| -- Jean Schurger j...@schurger.org Wed, 08 Dec 2010 12:38:31 -0500
The Closes has no reference to anything (so one could guess that it is the ITP
that is closed). And what is Upstream release as changelog for the very first
version supposed to tell me?
Next debian/control:
| Source: free42
| Section: misc
| Priority: optional
| Homepage: http://thomasokken.com/free42/
| Maintainer: Jean Schurger j...@schurger.org
| Build-Depends: debhelper (= 7.0.50), libxmu-dev, libgtk2.0-dev (= 2.10.3)
| Standards-Version: 3.9.1
|
| Package: free42
| Architecture: any
| Depends: ${misc:Depends}, ${shlibs:Depends}, debconf | debconf-2.0
| Description: HP42S Emulator
| Free42 is a re-implementation of the HP-42S calculator and the HP-82240
| printer. It is a complete rewrite, and doesn't use any HP code.
| You do not need an HP-42S ROM image in order to use it,
| yet it is fully HP-42S compatible.
| .
There is no need for an empty line at the end, so you can remove it
(the one with the dot).
I guess section otherosfs would be better than misc, as most other emulators
are there.
The It is a complete rewrite, and doesn't use any HP code. is a bit strange
to be in a description. (If it is not free software, it does not belong into
Debian. If it is free software, the copyright holder is not that important).
Why is this thing written without - in the short and with - in the long
description? I also think calculator could be added to the short description
and the long description be a bit more verbose what this thing is it emulates
might be helpfull.
Your debian/copyright file only lists
Thomas Okken and you, but as simple grep -i -r copyright . already gives:
Copyright _ 2005, Apple Computer, Inc. All rights reserved.
Copyright 2005 D. Jeff Dionne
Copyright (C) 1997 Rick Huebner
Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
Copyright (C) 1997 Free Software Foundation, Inc.
Copyright (c) 1998 John D. Polstra.
Copyright (c) 2004-2005 Greg Parker. All rights reserved.
Copyright (c) 2001 David E. O'Brien
Copyright (c) 2005-2009 voidware ltd.
Copyright Base2 Corporation 2009
Copyright (C) 1997 Rick Huebner
Some of which seems to even be compiled and explicitly have BSD like licenses
requiring to include their copyright statement (which your binary packages do
not).
I've not looked at the actual packaging or the build process.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110106152254.ga16...@pcpool00.mathematik.uni-freiburg.de
Re: libfoo.so.X symlink not created at build time
* Muammar El Khatib muammarelkha...@gmail.com [110104 22:43]: Hi Bernhard, On Tue, Jan 04, 2011 at 05:36:37PM +0100, Bernhard R. Link wrote: * Muammar El Khatib muammarelkha...@gmail.com [110104 16:52]: I'm maintaining a library which new upstream version is creating at build time *.la, *.so (development symlink), and the library itself with the form libfoo-x.y.z.so but not their symlinks that match their SONAME (I was expecting something like libfoo.so.X). Please take a look what their actual SONAME is (using readelf -d). Here I am pasting an example: $ readelf -d libCEGUIBase-0.7.5.so [...] 0x000e (SONAME) Library soname: [libCEGUIBase-0.7.5.so] [...] While the SONAME usually is something like libfoo.so.X, it might also be anything else (and the dynamic linker will that look for that file at runtime). If the SONAME is not libfoo.so.X there is no need to have a symlink of that name. I think I have understood you. So, in this case I am showing I don't need the symlinks of type libfoo.so.X because the SONAME is itself the libfoo-x.y.z.so. yes. If you have something like libfoo-X.so there, then this is not a development symlink, but the SONAME symlink. (so if any doc says .so.X they mean -X.so in that case and if they say .so they mean the real .so file and not the -X.so). Then, I should provide in the library package _only_ the lib*-x.y.z.so files, and obviously the *.la and *.so development symlinks into -dev package. Please, correct me if I am wrong. yes. Also note that your soname now includes the whole 0.7.5 part, so that this number should most likely be part of the library package *name*. (as the -1 seem to have been before). Now, packages which depends on this library to build are going to fail with this change. Things that build-depend on this package should most likely still be build-able with the -dev package installed. (Unless that version changes something else in comparison to packages already in the archive). But it is a soname change. That is why you have to change the package name, so that the old working library package (containing libCEGUIBASE.so.1 from version 0.6.2) is not removed if some package still depends on it. Packages build with the new -dev package will then have a dependency on the new package name with 0.7.5 in it. It can be said that a library transition has to be done. I'll rebuild packages gotten by executing apt-cache rdepends, and contact maintainers. If the API did not change, then those packages might only need an binNMU. Also note that as the version in the soname seems to be the whole version of the library (at least I guess so, as it is as 0.7.5 seems quite similar to the package upstream version of 0.6.2 in sid), every future minor upstream release will most likely change the soname and need a full library transition cycle (and perhaps waiting for NEW and so on). In other words: Unless you have some LART big enough to get upstream to switch back to stable ABIs, think twice if you want to keep maintaining this library or if simply droping it from Debian might be the better solution. I fear it might be everything but pleasent to deal with this all the time. If you keep maintaining it, I'd also suggest asking the release team for advice (as they will have to deal with those transitions). Ideally after squeeze release, though. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110105104140.ga7...@pcpool00.mathematik.uni-freiburg.de
Re: libfoo.so.X symlink not created at build time
* Muammar El Khatib muammarelkha...@gmail.com [110104 16:52]: I'm maintaining a library which new upstream version is creating at build time *.la, *.so (development symlink), and the library itself with the form libfoo-x.y.z.so but not their symlinks that match their SONAME (I was expecting something like libfoo.so.X). Please take a look what their actual SONAME is (using readelf -d). While the SONAME usually is something like libfoo.so.X, it might also be anything else (and the dynamic linker will that look for that file at runtime). If the SONAME is not libfoo.so.X there is no need to have a symlink of that name. If you have something like libfoo-X.so there, then this is not a development symlink, but the SONAME symlink. (so if any doc says .so.X they mean -X.so in that case and if they say .so they mean the real .so file and not the -X.so). As stupid as this is (especially the mixing of namespaces for filenames), there are sadly enough libraries already doing it this way and there is technically no problem with it. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104163637.gb2...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: libmatheval (updated package)
* Julian Taylor jtaylor.deb...@googlemail.com [101109 18:15]: I am looking for a sponsor for the new version 1.1.7-2 of my package libmatheval. As this is clearly not targeted at squeeze (you did almost repackaged it, it seems), this should not go to unstable but to experimental. - integer truncation in fortran interface on 64 bit (forwarded upstream) It would be nice if you could add some information about that to the patch you included. Also please take a look at debian/copyright. It does not even list the same copyright holder as the source files. (incomplete list of issues, I not even got so far as to looking at the actual package). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101109174420.ga18...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: xsol (updated package) [A solitaire game for the X Windows system]
* Mònica mon...@probeta.net [101021 12:29]: But in Debian archives, there is the long solution (I copied from there). I can't understand why these libraries were linked if they aren't used. They are needed for static linking or on platforms where dynamic libraries do not specify their dependencies. (So for Debian packages they can be removed without any problems. The simple solution of unconditionally removing them might not be feasible for upstream, though). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101021144248.ga2...@pcpool00.mathematik.uni-freiburg.de
Re: git-buildpackage and patches
* Pietro Battiston m...@pietrobattiston.it [100917 15:37]: On the other side, using quilt is just fine... but I do find great the idea that if you use a VCS, you _shouldn't_ need a separate tool for patches. And indeed, I see sometimes git-buildpackage automatically creates some patches named debian-changes-x.y.z - but I find the workflow of building the package every time I need to create a patch sub-optimal - and apparently undocumented. That is not git-buildpackage but rather dpkg-source, I'd guess. Is there anything I'm missing? There is also git-dpm. That stores patches as permanent git commits. That's not the work-flow you described, but perhaps nearer to what you want. http://wiki.debian.org/PackagingWithGit/GitDpm http://git-dpm.alioth.debian.org/ Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100917152327.ga24...@pcpool00.mathematik.uni-freiburg.de
Re: dfsg bit in the package name
* Tomasz Muras tom...@muras.eu [100824 19:34]: So to summarize: dfsg is a conventional way of naming a package, when the original source has been changed. It usually happens when upstream software contains some non-free elements. I do not think using dfsg makes sense if it was not repacked to remove non-dfsg-free stuff. For other reasons I think ds is sometimes chosen. (Though there are not really that many other legitimate reasons). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100824205549.gb13...@pcpool00.mathematik.uni-freiburg.de
Re: conflicts/replaces/provides vs. breaks/replaces/provides under policy 3.9.1
Not answering the Conflics/Breaks issue, but some remark about Provides. * Osamu Aoki os...@debian.org [100726 17:27]: = Case 2: package transition rule All the contents of the package foo is incorporated by bar in new 1.0 version and foo 1.0 became a transitional package with no real contents which can be removed safely. Please note pre-1.0 version of foo was not a transitional package. | Package: foo | Version: 1.0 | Description: ... | This is a transitional package for foo, and can be safely removed | after the installation is complete. | Package: bar | Version: 1.0 | Breaks: foo ( 1.0 ) | Replaces: foo ( 1.0 ) | Provides: foo Here the provide has advantages and disadvantages. I'd not suggest to use it unconditionally here (and even recommend against it in the usual cases). Also note that moving package foo to oldlibs makes it easier for people to remove such packages. = Case 2': package transition rule After stable release with case 2, you wish to remove the transitional package foo upon upgrade to unstable/testing/next-stable. I guess we do not package Package: foo at this moment when uploading. | Provides: foo I'd recommend against using recommend here unless in very special cases. An additional provides means more work for each dependency resolver. And after stable released with no real package with that name, there should no longer be any need for it. Do we do ... | Package: bar | Version: 1.0 | Conflicts: foo ( 1.0 ) | Replaces: foo ( 1.0 ) This only makes sense if you want to make life easier for backporters to oldstable. Or | Package: bar | Version: 1.0 | Conflicts: foo | Replaces: foo That means foo is to be removed. This means hard decisions for the resolver (hopefully it will decide to keep bar and remove foo, and not remove both). Question: Is there sure way to purge the old transitional package foo? Why do you want to make sure to remove it? It does not cause harm, is easy to find and remove. And it might be the only thing keeping bar from being removed as a no longer needed dependency. Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100726154816.ga31...@pcpool00.mathematik.uni-freiburg.de
Re: Renaming installed files
* Tony Houghton h...@realh.co.uk [100625 01:10]: OK, but more to the point I was wondering whether it's considered good practice to use a simple cp in install rules like this, or whether it would be better to add a quilt patch to make the upstream Makefile use the names I want in the package. Both is acceptable. I personally prefer to have as little changes to the upstream files as possible and doing as much as possible in debian/rules. In my experience, a large part of modifications of Makefiles found in Debian packages are unnecesary. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100625082800.ga6...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: rush
* George Danchev danc...@spnet.net [100613 09:33]: * the easy part: there is nothing wrong for non-DD to ask in advance if there are interested sponsor(s) of the piece of software they intend to package or adopt, especially with large and complex pieces. That would avoid wasting their time. I don't know about other sponsors and I was not active lately (whenever I was looking at something someone else sponsored it already in before I could even write a mail with the 5 most important things to fix first), but I'd say asking in advance is mostly a waste of time. There is hardly a way for a sponsor to know in advance if they are proficient enough in the languages and tools used, in the helper chosen for packaging and all the other stuff mostly only known when the package is mostly finished. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100613114737.ga18...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: 'snap2' rsync-based backup program with GUI
* Norbert Preining prein...@logic.at [100612 06:49]: One of the ways dpkg-source v3 differs from dpkg-source v1 is that any debian/ directory in the orig.tar.gz is removed before the debian.tar.gz is unpacked. So debian.tar.gz cannot be empty and the upstream debian/ directory if any is irrelevant. That is not compliant with what it *SHOULD* do. If there is a debian dir in upstream (again, anyone showing me the policy point forbidding that) then files in their should be replaced or whatever, but it is not correct (IMHO) that these files are removed. No, it is exactly correct and one of the important improvements of v3 that the .orig.tar.gz's debian/ dir is completely removed. Otherwise one either gets problems with files that by their sheer existance confuse helper scripts you cannot easily remove or needing some absurd way to specify how to remove them. If the contents of .debian.tar.gz becomes the contents of debian/ you have total control in an easy to understand way. Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100612094254.ga11...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: 'snap2' rsync-based backup program with GUI
* Thomas Goirand tho...@goirand.fr [100612 07:54]: I am quite sure that I read it somewhere, however, I can't find it again. It was more important in the past. Since there is the version 3 source format, an debian/ directory in the upstream tarball is only unecessary and no longer harmful. So no longer any need to have it renamed (unless you do not use v3). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100612094708.gb11...@pcpool00.mathematik.uni-freiburg.de
Re: Specifying %{variable} in control file for use in post inst?
* Ignacio Valdes ival...@hal-pc.org [100430 18:04]: rpm doesn't. I am going through the joy of trying to reconcile the two systems so as to not have two divergent code bases as much as possible. Sorry to say it that harsh: I doubt anyone here will be able to help you. We are focused on doing high-quality Debian packages. As you have another goal, most people here will not even understand what your problems are. If you make Debian packages other people are supposed to use, please consider doing proper postinst scripts that are targeted at Debian. Even for different versions of Debian, postinst scripts may need to differ a lot. I see no hope at all that anything that also works elsewhere has any chance to be a proper postinst script. (If you have some package specific tasks, consider creating some common helper scripts to be called from the package scripts. That has the additional advantage that users can also run them manually if needed). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100430161512.ga15...@pcpool00.mathematik.uni-freiburg.de
Re: Deleting files from .orig on unpack?
* Jonathan Niehof jtnie...@gmail.com [100408 01:56]: I'm working with a package where upstream uses a flat Makefile and the Debian package has been converted to automake. This means the Makefile from the .orig.tar.gz gets clobbered in the build process, and then removed entirely on clean. So build; clean isn't a no-op. I see several ways to deal with this: 1) Ignore it and be happy, but since clean doesn't actually restore the tree isn't this a policy violation? If there was a policy against it, then the policy would be buggy because it would neither document current practise nor would there be any reasons for such a requirement. The only sentence in this direction I can find is This must undo any effects that the build and binary targets may have had, which only says what it should do (undo the changes), not how. Practically you want to make sure that build - clean - dpkg-source -b works and produces the same results (except dpkg warning you a file vanished so it assumes you removed that deliverately) and that build clean - build build - clean - build clean - build - clean - build all produce the same result. 3) Add a bunch of rules logic to back up the shipped makefile on bulid and restore it on clean Now that is ugly, though there is some example of people doing it because of problems with their vcs workflow. I'd suggest to just remove it in clean and make sure it does not break your build if it is still there. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408090705.ga31...@pcpool00.mathematik.uni-freiburg.de
Re: Upgrading a package without patches to deb source 3.0
* Tony Houghton h...@realh.co.uk [100301 19:27]: It seems like it would be a good idea to upgrade roxterm to source format 3.0. Is it as simple as creating debian/source/format containing 3.0 (quilt) and running debuild as usual? Roxterm doesn't have any debian/patches, but I presume 3.0 (quilt) is the correct format rather than 3.0 (native) and it'll work just fine without a series file? yes. Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100301184513.ga24...@pcpool00.mathematik.uni-freiburg.de
Re: DEB_BUILD_OPTIONS=parallel=n work not as expected
* Erik Schanze schan...@gmx.de [091206 10:36]: /usr/bin/make --jobserver-fds=3,4 -j ... I don't know who changed $(MAKEFLAGS) from -j3 to --jobserver-fds=3,4 -j and why the number 3 was not used after -j. Could anybody please give an explanation? Is there something broken or did I miss something? [...] Because this will end in a build run with unlimited jobs, or did I miss smth.? If make was just passing -j3 down, you could not limit the number of jobs. Because if your top level makefile calls again submakes in - say - src/, doc/ and data/ (at the same time) and src/, doc/ and data/ would have 3 subdirectories, then there were already 9 subsubmakes processed at the same time. if they had been given a -j3, too, each would process 3 files at the same time, causing 27 processes running simultanously. That's why submakes do not get -j3, but instead get told to interact with the parent make, so that all possible submakes together process 3 things at the same time, but still being able to do so in multiple subdirectories (if there are for example subdirectories with only 1 file). Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Realloc is blocking execution
* Mats Erik Andersson mats.anders...@gisladisker.se [091016 11:55]: 4. The main process WM receives SIGHUP, and enters a signal handler. The signal handler uses two calls: free_menuitems(), get_menuitems(). If those calls call malloc or free or anything else this might be the problem. Memory allocation functions are not reentrant and due to threading support are easily blocking when used this way. Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
* ERSEK Laszlo la...@caesar.elte.hu [091006 04:48]: On Mon, 5 Oct 2009, Bernhard R. Link wrote: Note that you might do without a patch. make is build for cases like that in mind, so replacing variables in a makefile you do not like just needs those variables as command line arguments. so just changing debian/rules to $(MAKE) CFLAGS=$(CFLAGS) LDFLAGS=$(LDFLAGS) LIBS=$(LIBS) might do the same without needing to edit the Makefile. Those compiler options must be in the upstream Makefile(s). There isn't anything in the upstream release that would pass those compiler options to the Makefile from the outside. The upstream release is meant to be self-sufficient for any SUSv2 platform. So any port has to move those flags if they aren't in the right place for that port as shipped in upstream. Perhaps I am misunderstanding something here. Let's see if I got anything wrong: 1) we are speaking about lbzip2, aren't we? 2) that one has exactly one Makefile in the upstream tarball not calling any submakes in any strange way. 3) you patch that Makefile to no longer set CC CFLAGS LDFLAGS and LIBS What I am saying is that this patch is unnecessary. you can do that totally in debian/rules by placing those variables in the make invocation within your build-stamp target. Looking at the definition of those variables in your debian/rules also looks very complicated. Unless there is a reason to rerun this script all the time? There is none, but lbzip2 consists of only 5 .c files, so it's not very wasteful when building. Otherwise e.g. some LDFLAGS := $(shell ./lfs.sh LDFLAGS) might be a bit more efficient and easier to look at... := would be certainly easier on the eyes, but it's not supported by SUSv2 make [0], so := is avoided in the upstream version. I could use := in debian/rules, but the examples in the Policy [1] and other stuff I looked at originally IIRC don't use it, so I'm not convinced it wouldn't have side-effects. (Try it out and see if it works is not good enough :)) = and := are exactly the same, except that := is evaluated once and then stored, whereas = is evaluated later. If I were you I would be more worried that all the parsing and reparsing (which causes the need for the extra $) has some side effects. Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
* ERSEK Laszlo la...@caesar.elte.hu [091004 21:54]: Take a look at the FreeBSD port and see if the Makefile patch is appropriate to include upstream or if not, contact the port maintainer about it. The FreeBSD port creator/maintainer, Gábor Kövesdán, personally offered to do the port [0], and I gratefully accepted (obviously). We already discussed the Makefile patch and concluded that the FreeBSD port needs it, and that upstream can't merge it. A minimal justification sounds like: (1) the port doesn't compile with -D _XOPEN_SOURCE=500, (2) SUSv2 requires -D _XOPEN_SOURCE=500 [1], and upstream is written against SUSv2. No changes are planned for the upstream Makefile, so maintaining the patch shouldn't be much of a burden, hopefully. Note that you might do without a patch. make is build for cases like that in mind, so replacing variables in a makefile you do not like just needs those variables as command line arguments. so just changing debian/rules to $(MAKE) CFLAGS=$(CFLAGS) LDFLAGS=$(LDFLAGS) LIBS=$(LIBS) might do the same without needing to edit the Makefile. Looking at the definition of those variables in your debian/rules also looks very complicated. Unless there is a reason to rerun this script all the time? Otherwise e.g. some LDFLAGS := $(shell ./lfs.sh LDFLAGS) might be a bit more efficient and easier to look at... Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ktikz
* Florian Hackenberger flor...@hackenberger.at [090930 10:57]: I am looking for a sponsor for my package ktikz. http://mentors.debian.net/debian/pool/main/k/ktikz/ktikz_0.9-1.dsc Just the most obvious stuff from a cursory look: - DEB_BUILD_OPTIONS=noopt does not work (it still does -O2) - debian/copyright does not list copyright or license of src/lineedit.cpp - debian/menu has a pre-lenny section - debian/dirs has usr/sbin. I do not think you need that. - the manpage is a joke - if your README.Debian has nothing to say, delete the file Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: cflow (updated package)
* George Danchev danc...@spnet.net [090803 05:22]: cflow 1:1.2-3 (from sid) does not distribute /usr/share/info/dir.gz, so it seems that something has changed to the upstream build system, without being documented in their last ChangeLog entry... diff to the rescue? Most likely it is not upstream that has changes, but dpkg. It now calls a different install-info which can cause behaviour like that. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ITS: arc-colors, gnome-colors, shiki-colors are ready
* Dmitrijs Ledkovs dmitrij.led...@gmail.com [090605 20:01]: 2009/6/5 Bernhard R. Link brl...@debian.org: * Dmitrijs Ledkovs dmitrij.led...@gmail.com [090605 14:01]: I've asked multiple times and not yet got a single argument why I herby place this and that in the public domain could see any danger to be misunderstood or invalidated by a German court. http://en.wikipedia.org/wiki/Wikipedia:Public_domain#Rule_of_the_shorter_term Sorry no better source. Only thing I can find there is that the years after authors death is the same without looking where the author lived. And it also says that the USA has the same behaviour in this regard. I doubt we will find useable software anytime soon where the software is in the public domain because the author is many decades dead, but I was speaking about people giving up their copyrights. Hochachtungsvoll, Bernhard R. Link However, some countries make exceptions to this rule. A notorious case is Germany, which has had a bilateral treaty with the U.S. governing copyright since January 15, 1892. That treaty, which is still in effect, defined that a U.S. work was copyrighted in Germany according to German law irrespective of the work's copyright status in the U.S, and it did not contain a rule of the shorter term. In one case, a German court therefore decided that a U.S. work that had fallen into the public domain in the U.S. was still copyrighted in Germany in 2003 in spite of §7(1) of the EU directive. Good enough for me. To say what? All this says, especially with the context you omitted, that a work will not enter public domain N years after death of the author for N the value from the authors home country but only when the number of years by German law are reached. And given the list also linked on that page, that is true for many countries, including the US. If I misread anything, please tell me. But there is nothing at all saying that a I place this work in the public domain would have any more problems in Germany than in the US. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ITS: arc-colors, gnome-colors, shiki-colors are ready
* Benjamin Drung benjamin.dr...@gmail.com [090605 01:59]: It's sad, that public domain does not exists in Germany In the same sense public domain does not exist in Germany, copyright does not exist in Germany either. I've asked multiple times and not yet got a single argument why I herby place this and that in the public domain could see any danger to be misunderstood or invalidated by a German court. There are many problems with public domain, but those are unrelated with Germany. (Like people thinking if it is public domain in the USA because of being written by a government employee or author long enough dead would allow people to use it outside of the USA; or people not claiming something they got as 'freeware' was public domain.). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ITS: arc-colors, gnome-colors, shiki-colors are ready
* Dmitrijs Ledkovs dmitrij.led...@gmail.com [090605 14:01]: I've asked multiple times and not yet got a single argument why I herby place this and that in the public domain could see any danger to be misunderstood or invalidated by a German court. http://en.wikipedia.org/wiki/Wikipedia:Public_domain#Rule_of_the_shorter_term Sorry no better source. Only thing I can find there is that the years after authors death is the same without looking where the author lived. And it also says that the USA has the same behaviour in this regard. I doubt we will find useable software anytime soon where the software is in the public domain because the author is many decades dead, but I was speaking about people giving up their copyrights. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: skanlite
* Ben Finney ben+deb...@benfinney.id.au [090531 01:55]: A VCS log dump is rarely useful as a changelog. The VCS log is *developer-focussed, describing every commit to the VCS. The changelog is *user*-focussed, and should describe every user-visible change since the previous release. That depends on what you call a changelog. Usually (GNU coding standards and in many other free software) ChangeLog is focused on someone working on the source, while a NEWS files is there for all users. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps: warning: dependency on.... (they use none of its symbols)
* Yavor Doganov ya...@gnu.org [090324 12:13]: The keyword here is before. There were bugs in binutils exposed on some architectures, especially for C++ linking. Maybe new architectures like armel are still problematic in some cases. The problem Bernhard Link describes has been resolved upstream: http://sourceware.org/ml/binutils/2009-01/msg00413.html |(elf_link_add_object_symbols): Link in --as-needed libs if they | satisfy undefined symbols in other libs. I'm not into bfd enough to understand what it actually does, but both things I can imagine would be another argument against using it: 1) if it means to not remove libraries that suplies symbols that another library needs but that library is not linking to suplying library In this case it has nothing to do with the example I gave, because this only makes a difference if a library does not link to all the libraries it needs, which was not the case in my example. 2) if it means to not remove a library that is already needed by a library needed In this case --as-needed would still produce warnings in dpkg-shlibdeps for the harmless case (a program linking in dependencies of its libraries to support static linking), while it would silence warnings for the cases you would want to know about: linking against libraries not used at all. (Because in this case either something is very strange with the build-system or the no used at all is not really true). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Missing licenses in upstream source files
* Giacomo A. Catenazzi c...@debian.org [090320 10:08]: Too often, though, such files are a set of license *terms* only (e.g. the text of the GPL), with no copyright status or explicit *grant* of license. That's not enough for Debian to know the rights of recipients: mere inclusion of license terms is not a grant of license under those terms. I don't agree. Only in journals you will find copyright notice and author on every pages. Don't mean that there are copyright problem on my favorite book, in inner pages. I think it the same for sources. You could write the license (or a reference) on every file, or you could write only a general file (e.g. COPYING), if it is clear that the license cover all the files. While I agree that a single licence grant suffices, two limitations: 1) The grant should be in a form that it is reasonable to believe it fits two the whole content: a) simply a COPYING file in the tarball with the GPL in it does not suffice, and especially not if the package uses autotools. As when those are called the wrong way (i.e. without arguments), they just copy the file in. Also in other cases just copying a license file in is hard to take as an grant of an license, a little sentence above the license or in the documentation or somewhere else like this program is available under is a grant in my non-lawyerish eyes. b) when package contains materials from obviously different origin[1], it is far too likely that something went wrong upstream, so better ask for clarification. 2) When being in upstream role or making suggestions to upstream, please choose the one license grant per non-trivial file approach. It makes lives easier for all people much easier. Especially as code tends to hitch-hike in other programs. When you then have some code that every search engine shows you is copied from somewhere else, but you do not know where it origins from or if it actually has a free license, things get ugly... Hochachtungsvoll, Bernhard R. Link [1] like sources with different coding style, or code and other things like images and so on. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps: warning: dependency on.... (they use none of its symbols)
* Chow Loong Jin hyper...@gmail.com [090320 09:58]: Just curiosity, what kind of problems can be caused from using --as-needed? My memory of this is vague, searching the BTS I found these though: http://bugs.debian.org/379748 http://udrepper.livejournal.com/11056.html http://udrepper.livejournal.com/10946.html http://bugs.debian.org/502083 http://bugs.debian.org/320697 In that case would I be right in summarizing this up as --as-needed causes issues only when dlopen is used where the dlopen'd library requires symbols that are linked in via -lsomelibrary? No, that means that issues have been found in this cases yes. --as-needed radically changes the meaning of -l with a shared library. Just that all other than the given one people can think of do not exist in practise (or do not yet have shown up[1]), does not mean there cannot be other cases. Thus I stronly suggest to not use it unless you exactly know what happens and that the difference has no meaning in the case at hand. Otherwise I suggest to rather ignore the warning or hide it with dpkg-shlibdeps' --warnings= instead of risking to break something. Hochachtungsvoll, Bernhard R. Link [1] Which might be because most are quite absurd: Assume a program uses libB, which uses libA but leaks some details out, so that the program then uses features depending on which libA it was compiled with (sounds ugly, but this world is not perfect). libA's maintainer knows this and thus not have a symbols file but just a shlibs file to have at least the version of the library when the last time such a new feature was added. Assume program's upstream knows this thus added a explicit link to that library. Now if the maintainer just adds --as-needed to get rid of the warning, the package will no longer have a dependency to get a new enough libA. The ugly thing with this case is that it will not show up in unstable, but for example when the package migrates to testing but libA did not... -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: procmeter3 (updated package)
* Marco Rodrigues goth...@sapo.pt [090314 12:23]: I am looking for a sponsor for the new version 3.5b-1 of my package procmeter3. Nothing here that it is only an QA update and you do not want to adopt it and make it your package would have been nice. Even nicer would have been the debian/changelog, as that would also made have that clear. I would be glad if someone uploaded this package for me. the debian/copyright file is not up to date. Also stating the full license statement from the source file would be nice (so that it is clear that it is GPLv2 or higher, which is not clear from the part copied from the README file (or rather the old README file)) I've not yet looked at much else. (especially as libgtk is currently not installable). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: spacehero
* Arne Wichmann ar...@rasentrimmer.org [090219 11:25]: I am looking for a sponsor for my package spacehero. - URL: http://mentors.debian.net/debian/pool/main/s/spacehero You claim in debian/copyright you downloaded it from http://spacehero.koalo.de/, but that website directly only lists a different file with a different version number. Other packaging things: * Standards-Version is already a bit old * the description is a bit terse * You do not seem to build with the suggested -O2 -g, and support for noopt is also not there. * debian/rules could need a major clean up, configure not needed and things like that * what about a menu entry? As you also seem to be one of the upstream authors: How about putting a copyright notice in the actual sources? Some tipps about the Makefile: * Adding -l in LDFLAGS before the objects will break static linking. (usually one has a LIBS that is added afterwards for those) * it's nice to split preprocessor flags and compiler flags. (Best way is some CXXFLAGS for the compiler flags, CPPFLAGS for the preprocessor flags (like -D or `sdl-config --cflags`), adding the link call also the CXXFLAGS but not the CPPFLAGS, and when compiling both. Extra points for splitting things a user most likely wants to override CPPFLAGS and some intern preprocessor flags (like the `sdl-config --cflags` might want to keep even when setting other CPPFLAGS)) The way you implement those also breaks for people wanting to give make some CXXFLAGS or LDFLAGS (as that would overide the settings in the makefile) Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dh 7 broken by design?
* Helmut Grohne hel...@subdivi.de [090217 21:18]: So will the new minimal example look like the following then? #/usr/bin/make -Bf %: dh $@ Note that there is also the possibility of #/usr/bin/make -f Makefile: @# %: Makefile dh $@ which is another way to make things phony. (and avoids dh being called for the Makefile target as it is when naming that target FORCE as make's info file suggest). But I definitly think a debian/rules file should list all the required and optional rules it supports via a .PHONY: line. Even better the % rule should already list which targets it actually supports as #include /usr/share/debhelper/bla $(SUPPORTED_RULES): %: dh $@ .PHONY: $(SUPPORTED_RULES) everything else is just very fragile... Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: advise needed for library packaging
* Paul Wise p...@debian.org [081229 01:01]: I would suggest adding a .symbols file for the new ABI so you can detect ABI breakage in newer upstream versions. s/so you can detect/so dpkg-gensymbols can warn in case of some easy to detect / Before someone thinks that a symbols file suffices to check for ABI breakage After all it can only check the most notorious ones, manual work is still needed to be sure... Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: esmtp (updated package)
* José Fonseca [EMAIL PROTECTED] [081114 06:38]: dpkg-shlibdeps: warning: dependency on libdl.so.2 could be avoided if debian/esmtp/usr/bin/esmtp were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libssl.so.0.9.8 could be avoided if debian/esmtp/usr/bin/esmtp were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libcrypto.so.0.9.8 could be avoided if debian/esmtp/usr/bin/esmtp were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if debian/esmtp/usr/bin/esmtp were not uselessly linked against it (they use none of its symbols). I'm planning to request lintian override. If anybody has a better suggestion please let me know. Never mind -- I've just learned about --as-needed ld flag that solves both issues. Please note the --as-needed flag does some black magic so unless you know what it does and have tested things still work in every condition be carefull with it. Usually it is easier to just reduce the needed dependencies. For example by giving the make call a fixed LIBS= argument to override the one written to the Makefile, modifying the LIBS= line in Makefile or by adding your own config script filtering stuff out. The easiest in your case seems to be to change all $(MAKE) in your debian/rules with $(MAKE) LIBS=-lesmtp. I'd also suggest to give configure a LDFLAGS=-Wl,-z,defs to make sure nothing bad happens. BTW: if you contact upstream, please also tell them to: 1) never ever add -I (or -D) to CFLAGS (it belongs to CPPFLAGS) 2) not to output -I/usr/include, -L/usr/lib or -L/lib it only make logs more hard to read. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: salasaga (updated package)
* Iulian Udrea [EMAIL PROTECTED] [080919 17:03]: I am looking for a sponsor for the new version 0.8.0~alpha4-1 of my package salasaga. Your build system will run autogen and configure multiple times. Please make build depend on the appropiate patch-stamp file instead of patch directly and do not make it phony (usual way it to make it a build-stamp target, create build-stamp file at the end and make build simply depend on build-stamp). I've currently no sid system with enough build-depends available to test, but your clean target really looks like not cleaning enough. Please try to run dpkg-buildpackage -S after a dpkg-buildpackage and look at the .diff.gz, I'd be suprised if there weren't a myriad of additional files in there (at least I see nothing removing Makefile or Makefile.in and stuff like that). Your debian/copyright states it is LGPLv3 but does not point to the copy of the license in /usr/share/common-licenses/LGPL-3. You do not list the copyright holders of intl/ (17692 lines in .c files is not little), ide/font_outline/ArevCopyright.txt lists a copyright holder not found in there, and perhaps other files, too... Also having the package under LGPL 3 and the debianisation under GPL 2 looks strange to problematic to me... I've only looked at debian/rules and debian/copyright, other files might have other problems... Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDBS duplicate docs installation
* William Vera [EMAIL PROTECTED] [080917 03:57]: 2008/9/16 Charles Plessy [EMAIL PROTECTED]: it is probably that debhelper installs the docs (README AUTHORS ChangeLog TODO) in /usr/share/docs/foo and the makefile in /usr/doc/foo (see Makefile.am). The file names of the docs are generic enough that Debhelper guesses them. Thanks, that appears it is the problem, so I guess just need patch Makefile.am I'm correct? Patching Makefile.am is usually the last thing to do. There are usually many easier things: * just let make do it's game and remove the files from debian/packagename/usr/doc afterwards. (Looking at what is currently at mentors, that seems to be done already).. * tell make to install things elsewhere. Automake generated Makefiles files are usually properly parameterized, so you can just give it an additional argument. Sometimes you can even give that to configure. In this case, just call make install with argument docsdir=/usr/share/doc/scroot (and then tell dh_installdocs to not install those again at the same place with -X) Hochachtungsvoll, Bernhard R. Link P.S: your configure handling looks a bit off. You have an empty config.status: configure which will confuse make if someone asks for build-stamp directly, and your configure-status target depends on patch instead of patch-stamp. (and if you name the rule configure-stamp instead of config.status, you whould create those file at the end). Additionally please also set CFLAGS, otherwise your debian/rules might do funny things when called directly and not via some dpkg-buildpackage helper script. And tell upstream that -O3 does not belong into INCLUDES variable... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quilt and patches directory
* Michael Biebl [EMAIL PROTECTED] [080915 02:50]: Because patch is a phony target which is therefore always out of date, and therefore anything that depends on patch will be triggered to run every time that you run debian/rules. Depending on patch instead of $(QUILT_STAMPFN) can therefore cause odd behavior like running configure twice or make twice, depending on the rest of debian/rules. Could you give a real-world example when that can happen. I've always used the patch target (instead of $(QUILT_STAMPFN)) in my debian/rules files and so far haven't encountered any issues. Actually, I think the depending on the rest of debian/rules is incorrect, depending on patch always causes multiple invocations, not only sometimes. So to see the effects just take a lock at any build log of such a package: First look for debian/rules invocations. The important ones are build and binary-arch. In the first there is configure and make invocation. in the second there should usually (because of build*-patch) only be one make install invocation and not extra make or configure invocation. I you depend in patch instead of the stampfn there will be. Given that patch depends on $(QUILT_STAMPFN) I can't imagine a scenario where I would run into problems using the patch target. It causes build (and perhaps configure) to be run a second time in the binary target. That usually is usually not a real problem but only wasted cycles of the build daemons, but it makes the process more fragile. The binary target is usually run in fakeroot or other things, so that configure run there another time might for example include fakeroot's LD_PRELOAD or other things to places where you do not want it. Looking around on your packages, most do not use patch directly. The first I found that does (rsyslogd), has half of this problem and a potential other problem: | config.status: configure |[...] | build-stamp: patch config.status This avoids the problem of runing configure again by telling make that patch has not to be run before configure but in parallel (which usually leads to it be run before, unless told to use multiple processors). As you do not patch anything in the build system, that should not be an problem here, though. But make is run multiple times: Take a look at http://buildd.debian.org/fetch.cgi?pkg=rsyslogver=3.18.2-1arch=ia64stamp=1218673256file=log In line 150 there is the first debian/rules build call, which calls make in line 493. In line 774 there is the debian/rules binary-arch call, which calls make again in line 777 without need and touches build-stamp again in line 831 (as it does nothing in between, no harm is done but a few wasted buildd time, having a build-stamp stamp file when it cannot be used because of patch does not make much sense, though). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nemesis (updated package)
* William Vera [EMAIL PROTECTED] [080911 21:28]: I am looking for a sponsor for the new version 1:1.4beta3-1 of my package nemesis. The history of versions is quite disturbing: 1.32+1.4beta3-1 1.32+1.4beta3-2 1:1.4-1 1:1.4beta3-1 Yes, because upstream's tarball, I used a epoch for update 1.32+1.4beta3-2 to 1.4-1 Some recomendation? I see two problems here: 1) the epoch for 1.4 Epochs often cause more problems than they solve, one should not use them too lightweight, as you will never be able to get rid of them again. That 1.4 is after 1.32 (and not 28 releases before) means that upstream seems to use some strange numbering sheme based on decimal fractions. There are good chances this will happen again in the future, so instead of using an epoch, normalizing that to usual natural numbers by making that a 1.40 could have expressed the situation more clearly (and avoid similar problems in the future). But alas, it is to late, the epoch is in the archive, it can never ever go away now... 2) 1.4beta3 coming after 1.4 That sounds strange. Usually beta releases come before the final release (to be expressed in Debian version numbers either by ~ or by the oldversion-newbeta trick), so having this after 1.4 looks very strange to me. If you take a look at the dates at the download site, you see that this feeling seems to be right: nemesis-1.4beta3.tar.gz 29-Oct-2003 19:12 nemesis-1.4beta3.zip07-Oct-2004 02:02 nemesis-1.4.tar.gz 07-Oct-2004 04:29 nemesis-1.4.zip 07-Oct-2004 04:47 nemesis-1.4.zip.asc 07-Oct-2004 04:47 nemesis-1.4.tar.gz.asc 07-Oct-2004 04:49 So your new version seems to actually be almost a year older than the previous one and is the version you just replaced in the previous entry. If you do not want uscan to tell you in error that there is an newer upstream version if there is none, just tell it to Debianize the versions there, by adding an opts=uversionmangle=s/beta/~beta/ i.e make debian/watch look like the following (two lines): version=3 opts=uversionmangle=s/beta/~beta/ http://sf.net/nemesis/nemesis-(.*)\.tar\.gz Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: parcellite (updated package)
* Vincent Bernat [EMAIL PROTECTED] [080904 21:00]: Upstream have included an m4/ directory that should not be distributed (it is used by autotools stuff). Usually an m4/ directory are sources for autotool generated files and thus sources for the scripts needed to generate the binaries and thus part of the source (in the usual source definition invented by the GPL). There might be m4/ directories that have different stuff, but in general it is required in the tarball. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need help writing watch file for unusual, troublesome case.
* Brandon [EMAIL PROTECTED] [080902 22:31]: Also, xevil is a dead project. The latest release was years ago, and Satan doesn't respond to email. Would you guys recommend not having a watch file? I think especially with dead upstream a watch file is usefull. If upstream is active and knows you exists or you are on the webpage from time to time, then you will notice yourself. If upstream just wakes up, puts a new version and vanishes again then a watch file is almost the only chance you have to detect it... Also email addresses often change, sometimes it helps to look for other projects of the same person to see if there are other addresses now (sometimes there is even a mailinglist there also dedicated to the old project but not listed on the old project page directly). Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS libctl and meep
* Thorsten Alteholz [EMAIL PROTECTED] [080726 22:18]: - URL: http://mentors.debian.net/debian/pool/main/m/meep - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/meep/meep_0.20.2-1.dsc the files debian/patched/99-nopatch.dpatch.failed and patch-stampT in the .diff.gz seem to be cruft. The same for debian/*.debhelper* All the long descriptions end with an emtpy line (\n .). I do not think that makes much sense. As this is also the same for all, I guess you missed the description what those package actually are. The -dev packages only depending = on the non-dev packages looks quite strange. the left-over patch rules in debian/rules make a bit hard to read. You create debian/meep-mpi.1 but try to clean meep-mpi.1 Implementing the optional build-arch (and an empty build-indep) rules would be nice. Instead of -mkdir directory, i'd suggest mkdir -p directory. (and using the same temporary directory for both installs will break if anyone calls debian/rules with -jN for N 1). A symbols file for the libraries would be nice. I'm a bit confused debian/rules uses soname 1 and thus should do -plibmeep1, while debian/control lists those with 2. My unstable box is currently down, so the above are just the problems I can catch by looking-at without trying. Also Libraries are generally quite hard, so finding sponsers is relatively hard. Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a new window manager
* Michael Renner [EMAIL PROTECTED] [080725 11:41]: At the moment I'm building a deb package for a window manager. Everything is fine, but there is no entry in KDMs 'session type' menu. I found the 'update-alternatives' command and call update-alternatives --install /usr/bin/x-session-manager \ x-session-manager /usr/bin/5Dwm 50 in the postinst. I found such an entry in the ksmserver- as well as in the icewm package. While it work for these wm's, something is wrong with my entry. There are three things for that. The first is the x-session-manager x-window-manager alternatives. (If it is a windw manager, it should be x-window-manager, not x-session-manager). The second is the Debian menu. For this you need a debian/menu file and dh_installmenu. This allows all full window managers to switch to this directly and everything showing a list of window managers should show it. The third thing is that kdm and gdm are/were/whatever broken to not support the Debian menu system. (At least when menu-xdg is installed having the menu file should make it show up, otherwise it is a bug in the display manager). To work around this some people add .desktop files for window managers that have nothing to do with those things. As this might cause duplicate entries on well-configured systems or further work for you (to find out how to tell it that there are two entries there and only showing one), I strongly recommend against adding that file. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need anexample for debian packaging
* Kartik Mistry [EMAIL PROTECTED] [080721 09:25]: On Mon, Jul 21, 2008 at 12:04 PM, Reema Shah [EMAIL PROTECTED] wrote: In building debian packages,why do you require root privileges and so we have to use fakeroot..? fakeroot is not necessary now with new dpkg. Reading through the changelogs, I only find in a change Oct 2007 that dpkg-buildpackage uses fakeroot without being told so. I doubt it is possible to build proper packages without root/fakeroot or whatever else causing programs to think they run as root and preserving user and permissions of files not representable as mere user. Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: freemat
* Giuseppe Iuculano [EMAIL PROTECTED] [080703 02:50]: * After this unpatch no longer works. I think this is because you patch Makfile.in files. As you call autoreconf, this can only be harmfull. * running autoreconf changes many files, many are not reverted by your clean. I don't know how fix this, I need patching Makefile.in to fix UMFPACK search and so I need to call aclocal/automake/autoconf... How can I fix this? There are multiple ways, with different requirements and up and downs: 1) Modifying Makefile.in As Makefile.in in generated from Makefile.am by automake, if you modify Makefile.in, you do not need to run automake (as Makefile.am-Makefile.in is automake and Makefile.in-Makefile is configure). a) Modify Makefile.am and Makefile.in Also modifying Makefile.am has the advantage that upstream can make better use of your patch and if someone takes the patched Debian package, he can change Makefile.am and run automake and not loose the changes you did. The disadvantage of this is that unless upstream uses AM_MAINTAINER_MODE in it's automake, there is always the danger of make running automake and thus redoing Makefile.in again. (unless you make sure the timestamps are correctly, i.e. in debian/rules touch Makefile.am, wait 3 seconds (as some filesystems have 2 second resolution) and then touch Makefile.in and hope that nothing evil happens). b) only modifying Makefile.in This makes it much more unlikely automake is run by make, but has the danger that if it is done (for example a user copying the source dir, thus destroying timestamps) may run automake (unless upstream uses AM_MAINTAINER_MODE) and destroy your changes... 2) only modify Makefile.am and run automake (explicitly or implicitly) Advantages: you modify the file upstream would modify (i.e. the real source and not some intermediate file) and your patch is as minimal as possible. Disadvantages: You need to build-depend on automake, you need to hope automake does not change in ways breaking your setup (was usual in the past, the last years this has not happened, making this solution usually the prefered one). And you need to clean up afterwards, removing the generated files in your clean target. (configure if you call autoconf (directly or via autoreconf), config.h.in if you call autoheader (directly or indirectly), all Makefile.in when you call automake, autom4te.cache if nothing else removes that annoyance and so forth The easiest way to make sure you have removed anything generated, is unpacking the source package, building it, then creating the source package and looking at the diff. As you use debian/patches for all your changes, the diff (best look at it with diffstat) should only contain files in the debian dir. Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: freemat
* Giuseppe Iuculano [EMAIL PROTECTED] [080703 13:27]:
I don't know if this is a good and elegant solution, but I run
aclocal,automake,autoconf
and I created a diff in debian/patches/ . In this way, make doesn't run again
aclocal,automake,autoconf and debian/rules clean seems to work now...
The disadvantages this solution has:
* the patches are more complicated than necessary (though they are overall
small,
so this is not a big drawback in this case).
* it's relatively fragile w.r.t. timestamp issues. I guess it is
relatively safe here, as in your patches Makefile.am is always before
Makefile.in, so when applied the usual way, Makefile.in should never be
newer than Makefile.am (which would trigger automake to be rerun).
* you have to make sure everything is up to date and fits together.
It is relatively complicated to get right in that way.
For example in debian/patches/04_fix_path_dir.dpatch you have:
--- freemat-3.6~dfsg~/Makefile.in 2008-03-17 06:02:16.0 +0100
+++ freemat-3.6~dfsg/Makefile.in2008-07-01 14:21:08.0 +0200
@@ -15,9 +15,9 @@
@SET_MAKE@
VPATH = @srcdir@
-pkgdatadir = $(datadir)/@PACKAGE@
-pkglibdir = $(libdir)/@PACKAGE@
-pkgincludedir = $(includedir)/@PACKAGE@
+pkgdatadir = $(datadir)/freemat
+pkglibdir = $(libdir)/freemat
+pkgincludedir = $(includedir)/freemat
am__cd = CDPATH=$${ZSH_VERSION+.}$(PATH_SEPARATOR) cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
but in debian/patches/99_fix_configure.dpatch you have:
diff -urNad freemat-3.6+dfsg~/Makefile.in freemat-3.6+dfsg/Makefile.in
--- freemat-3.6+dfsg~/Makefile.in 2008-07-03 12:15:53.0 +0200
+++ freemat-3.6+dfsg/Makefile.in2008-07-03 12:23:45.0 +0200
@@ -1,8 +1,8 @@
-# Makefile.in generated by automake 1.10 from Makefile.am.
+# Makefile.in generated by automake 1.10.1 from Makefile.am.
# @configure_input@
# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
-# 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+# 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
@@ -15,9 +15,9 @@
@SET_MAKE@
VPATH = @srcdir@
-pkgdatadir = $(datadir)/freemat
-pkglibdir = $(libdir)/freemat
-pkgincludedir = $(includedir)/freemat
+pkgdatadir = $(datadir)/@PACKAGE@
+pkglibdir = $(libdir)/@PACKAGE@
+pkgincludedir = $(includedir)/@PACKAGE@
am__cd = CDPATH=$${ZSH_VERSION+.}$(PATH_SEPARATOR) cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
i.e.: you first make a change, and then you revert it...
Hochachtungsvoll,
Bernhard R. Link
--
Never contain programs so few bugs, as when no debugging tools are available!
Niklaus Wirth
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: freemat
* Giuseppe Iuculano [EMAIL PROTECTED] [070912 12:14]: Done, and re-uploaded. Some more issues: * you build-depend on autotools-dev and delete those file unconditionally, so there is no need to only copy config.guess and config.sub in if they are there. (i.e: remove the ifneq and endif around the copies) (Mostly a cosmetic issue) Acutally, as you tell autoreconf an -f -i, it might even copy them there a second time. (-f also modifies INSTALL, so perhaps without -f is better) * You miss a build-dependency on pkg-config. (And upstream's configure or something included by this needs better error reporting, most likely the m4 files from pkg-config). * After this unpatch no longer works. I think this is because you patch Makfile.in files. As you call autoreconf, this can only be harmfull. * running autoreconf changes many files, many are not reverted by your clean. (and no not forget to make the config.status rule then depend configure.in instead of configure) * you might want to tell upstream to tell whoever is responsible for AC_LIB_FREEMAT_CHECK in acinclude.m4, that neighter CFLAGS nor CXXFLAGS are suiteable places to put -I in (-I and -D belong only in CPPFLAGS, never ever into CFLAGS or CXXFLAGS). (heck, configure even print warnings about not finding umfpack.h in the preprocessor because of this). There might still be other issues, I did not yet give it a thourough look. (took me some time to figure out it was pkg-config missing and c++ is really slow, did not yet even do a full compile yet...) Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: freemat
* Giuseppe Iuculano [EMAIL PROTECTED] [080630 10:56]: I am looking for a sponsor for my package freemat. - URL: http://mentors.debian.net/debian/pool/main/f/freemat - What is the purpose of your debian/README.Debian? It looks like just another copy of the package description so should be removed. - why do you install README.source in the binary package? - your debian/rules does not specify in which order patch and configure are to be called. As you actually change files where this matters, config.status should depend on patch-stamp. - you only give CFLAGS to configure not CXXFLAGS but your program seems to be c++. - registering the documentation with doc-base would be nice. running out of time, other things perhaps later... Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plait - Command-Line Jukebox
* David Symons [EMAIL PROTECTED] [080610 14:55]: I am looking for a sponsor for my package plait. [...] - plait runs OK in a Sarge chroot so I have used Sarge versions for the binary dependencies. You do not need to add dependencies for essential packages. bash, findutils and grep are all essential, so you do not need to list them, unless you need specific versions. If it runs in sarge that means you do not need specific versions. Please also do not recommend packages from non-free (or otherwise outside Debian). You call ./plain --install from your configure script which includes commands like: | rm -f $HOME/.plait/commands/itunes-cmd-play.js | rm -f $HOME/.plait/commands/cmd-play.vbs | rm -fr /etc/plait Have you tested different shells (as this is /bin/sh) and different awks (as it calls awk directly)? Things of that size have often incompatiblities with one or the other implementation... Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: automake-idl
* Olaf Mandel [EMAIL PROTECTED] [080602 03:40]: * the repeated use of $(CURDIR) where a . or nothing at all would have sufficed is a bit annoying. (especially when done unsafe and unecessarily adding new problems if paths contain spaces). Actually, the unprotected use was only in the parts created by dh_make. I changed those. Also, I made the strings a bit shorter by using the variable $(DESTDIR) instead of $(CURDIR)/debian/foo. But leaving out $(CURDIR) completely... I like how it reminds me of where executables are and relative to which path I am working. Is it really that bad? I only said a bit annoying. '$(CURDIR)/configure' is quite more to parse than './configure'. * having a build-indep and a build-arch (the latter doing nothing) would be nice. Added. Thanks. But install still depends on build = build-indep. It's not like it makes any difference for this package, thus what install depends on does not matter. For packages having both build-arch and build-indep doing something and those being able to be done independently, having different install targets depending on the different build targets (or no install target at all and doing the work in binary-*), would be the way to go. But in this package the only difference in having build-arch and build-indep is increasing the number of packages supporting those target thus increasing the chances they will actually be used in some future and make building other packages faster. I didn't understand that part of the policy (ch 4.9) very well: Should I make build-arch return with exit status 2 or can I just leave it as an empty target? Just an empty target is good. After all, all what you had to build for arch dependent packages was done by doing nothing. * Copyright information is incomplete. While copyright information of the build files if often forgotten (but better should not be), Those are still missing. (i.e. files like missing, install-sh, ...) at least automake-idl seems to contain at least a partial fork auf automake (as opposed to be generated or copied by automake). Even if you do not install that stuff, it's copyrights and licenses should be listed. For autoconf-orb I agree, the information is missing. I don't want to add comments assigning the copyright information to upstream without talking to them, first. On that note: would it even be Ok for me to add such copyright notices to the files, copying information from the COPYING file? Or is this not valid? I think it is best to ask the author. COPYING only contains the whole license and neigther a copyright notice nor a license statement. Perhaps the COPYING file was just copied there by automake and the author did not think about it at all. After all, even FSF distributes their m4 files under a very permissive license: (from /usr/share/aclocal-1.10/init.m4 on my system) # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, # 2005, 2006 Free Software Foundation, Inc. # # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. But with automake-idl, where copyright information is present, I made a mistake. That package is GPL2, not GPL3 and the copyright holder is the FSF, not the upstream author of autoconf-orb! Sorry about that, it has been corrected in the newest upload. Unless Vladimir Panov assigned copyright to FSF, he still is copyright holder for at least his modifications. Some more I just saw: The dependencie of autoconf-orb look very strange. The dependency on automake-idl looks like it should be an Suggests at most. The version dependency on autoconf I do not understand. After all, even with this dependency, you cannot be sure an older autoconf is not used with those files, and none of them seems to include an AC_PREREQ to actually tell to need a newer version. So where does this version come from? Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Packager question again: can you point me to a not flawed package?
preferred
browser */
- htmlview, NULL,
+ /* Debian's sensible-browser is similar to Redhat's htmlview */
+ sensible-browser, NULL,
/* GNOME 2 */
- gconftool-2, gconftool-2 -g
/desktop/gnome/url-handlers/http/command,
+ gconftool-2, gconftool-2 -g
/desktop/gnome/url-handlers/http/command,
/* KDE */
- kfmclient,!kfmclient exec \%s\,
+ kfmclient,!kfmclient exec \%s\,
/* use fallbacks */
firefox, NULL,
- mozilla, NULL,
- konqueror,NULL,
- netscape, NULL,
- NULL, NULL
+ mozilla, NULL,
+ konqueror,NULL,
+ netscape, NULL,
+ NULL, NULL
};
If you mean this with purely white-space changes, please take a look at the
changed file before making some claims.
--- gqview-2.0.4.orig/src/editors.c
+++ gqview-2.0.4/src/editors.c
@@ -47,14 +47,14 @@
static gchar *editor_slot_defaults[] = {
- N_(The Gimp), gimp-remote -n %f,
- N_(XV), xv %f,
+ N_(The Gimp), gimp-remote %f,
N_(Xpaint), xpaint %f,
NULL, NULL,
NULL, NULL,
NULL, NULL,
NULL, NULL,
NULL, NULL,
+ NULL, NULL,
N_(Rotate jpeg clockwise), %vif jpegtran -rotate 90 -copy all
-outfile %p_tmp %p; then mv %p_tmp %p;else rm %p_tmp;fi,
N_(Rotate jpeg counterclockwise), %vif jpegtran -rotate 270 -copy
all -outfile %p_tmp %p; then mv %p_tmp %p;else rm %p_tmp;fi,
Well, that is very obvious, too.
So this package has three little changes (changes of program defaults,
savely overwrite config file and change of paths), that do no overlap
and have no danger of no being mixed up. What should be incorrect with
this one?
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: automake-idl
* Olaf Mandel [EMAIL PROTECTED] [080601 10:38]: I am looking for a sponsor for my packages autoconf-orb and automake-idl. * Package name: autoconf-orb Version : 1.1.1-1 Upstream Author : Vladimir Panov [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/autotools-idl/ * License : GPLv3 Section : devel * Package name: automake-idl Version : 1.1.0.1.10.1-1 Upstream Author : Vladimir Panov [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/autotools-idl/ * License : GPLv3 Section : devel Some things from a first shallow look: * None of those packages contains config.guess/config.sub nor uses them. So there is no need to copy them in before configure. * the repeated use of $(CURDIR) where a . or nothing at all would have sufficed is a bit annoying. (especially when done unsafe and unecessarily adding new problems if paths contain spaces). * having a build-indep and a build-arch (the latter doing nothing) would be nice. * most things starting with # from the templates can be removed when not needed. That makes the whole thing much more readable. * The For details, see ... in the package description looks like a candidate for a Homepage field instead. * Copyright information is incomplete. While copyright information of the build files if often forgotten (but better should not be), at least automake-idl seems to contain at least a partial fork auf automake (as opposed to be generated or copied by automake). Even if you do not install that stuff, it's copyrights and licenses should be listed. And let me say that GPLv3+ is a very strange license for those files, as it makes them explicitly impossible to be used by GPLv2 programs. It might be adviseable to put the license information into the distributed .m4 files, so if they end up in a GPLv2 project, they can more easily be spotted. The missing copyright information in most of the files also makes me quite suspicious. It is not unusal for such collections to just contain things from other sources and missing attribution (and thus a license to distribute them). Some more checks into that might be appropriate. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the quality of Debian's diff.gz
* George Danchev [EMAIL PROTECTED] [080601 17:14]: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html see, the PATCHDIR usually called files/ (analog to debian/patches/) from where they will be automatically applied to the upstream code. Each patch you wish to apply should be saved into a file named patch-* where * indicates the pathname of the file that is patched, such as patch-Imakefile or patch-src-config.h. and later To make fixes and upgrades easier, you should avoid having more than one patch fix the same file. Following those rules verbatimly would be no better than just have a single .diff.gz file. Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need some tips on building Debian packages
builddir ../configure (and replacing the generated file from configure.status to builddir/configure.status, of course) and not calling $(MAKE) later but $(MAKE) -C builddir Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: sctplib
* Thomas Dreibholz [EMAIL PROTECTED] [080508 14:54]: sctplib still has quite a lot of users and I have been asked regularly for up-to-date packages. Therefore, I have updated the Debian package to the latest sctplib version. Incomplete list of issues: - debian/rules needs some care. your install targets need to depend on the build targets, the build targets should actually do something instead of only configuring. - The -doc package ist just mostly empty. - I'd say it does not make much sense to start the long descriptions of the packages with an empty line. (and be different for those packages) - upstream adds strange things to CFLAGS (especially -O3 -g0 or -g3 -O0 overwriting anything given to it from debian/rules). - a symbols file would be nice for the future to make sure programs depending on that do not get inflated dependencies. - a debian revision of -1unstable looks strange - the -dev package should get a versioned dependency on the library (where would that .so symlink point at if there was a different version installed?) - the source contains a couple of rfc file. It's copyright is not listed in debian/copyright and it looks non-free (at least it seems to heavily restrict modifing) - some more copyrights seem to be missing (like manual/fixunder.sty, ...) - perhaps more, I stopped looking here... Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vexim
* Daniel Knabl [EMAIL PROTECTED] [080425 17:25]: after a long while I'm again searching for someone willing to sponsor and/or upload vexim to Debian. You might get better success rates if you write in your mails what it is about (unless it is so ugly you think noone would otherwise download it to take a look at it). you can find the latest files here: http://tirolinux.net/~daniel/vexim/ * http://tirolinux.net/~daniel/vexim/vexim_2.2.1-5.1.dsc * http://tirolinux.net/~daniel/vexim/vexim_2.2.1-5.1.tar.gz * http://tirolinux.net/~daniel/vexim/vexim_2.2.1-5.1_i386.changes The file vexim-2.2.1.orig.tar.gz should have had the name vexim_2.2.1.orig.tar.gz, then you would have got a .diff.gz instead of a .tar.gz (and that is not even downloadable permission problems) any hints and tips are really welcome, also suggestions for further improvement and features. Looking at the CVS as not otherwise getable: Your debian/rules looks improveable a lot. Why all this -stamp files if you do nothing at all (Especially the install-stamp file is totally useless twice, as it depends on a phony target and is not on a place where resuming is extremly usefull)? And why only patch if all is build but not if only the arch-independent stuff is to be build? (also patch should never be in build* prerequisites, but always as -stamp in the -stamp prerequisites). Additionally it would be nice to have an build-arch: target, so you have both of them. (And if by some chance a future buildd supporting those get this package to build arch-only nows faster that it has nothing to do). You seem not to use $(buildname) and $(DEBIAN) so why set them? And $(shell pwd) is unneeded, make has $(CURDIR). Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easiest way to Debianise a package?
* Ivan Vucica [EMAIL PROTECTED] [080413 19:09]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Apr 13, 2008 at 12:44 AM, Simon Ruggier wrote: If you're upstream, then for the sake of packagers, you probably want to release the data and source code in the same tarball, unless you like to release updates for them independently (i.e. if the source gets updated much more often than the data). That probably means I should include all the data files in the EXTRA_DIST variable in Makefile.am, right? As you want the data to end up somewhere, a dirname_data = might almost be a better idea, so that people using the source and installing per make install also get a fully working setup Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easiest way to Debianise a package?
* Ivan Vucica [EMAIL PROTECTED] [080411 18:18]: I'm looking for a smarter way to produce Debian packages for future games, out of SVN'ed, autotools-using projects. I'm looking for information for cases where I am the upstream. That means I could use tips with proper use of autotools to make generating DEBs easier; I'm still generally struggling with autotools. [...] So, I have an autotools project. Punching in make dist produces project-0.1.tar.gz. make distcheck also produces a valid executable provided that all libraries are installed. Data files are not (currently) mentioned anywhere in the autotools data files such as Makefile.am, configure.ac, etc. Questions: 1. What are your recommendations with regards to what to use to perform initial debianisation of the project? Meaning - what should I use? Just debhelper? CDBS? That depends whom you ask. Both has advantages and disadvantages. The biggest distadvantage of CDBS is that you have to know everything very good to be sure it does the right thing and still works tomorrow and not only by pure chance now. 2. Should data files be produced by same debianisation directory (by which I mean folder containing files copyright, rules, etc)? I don't understand the question. 3. Should source file generated by autotools contain the data files? Will that make debianisation any easier? That depends. Usually just having one .orig.tar.gz containing everything makes it easier for users compiling on their own (they just have to download a single file), for you if you want to put them into the same source package (which has the advantage of easier keeping them in sync in the archive, though the downsize that you only can upload new versions of program and data at the same time to Debian[1]). 4. In case my questions are wrong: What would be your steps for producing packages project and project-data, considering what I mentioned above and directory structure below? What would be your desires for upstream -- what should upstream do to make your life easier? In case everything is in the same source package (which I'd suggest), separating things at build time (and even only build the needed parts) is easier when arch-dependent and arch-independent parts are in separate directories and have their own Makefile's (in auto* by having their own Makefile.am doing the preparation and installing as opposed to having the top-level Makefile doing that) and no functionality in the top level dir (i.e. mostly only clean and things recursing into SUBDIRS there). What would you do after fetching SVN (not tar.gz) that contains data as below, and whose make dist would generate .tar.gz containing just sources? I guess I'd be confused but remember some games separate stuff and start reading the README. Note: src/Makefile.am.template is generated using autogen.sh to produce src/Makefile.am... don't ask. must. resist. the. urge Hochachtungsvoll, Bernhard R. Link [1] Though realistically, only both change at the same time usually. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: jin
* Anuradha Weeraman [EMAIL PROTECTED] [080409 04:38]: I am looking for a sponsor for my package jin. * Package name: jin Version : 2.14.1-1 Upstream Author : Alexander Maryanovsky * URL : http://www.jinchess.com/ * License : GPL Section : contrib/games It builds these binary packages: jin- Graphical client for chess servers I'm not that into java to sponsor myself and using cdbs makes me sponsoring even unlikelier, but some general hints: The package Depends: sun-java5-jre which according to packages.debian.org is only available in non-free yet, so this package could go at most into contrib. You should include the full license information, especially the part in copyright.txt about which versions of the GPL it is are most important and missing in your debian/copyright file. You also seem to miss copyright information for some files in debian/copyright. Not everything is from Alexander Maryanovsky, things like ./free/chess/EboardVectorPiecePainter.java list other people. Also src/free/jin/legal lists other licenses and copyright holders. Are they for specific parts and if yes which? and why is nothing in debian/copyright about them? some of the .zip files in resources/pieces have AUTHORS files with a name not listed in debian/copyright. why not? resources/lnfs and resources/libs contains jar files with classes but nothing seems to contain their sources. You have an jin.6.old file in the .diff. gpl.txt should not be in debian/docs. There is a copy in basefiles. The directory names might need reinvestigating. AFAIR it should be /usr/share/games/jin andn ot /usr/share/jin. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: failmalloc
* Jon Dowland [EMAIL PROTECTED] [080214 12:20]:
On Fri, Feb 08, 2008 at 07:32:18PM +0900, Michal ??iha?? wrote:
No you should not change orig.tar.gz, it should be exactly the same as
upstream provides (unless you have good reason to do so). Just delete
them in clean under same condition you use for copying them
from /usr/share, this way the change won't be present in diff.
How about
* build-depend on autotools-dev
* move the upstream config.guess and config.sub to
config.{guess,sub}.upstream in the configure target
* copy the guess/sub from the autotools-dev location into the
build tree, again in the configure target
* if the *upstream files exist; move them back over sub/guess in
the clean target
That way you don't modify the orig tarball; you're guaranteed to have an
appropriate and up-to-date sub/guess; the unpacked source is back to
pristine upstream after the make clean target, which is particularly
nice if you have your tree in a VCS and don't want to keep filtering the
sub/guess changes out of commits.
Again: there is no need to save the old config.guess and config.sub.
Just delete them in clean and copy them in before configuring, all
problems solved.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
