Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
On Fri, Aug 24, 2018 at 10:35 PM Theodore Y. Ts'o wrote: > > I've submitted version 1.11.0-1 of f2fs-tools; it's currently in the > NEW queue. > > The git tree for f2fs-tools is in Salsa: > > https://salsa.debian.org/debian/f2fs-tools > > The branches in the git tree are laid out to be DEP-14 compliant. The > master branch contains the debian packaging, and there is a gbp.conf > file in the debian directory. The f2fs-tools_1.11.0.orig.tar.gz was > generated using: > > git archive --format tar --prefix f2fs-tools-1.11.0/ v1.11.0 | \ > gzip -9n > f2fs-tools_1.11.0.orig.tar.gz > > and is stored using pristine-tar in the pristine-tar branch. > > The 1.11.0-1 f2fs-tools packages were build using git-buildpackage, > using the command "gbp buildpackage". I'm using sbuild as my builder > so I have in my ~/.gbp.conf: > > [buildpackage] > builder = sbuild -A -s -v -d unstable > export-dir = /tmp/gbp > purge = False > > [tag] > sign-tags = True > > And I have in my ~/.sbuildrc: > > $build_arch_all = 1; > $distribution = 'unstable'; > $source_only_changes = 1; > > I fixed quite a few packaging issues while I was at it: > > f2fs-tools (1.11.0-1) unstable; urgency=medium > > * New upstream release. (Closes: #904286) > - add sg_write_buffer for UFS firmware update in Android > - wanted_sector_size to specify sector size explicitly > - support fsverity feature bit > - support lost+found feature > * Install the library link files in /usr/lib where they belong > * Replace the libf2fs0 package with libf2fs5 and libf2fs-format4 > * Fixed missing libblkid dependency in the shared library > * Updated Standards compliance to 4.2.0 > * Added Theodore Ts'o as an uploader for the package > > -- Theodore Y. Ts'o Fri, 24 Aug 2018 03:32:49 -0400 Thank you again for taking the time to give f2fs-tools some much needed TLC! Regards, Vincent
Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
I've submitted version 1.11.0-1 of f2fs-tools; it's currently in the NEW queue. The git tree for f2fs-tools is in Salsa: https://salsa.debian.org/debian/f2fs-tools The branches in the git tree are laid out to be DEP-14 compliant. The master branch contains the debian packaging, and there is a gbp.conf file in the debian directory. The f2fs-tools_1.11.0.orig.tar.gz was generated using: git archive --format tar --prefix f2fs-tools-1.11.0/ v1.11.0 | \ gzip -9n > f2fs-tools_1.11.0.orig.tar.gz and is stored using pristine-tar in the pristine-tar branch. The 1.11.0-1 f2fs-tools packages were build using git-buildpackage, using the command "gbp buildpackage". I'm using sbuild as my builder so I have in my ~/.gbp.conf: [buildpackage] builder = sbuild -A -s -v -d unstable export-dir = /tmp/gbp purge = False [tag] sign-tags = True And I have in my ~/.sbuildrc: $build_arch_all = 1; $distribution = 'unstable'; $source_only_changes = 1; I fixed quite a few packaging issues while I was at it: f2fs-tools (1.11.0-1) unstable; urgency=medium * New upstream release. (Closes: #904286) - add sg_write_buffer for UFS firmware update in Android - wanted_sector_size to specify sector size explicitly - support fsverity feature bit - support lost+found feature * Install the library link files in /usr/lib where they belong * Replace the libf2fs0 package with libf2fs5 and libf2fs-format4 * Fixed missing libblkid dependency in the shared library * Updated Standards compliance to 4.2.0 * Added Theodore Ts'o as an uploader for the package -- Theodore Y. Ts'o Fri, 24 Aug 2018 03:32:49 -0400 Cheers, - Ted
Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
On Tue, Aug 21, 2018 at 6:32 PM, Vincent Cheng wrote: > On Tue, Aug 21, 2018 at 1:36 PM, Theodore Y. Ts'o wrote: >> On Tue, Aug 21, 2018 at 01:01:10PM -0700, Vincent Cheng wrote: >>> >>> I can't find a reference right now, but I seem to recall that one of >>> the Alioth admins pointed out that mailing lists specifically for >>> package/bug tracking purposes (i.e. not used for discussion) shouldn't >>> be migrated to lists.d.o. I don't know what other alternatives there >>> are, however. I haven't really kept up with the Alioth >>> migration/deprecation as you can probably tell. :) >> >> I thought there a difference between package-specific mailing lists >> and groups that maintain a large number of packages (e.g., python, X, >> etc.) But I could be wrong. I thought the lists.alioth.debian.org >> was only guaranteed to be around for a year, but we do have time to >> figure out what to do. > > It's certainly worth a try to see if the lists.d.o admins would allow > the creation of a filesystems-devel list. Do we need someone to > volunteer to be list admin for the new list? I did so when I requested > for the old alioth list to be migrated to alioth-lists.d.n, but that > was mostly to prevent RC bugs from kicking f2fs-tools out of testing, > and not because I particularly enjoy being a list admin. It looks like there's no need to nominate a specific person as list admin, so I went ahead and filed #906898 to request that debian-filesystems@l.d.o be created. If that falls through, maybe we could piggyback on debian-kernel or some other list? Regards, Vincent
Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
On Tue, Aug 21, 2018 at 1:36 PM, Theodore Y. Ts'o wrote: > On Tue, Aug 21, 2018 at 01:01:10PM -0700, Vincent Cheng wrote: >> >> I can't find a reference right now, but I seem to recall that one of >> the Alioth admins pointed out that mailing lists specifically for >> package/bug tracking purposes (i.e. not used for discussion) shouldn't >> be migrated to lists.d.o. I don't know what other alternatives there >> are, however. I haven't really kept up with the Alioth >> migration/deprecation as you can probably tell. :) > > I thought there a difference between package-specific mailing lists > and groups that maintain a large number of packages (e.g., python, X, > etc.) But I could be wrong. I thought the lists.alioth.debian.org > was only guaranteed to be around for a year, but we do have time to > figure out what to do. It's certainly worth a try to see if the lists.d.o admins would allow the creation of a filesystems-devel list. Do we need someone to volunteer to be list admin for the new list? I did so when I requested for the old alioth list to be migrated to alioth-lists.d.n, but that was mostly to prevent RC bugs from kicking f2fs-tools out of testing, and not because I particularly enjoy being a list admin. >> Well, the shared library being split into a separate package was >> intentional (#793863), but having never updated the package name is >> not (I must have overlooked this somehow...). I wonder how I never got >> any bug reports about this, because in theory that should mean that >> android-libf2fs-utils (src:android-platform-system-extras) is flat out >> broken (I never initiated any transitions or binNMU requests for >> android-platform-system-extras after f2fs-tools updates). > > I think the right thing to do is to create separate packages for > libf2fs and libf2fs_format. (And the separate -dev packages, of > course). They have different so version numbers, and so there is no > guarantee they will be both incremented in a particular release. I'll > work on that as part of the f2fs-tools 1.11 release. I initially used Policy 8.1 as an excuse to lump them both into the same binary package, but you're right, there is no guarantee that soversion will change for both at the same time. Thanks! Regards, Vincent
Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
On Tue, Aug 21, 2018 at 01:01:10PM -0700, Vincent Cheng wrote: > > I can't find a reference right now, but I seem to recall that one of > the Alioth admins pointed out that mailing lists specifically for > package/bug tracking purposes (i.e. not used for discussion) shouldn't > be migrated to lists.d.o. I don't know what other alternatives there > are, however. I haven't really kept up with the Alioth > migration/deprecation as you can probably tell. :) I thought there a difference between package-specific mailing lists and groups that maintain a large number of packages (e.g., python, X, etc.) But I could be wrong. I thought the lists.alioth.debian.org was only guaranteed to be around for a year, but we do have time to figure out what to do. > Well, the shared library being split into a separate package was > intentional (#793863), but having never updated the package name is > not (I must have overlooked this somehow...). I wonder how I never got > any bug reports about this, because in theory that should mean that > android-libf2fs-utils (src:android-platform-system-extras) is flat out > broken (I never initiated any transitions or binNMU requests for > android-platform-system-extras after f2fs-tools updates). I think the right thing to do is to create separate packages for libf2fs and libf2fs_format. (And the separate -dev packages, of course). They have different so version numbers, and so there is no guarantee they will be both incremented in a particular release. I'll work on that as part of the f2fs-tools 1.11 release. - Ted
Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
On Fri, Aug 17, 2018 at 1:09 PM, Theodore Y. Ts'o wrote: > OK, I've created a new project in Salsa for f2fs-tools: > > https://salsa.debian.org/debian/f2fs-tools > > and I've uploaded git repo with a work-in-progress for a f2fs-tools > v1.11.0 packaging. > > A couple of things which I've noted: > > 1) The maintainers is listed as: > > filesystems-de...@lists.alioth.debian.org > > I wonder if it's worth it to migrate the mailing list over to > lists.debian.org, and leave a forwarding pointer behind at the > lists.alioth.debian.org address? It will take a while to update all > of the various file system utility packages to use a non-Alioth > address, but I wonder if we should get started. Not high priority, so > we don't have to do this on this particular upload. I can't find a reference right now, but I seem to recall that one of the Alioth admins pointed out that mailing lists specifically for package/bug tracking purposes (i.e. not used for discussion) shouldn't be migrated to lists.d.o. I don't know what other alternatives there are, however. I haven't really kept up with the Alioth migration/deprecation as you can probably tell. :) > 2) In f2fs-tools 1.10.0-1, there is the shared libary package > libf2fs0, which contains the shared libaries: > > libf2fs.so.4.0.0 > libf2fs_format.so.3.0.0 > > In f2fs-tools 1.11.0 upstream, these have been bumped to: > > libf2fs.so.5.0.0 > libf2fs_format.so.4.0.0 > > I very much doubt any other packages are actually depending on > libf2fs0, but it seems wrong that we're using libf2fs0, as opposed to > say, libf2fs4 and now libf2fs5. > > Was this intentional, or just one of those things that had never been > noticed/fixed earlier? Well, the shared library being split into a separate package was intentional (#793863), but having never updated the package name is not (I must have overlooked this somehow...). I wonder how I never got any bug reports about this, because in theory that should mean that android-libf2fs-utils (src:android-platform-system-extras) is flat out broken (I never initiated any transitions or binNMU requests for android-platform-system-extras after f2fs-tools updates). Regards, Vincent
Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
OK, I've created a new project in Salsa for f2fs-tools: https://salsa.debian.org/debian/f2fs-tools and I've uploaded git repo with a work-in-progress for a f2fs-tools v1.11.0 packaging. A couple of things which I've noted: 1) The maintainers is listed as: filesystems-de...@lists.alioth.debian.org I wonder if it's worth it to migrate the mailing list over to lists.debian.org, and leave a forwarding pointer behind at the lists.alioth.debian.org address? It will take a while to update all of the various file system utility packages to use a non-Alioth address, but I wonder if we should get started. Not high priority, so we don't have to do this on this particular upload. 2) In f2fs-tools 1.10.0-1, there is the shared libary package libf2fs0, which contains the shared libaries: libf2fs.so.4.0.0 libf2fs_format.so.3.0.0 In f2fs-tools 1.11.0 upstream, these have been bumped to: libf2fs.so.5.0.0 libf2fs_format.so.4.0.0 I very much doubt any other packages are actually depending on libf2fs0, but it seems wrong that we're using libf2fs0, as opposed to say, libf2fs4 and now libf2fs5. Was this intentional, or just one of those things that had never been noticed/fixed earlier? Cheers, - Ted
Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
On Sun, Aug 12, 2018 at 9:31 AM, Theodore Y. Ts'o wrote:
> On Sun, Aug 12, 2018 at 02:19:29AM -0700, Vincent Cheng wrote:
>>
>> Sorry, I haven't had time lately to properly care for my packages.
>> Please go ahead with the NMU (bonus points if you have time to move
>> everything to salsa, extra bonus points if you're willing to
>> co-maintain the package too). Thanks!
>
> Was there a previous git repo for f2fs-tools on Alioth? I didn't base
> my last upload of f2fs to stretch-backports (just started with the
> tree from "apt-get source f2fs-tools"), but if you want me to move it
> to Salsa, it would probably be a good idea to preserve the git repo
> (if any) you were of the Debian packaging. Unfortunately I can't seem
> to find where the Alioth backups of the repos that were stored there
> can be found, and while I can try to ask for them, if you have a local
> git repo that you can push up to github or gitlab, that would be
> great.
There used to be a svn collab-maint repo on Alioth for f2fs-tools, but
unfortunately I didn't get a chance to migrate that to git before
Alioth was taken down. The f2fs-tools packaging isn't complex and the
svn history isn't particularly interesting, so it's probably not
worthwhile to grab the collab-maint svn dump and to try converting
that to git. Feel free to just start off the repo from scratch if
you'd like (if I had time I'd probably start off by importing the last
dozen or so snapshots with gbp, but I'm not picky about how the repo
is structured), or just skip it altogether.
> Otherwise I can just start a new git repo --- I already have
> f2fs-tools v1.11.0 already packaged up for {kvm,gce,android}-xfstests,
> and it was a desire to allow others to reproduce the VM image
> completely from sources and debian snapshots w/o having to manually
> compile f2fs-tools which is why I've been interested in keeping
> f2fs-tools updated in stable backports.
>
> So as far as co-maintenance, I'm happy to help, although I don't
> actually do much with f2fs myself (other as part of the kernel file
> systems regression testing).
Thanks! It's entirely up to you of course. I've just been asking the
same question to anyone at all who's shown interest in my packages so
I don't feel nearly as guilty about neglecting them as I otherwise
would. :)
Regards,
Vincent
Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
On Sun, Aug 12, 2018 at 02:19:29AM -0700, Vincent Cheng wrote:
>
> Sorry, I haven't had time lately to properly care for my packages.
> Please go ahead with the NMU (bonus points if you have time to move
> everything to salsa, extra bonus points if you're willing to
> co-maintain the package too). Thanks!
Was there a previous git repo for f2fs-tools on Alioth? I didn't base
my last upload of f2fs to stretch-backports (just started with the
tree from "apt-get source f2fs-tools"), but if you want me to move it
to Salsa, it would probably be a good idea to preserve the git repo
(if any) you were of the Debian packaging. Unfortunately I can't seem
to find where the Alioth backups of the repos that were stored there
can be found, and while I can try to ask for them, if you have a local
git repo that you can push up to github or gitlab, that would be
great.
Otherwise I can just start a new git repo --- I already have
f2fs-tools v1.11.0 already packaged up for {kvm,gce,android}-xfstests,
and it was a desire to allow others to reproduce the VM image
completely from sources and debian snapshots w/o having to manually
compile f2fs-tools which is why I've been interested in keeping
f2fs-tools updated in stable backports.
So as far as co-maintenance, I'm happy to help, although I don't
actually do much with f2fs myself (other as part of the kernel file
systems regression testing).
Cheers,
- Ted
Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
Hi Ted, On Sat, Aug 11, 2018 at 7:42 AM, Theodore Y. Ts'o wrote: > On Sun, Jul 22, 2018 at 01:49:17PM -0400, Theodore Y. Ts'o wrote: >> >> Please consider packaginging f2fs-tools 1.11.0 from upstream. This >> release includes: >> >> - add sg_write_buffer for UFS firmware update in Android >> - wanted_sector_size to specify sector size explicity >> - support fsverity feature bit >> - support lost+found feature >> - some critical bug fixes > > Hi Vincent, > > Do you think you will have time to update f2fs-tools to 1.11? If not, > would you be OK if I were to submit an NMU to update f2fs-tools? Sorry, I haven't had time lately to properly care for my packages. Please go ahead with the NMU (bonus points if you have time to move everything to salsa, extra bonus points if you're willing to co-maintain the package too). Thanks! Vincent
Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
On Sun, Jul 22, 2018 at 01:49:17PM -0400, Theodore Y. Ts'o wrote: > > Please consider packaginging f2fs-tools 1.11.0 from upstream. This > release includes: > > - add sg_write_buffer for UFS firmware update in Android > - wanted_sector_size to specify sector size explicity > - support fsverity feature bit > - support lost+found feature > - some critical bug fixes Hi Vincent, Do you think you will have time to update f2fs-tools to 1.11? If not, would you be OK if I were to submit an NMU to update f2fs-tools? Many thanks!! - Ted
Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0
Package: f2fs-tools Version: 1.10.0-1 Severity: normal Dear Maintainer, Please consider packaginging f2fs-tools 1.11.0 from upstream. This release includes: - add sg_write_buffer for UFS firmware update in Android - wanted_sector_size to specify sector size explicity - support fsverity feature bit - support lost+found feature - some critical bug fixes -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-rc2-00147-ga1bc5014edfd (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages f2fs-tools depends on: ii libc62.27-5 ii libf2fs0 1.10.0-1 ii libselinux1 2.8-1+b1 ii libuuid1 2.32-0.1 f2fs-tools recommends no packages. f2fs-tools suggests no packages. -- no debconf information
