Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Theodore Y. Ts'o
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  libc6        2.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

Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Theodore Y. Ts'o
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

Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Vincent Cheng-2
Hi Ted,

On Sat, Aug 11, 2018 at 7:42 AM, Theodore Y. Ts'o <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Theodore Y. Ts'o
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

Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Vincent Cheng-2
On Sun, Aug 12, 2018 at 9:31 AM, Theodore Y. Ts'o <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Theodore Y. Ts'o
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:

        [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Vincent Cheng-2
On Fri, Aug 17, 2018 at 1:09 PM, Theodore Y. Ts'o <[hidden email]> 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:
>
>         [hidden email]
>
> 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

Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Theodore Y. Ts'o
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

Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Vincent Cheng-2
On Tue, Aug 21, 2018 at 1:36 PM, Theodore Y. Ts'o <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Vincent Cheng-2
On Tue, Aug 21, 2018 at 6:32 PM, Vincent Cheng <[hidden email]> wrote:

> On Tue, Aug 21, 2018 at 1:36 PM, Theodore Y. Ts'o <[hidden email]> 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
[hidden email] be created. If that falls through, maybe we
could piggyback on debian-kernel or some other list?

Regards,
Vincent

Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Theodore Y. Ts'o
In reply to this post by Theodore Y. Ts'o
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 <[hidden email]>  Fri, 24 Aug 2018 03:32:49 -0400

Cheers,

                                        - Ted

Reply | Threaded
Open this post in threaded view
|

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

Vincent Cheng-2
On Fri, Aug 24, 2018 at 10:35 PM Theodore Y. Ts'o <[hidden email]> 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 <[hidden email]>  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