Bug#1069906: marked as done (RFS: vzlogger/0.8.6-1 -- Fixes for the migration to testing)

2024-05-18 Thread Debian Bug Tracking System
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

Bug#1069906: RFS: vzlogger/0.8.6-1 -- Fixes for the migration to testing

2024-05-18 Thread Joachim Zobel
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 upstr

Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing

2024-05-14 Thread Joachim Zobel
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 tw

Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing

2024-05-14 Thread Tobias Frost
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

Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing

2024-05-14 Thread Tobias Frost
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 > > (th

Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing

2024-05-12 Thread Joachim Zobel
(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

Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing

2024-05-03 Thread Tobias Frost
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, but

Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing

2024-04-26 Thread Joachim Zobel
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 *

Re: Again question about migration to testing

2020-04-29 Thread Hilmar Preuße
Am 24.04.2020 um 06:21 teilte Sebastiaan Couwenberg mit: > On 4/24/20 12:01 AM, Hilmar Preuße wrote: Hi Sebastiaan, >> I'm quite sure, this regression is not caused by the TL upload, but by >> the Sphinx upload. The last successful autopkgtest was with version >> Sphinx v1.8.5, it fails since v2.

Re: Again question about migration to testing

2020-04-23 Thread Sebastiaan Couwenberg
On 4/24/20 12:01 AM, Hilmar Preuße wrote: > 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 ♻ It has a popcon

Again question about migration to testing

2020-04-23 Thread Hilmar Preuße
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 t

Re: migration to testing

2010-04-14 Thread Stanislav Maslovski
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

Re: migration to testing

2010-04-14 Thread Charles Plessy
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

Re: migration to testing

2010-04-14 Thread Stanislav Maslovski
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 sea

Re: migration to testing

2010-04-05 Thread Adam Borowski
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

Re: migration to testing

2010-04-05 Thread Stanislav Maslovski
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. T

Re: migration to testing

2010-03-28 Thread Mike Hommey
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 m

Re: migration to testing

2010-03-27 Thread Peter Samuelson
[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 fusemo

Re: migration to testing

2010-03-27 Thread Stanislav Maslovski
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/kfreebs

Re: migration to testing

2010-03-27 Thread Mike Hommey
Cc'ing to -devel, as it is a more general problem and I'd like to hear feedback from other fellow developers. 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

Re: migration to testing

2010-03-27 Thread Simon Paillard
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

migration to testing

2010-03-27 Thread Stanislav Maslovski
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

Re: gimp-print/cupsys migration to testing

2003-06-15 Thread Colin Watson
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 > > > cu

Re: gimp-print/cupsys migration to testing

2003-06-15 Thread Joshua Kwan
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, m

Re: gimp-print/cupsys migration to testing

2003-06-15 Thread Colin Watson
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 > > > cu

Re: gimp-print/cupsys migration to testing

2003-06-15 Thread Joshua Kwan
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, m