Bug#1069906: marked as done (RFS: vzlogger/0.8.6-1 -- Fixes for the migration to testing)
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. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1069906: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069906 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- 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 * License : GPL-3.0-or-later * Vcs : https://github.com/volkszaehler/vzlogger/tree/debian Section : net The source builds the following binary packages: vzlogger - program for logging measurements of smart meters To access further information about this package, please visit the following URL: http://www.heute-morgen.de/debian/repo/unstable/main/source/net/ Alternatively, you can download the package with 'dget' using this command: dget -x http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.5-1.dsc Changes since the last upload: * Fixed logrotate conf user name * Fixed passing of hardening flags to cmake Regards, -- Joachim Zobel --- End Message --- --- Begin Message --- On Sat, May 18, 2024 at 05:06:57PM +0200, Joachim Zobel wrote: > 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 upstream outside of the debian directory. The orig.tar.gz must be identical with upstream's, IOW uscan must provide the same tarball. currently, it doesn't: uscan: ecaf73fa507e4c9e3367aa320717445ee02d5e57823d18f26393ac20528fdb96 vzlogger_0.8.6.orig.tar.gz your dsc: 029a9f3361531a5505dd2ad3dc3d0240f67d6d9c79ef65950923414784fe0a53 vzlogger_0.8.6.orig.tar.gz-from-dsc As the difference was only the debian directory (the uscan one has it, yours don't) , I'll uploading the package with the orig.tar produced by uscan. (Let me know if there are any questions on this) Thanks for your contribution to Debian! -- tobi--- End Message ---
Bug#1069906: RFS: vzlogger/0.8.6-1 -- Fixes for the migration to testing
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 upstream outside of the debian directory. To access further information about this package, please visit the following URL: http://www.heute-morgen.de/debian/repo/unstable/main/source/net/ Alternatively, you can download the package with 'dget' using this command: dget -x http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.6-1.dsc Sincerely, Joachim
Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
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 two 0.8.5s? Is it that upstream has moved and you consider 0.8.5-1 a 0.8.5? Sincerely, Joachim
Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
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 there are now two 0.8.5 in the world. Please avoid that. The watch file is not working: tobi@gondor:~/workspace/deb/mentors/JoachimZobel/vzlogger/debcheckout/vzlogger$ uscan --force-download uscan warn: In directory ., downloading https://github.com/volkszaehler/vzlogger/releases/download/v0.8.5/vzlogger-0.8.5.tar.gz failed: 404 Not Found uscan warn: No upstream tarball downloaded. No further processing with mk_origtargz ... (Tagging moreinfo because of the watchfile.) > Sincerely, > Joachim >
Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
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 > > (the entry "Fixed logrotate conf user name" is an upstream > change.) > > There are exceptions, like if it a very noteworthy change, but > this > > is one isn't in that category. > > - When packaging a new upstream version, you say so in the > changelog. > > (Like first changelog entry: > > * New upstream version. > > ) > > - There are undocumented changes, for example the change to the > > Standard-Version. > > > > Done. > > > A nitpick on d/rules: > > I'm a fan of declarative syntax, so I'd replace the dh_clean > override > > with specifing the file to be deleted in the file d/clean. (If you > feel > > different about this, it is ok to ignore my nitpicking) > > Done, thx. > > > Remarks on Readme.md: > > - It cointains only information not relevant when the user is > > installing the binary package (like how to build, how to install > and > > where to find the packages), so it should not be installed into > > the binary package. > > Not exactly. There is the important line "Our packages are built with > MQTT support, but without OMS support.". In addition it is a moving > target. So I'd prefer to keep it as now. This information would go into the long description of the package, (README.md is not available pre-install, and this is something the user wants to knowbeforehand; using README.md for this purpose is very unusal in Debian.) > > - "Debian" is written with a captial "D". > > Done. > > > - The sentence "Unfortunately Debian armhf packages do not > > run on Raspberry Pi 1 although the architecture on the RPi is > named armhf. > > Using Raspian armhf packages fixes that." is a bit hard to parse, > a > > bit off: > > - Raspberry Pi 1 is supported by the Debian armel architecture, > so people > > running (real) Debian on the Pi 1 need to use "armel" not > "armhf". > > - Paspian has been renamed to Raspberry Pi OS, so the naming > should > > maybe be also updated. > > Done. During the discussion more changes were added. > > > Maybe this should be separated into a Debian and Raspberry Pi OS > > section? (They are different distributions anyways…) > > The handling is very similar from the users perspective. > > > > > Some parts already mentioned for the previous upload, would be great > if > > you could start tackling them: > > > > As you are involved with upstream: > > The manpage, initfile, systemd service file should probably be > included in the > > upstream part, it is not only useful for Debian alone. > > > > It is currently under discussion if other installation methods are > still needed. I'd still say README.md shouldn't end up in the binary package, as it only covers installation topics, which are irrelevant to our users. > > Linitian: (I've pre-filtered them a bit already on those that should > be > > investigaged. If harderning is working now, override the linitian I: > tag.) > > I: vzlogger source: debian-rules-parses-dpkg-parsechangelog > [debian/rules:15] > > I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger] > > I: vzlogger: systemd-service-file-missing-documentation-key > [usr/lib/systemd/system/vzlogger.service] > > P: vzlogger source: trailing-whitespace [debian/changelog:10] > > P: vzlogger source: trailing-whitespace [debian/changelog:4] > > P: vzlogger source: trailing-whitespace [debian/control:17] > > P: vzlogger source: trailing-whitespace [debian/control:40] > > P: vzlogger source: trailing-whitespace [debian/rules:45] > > X: vzlogger: systemd-service-file-missing-hardening-features > [usr/lib/systemd/system/vzlogger.service] > > X: vzlogger source: upstream-metadata-file-is-missing > > All done except for upstream-metadata-file-is-missing. I don't think > this is of much use for a service. > > An updated 0.8.5-1 has been uploaded. > > Sincerely, > Joachim
Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
(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 exceptions, like if it a very noteworthy change, but this > is one isn't in that category. > - When packaging a new upstream version, you say so in the changelog. > (Like first changelog entry: > * New upstream version. > ) > - There are undocumented changes, for example the change to the > Standard-Version. > Done. > A nitpick on d/rules: > I'm a fan of declarative syntax, so I'd replace the dh_clean override > with specifing the file to be deleted in the file d/clean. (If you feel > different about this, it is ok to ignore my nitpicking) Done, thx. > Remarks on Readme.md: > - It cointains only information not relevant when the user is > installing the binary package (like how to build, how to install and > where to find the packages), so it should not be installed into > the binary package. Not exactly. There is the important line "Our packages are built with MQTT support, but without OMS support.". In addition it is a moving target. So I'd prefer to keep it as now. > - "Debian" is written with a captial "D". Done. > - The sentence "Unfortunately Debian armhf packages do not > run on Raspberry Pi 1 although the architecture on the RPi is named armhf. > Using Raspian armhf packages fixes that." is a bit hard to parse, a > bit off: > - Raspberry Pi 1 is supported by the Debian armel architecture, so people > running (real) Debian on the Pi 1 need to use "armel" not "armhf". > - Paspian has been renamed to Raspberry Pi OS, so the naming should > maybe be also updated. Done. During the discussion more changes were added. > Maybe this should be separated into a Debian and Raspberry Pi OS > section? (They are different distributions anyways…) The handling is very similar from the users perspective. > > Some parts already mentioned for the previous upload, would be great if > you could start tackling them: > > As you are involved with upstream: > The manpage, initfile, systemd service file should probably be included in the > upstream part, it is not only useful for Debian alone. > It is currently under discussion if other installation methods are still needed. > Linitian: (I've pre-filtered them a bit already on those that should be > investigaged. If harderning is working now, override the linitian I: tag.) > I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:15] > I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger] > I: vzlogger: systemd-service-file-missing-documentation-key [usr/lib/systemd/system/vzlogger.service] > P: vzlogger source: trailing-whitespace [debian/changelog:10] > P: vzlogger source: trailing-whitespace [debian/changelog:4] > P: vzlogger source: trailing-whitespace [debian/control:17] > P: vzlogger source: trailing-whitespace [debian/control:40] > P: vzlogger source: trailing-whitespace [debian/rules:45] > X: vzlogger: systemd-service-file-missing-hardening-features [usr/lib/systemd/system/vzlogger.service] > X: vzlogger source: upstream-metadata-file-is-missing All done except for upstream-metadata-file-is-missing. I don't think this is of much use for a service. An updated 0.8.5-1 has been uploaded. Sincerely, Joachim
Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
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 this is one isn't in that category. - When packaging a new upstream version, you say so in the changelog. (Like first changelog entry: * New upstream version. ) - There are undocumented changes, for example the change to the Standard-Version. A nitpick on d/rules: I'm a fan of declarative syntax, so I'd replace the dh_clean override with specifing the file to be deleted in the file d/clean. (If you feel different about this, it is ok to ignore my nitpicking) Remarks on Readme.md: - It cointains only information not relevant when the user is installing the binary package (like how to build, how to install and where to find the packages), so it should not be installed into the binary package. - "Debian" is written with a captial "D". - The sentence "Unfortunately Debian armhf packages do not run on Raspberry Pi 1 although the architecture on the RPi is named armhf. Using Raspian armhf packages fixes that." is a bit hard to parse, a bit off: - Raspberry Pi 1 is supported by the Debian armel architecture, so people running (real) Debian on the Pi 1 need to use "armel" not "armhf". - Paspian has been renamed to Raspberry Pi OS, so the naming should maybe be also updated. Maybe this should be separated into a Debian and Raspberry Pi OS section? (They are different distributions anyways…) Some parts already mentioned for the previous upload, would be great if you could start tackling them: As you are involved with upstream: The manpage, initfile, systemd service file should probably be included in the upstream part, it is not only useful for Debian alone. Linitian: (I've pre-filtered them a bit already on those that should be investigaged. If harderning is working now, override the linitian I: tag.) I: vzlogger source: debian-rules-parses-dpkg-parsechangelog [debian/rules:15] I: vzlogger: hardening-no-bindnow [usr/bin/vzlogger] I: vzlogger: systemd-service-file-missing-documentation-key [usr/lib/systemd/system/vzlogger.service] P: vzlogger source: trailing-whitespace [debian/changelog:10] P: vzlogger source: trailing-whitespace [debian/changelog:4] P: vzlogger source: trailing-whitespace [debian/control:17] P: vzlogger source: trailing-whitespace [debian/control:40] P: vzlogger source: trailing-whitespace [debian/rules:45] X: vzlogger: systemd-service-file-missing-hardening-features [usr/lib/systemd/system/vzlogger.service] X: vzlogger source: upstream-metadata-file-is-missing -- Cheers, tobi On Fri, Apr 26, 2024 at 10:37:26PM +0200, Joachim Zobel wrote: > 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 > * License : GPL-3.0-or-later > * Vcs : https://github.com/volkszaehler/vzlogger/tree/debian > Section : net > > The source builds the following binary packages: > > vzlogger - program for logging measurements of smart meters > > To access further information about this package, please visit the following > URL: > > http://www.heute-morgen.de/debian/repo/unstable/main/source/net/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.5-1.dsc > > Changes since the last upload: > > * Fixed logrotate conf user name > * Fixed passing of hardening flags to cmake > > Regards, > -- > Joachim Zobel > signature.asc Description: PGP signature
Bug#1069906: RFS: vzlogger/0.8.5-1 -- Fixes for the migration to testing
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 * License : GPL-3.0-or-later * Vcs : https://github.com/volkszaehler/vzlogger/tree/debian Section : net The source builds the following binary packages: vzlogger - program for logging measurements of smart meters To access further information about this package, please visit the following URL: http://www.heute-morgen.de/debian/repo/unstable/main/source/net/ Alternatively, you can download the package with 'dget' using this command: dget -x http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.5-1.dsc Changes since the last upload: * Fixed logrotate conf user name * Fixed passing of hardening flags to cmake Regards, -- Joachim Zobel
Re: Again question about migration to testing
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.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 unblocking migration of packages it blocked. > That worked. The autopkg test works again, and [0] shows that TL 2020 has migrated to testing. Thanks for help! Hilmar [0] https://tracker.debian.org/pkg/texlive-bin -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Re: Again question about migration to testing
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 below 5% so it's not a key package and can be autoremoved from testing. > 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.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 unblocking migration of packages it blocked. If that takes too long because of activity in the bugreport for example, contact the release team [1] and ask them for help getting texlive to migrate. [0] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html [1] https://wiki.debian.org/Teams/ReleaseTeam Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Again question about migration to testing
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 the Sphinx upload. The last successful autopkgtest was with version Sphinx v1.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? Thanks, Hilmar -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Re: migration to testing
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 supported by fuse-utils. Respectively, I amended the > > Architecture: line in the debian/control of my package. Then, my > > sponsor uploaded it to unstable. However, because there had been > > already a version of my package in testing (sucessfully built on > > kfreebsd-*) [as I wrote, it got there because originally my package > > did not have a dependency on fuse-utils, that was, strictly speaking, > > a bug on linux that I recently attempted to correct], I suspect that > > this upload would not be enough to let the new version of the package > > propagate into testing. Please correct me if I am wrong. If not, > > please let me know what to do in this situation. > > Dear Stanislav, > > you need to request the removal of the kfreebsd version in unstable. > > http://wiki.debian.org/ftpmaster_Removals Thank you Charles, this wiki page was quite informative. I will request a removal. -- Stanislav -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100414211223.ga24...@kaiba.homelan
Re: migration 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 the debian/control of my package. Then, my > sponsor uploaded it to unstable. However, because there had been > already a version of my package in testing (sucessfully built on > kfreebsd-*) [as I wrote, it got there because originally my package > did not have a dependency on fuse-utils, that was, strictly speaking, > a bug on linux that I recently attempted to correct], I suspect that > this upload would not be enough to let the new version of the package > propagate into testing. Please correct me if I am wrong. If not, > please let me know what to do in this situation. Dear Stanislav, you need to request the removal of the kfreebsd version in unstable. http://wiki.debian.org/ftpmaster_Removals Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100414093838.gb23...@kunpuu.plessy.org
Re: migration to testing
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 seamlessly in the past. > > That missing dependency was a bug on linux, because the operation of > convmvfs depends on preloading the fuse kernel module (the initscript > of fuse-utils does that) and on the avaliability of fusermount. > > > You might ask kfreebsd porters on debian-bsd list for details. > > I am CC-ing this to debian-...@lists.debian.org. 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 the debian/control of my package. Then, my sponsor uploaded it to unstable. However, because there had been already a version of my package in testing (sucessfully built on kfreebsd-*) [as I wrote, it got there because originally my package did not have a dependency on fuse-utils, that was, strictly speaking, a bug on linux that I recently attempted to correct], I suspect that this upload would not be enough to let the new version of the package propagate into testing. Please correct me if I am wrong. If not, please let me know what to do in this situation. Many thanks for any help! -- Stanislav -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100414083403.ga11...@kaiba.homelan
Re: migration 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 package builds on that architecture just fine, but > unfortunately I cannot test myself if it works there. Just install it yourself in virtualbox (slow, always works) or kvm (requires hardware support). I just lost several hours today trying, so here's a list of pitfalls: * You need to change the virtual network card. VirtualBox's default, "PCnet-FAST III (Am79C973)", is recognized by kfreebsd but doesn't see the network. "PCnet-PCI II (Am79C970A)" works fine. * You need a particular d-i build: http://d-i.debian.org/daily-images/kfreebsd-i386/20100221-11:20/monolithic/ (I assume -amd64 works too). Current d-i dailies are broken (the partitioner fails, even with a pre-partitioned disk, not letting you assign mount points). Don't use the sysinstall images either (they install but filesystem operations randomly fail). Rumours that d-i builds 20100306 or 20100223 are ok are untrue as well (won't even boot past the splash screen). -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100405230539.ga32...@angband.pl
Re: migration to testing
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. 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-(amd64|i386) since it's > > Linux-specific, see #528537: [snip] > Anyways, on kfreebsd, fusemount is provided by another package (fusebsd, > iirc), which means that except if the freebsd kernel allows the mount > syscall for users, all packages currently depending on fuse-utils should > now depend on fuse-utils | fusebsd. I could not find this fusebsd package in Debian :( However, a related project indeed exists [1]. 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 package builds on that architecture just fine, but unfortunately I cannot test myself if it works there. > This just sounds plain wrong, and IMHO, libfuse itself should do the > depend, though arguably, some libfuse rdepends don't need them. Well, if that would be possible I would simply prefer to add a dependence to my package and forget about it for a while. [1] http://fuse4bsd.creo.hu/ -- Stanislav -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100405210552.ga6...@kaiba.homelan
Re: migration to testing
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, since > > mount(2) is unfortunately a CAP_SYS_ADMIN syscall, and fusemount is > > suid root, allowing the fs to be mounted. > > If there are particular entry points into libfuse that cause it to > require fuse-utils, it seems to me you could express the dependency > conditionally via the .symbols file. Not that I've ever tried it, but > deb-symbols(5) indicates that this sort of flexibility is possible. Unfortunately, there is no symbol that could be used for this. fuse_mount() ends up first trying mount(2) and if that fails because of permissions, it then tries running fusemount. And most fuse filesystems don't even call fuse_mount directly, and rely on some other helper in the library to just do it for them. Now, looking at the code, it appears the bsd version doesn't even try to use mount(2), which means that in any case, all filesystems do need fusebsd on bsd systems. libfuse should really depend on it on bsd systems if that's not already the case. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100328072855.gb3...@glandium.org
Re: migration to testing
[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 is > suid root, allowing the fs to be mounted. If there are particular entry points into libfuse that cause it to require fuse-utils, it seems to me you could express the dependency conditionally via the .symbols file. Not that I've ever tried it, but deb-symbols(5) indicates that this sort of flexibility is possible. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327182129.gv18...@p12n.org
Re: migration to testing
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 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-(amd64|i386) since it's > Linux-specific, see #528537: > > | Please find below a patch to add GNU/kFreeBSD support to fuse. On this > | system, the kernel module and the utilities are provided in a separate > | source package called fuse4bsd. That's why the patch disable fuse-utils > | on non Linux systems. > > Given previous versions of fuse-convmvfs exist in testing, I guess the > package is meant to be usable on kfreebsd even without fuse-utils > available. That would mean fuse-utils is actually a recommend ? 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 seamlessly in the past. That missing dependency was a bug on linux, because the operation of convmvfs depends on preloading the fuse kernel module (the initscript of fuse-utils does that) and on the avaliability of fusermount. > You might ask kfreebsd porters on debian-bsd list for details. I am CC-ing this to debian-...@lists.debian.org. -- Stanislav -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327131918.gb30...@kaiba.homelan
Re: migration to testing
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 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-(amd64|i386) since it's > Linux-specific, see #528537: > > | Please find below a patch to add GNU/kFreeBSD support to fuse. On this > | system, the kernel module and the utilities are provided in a separate > | source package called fuse4bsd. That's why the patch disable fuse-utils > | on non Linux systems. > > Given previous versions of fuse-convmvfs exist in testing, I guess the > package is meant to be usable on kfreebsd even without fuse-utils > available. That would mean fuse-utils is actually a recommend ? > > You might ask kfreebsd porters on debian-bsd list for details. 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 is suid root, allowing the fs to be mounted. So, actually, the one that requires fuse-utils is not technically the end package, but libfuse itself. There are users of libfuse that don't (indirectly) require fusemount, such as zfs-fuse, since it is only intended to be run as root, as a daemon and thus can call mount(2) itself. Anyways, on kfreebsd, fusemount is provided by another package (fusebsd, iirc), which means that except if the freebsd kernel allows the mount syscall for users, all packages currently depending on fuse-utils should now depend on fuse-utils | fusebsd. This just sounds plain wrong, and IMHO, libfuse itself should do the depend, though arguably, some libfuse rdepends don't need them. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327123856.ga8...@glandium.org
Re: migration to testing
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 unsatisfiable Depends: fuse-utils > > What is the recommended way of solving this? fuse-utils is not build on kfreebsd-(amd64|i386) since it's Linux-specific, see #528537: | Please find below a patch to add GNU/kFreeBSD support to fuse. On this | system, the kernel module and the utilities are provided in a separate | source package called fuse4bsd. That's why the patch disable fuse-utils | on non Linux systems. Given previous versions of fuse-convmvfs exist in testing, I guess the package is meant to be usable on kfreebsd even without fuse-utils available. That would mean fuse-utils is actually a recommend ? You might ask kfreebsd porters on debian-bsd list for details. -- Simon Paillard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327120537.gc29...@dedibox.ebzao.info
migration to testing
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 this? -- Stanislav -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327111658.ga27...@kaiba.homelan
Re: gimp-print/cupsys migration to testing
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 | 1.1.19final-1 | unstable | source, alpha, arm, hppa, > > > i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > > This is spectacular news, but ... > > The following extra packages will be installed: > gs-esp libcupsimage2 libcupsys2 > The following packages will be REMOVED: > cupsys-driver-gimpprint foomatic-db-gimp-print ijsgimpprint > The following NEW packages will be installed: > libcupsimage2 > The following packages will be upgraded > cupsys gs-esp libcupsys2 > > Sigh :( can some magic be worked on these too? Looks like the gimp-print > stuff itself just needs a poke? No, all the packages apt-get wants to remove from your system are up to date in testing, so it can't be quite that simple. Can you get a more intelligent package management frontend to explain why those packages are to be removed? -- Colin Watson [EMAIL PROTECTED]
Re: gimp-print/cupsys migration to testing
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, mipsel, powerpc, s390, sparc This is spectacular news, but ... The following extra packages will be installed: gs-esp libcupsimage2 libcupsys2 The following packages will be REMOVED: cupsys-driver-gimpprint foomatic-db-gimp-print ijsgimpprint The following NEW packages will be installed: libcupsimage2 The following packages will be upgraded cupsys gs-esp libcupsys2 Sigh :( can some magic be worked on these too? Looks like the gimp-print stuff itself just needs a poke? Regards Josh -- New PGP public key: 0x27AFC3EE pgpVs4VvkUugn.pgp Description: PGP signature
Re: gimp-print/cupsys migration to testing
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 | 1.1.19final-1 | unstable | source, alpha, arm, hppa, i386, > > > ia64, m68k, mips, mipsel, powerpc, s390, sparc > > This is spectacular news, but ... > > The following extra packages will be installed: > gs-esp libcupsimage2 libcupsys2 > The following packages will be REMOVED: > cupsys-driver-gimpprint foomatic-db-gimp-print ijsgimpprint > The following NEW packages will be installed: > libcupsimage2 > The following packages will be upgraded > cupsys gs-esp libcupsys2 > > Sigh :( can some magic be worked on these too? Looks like the gimp-print > stuff itself just needs a poke? No, all the packages apt-get wants to remove from your system are up to date in testing, so it can't be quite that simple. Can you get a more intelligent package management frontend to explain why those packages are to be removed? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gimp-print/cupsys migration to testing
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, mipsel, powerpc, s390, sparc This is spectacular news, but ... The following extra packages will be installed: gs-esp libcupsimage2 libcupsys2 The following packages will be REMOVED: cupsys-driver-gimpprint foomatic-db-gimp-print ijsgimpprint The following NEW packages will be installed: libcupsimage2 The following packages will be upgraded cupsys gs-esp libcupsys2 Sigh :( can some magic be worked on these too? Looks like the gimp-print stuff itself just needs a poke? Regards Josh -- New PGP public key: 0x27AFC3EE pgp0.pgp Description: PGP signature
