Your message dated Sat, 18 May 2024 18:40:20 +0200
with message-id
and subject line Re: Bug#1069906: RFS: vzlogger/0.8.6-1 -- Fixes for the
migration to testing
has caused the Debian Bug report #1069906,
regarding RFS: vzlogger/0.8.6-1 -- Fixes for the migration to testing
to be marked as done
Hi.
I have resolved this by doing a new upstream release as the base for
the Debian release. There was also a modified configuration in the
debian branch that was adapted for the Debian package. This is now a
quilt patch. If I understood you correctly the debian branch should not
differ from
Am Dienstag, dem 14.05.2024 um 13:35 +0200 schrieb Tobias Frost:
(forgotten cc, again, sorry)
> However, recycling upstream version numbers (as upstream) should be
> avoided, as there are now two 0.8.5 in the world. Please avoid that.
Where did I recycle upstream version numbers? Which are the
Control: tags -1 moreinfo
Hi Joachim,
On Sun, May 12, 2024 at 01:59:22PM +0200, Joachim Zobel wrote:
>
> An updated 0.8.5-1 has been uploaded.
It's nice that you've picked up my suggestions regarding the README.md…
However, recycling upstream version numbers (as upstream) should be
avoided, as
On Sun, May 12, 2024 at 01:59:22PM +0200, Joachim Zobel wrote:
> (forgotten cc)
>
> Am Freitag, dem 03.05.2024 um 18:50 +0200 schrieb Tobias Frost:
> > reviewing your new package:
> >
> > - d/changelog
> > - generally documents only changes to the packaging, not "upstream"
> changes
> >
(forgotten cc)
Am Freitag, dem 03.05.2024 um 18:50 +0200 schrieb Tobias Frost:
> reviewing your new package:
>
> - d/changelog
> - generally documents only changes to the packaging, not "upstream"
changes
> (the entry "Fixed logrotate conf user name" is an upstream
change.)
> There are
Control: tags -1 moreinfo
Hi Joachim,
reviewing your new package:
- d/changelog
- generally documents only changes to the packaging, not "upstream" changes
(the entry "Fixed logrotate conf user name" is an upstream change.)
There are exceptions, like if it a very noteworthy change,
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "vzlogger":
* Package name : vzlogger
Version : 0.8.5-1
Upstream contact : Joachim Zobel
* URL : http://wiki.volkszaehler.org/software/controller/vzlogger
1.8.5, it fails since v2.4.3. Is there anything I can do to
>> clarify the situation? Do I have to file a bug anywhere?
>
> Start by filing an RC bug against jupyter-sphinx-theme for the failing
> autopkgtest [0], testing autoremoval should help get it out of testing
> and unbl
anything I can do to
> clarify the situation? Do I have to file a bug anywhere?
Start by filing an RC bug against jupyter-sphinx-theme for the failing
autopkgtest [0], testing autoremoval should help get it out of testing
and unblocking migration of packages it blocked.
If that takes too long bec
Hi,
the TeX Live packages do not migrate to testing, although there is no RC
bug and they are old enough. The only reason I see is:
autopkgtest for jupyter-sphinx-theme/0.0.6+ds1-9: amd64: Regression ♻ ,
arm64: Regression ♻
I'm quite sure, this regression is not caused by the TL upload, but by
On Sat, Mar 27, 2010 at 04:19:18PM +0300, Stanislav Maslovski wrote:
The package builds on kfreebsd just fine, but I never tested if it
really works there. Actually, before the last upload the package did
not have any explicit dependency on fuse-utils, that is why it
migrated to testing
Le Wed, Apr 14, 2010 at 12:34:03PM +0400, Stanislav Maslovski a écrit :
Because nobody on kfreebsd list was interested, and I myself is not
interested in that architecture, I decided to limit the ARCHs by only
those supported by fuse-utils. Respectively, I amended the
Architecture: line in
On Wed, Apr 14, 2010 at 06:38:38PM +0900, Charles Plessy wrote:
Le Wed, Apr 14, 2010 at 12:34:03PM +0400, Stanislav Maslovski a écrit :
Because nobody on kfreebsd list was interested, and I myself is not
interested in that architecture, I decided to limit the ARCHs by only
those
On Sat, Mar 27, 2010 at 01:38:56PM +0100, Mike Hommey wrote:
On Sat, Mar 27, 2010 at 01:05:37PM +0100, Simon Paillard wrote:
On Sat, Mar 27, 2010 at 02:16:58PM +0300, Stanislav Maslovski wrote:
One of my packages, fuse-convmvfs (uploaded by a sponsor), cannot
migrate to testing
On Tue, Apr 06, 2010 at 01:05:52AM +0400, Stanislav Maslovski wrote:
As the original poster of that question on debian-mentors, I would
like to ask anyone who has access to a Debian/kFreeBSD installation to
test if fuse-convmvfs from sid works there (provided that fuse4bsd is
installed). My
On Sat, Mar 27, 2010 at 01:21:29PM -0500, Peter Samuelson wrote:
[Mike Hommey]
There is a general problem with fuse, actually. fuse-utils is needed by
any program using libfuse and allowing users (i.e not root) to mount a
filesystem: In this case, libfuse uses fusemount to do the mount,
Hi,
One of my packages, fuse-convmvfs (uploaded by a sponsor), cannot
migrate to testing. The migration is blocked by kfreebsd:
* fuse-convmvfs/kfreebsd-amd64 unsatisfiable Depends: fuse-utils
* fuse-convmvfs/kfreebsd-i386 unsatisfiable Depends: fuse-utils
What is the recommended way of solving
On Sat, Mar 27, 2010 at 02:16:58PM +0300, Stanislav Maslovski wrote:
One of my packages, fuse-convmvfs (uploaded by a sponsor), cannot
migrate to testing. The migration is blocked by kfreebsd:
* fuse-convmvfs/kfreebsd-amd64 unsatisfiable Depends: fuse-utils
* fuse-convmvfs/kfreebsd-i386
by a sponsor), cannot
migrate to testing. The migration is blocked by kfreebsd:
* fuse-convmvfs/kfreebsd-amd64 unsatisfiable Depends: fuse-utils
* fuse-convmvfs/kfreebsd-i386 unsatisfiable Depends: fuse-utils
What is the recommended way of solving this?
fuse-utils is not build on kfreebsd
On Sat, Mar 27, 2010 at 01:05:37PM +0100, Simon Paillard wrote:
On Sat, Mar 27, 2010 at 02:16:58PM +0300, Stanislav Maslovski wrote:
One of my packages, fuse-convmvfs (uploaded by a sponsor), cannot
migrate to testing. The migration is blocked by kfreebsd:
* fuse-convmvfs/kfreebsd-amd64
[Mike Hommey]
There is a general problem with fuse, actually. fuse-utils is needed by
any program using libfuse and allowing users (i.e not root) to mount a
filesystem: In this case, libfuse uses fusemount to do the mount, since
mount(2) is unfortunately a CAP_SYS_ADMIN syscall, and fusemount
On Sun, Jun 15, 2003 at 02:40:35PM +0200, Johannes Rohr wrote:
cupsys | 1.1.19final-1 | testing | source, alpha, arm, hppa, i386, ia64,
m68k, mips, mipsel, powerpc, s390, sparc
cupsys | 1.1.19final-1 | unstable | source, alpha, arm, hppa, i386, ia64,
m68k, mips,
On Sun, Jun 15, 2003 at 02:19:26PM -0700, Joshua Kwan wrote:
On Sun, Jun 15, 2003 at 02:40:35PM +0200, Johannes Rohr wrote:
Colin Watson wrote:
cupsys | 1.1.19final-1 | testing | source, alpha, arm, hppa, i386,
ia64, m68k, mips, mipsel, powerpc, s390, sparc
cupsys |
On Sun, Jun 15, 2003 at 02:40:35PM +0200, Johannes Rohr wrote:
cupsys | 1.1.19final-1 | testing | source, alpha, arm, hppa,
i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
cupsys | 1.1.19final-1 | unstable | source, alpha, arm, hppa,
i386, ia64, m68k, mips,
On Sun, Jun 15, 2003 at 02:19:26PM -0700, Joshua Kwan wrote:
On Sun, Jun 15, 2003 at 02:40:35PM +0200, Johannes Rohr wrote:
Colin Watson wrote:
cupsys | 1.1.19final-1 | testing | source, alpha, arm, hppa,
i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
cupsys |
26 matches
Mail list logo
