Re: Packaging upstream tarballs with mixed C and Python sources
On Sat, Dec 22, 2012 at 11:50 PM, Игорь Пашев wrote:
> I think override_dh_auto_{build,install,clean} in debian/rules could help.
> For example:
>
> override_dh_auto_build:
> cd server && ... # build server
> $(MAKE) ... # build in top dir
Best talk upstream into providing a better build system, but until
they do that, this workaround would be better I think:
override_dh_auto_build:
dh_auto_build --sourcedirectory=server
dh_auto_build
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKTje6FhoV5t21AyfxuLTYxV2BwqGaSp=uj4r9o6TS�ch...@mail.gmail.com
Re: Package variant selection policy using meta packages
Hi, Am Samstag, den 22.12.2012, 12:51 -0600 schrieb Peter Samuelson: > According to the package description, you only need the -dev package if > you actually plan to configure the window manager instead of using its > defaults. Which presumably most people do, so I guess the Recommends > makes sense. Excpet for the part where this requires one or more -dev > packages at all. It looks as though configuring xmonad involves > _recompiling_ it. What is this, an old school Unix kernel? I'm > confused. this is getting off topic, but let me lessen your confusion: The popularity of xmonad lies in the fact that to configure it, you have the full power of a high level programming language available. The defaults are quite minimalistic, so most people will do that and willneed the -dev packages. However, they have no interest in the -prof packages altogether; this policy decision is what I want to make easier for the user to express and enforce. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Package variant selection policy using meta packages
[Joachim Breitner] > > And a foo-dev Recommends: foo-prof is not suitable because? > > because we cannot tell what the user will want. For example, a user of > xmonad will not want -prof packages installed, and an addition 400MB of > useless stuff on his computer is not in his, and hence our, interest. So, it appears xmonad is a window manager. It seems a fair question why someone who runs a window manager needs -dev packages at all, let alone -prof packages. According to the package description, you only need the -dev package if you actually plan to configure the window manager instead of using its defaults. Which presumably most people do, so I guess the Recommends makes sense. Excpet for the part where this requires one or more -dev packages at all. It looks as though configuring xmonad involves _recompiling_ it. What is this, an old school Unix kernel? I'm confused. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121222185144.gp4...@p12n.org
Re: Packaging upstream tarballs with mixed C and Python sources
2012/12/22 John Paul Adrian Glaubitz :
> Hi,
>
> I am currently trying to figure out how to get the new UAE fork
> "fs-uae" [1] ready for Debian and I haven't yet found a satisfiable
> way to build the package.
>
> fs-uae itself is written in C, but it ships together with a launcher
> GUI and a server for multi-player games, both written in Python. While
> the C source code for the emulator itself is located at the top
> directory of the source tarball, both the launcher and the server are
> located in sub-directories.
>
> If I just create the usual debhelper 9 rules file, the package will be
> built from the C sources only, ignoring the Python code for launcher
> and server.
>
> Does anyone have an idea how to create the three binary packages for
> the emulator, launcher and server from one source package. I am asking
> since I am not such an expert on Python packaging yet and hope that
> someone here knows better :).
>
> I am CC'ing upstream since I have been discussing the issue with him
> as well. Also, there might be the possibility to just split the
> upstream tarball into emulator, launcher and server to simplify
> packaging.
>
> The upstream tarball can be found here [2], if anyone wants to have a
> look.
>
> Cheers,
>
> Adrian
>
>> [1] http://fengestad.no/fs-uae/
>> [2] http://fengestad.no/fs-uae/stable/2.0.1/fs-uae-2.0.1.tar.gz
I think override_dh_auto_{build,install,clean} in debian/rules could help.
For example:
override_dh_auto_build:
cd server && ... # build server
$(MAKE) ... # build in top dir
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/call-q8wmo7xsjm4ua5budnyovyentnk7ehlm8vxmvxw0xke...@mail.gmail.com
Bug#696541: ITP: filerock-client -- client for FileRock Secure Cloud Storage
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: filerock-client Version : 0.4.0 Upstream Author : Heyware s.r.l * URL : http://www.filerock.com * License : GPL Programming Lang: Python Description : client for FileRock Secure Cloud Storage This package provides the client application of FileRock, a backup and synchronization service that provides data confidentiality and integrity. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121222153326.6856.8285.reportbug@Aspire-1410
Packaging upstream tarballs with mixed C and Python sources
Hi, I am currently trying to figure out how to get the new UAE fork "fs-uae" [1] ready for Debian and I haven't yet found a satisfiable way to build the package. fs-uae itself is written in C, but it ships together with a launcher GUI and a server for multi-player games, both written in Python. While the C source code for the emulator itself is located at the top directory of the source tarball, both the launcher and the server are located in sub-directories. If I just create the usual debhelper 9 rules file, the package will be built from the C sources only, ignoring the Python code for launcher and server. Does anyone have an idea how to create the three binary packages for the emulator, launcher and server from one source package. I am asking since I am not such an expert on Python packaging yet and hope that someone here knows better :). I am CC'ing upstream since I have been discussing the issue with him as well. Also, there might be the possibility to just split the upstream tarball into emulator, launcher and server to simplify packaging. The upstream tarball can be found here [2], if anyone wants to have a look. Cheers, Adrian > [1] http://fengestad.no/fs-uae/ > [2] http://fengestad.no/fs-uae/stable/2.0.1/fs-uae-2.0.1.tar.gz -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121222152322.ga32...@physik.fu-berlin.de
Re: Package variant selection policy using meta packages
On Sat, 22 Dec 2012 14:57:56 +0100 Joachim Breitner wrote: > Am Samstag, den 22.12.2012, 14:39 +0200 schrieb Andrei POPESCU: > > On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: > > > Users tend to fall into one of three classes: > > > A. Users that, if they have foo-dev installed, always also want > > > foo-prof installed. > > > B. Users that want to manually decide for what packages they want > > > the -prof package and for what package not. > > > C. Users who don’t want any -prof package around. > > > > > > Currently, we only really help user B. If user A installs foo-dev there > > > is nothing that ensures that he gets foo-prof installed as well. > > > > And a foo-dev Recommends: foo-prof is not suitable because? > > because we cannot tell what the user will want. For example, a user of > xmonad will not want -prof packages installed, and an addition 400MB of > useless stuff on his computer is not in his, and hence our, interest. apt-get --no-install-recommends xmonad-prof ... > Also, a user from the class A wants a stronger guarantee than just > Recommends, which is just a suggestion to the package manager, but not a > a hard relation. With the i-want-all-prof-package metapackage it is > guaranteed that for every -dev package, there is the corresponding -doc > package installed. I don't see why this is necessary. Recommends is a strong guarantee for most cases, it is also sufficiently flexible for those who want more control. Individual packages can check for extras, just like devscripts does. (I find it hard to believe that anyone except devscripts maintainers actually needs all of the Recommends: listed for devscripts.) > Am Samstag, den 22.12.2012, 13:32 + schrieb Neil Williams: > > IMHO, actively preventing the installation of optional dependencies is > > not something which actually warrants support. > > I admit that use case C might not be as useful as the difference between > B and A, but it doesn’t hurt either (assuming a meta-package based > approach is taken for A and B). > > > None of these packages get installed by default, simply disabling the > > installation of Recommends by default meets all the requirements of > > cases B & C without making an artificial block between the two. > > I find this a bit coarsely grained. I might be a user in class B or C, > but besides that I certainly want to follow whatever the maintainer of a > package recommends me to install. Disabling the installation of > Recommends would change the behavior of _all_ Debian package. I don’t > think this is a good solution. It doesn't have to affect all packages. --no-install-recommends is your friend. What's more, package managers like synaptic will clearly show which packages are available as Recommends but which weren't installed. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpyInWAsFuwd.pgp Description: PGP signature
Re: Package variant selection policy using meta packages
Hi, Am Samstag, den 22.12.2012, 14:39 +0200 schrieb Andrei POPESCU: > On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: > > Users tend to fall into one of three classes: > > A. Users that, if they have foo-dev installed, always also want > > foo-prof installed. > > B. Users that want to manually decide for what packages they want > > the -prof package and for what package not. > > C. Users who don’t want any -prof package around. > > > > Currently, we only really help user B. If user A installs foo-dev there > > is nothing that ensures that he gets foo-prof installed as well. > > And a foo-dev Recommends: foo-prof is not suitable because? because we cannot tell what the user will want. For example, a user of xmonad will not want -prof packages installed, and an addition 400MB of useless stuff on his computer is not in his, and hence our, interest. Also, a user from the class A wants a stronger guarantee than just Recommends, which is just a suggestion to the package manager, but not a a hard relation. With the i-want-all-prof-package metapackage it is guaranteed that for every -dev package, there is the corresponding -doc package installed. Am Samstag, den 22.12.2012, 13:32 + schrieb Neil Williams: > IMHO, actively preventing the installation of optional dependencies is > not something which actually warrants support. I admit that use case C might not be as useful as the difference between B and A, but it doesn’t hurt either (assuming a meta-package based approach is taken for A and B). > None of these packages get installed by default, simply disabling the > installation of Recommends by default meets all the requirements of > cases B & C without making an artificial block between the two. I find this a bit coarsely grained. I might be a user in class B or C, but besides that I certainly want to follow whatever the maintainer of a package recommends me to install. Disabling the installation of Recommends would change the behavior of _all_ Debian package. I don’t think this is a good solution. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Package variant selection policy using meta packages
On Sat, 22 Dec 2012 14:24:46 +0100 Jonas Smedegaard wrote: > Quoting Andrei POPESCU (2012-12-22 13:39:07) > > On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: > > > Users tend to fall into one of three classes: > > > A. Users that, if they have foo-dev installed, always also want > > > foo-prof installed. > > > B. Users that want to manually decide for what packages they want > > > the -prof package and for what package not. > > > C. Users who don’t want any -prof package around. > > > > > > Currently, we only really help user B. If user A installs foo-dev there > > > is nothing that ensures that he gets foo-prof installed as well. > > > > And a foo-dev Recommends: foo-prof is not suitable because? > > Recommends are for relations suitable for most users, not some class of > users. In this case, the only difference is that using Recommends doesn't distinguish between cases B & C. I don't see that as a problem. IMHO, actively preventing the installation of optional dependencies is not something which actually warrants support. None of these packages get installed by default, simply disabling the installation of Recommends by default meets all the requirements of cases B & C without making an artificial block between the two. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpMllDwmDng0.pgp Description: PGP signature
Re: Package variant selection policy using meta packages
Quoting Andrei POPESCU (2012-12-22 13:39:07) > On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: > > Users tend to fall into one of three classes: > > A. Users that, if they have foo-dev installed, always also want > > foo-prof installed. > > B. Users that want to manually decide for what packages they want > > the -prof package and for what package not. > > C. Users who don’t want any -prof package around. > > > > Currently, we only really help user B. If user A installs foo-dev there > > is nothing that ensures that he gets foo-prof installed as well. > > And a foo-dev Recommends: foo-prof is not suitable because? Recommends are for relations suitable for most users, not some class of users. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Package variant selection policy using meta packages
On Sb, 22 dec 12, 13:17:32, Joachim Breitner wrote: > Users tend to fall into one of three classes: > A. Users that, if they have foo-dev installed, always also want > foo-prof installed. > B. Users that want to manually decide for what packages they want > the -prof package and for what package not. > C. Users who don’t want any -prof package around. > > Currently, we only really help user B. If user A installs foo-dev there > is nothing that ensures that he gets foo-prof installed as well. And a foo-dev Recommends: foo-prof is not suitable because? Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Bug#696526: ITP: libmojolicious-plugin-i18n-perl -- Internationalization Plugin for Mojolicious 3.x and higher
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmojolicious-plugin-i18n-perl Version : 0.82 Upstream Author : Anatoly Sharifulin * URL : http://search.cpan.org/dist/Mojolicious-Plugin-I18N/ * License : Artistic-2.0 Programming Lang: Perl Description : Internationalization Plugin for Mojolicious 3.x and higher Mojolicious::Plugin::I18N is an internationalization plugin for Mojolicious 3.x and higher. I18N is provided by Locale::Maketext. Dominique signature.asc Description: This is a digitally signed message part.
Package variant selection policy using meta packages
Dear developers, I’d like to get opinions on whether it is ok to (ab)use meta packages, alternative dependencies and conflicts to provide package selection policy features to our users that are not supported otherwise. Here is an example (and it is the use case that I am considering): Haskell libraries are always shipped in three different packages: * libghc-foo-dev ← The library itself * libghc-foo-prof ← Extra data only used when profiling code * libghc-foo-doc ← Documentation. Let’s look at -prof only(for -doc the same scheme would be useful). Users tend to fall into one of three classes: A. Users that, if they have foo-dev installed, always also want foo-prof installed. B. Users that want to manually decide for what packages they want the -prof package and for what package not. C. Users who don’t want any -prof package around. Currently, we only really help user B. If user A installs foo-dev there is nothing that ensures that he gets foo-prof installed as well. So my idea is to have a meta package for each use case. Note that this meta package should _not_ have to explicitly list all libghc-*-* packages, as it should not have to be changed when we add a new Haskell library (and it would make the testing migration even harder). So this should work (names just working titles, of course): I create three meta packages, named i-want-all-prof-packages, i-want-some-prof-packages, i-want-no-prof-packages. The package relations are then: i-want-all-prof-packages: Conflicts: i-want-some-prof-packages i-want-no-prof-packages i-want-no-prof-packages: Conflicts: i-want-some-prof-packages i-want-some-prof-packages: [no special relations] libghc-foo-dev: Depends: libghc-foo-prof | i-want-some-prof-packages | i-want-no-prof-package libghc-foo-prof: Conflicts: i-want-no-prof-package Clearly, only at most one of the three policy packages will be installed. * If i-want-all-prof-packages is installed, this means that the dependency of foo-dev implies foo-prof, as intended. * If i-want-some-prof-packages is installed, then the dependency of foo-dev is always fulfilled, so the user can decide what he wants or what not. * If i-want-no-prof-packages is installed, then the foo-dev dependency is fulfilled, but no -prof package can be installed. So all three use cases are supported, and our users happy. What do you think – should Debian employ such methods, or not? If not, why not? Greetings, Joachim PS: The existence of i-want-some-prof-packages, which has no dependencies, ensures that installability in general is not impaired, so this scheme would have /no/ bad effect on the testing migration. -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Uscan enhancements revitalised (Was: let uscan exclude some upstream files)
On Thu, Dec 20, 2012 at 11:19:19PM +0100, Andreas Tille wrote: > As I see on your Wiki page you have described your proposal from your > last posting on the mailing list[3] which is actually in contrast to > what is implemented in [2] and was described and discussed in the thread > starting here[4]. I should most probably add the current implementation > to the Wiki page and I will do so in the next couple of days. But > before I'm starting to do so I would like to clarify why you used the > headline "Implementation" about the paragraph explaining what is not > implemented. That's a bit confusing but may be I missunderstood > something. Before I start mixing up things I'd like to hear your real > intention which I might have missed. > > Now for the current implementation: The stumbling block I was currently > facing is that I want to strip some upstream source (of igv[5]) from a > jar file which resides inside the packaging root as well as in a > subdirectory. It looks like > >IGVDistribution_2.1.30/goby-io-igv.jar (a) >IGVDistribution_2.1.30/lib/goby-io-igv.jar (b) > > The thing is that (a) should be removed and (b) needs to remain - but > this case is not possible with the current implementation. If > Files-Excluded contains a string without '/' a "find -name" search is > approached and catches them all. I remember this behaviour was > mentioned as a design flaw but the pro-argument is that you really > comfortably can use this when doing things like > >Files-Excluded: ._* *~ .DS_Store > > If you would need to specify each and any dir containing such cruft > files this would become a really lousy way which is not better than > keeping the old get-orig-source way. I should have documented the Files-Excluded field in the "Deleted file specification" section. The "Implementation" section was supposed to collect information for developers, but the name is quite inaccurate. Feel free to modify the page. However, I strongly disagree to interpret patterns differently depending on whether they contain a slash or not, while "find -path" alone handles your examples. for pattern in IGVDistribution_2.1.30/goby-io-igv.jar ._* */._* *~ .DS_Store */.DS_Store loop `find "$main_source_dir" -path "$main_source_dir/$_" -print0 | xargs -0 rm -rf`; end loop; The objection you've raised in https://lists.debian.org/debian-devel/2012/09/msg00202.html persists, but I consider that sparing a few patterns is not worth the added complexity. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121222110611.GA5759@pegase
Bug#696520: ITP: doris -- Delft object-oriented radar interferometric software
Package: wnpp Severity: wishlist Owner: Antonio Valentino * Package name: doris Version : 4.06 Upstream Author : Delft University of Technology * URL : http://doris.tudelft.nl * License : GPL Programming Lang: C++, Python, csh Description : Delft object-oriented radar interferometric software DORIS is an Interferometric Synthetic Aperture Radar (InSAR) processor developed by the Delft Institute of Earth Observation and Space Systems of Delft University of Technology. Interferometric products and endproducts such as Digital Elevation Models and displacement maps can be generated with this software from Single Look Complex data. Data from the satellites ERS, ENVISAT (first ENVISAT interferogram, DEM, and perspective view, JERS (first JERS interferogram), and RADARSAT (first RADARSAT interferogram) can be processed with the Doris software. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121222085546.6477.14258.report...@mac2.local.net
