Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "sblim-wbemcli"
Package name: sblim-wbemcli
Version : 1.6.2-4
Upstream Author : Tyrel Datwyler
URL :
http://sourceforge.net/apps/mediawiki/sblim/index.php?
Etienne Dysli-Metref writes:
> I would like to backport Shibboleth packages [1] to jessie and wheezy.
>
> - What branch name should I use?
> Documentation for git-buildpackage [2] says "debian/" so that
> would yield "debian/jessie-backports-sloppy", but I've seen
> "backports/" earlier so I'm un
Herbert Fortes writes:
> So I did a new Debian revision after the +dfsg.orig.tar.gz file be
> replaced.
>
> I just did a 'debdiff' to check the differences between the Debian
> revisions, and of course, the output is:
>
> dpkg-source: error: file webcamoid/webcamoid_7.2.0+dfsg.orig.tar.gz
> has s
Herbert Fortes writes:
>> You can work around this locally by rewriting your .changes files; the
>> changestool utility in the reprepro packages can help with that. But
>> you won't be able to upload different files with the same name. The
>> usual solution is adding a numeric part to the versi
Gianfranco Costamagna writes:
> the library has been renamed and conflicting with the non-v5 version, because
> of the libstdc++ transition.
>
> backporting to jessie and wheezy (where the transition didn't happen), means
> you have to revert that change, because otherwise the package will be
>
Gianfranco Costamagna writes:
> Hi Ferenc and Etienne,
>
>>> It'd probably make sense to start with a jessie backport, where
>>> this change is necessary, then branch off the wheezy backport from
>>> that, and do the PKG_INSTALLDIR change only.
>
> fully agree
> (do you mean, "the revert is neces
Sean Whitton writes:
> For example, support I'm packaging 0~git.abc123d. This version number
> might be used because I'm basing my packaging on upstream git commit
> whose hash is uniquely identified by the string 'abc123d'.
Such version numbers won't order correctly. Didn't you mean to includ
Hi,
I'd be more than happy to replace the custom recipes in my rules files
with your dh-text solution, it seems very neat. Just let me point out a
copy&paste mistake in the head of dh-text:
# dh_text --- debhelper to create system users
Please give it its own synopsis.
--
Thanks,
Feri
Paul Wise writes:
> On Wed, Aug 17, 2016 at 7:39 PM, Paul Wise wrote:
>
>> That sounds like the best option. I've pointed the dpkg maintainer at
>> your mail on IRC and asked for their thoughts on the matter.
>
> Guillem got enthusiastic about this and came up with this patch:
>
> https://www.had
In #832941 Sean Whitton writes:
> 6. config.guess, config.sub, configure, configure.in, Makefile.in and
> install-sh are not accounted for in d/copyright.
Hi,
The license and the copyright of these files is pretty much the same all
the time (some details can depend on the date). However, track
Etienne Dysli-Metref writes:
> Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the
> holidays, I'm now backporting it to jessie. So far there is nothing to
> change, however piuparts gives me the following error (which does not
> appear on stretch):
>
>> 0m34.6s ERROR: FAIL: Package
Etienne Dysli-Metref writes:
> On 19/01/17 23:46, Ferenc Wágner wrote:
>
>> I couldn't reproduce this on a real jessie system, only in a piuparts
>> chroot. I think the reason is that piuparts removes init-system-helpers
>> (the home of deb-systemd-helper) before th
Etienne Dysli-Metref writes:
> On 20/01/17 12:31, Ferenc Wágner wrote:
>
>> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html says:
>>
>> The postrm script is called after the package's files have been
>> removed or replaced. The packa
Dmitry Bogatov writes:
> During my work on bglibs, I discovered following:
>
> - new upstream release (2.03) include doxygen documentation into tarball
> - unlike previous packageed release (1.06) it contains minified JS file
> - Lintian warns about source package, containing prebuilt document
the various options for fixing it have been discussed on the
BTS, and this seems like the best solution for now.
Regards,
Ferenc Wágner
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Arch
Hi,
I'm packaging a program which wants to dlopen() some library. It finds
this library via pkg-config (PKG_CHECK_MODULES). How to best determine
the filename to use in the dlopen() call? It should work cross-distro,
for cross-compilation and whatnot. Is it always safe to use the SONAME
as the
Christian Seiler writes:
> Am 2017-11-13 13:23, schrieb wf...@niif.hu:
>
>> I'm packaging a program which wants to dlopen() some library. It finds
>> this library via pkg-config (PKG_CHECK_MODULES). How to best determine
>> the filename to use in the dlopen() call? It should work cross-distro,
Guillem Jover writes:
> On Mon, 2017-11-13 at 13:23:01 +0100, Ferenc Wágner wrote:
>
>> I'm packaging a program which wants to dlopen() some library. It finds
>> this library via pkg-config (PKG_CHECK_MODULES). How to best determine
>> the filename to use in the d
Wookey writes:
> Is there a suffix typically used for this situation of essentially
> 're-done upstream source'
Hi,
$ grep "Version.*real"
/var/lib/apt/lists/deb.debian.org_debian_dists_stretch_main_binary-amd64_Packages
reveals some other options like +real and (+)really, and I've seen .re
"Debian Bug Tracking System" writes:
> For the sake of others who upload a backport-relying-on-backports, the
> incantation is:
>
> sbuild --build-dep-resolver=aptitude -s -d stretch-backports -c
> stretch-amd64-sbuild wine_3.0-1~bpo9+1.dsc
You can leave out the -c option if you add
aliases=str
Dear Mentors,
When building packages in clean chroots many configure checks are
expected to fail not finding their dependencies. This is fine. Until
somebody tries to build the package in a not so clean chroot, where the
additional packages present satisfy some of these checks enabling extra
fea
Andrey Rahmatullin writes:
> gbp runs clean before the second build
Gbp runs clean before each build, but the default clean command was
changed to /bin/true in version 0.6.9. You can try
gbp buildpackage --git-cleaner="debuild -- clean"
or something similar.
--
Feri
Lumin writes:
> The problem is, if I maintain the two releases in parallel, the
> dch would become a mess when moving the 1.0 release to sid.
> dch will contain duplicated changelog entries (e.g. fixing
> common problems found in both 0.7 and 1.0) and the timeline
> is also screwed up.
Do you kn
Andreas Tille writes:
> I explicitly added "Build-Depends: libnewlib-dev" und thus there is
>
> find /usr/include -name ieeefp.h
> /usr/include/newlib/ieeefp.h
> /usr/include/newlib/machine/ieeefp.h
Use #include or pass -Inewlib to the compiler (I don't
know whether that's a good idea).
> I ha
Paul Wise writes:
> On Tue, Jan 15, 2019 at 7:06 PM wrote:
>
>> Could somebody please explain me the meaning of the "Checking
>> build-dependency (indep) on amd64" migration excuse as seen on
>> https://qa.debian.org/excuses.php?package=pacemaker?
>
> Looking at the code, I think it means that t
Raphaël Halimi writes:
> I'm trying to fully understand the git-buildpackage workflow and I'm
> kind of stuck on a specific part of the process, regarding the handling
> of the upstream branch when upstream uses git but the maintainer still
> wants to use pristine-tar to commit upstream tarballs.
26 matches
Mail list logo