Re: Seeking Sponsors for my package - roadfighter

On Fri, Apr 08, 2016 at 09:45:35PM -0300, Carlos Donizete Froes wrote: > > > However, there's a wee little problem: > > > [~]$ roadfighter > > > Segmentation fault (core dumped) It looks like it _does_ work when ran from the build dir, fails otherwise. (Sorry for the delay, I was, uhm, making

Re: Seeking Sponsors for my package - roadfighter

> > However, there's a wee little problem: > > [~]$ roadfighter > > Segmentation fault (core dumped) > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x7707f02a in TTF_SizeUNICODE () from > > /usr/lib/x86_64-linux-gnu/libSDL_ttf-2.0.so.0 > > (gdb) bt > > #0

Re: Seeking Sponsors for my package - roadfighter

On Fri, Apr 08, 2016 at 08:44:24PM -0300, Carlos Donizete Froes wrote: > I'm looking for a sponsor my game package roadfighter [Road Fighter > Remake]. > > http://mentors.debian.net/package/roadfighter The packaging itself looks good. You might want to ask debian-l10n-english for a proofreading

Seeking Sponsors for my package - roadfighter

Hi, I'm looking for a sponsor my game package roadfighter [Road Fighter Remake]. http://mentors.debian.net/package/roadfighter The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/r/roadfighter/roadfighter_1.0.1269-1.dsc Awaiting reviews, tips, advice or approval

Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]

Hi, >I've filed a bug and submitted a patch for debian-cd and have>contacted the >maintainers of partman-btrfs links to the updated >package on mentors and to a github repo, because jcristau on >#debian-installer said he preferred pulling from a git repo. How long >should I wait before filing

Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]

Moreinfo removed, because Sledge on #debian-installer directed me to what I needed to patch in debian-cd. -- Nicholas

Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]

I've filed a bug and submitted a patch for debian-cd and have contacted the maintainers of partman-btrfs links to the updated package on mentors and to a github repo, because jcristau on #debian-installer said he preferred pulling from a git repo. How long should I wait before filing an RFS bug

mentors delete all the work after 2 month when people are full of work!

That its a problem for people that are doing a hard work: >> mentors packages that has a related ITP must be mantain event erased >> in the time! > Tell that to the debian devs who made the mentors website, I don't know why > the website deletes your package after 2 months. and that its a true: >

Bug#816192: RFS: proselint/0.3.5-1 [ITP] -- A prose linter

retitle 816192 RFS: proselint/0.3.5-1 [ITP] -- A prose linter tags 816192 - moreinfo retitle 816149 ITP: proselint -- Command-line prose linter utility thanks On 05/04/16 21:58, Gianfranco Costamagna wrote: > let me know if you are still interested. I am :). I intend to help upstream beat the

Any reason to keep libsdsl in experimental (Was: Please help creating shared *and* static library with cmake)

On Fri, Apr 08, 2016 at 06:16:51PM +0100, Sascha Steinbiss wrote: > For the record, I seem to remember there is already a libsdsl package in > experimental: > https://packages.qa.debian.org/libs/libsdsl.html Ahhh, very helpful hint!! Tomasz, is there any reason to have this package in

Bug#818184: RFS: hal-flash/0.3.3-1 [ITP]

Please restart ITP process and re-upload this with removal of overriding for pedantic tags. -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E signature.asc Description: PGP signature

Re: Please help creating shared *and* static library with cmake

On Fri, Apr 08, 2016 at 05:53:48PM +0200, Ole Streicher wrote: > Andreas Tille writes: > > I need to package libsdsl[1] as some precondition for a Debian Med > > package. The default cmake build only creates a static library and I > > found a patch to create a shared library.

Re: Please help creating shared *and* static library with cmake

On Fri, Apr 08, 2016 at 06:13:13PM +0200, Joachim Reichel wrote: > in the "cgal" package I basically build the package twice: > > override_dh_auto_configure-arch: > mkdir -p static > cd static && cmake .. -DBUILD_SHARED_LIBS=FALSE > mkdir -p shared > cd shared && cmake ..

Re: Please help creating shared *and* static library with cmake

For the record, I seem to remember there is already a libsdsl package in experimental: https://packages.qa.debian.org/libs/libsdsl.html Cheers Sascha On 8 April 2016 16:30:36 BST, Andreas Tille wrote: > Hi, > > I need to package libsdsl[1] as some precondition for a Debian

Re: Please help creating shared *and* static library with cmake

Hi, On 04/08/2016 05:30 PM, Andreas Tille wrote: > I need to package libsdsl[1] as some precondition for a Debian Med > package. The default cmake build only creates a static library and I > found a patch to create a shared library. But since library packages > should include both I wonder how

Re: Please help creating shared *and* static library with cmake

Andreas Tille writes: > I need to package libsdsl[1] as some precondition for a Debian Med > package. The default cmake build only creates a static library and I > found a patch to create a shared library. But since library packages > should include both I wonder how to get

Re: Please help creating shared *and* static library with cmake

Hi Andreas, In my past experience, I had been told that library packages should no longer ship static libraries. It makes your life easier to only build shared libraries. Regards, Kai-Chung Yan 2016-04-08 23:30 GMT+08:00 Andreas Tille : > Hi, > > I need to package libsdsl[1]

Please help creating shared *and* static library with cmake

Hi, I need to package libsdsl[1] as some precondition for a Debian Med package. The default cmake build only creates a static library and I found a patch to create a shared library. But since library packages should include both I wonder how to get both shared and static library without doing

Bug#820196: RFS: dante/1.4.1+dfsg-1 -- new upstream version, packaging updates

On Fri, Apr 08, 2016 at 03:59:16PM +0300, Peter Pentchev wrote: > control: tags -1 -moreinfo > > On Thu, Apr 07, 2016 at 03:46:24PM +0300, Peter Pentchev wrote: > > On Wed, Apr 06, 2016 at 05:33:28PM +0300, Peter Pentchev wrote: > > > On Wed, Apr 06, 2016 at 01:39:07PM +, Gianfranco

Bug#820196: RFS: dante/1.4.1+dfsg-1 -- new upstream version, packaging updates

control: tags -1 -moreinfo On Thu, Apr 07, 2016 at 03:46:24PM +0300, Peter Pentchev wrote: > On Wed, Apr 06, 2016 at 05:33:28PM +0300, Peter Pentchev wrote: > > On Wed, Apr 06, 2016 at 01:39:07PM +, Gianfranco Costamagna wrote: > > > control: owner -1 ! > > > control: tags -1 moreinfo > > >

Bug#819396: RFS: smpq/1.5-1 [ITP]

Hello, I'm still looking for a sponsor for package "smpq" and its dependences. Please look at bug 819396. Thanks! -- Pali Rohár pali.ro...@gmail.com

Bug#820407: marked as done (RFS: smartmontools/6.4+svn4214-1~bpo8+1)

Your message dated Fri, 8 Apr 2016 09:36:51 + (UTC) with message-id <622308044.2271024.1460108211062.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#820407: RFS: smartmontools/6.4+svn4214-1~bpo8+1 has caused the Debian Bug report #820407, regarding RFS:

Bug#814921: RFS: sphde/1.1.0-1 [ITP] -- sphde -- Shared Persistent Heap Data Environment library

Hi Jakub, > *.manpages are mostly useful for manual pages that weren't installed by > the upstream build system. (Perhaps the dh_installmanpages documentation > should be more clear about it...) > > If the upstream build system did install them, you should use *.install > files instead, where

Re: Git-buildpackage question: tracking upstream git and tarballs

Charles Plessy writes: > If you do this and intend to make your source package's repository easy to use > for collaborative maintenance, it will be good to document this workflow > somewhere (perhaps README.source ?) since it is not standard. Agreed. If getting a

Re: Git-buildpackage question: tracking upstream git and tarballs

Le Thu, Apr 07, 2016 at 03:25:08PM +0200, Raphaël Halimi a écrit : > > If I understand [1] and [2] correctly, one would need two upstream > branches : one originating from upstream, with the full commit history, > and one managed by gbp import-orig, which would contain upstream sources > imported

Re: fed (fedit) seeking a linux home

*Change GPG key* Current GPG key: 2048R/DE8473B0 Delete current key: GPG key: Please use the output of gpg ... On Thu, Apr 7, 2016 at 3:08 AM, Gianfranco Costamagna < locutusofb...@debian.org> wrote: > strange, I did look at ftp://mentors.debian.net/ and I didn't see them > (they disappear once