Hello,
I guess ITP bugs are common practice for new packages... but are they
*required* by anything? It seems like fairly high-friction, low-value work -
especially if you're talking about more than a single package. So I'd like to
avoid it, but I'm not sure what the costs would be.
Thanks,
Package: sponsorship-requests
Severity: important
X-Debbugs-Cc: rvandegr...@debian.org
Dear mentors,
I am looking for a sponsor for the package "connman":
* Package name: connman
Version : 1.36-2.2
Upstream Author : Marcel Holtmann
* URL :
* License :
Hello,
Does anyone have any advice or examples of using cme to manage
d/copyright on packages that contain binary artifacts? They usually end
up with garbage in the Copyright field.
I can ignore by paths/suffix in copyright-scan-patterns.yml, but then
cme thinks that they aren't in the archive
Hello,
Many shared library packages ship a single shared library. The policy manual
explains and encourages this pattern. But when many libraries are built from
the same source, it can get tedious and error-prone.
Are there things I should look out for if I try to combine many shared library
On Mon, Aug 12, 2019 at 06:17:02AM +0800, Paul Wise wrote:
> On Mon, Aug 12, 2019 at 3:18 AM Ross Vandegrift wrote:
> > Make it easier for users/devs to get backtraces for EFL apps. Automatic
> > dbgsym
> > results in 49 dbgsym packages from src:efl. Getting all of t
On Sun, Aug 11, 2019 at 07:46:06PM +0200, Sven Joachim wrote:
> On 2019-08-11 09:31 -0700, Ross Vandegrift wrote:
> > I'd like a metapackage that'd pull in all automatic dbgsyms from one source
> > package. But I don't see any way to accomplish this. Is this possible?
>
&
Hello,
I'd like a metapackage that'd pull in all automatic dbgsyms from one source
package. But I don't see any way to accomplish this. Is this possible?
Thanks,
Ross
Hi Ben - thanks fo the thorough explanation, much appreciated!
On Tue, Oct 17, 2017 at 09:23:57AM +1100, Ben Finney wrote:
> So now that we agree it's not too clear, and may be difficult to find, I
> would welcome a bug report against Policy for clarifying this issue.
>
> As someone who went
On Mon, Oct 16, 2017 at 11:54:20AM +1100, Ben Finney wrote:
> Ross Vandegrift <r...@kallisti.us> writes:
> > Good question. I guess I think of a changelog as history - so changes
> > I made on 1.15 go with 1.15 whether it was released or not.
>
> Thanks for
On Sun, Oct 15, 2017 at 12:14:59AM +0200, Mattia Rizzolo wrote:
> > Thanks for the hint. dpkg-genchanges(1) says -c requires a version. Is
> ^
> I'll assume this is a typo and you meant -v
whoops yes!
> > there a
On Sat, Oct 14, 2017 at 11:53:25PM +0500, Andrey Rahmatullin wrote:
> It's not BTS, it's dpkg-genchanges. Pass a proper -v to the command you
> use to build the package.
Thanks for the hint. dpkg-genchanges(1) says -c requires a version. Is
there a downside to always starting from the first
Hi all,
My changelog [1] documents versions that weren't released. I like
including that info (it's been useful for me). But the BTS doesn't pick
up on Closes from those - even though later versions have been uploaded.
Is there a way to make the BTS notice these entries - or do I need to
Hello,
#858563 reports that debian/rules cannot be invoked directly on efl.
The suggested fix is to add "include /usr/share/dpkg/default.mk".
That doesn't work, I'm struggling to understand why:
$ gbp buildpackage --git-builder=sbuild --git-arch=amd64
--git-dist=experimental --git-ignore-new
On Wed, Jan 11, 2017 at 05:09:10PM +0100, Mattia Rizzolo wrote:
> terminology doesn't seem to be affected by any RC bug. What are you
> talking about?
Oh you're right, I messed up - I thought 848370 was severity serious,
but it's only important.
Thanks,
Ross
signature.asc
Description: PGP
terminology was affected by the RC bugs flooding issue mentioned in the
recent email on the Strech freeze status. In [1], it says to upload the
old version. I'm not clear on what I need to do - should I open
an RFS with the old version from snapshot.d.o?
Thanks,
Ross
[1]:
On Sat, Nov 26, 2016 at 02:30:59AM +0100, Christian Seiler wrote:
> > 2) Is there a common pattern for handling upstream tests that break this
> > rule? Maybe there's an alternative to disabling them?
>
> If upstream tests do that, I would suggest sending a patch
> upstream that fixes them,
On 11/11/2016 0826:45 AM, Christian Seiler wrote:
> pbuilder sets the home directory of the pbuilder user to /nonexistent
> to make sure that builds don't modify files in the home directory,
> which is forbidden by Debian Policy (for good reason builds are not
> supposed to change things outside
On Mon, Nov 21, 2016 at 05:46:24PM -0500, Ross Vandegrift wrote:
> So I'll prepare another version that consists only of the security fix
> backported to jessie. The new version will wait for experimental.
Here it is, this time just adopting and fixing the security issue:
On Mon, Nov 21, 2016 at 04:53:58PM +0100, Adam Borowski wrote:
> Cool, please move "New maintainer" to the front so it's better visible.
>
> Alas, I'm afraid it doesn't quite work for me. In the first run, after
> maximizing it stopped redrawing its window and had to be killed (doesn't
> seem to
ngelog:
[ Ross Vandegrift ]
* New upstream release
- Fix for "CVE-2015-8971: Escape Sequence Command Execution
vulnerability" (Closes: #843434)
* fix-minus-signs-manpage.patch: drop patch, fixed upstream
* use-system-lz4.patch: defuzz
* fix-del-backspace-key.patch: defuzz
* Pr
On Fri, Nov 18, 2016 at 05:04:02PM +, Gianfranco Costamagna wrote:
> > [ Ross Vandegrift ]
>
> > * Non-maintainer upload.
>
> Hi Ross, can you please fix and answer if you want to maintain or not
> the package?
Sorry for the slow response - I'm planning to fix
:
https://mentors.debian.net/package/terminology
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/t/terminology/terminology_0.9.1-0.1.dsc
Changes since the last upload:
[ Ross Vandegrift ]
* Non-maintai
On 09/12/2016 10:21 PM, Paul Wise wrote:
On Mon, Sep 12, 2016 at 1:35 AM, Ross Vandegrift wrote:
https://mentors.debian.net/debian/pool/main/e/e17/e17_0.21.2-1.dsc
I'd suggest renaming the source and binary packages to
'enlightenment', e17 was never the right choice of name.
I agree
On 09/12/2016 05:49 AM, Gianfranco Costamagna wrote:
I won't test/review, unless you want it to be uploaded in Debian
(with an RFS bug), sorry!
That's cool - thanks for taking a look at my questions.
2) The previous maintainer hasn't been active, so my work is not in the
alioth pkg-e-devel
Hello,
If anyone has time and interest, I'm looking for more feedback on
Enlightenment 0.21 and EFL 1.18 packages that are uploaded to mentors:
https://mentors.debian.net/debian/pool/main/e/efl/efl_1.18.0-1.dsc
https://mentors.debian.net/debian/pool/main/e/e17/e17_0.21.2-1.dsc
Some particular
dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/e/e17/e17_0.17.6-1.1.dsc
Changes since the last upload:
* debian/rules: override dh_fixperms only for arch-dependent packages.
Thanks to Santiago Vila. (Closes: #806019)
Regards,
Ross Vandegrift
On 03/21/2016 09:43 PM, Sean Whitton wrote:
> When there's a new release, I fetch upstraem's tags and then run
> something like `git merge 1.1.1 && dch -v1.1.1`. In the case you
> describe where 1.1.1 cannot be cleanly merged with 1.0.2, I would just
> run `git merge --strategy recursive
Hello all,
I've been working on packages using git-buildpackage, and have been
wondering if there's a better pattern out there.
Upstream makes periodic releases, which often receive a few maintenance
updates. For upstream, often looks like this:
o---ooooo
28 matches
Mail list logo
