Hi!
I'd like to use an epoch so I'm asking for consensus per policy 5.6.12.
As part of the Salvage Team's trixie view-os removal plan ‒
RM: umview -- RoQA; obsolete, low popcon #1085454
RM: fuse-umfuse-ext2 -- RoQA; dead upstream, low popcon #1085457
+ replace with https://github.com/alperakcan/fuse-ext2
RM: umview-mod-umfusefat [amd64 i386 ppc64] -- RoQA; view-os removed ITS #1085458 (2024-11-09); https://github.com/virtualsquare/fusefatfs/pull/2
RM: fuse-umfuse-iso9660 -- RoQA; dead upstream, duplicates fuseiso #1085456
+ implement "fuseiso -o fuseopt -o fuseopt iso mtpt" in fuseiso #1083034
(currently only accepts "fuseiso iso mtpt -o fuseopt -o fuseopt")
have that provide a transitional package (sge@ contacted thus)
‒ fuseext2 is to be provided by https://github.com/alperakcan/fuse-ext2 instead of src:fuse-umfuse-ext2.
The current version of src:fuse-umfuse-ext2 in sid is 0.4-1.5,
and the current version of https://github.com/alperakcan/fuse-ext2 is 0.0.11, so src:fuse-ext2 would need to be version 1:0.0.11-1 to update right.
Thoughts?
On Sun, 2024-10-20 at 20:03 +0200, наб wrote:The current implementation's README also says this, so I'd say so, yeah
I'd like to use an epoch so I'm asking for consensus per policy 5.6.12.
As part of the Salvage Team's trixie view-os removal plan ‒
RM: umview -- RoQA; obsolete, low popcon #1085454
RM: fuse-umfuse-ext2 -- RoQA; dead upstream, low popcon #1085457
+ replace with https://github.com/alperakcan/fuse-ext2
RM: umview-mod-umfusefat [amd64 i386 ppc64] -- RoQA; view-os removed ITS #1085458 (2024-11-09); https://github.com/virtualsquare/fusefatfs/pull/2
RM: fuse-umfuse-iso9660 -- RoQA; dead upstream, duplicates fuseiso #1085456
+ implement "fuseiso -o fuseopt -o fuseopt iso mtpt" in fuseiso #1083034
(currently only accepts "fuseiso iso mtpt -o fuseopt -o fuseopt")
have that provide a transitional package (sge@ contacted thus)
‒ fuseext2 is to be provided by https://github.com/alperakcan/fuse-ext2 instead of src:fuse-umfuse-ext2.
The current version of src:fuse-umfuse-ext2 in sid is 0.4-1.5,
and the current version of https://github.com/alperakcan/fuse-ext2 is 0.0.11,
so src:fuse-ext2 would need to be version 1:0.0.11-1 to update right.
Thoughts?
Given that fuse-ext2's README says "please do not mount your
filesystems with write support unless you have nothing to lose", is it
really suitable to replace the current implementation?
uses upstream fuse-ext2 directly?),so, the way I read it, src:fuse-umfuse-ext2 is fuse-ext2 0.0.6.0
Perhaps it would be better not to provide any replacement until fuse-Given the above, this is looking less like a replacement
ext2 is more mature - at which point its version may have increased
such that an epoch is not necessary.
On Sun, Oct 20, 2024 at 11:39:36PM +0200, Ben Hutchings wrote:
On Sun, 2024-10-20 at 20:03 +0200, наб wrote:
I'd like to use an epoch so I'm asking for consensus per policy 5.6.12.
As part of the Salvage Team's trixie view-os removal plan ‒
RM: umview -- RoQA; obsolete, low popcon #1085454
RM: fuse-umfuse-ext2 -- RoQA; dead upstream, low popcon #1085457
+ replace with https://github.com/alperakcan/fuse-ext2
RM: umview-mod-umfusefat [amd64 i386 ppc64] -- RoQA; view-os removed ITS #1085458 (2024-11-09); https://github.com/virtualsquare/fusefatfs/pull/2
RM: fuse-umfuse-iso9660 -- RoQA; dead upstream, duplicates fuseiso #1085456
+ implement "fuseiso -o fuseopt -o fuseopt iso mtpt" in fuseiso #1083034
(currently only accepts "fuseiso iso mtpt -o fuseopt -o fuseopt")
have that provide a transitional package (sge@ contacted thus)
‒ fuseext2 is to be provided by https://github.com/alperakcan/fuse-ext2 instead of src:fuse-umfuse-ext2.
The current version of src:fuse-umfuse-ext2 in sid is 0.4-1.5,
and the current version of https://github.com/alperakcan/fuse-ext2 is 0.0.11,
so src:fuse-ext2 would need to be version 1:0.0.11-1 to update right.
Thoughts?
Given that fuse-ext2's README says "please do not mount yourThe current implementation's README also says this, so I'd say so, yeah
filesystems with write support unless you have nothing to lose", is it really suitable to replace the current implementation?
(the manuals for both clearly indicate that R/W mounts are experimental).
The similarity was too good to be accidental, and seemingly, per
https://sourceforge.net/p/view-os/code/HEAD/tree/trunk/fuse-modules/fuse-umfuse-ext2/
fuse-umfuse-ext2 is actually just a fork of fuse-ext2:
Perhaps it would be better not to provide any replacement until fuse-Given the above, this is looking less like a replacement
ext2 is more mature - at which point its version may have increased
such that an epoch is not necessary.
and more like a version bump with upstream changing versioning schemes? Either way, I feel like this resolves the question of implementation maturity.
(I also don't fore-see fuse-ext2 version ever growing past 0.4.0,
seeing as in the past decade it grew by 0.0.5.)
Thoughts?
On Mon, 2024-10-21 at 00:49 +0200, наб wrote:
On Sun, Oct 20, 2024 at 11:39:36PM +0200, Ben Hutchings wrote:
On Sun, 2024-10-20 at 20:03 +0200, наб wrote:
I'd like to use an epoch so I'm asking for consensus per policy 5.6.12.
As part of the Salvage Team's trixie view-os removal plan ‒
RM: umview -- RoQA; obsolete, low popcon #1085454
RM: fuse-umfuse-ext2 -- RoQA; dead upstream, low popcon #1085457
+ replace with https://github.com/alperakcan/fuse-ext2
RM: umview-mod-umfusefat [amd64 i386 ppc64] -- RoQA; view-os removed ITS #1085458 (2024-11-09); https://github.com/virtualsquare/fusefatfs/pull/2
RM: fuse-umfuse-iso9660 -- RoQA; dead upstream, duplicates fuseiso #1085456
+ implement "fuseiso -o fuseopt -o fuseopt iso mtpt" in fuseiso #1083034
(currently only accepts "fuseiso iso mtpt -o fuseopt -o fuseopt")
have that provide a transitional package (sge@ contacted thus)
‒ fuseext2 is to be provided by https://github.com/alperakcan/fuse-ext2
instead of src:fuse-umfuse-ext2.
The current version of src:fuse-umfuse-ext2 in sid is 0.4-1.5,
and the current version of https://github.com/alperakcan/fuse-ext2 is 0.0.11,
so src:fuse-ext2 would need to be version 1:0.0.11-1 to update right.
Thoughts?
Perhaps it would be better not to provide any replacement until fuse- ext2 is more mature - at which point its version may have increased
such that an epoch is not necessary.
Given the above, this is looking less like a replacement
and more like a version bump with upstream changing versioning schemes? Either way, I feel like this resolves the question of implementation maturity.
(I also don't fore-see fuse-ext2 version ever growing past 0.4.0,
seeing as in the past decade it grew by 0.0.5.)
Given the relationship between the two projects, it might be worth
asking upstream to bump the version number so it's more obviously newer
than the forked versions. But if they won't do that, adding the epoch
seems pretty reasonable.
On Tue, 2024-10-22 at 00:00:21 +0200, Ben Hutchings wrote:I kinda wanted to do something like this,
On Mon, 2024-10-21 at 00:49 +0200, наб wrote:
On Sun, Oct 20, 2024 at 11:39:36PM +0200, Ben Hutchings wrote:
On Sun, 2024-10-20 at 20:03 +0200, наб wrote:
I'd like to use an epoch so I'm asking for consensus per policy 5.6.12.
As part of the Salvage Team's trixie view-os removal plan ‒
RM: umview -- RoQA; obsolete, low popcon #1085454
RM: fuse-umfuse-ext2 -- RoQA; dead upstream, low popcon #1085457
+ replace with https://github.com/alperakcan/fuse-ext2
RM: umview-mod-umfusefat [amd64 i386 ppc64] -- RoQA; view-os removed ITS #1085458 (2024-11-09); https://github.com/virtualsquare/fusefatfs/pull/2
RM: fuse-umfuse-iso9660 -- RoQA; dead upstream, duplicates fuseiso #1085456
+ implement "fuseiso -o fuseopt -o fuseopt iso mtpt" in fuseiso #1083034
(currently only accepts "fuseiso iso mtpt -o fuseopt -o fuseopt")
have that provide a transitional package (sge@ contacted thus)
‒ fuseext2 is to be provided by https://github.com/alperakcan/fuse-ext2
instead of src:fuse-umfuse-ext2.
The current version of src:fuse-umfuse-ext2 in sid is 0.4-1.5,
and the current version of https://github.com/alperakcan/fuse-ext2 is 0.0.11,
so src:fuse-ext2 would need to be version 1:0.0.11-1 to update right.
Thoughts?
Perhaps it would be better not to provide any replacement until fuse- ext2 is more mature - at which point its version may have increased such that an epoch is not necessary.
Given the above, this is looking less like a replacement
and more like a version bump with upstream changing versioning schemes? Either way, I feel like this resolves the question of implementation maturity.
(I also don't fore-see fuse-ext2 version ever growing past 0.4.0,
seeing as in the past decade it grew by 0.0.5.)
Given the relationship between the two projects, it might be worth
asking upstream to bump the version number so it's more obviously newer than the forked versions. But if they won't do that, adding the epoch seems pretty reasonable.
Alternatively you could instead package this as src:fuse-ext2
bin:fuse-ext2 both without an epoch, and if you want to transition the
old users off bin:fuseext2 then provide that as well for a transition
period with the old version prefixed (say 0.4+0.0.11-1, which can be constructed dynamically at build time).
Using fuse-ext2 would match the naming convention of many of the existing fuse package,Honestly this kinda seems like a wash
would match the main program name (fuseext2 being aAgree on all fronts this would be better.
compat symlink), and would make the source and binary packages match name which seems like a bonus anyway.
And epochs are forever, and reset anyI don't suspect there are that many but this is also fair
existing versioned dependencies, including for local/custom packages
where we have no visibility.
...but now that I look at this there's fuse2fs,
which is naturally better than some third-party implementation.
The interface is a little different
(the default is -o rw instead of -s -o ro,allow_other,default_permissions)
so this can be turned into somehing like
src:e2fsprogs -> fuseext2 (transitional package) Depends: fuse2fs
+ adding the current fuseext2 interface with a wrapper to fuse2fs
and dropping the transitional package in forky and the wrapper... never?
in forky? forky+1?
(Or just RM fuseext2 and let users figure this out on their own but
that seems awfully anti-user.)
The epoch is avoided because e2fsprogs is 1.47.1.
On Tue, Oct 22, 2024 at 04:56:05PM +0200, наб wrote:Thanks, this is most likely the best approach, then.
...but now that I look at this there's fuse2fs,
which is naturally better than some third-party implementation.
The interface is a little different
(the default is -o rw instead of -s -o ro,allow_other,default_permissions) so this can be turned into somehing like
src:e2fsprogs -> fuseext2 (transitional package) Depends: fuse2fs
+ adding the current fuseext2 interface with a wrapper to fuse2fs
and dropping the transitional package in forky and the wrapper... never?
in forky? forky+1?
(Or just RM fuseext2 and let users figure this out on their own but
that seems awfully anti-user.)
The epoch is avoided because e2fsprogs is 1.47.1.I suppose another, simpler approach might be to have the fuse2fs
package ship the fuse-ext2 wrapper script, and then we can just have
the debian fuse2fs replace/conflits with fuseext2. I'm certainly OK
with doing this if someone wants to send me a patch.
I'll note that e2fsprogs's fuse2fs supports 64-bit filesystems, PosixYeah, I expected as much. My summary of the diff was from the perspective
ACL's, and has thread supports enabled, in contrast to fuse-ext2 which
does not.
I've implemented this but can't test it fully because
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
is missing an up-to-date pristine-tar
(it's at 1.47.0 so it looks like you just forgot to push?).
On Thu, Oct 24, 2024 at 02:13:05PM +0200, наб wrote:Yeah, that worked now.
I've implemented this but can't test it fully becauseShould be fixed now; thanks for pointing that out.
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
is missing an up-to-date pristine-tar
(it's at 1.47.0 so it looks like you just forgot to push?).
idk if you got a notification (the confirmation mail would indicate otherwise?), but the patch is at #1085590. I've tested it to behave
the same as the real fuseext2 and it upgrades smoothly.
On Thu, Oct 24, 2024 at 05:37:59PM +0200, наб wrote:Thanks :)
idk if you got a notification (the confirmation mail would indicate otherwise?), but the patch is at #1085590. I've tested it to behaveI've uploaded e2fsprogs 1.47.2~rc1-1 to unsstable and it has your
the same as the real fuseext2 and it upgrades smoothly.
patch to replace the fuseext2 binary package.
The fuseext2 bugs are now showing up in bugs.debian.org'sI was expecting src:fuse-umfuse-ext2 to clear the RM queue by the time
src:e2fsprogs page, and I'm pretty sure they should all be closed out
by the fuse2fs emulation of fuseext2.
I was expecting src:fuse-umfuse-ext2 to clear the RM queue by the time
this was uploaded, so I didn't think to enumerate them earlier.
Tested all, all fixed, closed all.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 04:12:30 |
| Calls: | 10,386 |
| Calls today: | 1 |
| Files: | 14,057 |
| Messages: | 6,416,605 |