packaging haskell application
Hi, I just tried to package a haskell application. I must say I have no experience with haskell whatsoever. All the guidance I found is for libraries: https://wiki.debian.org/Haskell/CollabMaint/PackageTemplate https://wiki.haskell.org/Creating_Debian_packages_from_Cabal_package Trying to adapt it to an application, resulted in an almost empty package: https://mentors.debian.net/package/haskell-tttool Can anybody point me in the right direction to have it filled? Rgds Richard -- 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/1427403496.22218.4.ca...@gmail.com
Bug#763853: RFS: python-trezor/0.5.3-1 ITP#763376 Python library for communicating with TREZOR Bitcoin Hardware wallet
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "trezor" Package name: python-trezor Version : 0.5.3-1 Upstream Author : Pavol Rusnak URL : https://github.com/trezor/python-trezor License : public domain Section : python It builds those binary packages: python-trezor - Python library for communicating with TREZOR Bitcoin Hardware wallet To access further information about this package, please visit the following URL: http://mentors.debian.net/package/trezor Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/trezor/trezor_0.5.3-1.dsc More information about hello can be obtained from http://www.bitcointrezor.com/. It would be best if you could also review the two packages it depends on in the same go: * http://mentors.debian.net/package/hidapi * http://mentors.debian.net/package/mnemonic I have some questions: * The name for the binary package is clear to me: python-trezor, but I'm not so certain about the correct name for the source package. It's called python-trezor on github, but only trezor on pypi, where the release tarball is from. * Is there a better way to install the udev rule? * There is a binary deb package from https://mytrezor.com that installs the same udev rule. Should I choose another name to avoid conflicts? Regards, Richard Ulrich signature.asc Description: This is a digitally signed message part
install files for python packages
Do install files work differently for packages that involve python_distutils? When I package C++ stuff, I used install or packagename.install files to suppress certain files, to add certain files to specific locations or to split files among packages. But as soon as I introduce an install file to a python lib package that I started with py2dsc, I start getting error messages. Rgds Richard signature.asc Description: This is a digitally signed message part
Re: Bug#750644: RFS: bitcoin-armory/0.91.1-1 [ITP]
Hi Joseph, this is great news. I wanted to use armory for quite some time, but since it was missing in the repo, and I couldn't find it in any ppa neither, I hesitated. Could you also make sure it lands in debian packports and a launchpad ppa? That would be great. Rgds Richard Am Donnerstag, den 05.06.2014, 07:17 -0400 schrieb Joseph Bisch: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "bitcoin-armory" > > * Package name: bitcoin-armory > Version : 0.91.1-1 > Upstream Author : Armory Technologies, Inc. > * URL : https://bitcoinarmory.com/ > * License : AGPL3 > Section : net > > It builds those binary packages: > > bitcoin-armory - Advanced Bitcoin Wallet Management Software > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/bitcoin-armory > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/b/bitcoin-armory/bitcoin-armory_0.91.1-1.dsc > > More information about Armory can be obtained from https://bitcoinarmory.com/. > > > Regards, > Joseph Bisch > > signature.asc Description: This is a digitally signed message part
Re: building debug and release with new style debhelper
Am Freitag, den 05.04.2013, 14:26 +0600 schrieb Andrey Rahmatullin: > On Thu, Apr 04, 2013 at 11:31:43PM +0200, Richard Ulrich wrote: > > > > > > I'm even considering to make the librichbool-dev package depend on > > > > > > the > > > > > > librichbool-dbg package. > > > > > Note that -dbg packages usually contain only detached debug symbols, > > > > > and > > > > > you seem to build two separate libraries with the same soname but > > > > > different compilation options and package them into libfoo and > > > > > libfoo-dbg, > > > > > is that true? > > > > Ok, then I pack the debug lib into the dev package. > > > So there are two shared libs with different sonames? > > Exactly. > Then you need two library packages as usual. Ah, ok. Now I have: librichbool-dev librichbool1 librichboold1 In the meantime, I also uploaded the corresponding project: https://mentors.debian.net/package/modassert Rgds Richard -- 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/1365200432.12960.4.camel@quadulrich
Re: building debug and release with new style debhelper
Am Donnerstag, den 04.04.2013, 06:42 +0600 schrieb Andrey Rahmatullin: > > > > I'm even considering to make the librichbool-dev package depend on the > > > > librichbool-dbg package. > > > Note that -dbg packages usually contain only detached debug symbols, and > > > you seem to build two separate libraries with the same soname but > > > different compilation options and package them into libfoo and libfoo-dbg, > > > is that true? > > Ok, then I pack the debug lib into the dev package. > So there are two shared libs with different sonames? > Exactly. I worked through the lintian warnings, and uploaded the package. https://mentors.debian.net/package/richbool Would be nice, if you had a look, or even sponsored it. BTW: is is not terribly useful by itself, but is closely related to modassert: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704710 Rgds Richard -- 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/136503.24048.9.camel@quadulrich
Re: building debug and release with new style debhelper
Am Mittwoch, den 03.04.2013, 15:38 +0600 schrieb Andrey Rahmatullin: > > > > The problem I'm facin is that I don't know how to handle the fact > > > > that I want to build debug and release with cmake. > > > > > > I think you should instead drop the debug build, those aren't shipped > > > in Debian usually. > > > > That's not really what I want. The packages I'm building (richbool and > > modassert) are mainly concerned with providing information about failed > > asserts in debug code. So the debug builds are actually more important > > than the release ones. > Are release builds still necessary then? I would say so. If an application is built in debug, it links the debug libs, and gets all the verbose output. If an application is built in release, it links the release build, which still can have some reporting, but reduced. > > I'm even considering to make the librichbool-dev package depend on the > > librichbool-dbg package. > Note that -dbg packages usually contain only detached debug symbols, and > you seem to build two separate libraries with the same soname but > different compilation options and package them into libfoo and libfoo-dbg, > is that true? Ok, then I pack the debug lib into the dev package. Rgds Richard -- 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/1365027424.8940.6.camel@quadulrich
Re: building debug and release with new style debhelper
Am Mittwoch, den 03.04.2013, 09:33 +0800 schrieb Paul Wise: > > > That's not really what I want. The packages I'm building (richbool and > > modassert) are mainly concerned with providing information about failed > > asserts in debug code. So the debug builds are actually more important > > than the release ones. > > I'm even considering to make the librichbool-dev package depend on the > > librichbool-dbg package. > > H. > > > I started mixing in the overrides like below (not working yet). > > Am I on the right path with that? > > How about this (untested): > > %: > dh $@ --buildsystem cmake --builddirectory=build-debian-release > dh $@ --buildsystem cmake --builddirectory=build-debian-debug > > override_dh_auto_configure: > dh_auto_configure --builddirectory=build-debian-release -- > -DCMAKE_BUILD_TYPE:STRING=Release > dh_auto_configure --builddirectory=build-debian-debug -- > -DCMAKE_BUILD_TYPE:STRING=Debug I had to add some more overrides, but that got me on the right direction. It looks now a lot cleaner than what I tried previously. Thanks Richard -- 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/1365027211.8940.2.camel@quadulrich
Re: building debug and release with new style debhelper
Am Montag, den 01.04.2013, 20:46 +0800 schrieb Paul Wise: > > The problem I'm facin is that I don't know how to handle the fact > > that I want to build debug and release with cmake. > > I think you should instead drop the debug build, those aren't shipped > in Debian usually. That's not really what I want. The packages I'm building (richbool and modassert) are mainly concerned with providing information about failed asserts in debug code. So the debug builds are actually more important than the release ones. I'm even considering to make the librichbool-dev package depend on the librichbool-dbg package. I started mixing in the overrides like below (not working yet). Am I on the right path with that? %: dh $@ --buildsystem cmake --builddirectory=build-debian-release override_dh_auto_clean : dh_auto_clean rm -rf $(CURDIR)/build-debian-release rm -rf $(CURDIR)/build-debian-debug rm -rf $(CURDIR)/debian/richbooltmp override_dh_auto_configure : mkdir -p $(CURDIR)/build-debian-release (cd $(CURDIR)/build-debian-release; cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=1 -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_SKIP_RPATH:BOOL=1 ..) mkdir -p $(CURDIR)/build-debian-debug (cd $(CURDIR)/build-debian-debug; cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=1 -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_SKIP_RPATH:BOOL=1 ..) override_dh_auto_build : (cd $(CURDIR)/build-debian-release; $(MAKE) ) (cd $(CURDIR)/build-debian-debug; $(MAKE) ) override_dh_auto_install : (cd $(CURDIR)/build-debian-release; $(MAKE) install DESTDIR= $(CURDIR)/debian/richbooltmp/ ) (cd $(CURDIR)/build-debian-debug; $(MAKE) install DESTDIR= $(CURDIR)/debian/richbooltmp/ ) dh_install --sourcedir=debian/richbooltmp/ Rgds Richard -- 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/1364921563.8556.8.camel@quadulrich
building debug and release with new style debhelper
Hi gurus, I'm trying to convert an old style debhelper rules file to the new style. The problem I'm facin is that I don't know how to handle the fact that I want to build debug and release with cmake. Here are some relevant parts of the old rules file: build-stamp: configure-stamp dh_testdir mkdir -p $(CURDIR)/build-debian-release (cd $(CURDIR)/build-debian-release; cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_BUILD_TYPE:STRING=Release ..) mkdir -p $(CURDIR)/build-debian-debug (cd $(CURDIR)/build-debian-debug; cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_BUILD_TYPE:STRING=Debug ..) (cd $(CURDIR)/build-debian-release; $(MAKE) ) (cd $(CURDIR)/build-debian-debug; $(MAKE) ) But how does that fit into the new scheme?: %: dh $@ --buildsystem cmake --builddirectory=build override_dh_auto_configure : dh_auto_configure -- -DCMAKE_INSTALL_PREFIX=/usr Rgds Richard -- 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/1364591758.8637.6.camel@quadulrich
Loading kernel modules
Hi mentors, I'm in the process of writing and packaging a small application that communicates over gpio pins on the i2c protocol with another device. Now the following page shows what to do during testing. http://blog.famzah.net/2009/12/05/i2c-via-gpio-on-bifferboard-running-debian/ It works during testing, but after the next reboor, I have to execute all the modprobes again. So this page describes what to do, so that the modules are loaded on every boot. http://kernel-handbook.alioth.debian.org/ch-modules.html But these instructions don't seem to be well suited for inclusion in a deb package, as it involves editing files already on the system. I would much prefer an approach such as used with cron. Where one can put a packagename.cron.d file into the debian folder. Also http://man.he.net/man1/dh_installmodules talks about installing modues that belong to the package. But the modules that I want to load don't belong to my package. They beolng to packages that my packages depends on. So, what is the correct way to make a package load modules from another package? Rgds Richard signature.asc Description: This is a digitally signed message part
/usr/lib64 or /usr/lib
Hi Mentors, I want to package a library which hast the following lines in CMakeLists.txt IF(CMAKE_SIZEOF_VOID_P EQUAL 8) SET(LIBDIR lib64) ELSE (CMAKE_SIZEOF_VOID_P EQUAL 8) SET(LIBDIR lib) ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 8) now, how do I have to handle this in debian/libxyz.install? Rgds Richard -- 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/1307645250.5436.3.camel@quadulrich
Re: nested ifeq in debian/rules (makefile)
Hi Joachim, dpk-vendor checks the contents of /etc/dpkg/origins/default. Both are missing on lenny. Trying to call (the missing) dpk-vendor on lenny results in an error. That's the reason I'm checking for file existence. Rgds Richard signature.asc Description: This is a digitally signed message part
Re: nested ifeq in debian/rules (makefile)
Hi Jakub, I played around with the spaces a lot. The result was always the same. ifeq ($(shell[-e /etc/dpkg/origins/default];printf $$?),0) ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes) Rgds Richard -- 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/1299108560.5190.37.camel@quadulrich
nested ifeq in debian/rules (makefile)
Hi, I'm new to debian mentors. A while ago I read a blog article about how to use only one branch for debian and ubuntu packages with different dependencies. http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/ I tried to implement it, but I'm struggling. Essentially, I'm not familiar with makefile syntax, and searching makefile tutorials and asking in IRC chats helped, but couldn't fully solve the problems I faced. So, I hope the experts here can help find a good solution. Here is what I have so far: http://flightpred.svn.sourceforge.net/viewvc/flightpred/trunk/debian/rules?revision=297 But it basically boils down to the following behavior, which I don't understand: $ cat makefile all: @echo $(shell [ -e /etc/dpkg/origins/default ]; printf $$?) @echo $(shell [ -e /etc/dpkg/origins/dabadabadu ]; printf $$?) @echo $(shell [ ! -e /etc/dpkg/origins/default ]; printf $$?) @echo $(shell [ ! -e /etc/dpkg/origins/dabadabadu ]; printf $$?) ifeq ( $(shell [ -e /etc/dpkg/origins/default ]; printf $$?), 0) ifeq ( $(shell dpkg-vendor --derives-from Ubuntu && echo yes), yes) @echo "ubuntu maverick" else @echo "debian squeeze" endif else @echo "debian lenny" endif $ make 0 1 1 0 debian lenny -- 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/1299100390.5190.10.camel@quadulrich
