Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 02/03/14 06:56, Turbo Fredriksson wrote: > On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote: > >> > Hostile binary takeover is not allowed - that is two separate source >> > packages should not build the same binary package names, even if on >> > different architectures. > Ok, sounds reasonable when you say it like that. I'd still appreciate a link > to the policy for that. One possible example of theoretical breakage is to run the command "apt-get source libzfs1", right now it downloads the kfreebsd/zfsutils sources, but I don't know what will happen when zfs-linux is allowed into the archives. Is apt intelligent enough to pick the source corresponding to the binary package of the host arch? signature.asc Description: OpenPGP digital signature
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 2 March 2014 16:05, Steven Chamberlain wrote: > On 02/03/14 12:19, Turbo Fredriksson wrote: >> Might I suggest that the reason is that these is _completely_ different >> implementation, with >> absolutly no common code? > > Right, so conversely, zfs-linux shares a lot of code already with > zfsutils and it makes no sense for them to be packaged separately or > compete over namespace? > I think it makes sense for myself to go through the differences and propose packaging changes for Robert to review, to simply enable linux-any targets in the existing zfs packages. This thus avoids the packaging conflict all-together, but does impose compatability (e.g. such that end-user binaries have compatible commandline interface, flags, and operations - clearly different zfs api levels / options will be supports, but the common base set should work the same across all supported kernels). If patches are intrusive, then conditionally applying the patches on linux-any might work (as many other profilic packages do - binutils, gcc, etc.) >> if the FTP maintainers [...] say that this is not acceptable, >> then we'll rename it, without any bitching or >> whining or expressing opinions that we can't backup with facts. > >> Basically, their ruling is law. Your opinion is just that - your opinion and >> bear no weight at this >> moment. > > It actually seemed to be an offer for collaboration with you, but I > don't see that working so well now. > No ftp-masters decisions are not laws - rejects usually only happen after contacting the developer, inquiring unclear technical points and mitigating the problems. Quite often, if it's possible to fix, things are reuploaded. it's simply their archive you ask inclusion into and they are free to include things or not and tell you why =))) The maintainer of a package, ultimately has the power to veto what goes into the packages they are maintaining. If you are not sure what or who a maintainer is, here is reference to the policy you are so after https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer Current maintainers and uploads of zfsutils are listed at http://packages.qa.debian.org/z/zfsutils.html Debian welcomes all contributions by everyone, as long as one constructively interacts with Debian. (If you want a reference, here you go https://www.debian.org/intro/diversity ) Since you acknowledge the code differences are small, can you refactor zfsutils required portions as patch series to existing zfsutils package (and hence the related libraries, utils and udebs) ? That would be ultimately easier to maintain, and will go quicker through NEW queue, as it's only the utils and not the kernel module. And then kernel dkms module can go through as a separate package. Not sure if it at all makes sense to ship -dkms module out of the zfsutils package, as I'm expecting linux dkms module to move at a faster pace than the utils. Would that work you? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUh4ij6cN-qBp=U8MF-DSVP5iZmf-gLQBfm=y8bexqq...@mail.gmail.com
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
I'm not anyone "important," but I'd like to suggest you just rename the conflicting packages now. It's quite possible that at least part of the reason it's languishing in the NEW queue is because every time an ftp-master looks at it, they think "Oh right, this mess." They can't find a firm reason to reject it, but they can't find a firm reason to say it's okay either. So it just sits. I suspect that the "objective reality" here is that there's no actual Policy statement against this, but the tools aren't setup to handle it either. In the past, I've looked for a Policy statement to try to resolve this either way, but I wasn't able to find one. But even if it's not prohibited explicitly, that doesn't necessarily mean it's a good idea. ZFS on Linux is complicated enough without needing to worry about corner cases in Debian tools. zol-zfsutils or linux-zfsutils or something should be fine. Adding "Provides: zfsutils" might be wise as well. Then, ideally, the FreeBSD side could rename theirs too, and add the same Provides. If at some point in the future, they share a codebase, then (and only then) the packages can be merged. -- Richard signature.asc Description: This is a digitally signed message part
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 02/03/14 12:19, Turbo Fredriksson wrote: > Might I suggest that the reason is that these is _completely_ different > implementation, with > absolutly no common code? Right, so conversely, zfs-linux shares a lot of code already with zfsutils and it makes no sense for them to be packaged separately or compete over namespace? > if the FTP maintainers [...] say that this is not acceptable, > then we'll rename it, without any bitching or > whining or expressing opinions that we can't backup with facts. > Basically, their ruling is law. Your opinion is just that - your opinion and > bear no weight at this > moment. It actually seemed to be an offer for collaboration with you, but I don't see that working so well now. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531356ba.5090...@pyro.eu.org
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 02/03/2014 12:19, Turbo Fredriksson wrote: > Basically, their ruling is law. Your opinion is just that - your opinion and > bear no weight at this > moment. Ah, good. Finally you openly admit that you're requesting ftp-master support for your hostile takeover instead of trying to coordinate with existing maintainers. I won't waste one more minute of my time trying to talk sense into you. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53134544.5040...@debian.org
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On Mar 2, 2014, at 12:05 PM, Robert Millan wrote: > There's a reason we add a "freebsd-" prefix to functionally equivalent > packages like: > > freebsd-smbfs - mount command for the SMB/CIFS filesystem > freebsd-net-tools - FreeBSD networking tools > freebsd-nfs-common - NFS support files common to client and server > freebsd-nfs-server - FreeBSD server utilities needed for NFS on GNU/kFreeBSD > freebsd-ppp - FreeBSD Point-to-Point Protocol (PPP) userland daemon Might I suggest that the reason is that these is _completely_ different implementation, with absolutly no common code? > Your repeated insistence on occupying the "zfsutils" namespace makes me think > you have a self-serving reason for this. Of course I have - I have never denied this. But the same can be said for you - you have shown an extreme "ill will" against us using that name. One could only guess why... My/our reasoning is that it is based on the same code (even if not the same source package - yet), gives the same functionality, with the same... etc, etc. I've said that a few times by now, if you don't want to understand that part, let's wait for the FTP maintainers ruling. > How do you plan to react when actual breakage happens? Rename it. It's just that easy. IF someone can actually show me that this is actually illegal and can point me to a policy AND/OR if the FTP maintainers (which have the final say in this - not you, not me, not any one else!) say that this is not acceptable, then we'll rename it, without any bitching or whining or expressing opinions that we can't backup with facts. For now, I have not heard one word about this from them. The only thing I've heard is that there "might" be a problem with the licensing and that they want to investigate this properly and be absolutly sure - it is their job, the one they where elected and trusted to do. Basically, their ruling is law. Your opinion is just that - your opinion and bear no weight at this moment. Dimitri is the only one that have given something that is slightly more than just a personal opinion: On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote: > Hostile binary takeover is not allowed - that is two separate source > packages should not build the same binary package names, even if on > different architectures. This at least SOUNDS like something that could be a policy. You have not provided ANYTHING that can be considered anything else than a personal opinion and "dislike/disdain" of the name. I still want/need something that actually IS a policy. Until then, may I suggest we both table further discussion about renaming the package until we get the FTP maintainers ruling on the package. They have been Cc'd on this thread, so they will know that there "might" be a controversy in the naming. If they rule the license ok but the name wrong, they won't allow it into the archive as-is anyway, so there is no danger in waiting and letting them do their job. > Unless I missed something, ZoL is not OpenZFS. No ? Where did you get/draw that conclusion from? > And neither ZoL nor OpenZFS support the kernel of FreeBSD at the time of > writing. I can't say yes or no on that, I just don't know. I'm involved in ZoL, not OpenZFS. But it would actually surprise me somewhat if it didn't. This because they, from what I understand (which might be wrong) used the Illumos code as starting point. And, again from what I understand, is the code *BSD is using. But talking about what OpenZFS _IS_ and what it's _INTENDED_ to be is irrelevant at the moment. My point have been that _eventually_, there won't BE a "FreeBSD/ZFS' or a "Linux/ZFS" version. There will ONLY be OpenZFS! And that is only partly irrelevant. In the sense that the current FreeBSD 'zfsutils' and the Linux 'zfsutils' is _basically_ the same, but still not _exactly_ the same > You make it look like you're adding a portable package No I don't. I haven't even hinted to it.. > when in fact it is a Linux-specific package. Yes. Have someone made you believe it to be something else? > I think it would serve that agenda to imply that ZoL is OpenZFS and the > source you're adding is > portable, but I don't think you even believe what you're implying. This is completely your complete misunderstanding and inability to read and understand what's been said. You need to go back and read it again. > If you truly believe in the "unification path" I do. Whole heartedly - it's the only way forward into the future! Keeping X number of implementations, sharing a huge part of the exact same code won't be sustainable in the long run (it have already proved somewhat of a problem - both in ZoL and in Illumos). > I notice that you ignored it on your reply to him: > > On 02/03/2014 03:52, Dimitri John Ledkov wrote: >> Also, if there is zfs-dkms module available, why existing zfsutils >> packages just can't enable compilation on "linux-any"?! Which should >> also reduce the scope o
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 01/03/2014 15:46, Turbo Fredriksson wrote: > Please give us/me a direct link to the Debian GNU/Linux policy point that > explain that this is not acceptable. I don't have that. I'm telling you that Debian infrastructure is not ready to handle cross-arch namespace collisions based on my experience hitting the exact same problem before. There's a reason we add a "freebsd-" prefix to functionally equivalent packages like: freebsd-smbfs - mount command for the SMB/CIFS filesystem freebsd-net-tools - FreeBSD networking tools freebsd-nfs-common - NFS support files common to client and server freebsd-nfs-server - FreeBSD server utilities needed for NFS on GNU/kFreeBSD freebsd-ppp - FreeBSD Point-to-Point Protocol (PPP) userland daemon Your repeated insistence on occupying the "zfsutils" namespace makes me think you have a self-serving reason for this. How do you plan to react when actual breakage happens? On 02/03/2014 05:56, Turbo Fredriksson wrote: > That is what OpenZFS.org is for - eventually (hopefully sooner than later), > you/we/I will be able to > do just that - one source base for all architectures (Linux, FreeBSD, Illumos > etc). But we (they) > aren't there yet. > > > As it stands today, there are two "upstream sources" for/in Debian GNU/Linux > - one for the Linux > kernel and one for the FreeBSD kernel. These share _a lot_ (I can't give you > an exact figure, but if > I had to give a "between thumb and index finger guess", I'd say 90%) of the > same code (they both > originated from the last open Solaris release before Oracle closed the source > again) and provide the > exact same functionality, in the exact same way with binary programs that > behave the exact same way > (same options and parameters etc). Unless I missed something, ZoL is not OpenZFS. And neither ZoL nor OpenZFS support the kernel of FreeBSD at the time of writing. You make it look like you're adding a portable package, when in fact it is a Linux-specific package. The idea that you're adding a portable package is very consistent with your pretension of occupying the namespace. I think it would serve that agenda to imply that ZoL is OpenZFS and the source you're adding is portable, but I don't think you even believe what you're implying. If you truly believe in the "unification path", why don't you try Dimitri's suggestion? I notice that you ignored it on your reply to him: On 02/03/2014 03:52, Dimitri John Ledkov wrote: > Also, if there is zfs-dkms module available, why existing zfsutils > packages just can't enable compilation on "linux-any"?! Which should > also reduce the scope of linux specific packages down to > -dkms/-initramfs, and maybe an arch specific patch-series. The packages are so similar, right? Maybe he has a point. Why don't you send patches for zfsutils to enable compilation on linux-any? I'll be happy to work with you. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53131091.8060...@debian.org
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On Mar 2, 2014, at 6:56 AM, Turbo Fredriksson wrote: > On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote: > >> Since these are two different implementations > > You said it yourself - they are different implementations. Actually, this is not quite true either come to think of it. > they both originated from the last open Solaris release before Oracle closed > the source again They are both the exact same (!) implementation, they're just two different ports from the Solaris code they originate from. The *BSD versions are probably a little closer to the Solaris implementation (I guess, because BSD is closer to Solaris than Linux is). And since Illumos have been working on their ZFS implementation longer than ZoL, that's a reason why their version is "more" (more function and more developed I guess would be a reasonable conclusion), which is the reason why ZoL is currently trying to "catch up" with the Illumos version. But again, that's what OpenZFS if for - merging all the current implementation into one code base. -- Turbo Fredriksson tu...@bayour.com -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6ee84a1e-a389-4a25-9073-9019db1be...@bayour.com
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote: > Hostile binary takeover is not allowed - that is two separate source > packages should not build the same binary package names, even if on > different architectures. Ok, sounds reasonable when you say it like that. I'd still appreciate a link to the policy for that. I think (explanation below) that in this case, it would/could be warranted to keep the names and do the "hostile binary takeover" as you put it. > Since these are two different implementations > why existing zfsutils packages just can't enable compilation on "linux-any"?! You said it yourself - they are different implementations. Yes, they share a lot (!!) of similar code, but they are also not compilable on their "opposite" arch. That is what OpenZFS.org is for - eventually (hopefully sooner than later), you/we/I will be able to do just that - one source base for all architectures (Linux, FreeBSD, Illumos etc). But we (they) aren't there yet. As it stands today, there are two "upstream sources" for/in Debian GNU/Linux - one for the Linux kernel and one for the FreeBSD kernel. These share _a lot_ (I can't give you an exact figure, but if I had to give a "between thumb and index finger guess", I'd say 90%) of the same code (they both originated from the last open Solaris release before Oracle closed the source again) and provide the exact same functionality, in the exact same way with binary programs that behave the exact same way (same options and parameters etc). > The conflict is there, by virtue of enabling multiarch one can install > "zfsutils" for either a linux or kfreebsd architecture Are you saying that with multiarch, it's possible to install packages for two completely different kernels - Linux and FreeBSD!? > Changes to partman-zfs on linux-any, confuse and surprise me, as that > implies providing a pre-build dmks module for the installer's Linux > kernel which is not redistributable. That was not (and I still haven't seen a categorical proof of this!) determined at the time. Besides, even if this is eventually proved and decided, having the support for ZFS in d-i/partman for linux would still be a good option. People can have their module loaded manually or manually put it on their own, private CD/DVD or FTP repo etc. > DId partman-zfs/linux-any relied on compiling -dkms module? Yes and no. The module will off course be required to "enable" the functionality at the time of booting the installation - I wrote it in such a way that if there is no ZoL support, that part of d-i/partman will be disabled. Installing on a ZFS filesystem on Linux will just not be available/possible/shown if the ZoL module isn't available. It doesn't require any linking with any ZoL library etc when creating the boot/install "stuff", so in that regard, there is no licensing issue by accepting the patches. The changes [to d-i/partman] was quite minor, so not accepting them just because there is/might be a licensing issue with distributing a binary module in/with Debian GNU/Linux might be a little nitpicking. -- I love deadlines. I love the whooshing noise they make as they go by. - Douglas Adams -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1653c1e1-c18e-47b1-b162-7120e001f...@bayour.com
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 1 March 2014 15:46, Turbo Fredriksson wrote: > On Mar 1, 2014, at 2:25 PM, Robert Millan wrote: > >> I already explained. Nobody listens... (sigh) > > All I've seen is that you "think" that it "might" be a problem and that we > "might" be better of renaming it... > > > Please give us/me a direct link to the Debian GNU/Linux policy point that > explain that this is not acceptable. Hostile binary takeover is not allowed - that is two separate source packages should not build the same binary package names, even if on different architectures. Since these are two different implementations that should be clearly reflected in the binary package names. There is no need to rename the command-line utilities themself. Typically you'd still declare a common name as a virtual package name provider: Package: zolutils Provides: zfsutils Description: zfs on linux utilities The conflict is there, by virtue of enabling multiarch one can install "zfsutils" for either a linux or kfreebsd architecutre, based on higher version number kfreebsd one will win... thus it's in your own interest to rename zfsutils binary package name. Similarly you can't share library package names, since that will break multiarch installations of those, since versions and files do not match between kfreebsd/linux arches. The packages that are ok, are "-dbg" "-dkms" and "-initramfs". Also, if there is zfs-dkms module available, why existing zfsutils packages just can't enable compilation on "linux-any"?! Which should also reduce the scope of linux specific packages down to -dkms/-initramfs, and maybe an arch specific patch-series. Changes to partman-zfs on linux-any, confuse and surprise me, as that implies providing a pre-build dmks module for the installer's Linux kernel which is not redistributable. DId partman-zfs/linux-any relied on compiling -dkms module? Debian has spent a long time to provide fully free kernels, introducing a non-redistributable component into the installer is a no-go. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUjwWG8riu6pg7fFe=BQoHAmc+U1L4sxd=3vu_+jdwf...@mail.gmail.com
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On Mar 1, 2014, at 2:25 PM, Robert Millan wrote: > I already explained. Nobody listens... (sigh) All I've seen is that you "think" that it "might" be a problem and that we "might" be better of renaming it... Please give us/me a direct link to the Debian GNU/Linux policy point that explain that this is not acceptable. -- Choose a job you love, and you will never have to work a day in your life. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/be8a6574-93a9-4e3e-89d3-0e5905749...@bayour.com
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 28/02/2014 15:13, Turbo Fredriksson wrote: > On Feb 28, 2014, at 1:29 PM, Robert Millan wrote: > >> The proposed package is poorly integrated with existing ZFS packages (e.g. >> zfsutils for native >> kFreeBSD support). >> >> First and foremost, there's a namespace grab which is likely to result in >> trouble, as I explained >> last November (and got no answer) > > Why is this a problem? I already explained. Nobody listens... (sigh) I pointed to the explanation in my previous mail. Please have a look. I urge you to take care of this now. If you'd rather ignore this, be aware that I won't lift a finger when actual breakage happens and you realize that you're forced to rename. > Also, "eventually" _all_ open source ZFS implementations will be built from > the source base. That would be great, but for now it's just wishful thinking. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5311dfe0.6030...@debian.org
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
Hi! On 02/28/2014 06:23 PM, Yaroslav Halchenko wrote: > I am not an ftp-master but if I were one (and as a mentor for quite a > few projects) I would have preferred to have re-uploads because > > - ftp masters already looked at some past version We are talking about packages in NEW, those haven't usually been in the archives before. The case you are describing can only occur if an existing package is stuck in NEW because of new binary components, for example. > - having old and new versions eases to see what has changed (debdiff) > instead of starting all over or digging out previous version Not if there isn't any old version in the archives. > - shows active interest of original maintainers I don't understand this argument. Again, what I am saying is that if you upload something into NEW and you realized you messed something up or the package has been in the queue for quite some time now without any of the FTP masters having looked at the package yet and the maintainer has changed the packaging a lot in the meantime, I think it's the proper approach to ask the FTP team to mark the package as REJECT and upload a current version. This way the FTP team doesn't waste their time on reviewing a package which is going to be replaced very soon anyway. Especially when the packaging was considerably changed in the mean time. Who tells you that the maintainers didn't make any mistake in their new package version that would normally have triggered a REJECT by the FTP team, but the maintainers get to upload it into the archives anyway because there is already a version in unstable that has been accepted? Honestly, I think packages should automatically be removed from NEW after a certain grace period. This shouldn't be regarded as a REJECT for the package in general, but simply that no one has managed so far to review the package and it "fell out" of the queue. Helps keeping the packages in NEW "fresh" in my opinion. > for original uploader benefit is that package doesn't loose its order in > the NEW (IIRC). I don't see how this would be of any advantage. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5311ad8c.3000...@physik.fu-berlin.de
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
Steven Chamberlain (2014-02-28): > The actually useful bits for Linux were later reverted by KiBi due to > d-i build issues, but the other changes (including some that are > problematic for kFreeBSD) are still there. > > Perhaps I could undo Turbo's changes in master, and we can later > carefully review, clean up and reintroduce changes ZoL really needs? That's what I suggested in the last paragraph of <20140203224646.gb5...@mraw.org>: https://lists.debian.org/debian-bsd/2014/02/msg00043.html Mraw, KiBi. signature.asc Description: Digital signature
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 28/02/14 15:13, Turbo Fredriksson wrote: > It's very flattering that people thought my stuff was good enough to accept > without further review, > but it's also a bit frightening - I'm good, but not THAT good (as we could > see :). ISTR it was committed to master by mistake? Then reverted, but when Christian Perrier originally did this he rewrote git history; Joey Hess corrected that in the VCS, but Christian's next upload reintroduced it all from his working copy. Or something like that. The actually useful bits for Linux were later reverted by KiBi due to d-i build issues, but the other changes (including some that are problematic for kFreeBSD) are still there. Perhaps I could undo Turbo's changes in master, and we can later carefully review, clean up and reintroduce changes ZoL really needs? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5310f6e7.4000...@pyro.eu.org
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 28/02/14 17:58, John Paul Adrian Glaubitz wrote: >> > However, I will wait for a resolution from ftp-master before >> > resuming my work on the package, because there is the possibility >> > of ftp-master not allowing the upload and I don't like to waste my >> > time. > Just because your package is rejected doesn't mean you can't get it > into unstable at all. Packages are rejected all the time. It just > means the package is not *yet* fit for ACCEPT. What I'm afraid of is ftp-masters rejecting the package for license issues (CDDL-GPL). If the ftp-masters reject the package on a license issue basis this would mean that zfs-linux won't get into Debian. So I rather will wait for this before resuming my work on the current package. I think the license isn't a problem at all because zfs-dkms only ships source code (no binary distributed). And the binary utilities distributed on zfsutils don't depend on any CDDL-incompatible library/package. signature.asc Description: OpenPGP digital signature
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On Fri, 28 Feb 2014, John Paul Adrian Glaubitz wrote: > On 02/28/2014 05:37 PM, Carlos Alberto Lopez Perez wrote: > > I advise against this. The upload is to experimental, is OK if the > > package has RC bugs. > Why? If the maintainer has made some changes in the meantime while the > package has been waiting in NEW and the FTP team hadn't yet the > possibility to look at the package, why waste their time to review a > package which is going to be redone anyway? I am not an ftp-master but if I were one (and as a mentor for quite a few projects) I would have preferred to have re-uploads because - ftp masters already looked at some past version - having old and new versions eases to see what has changed (debdiff) instead of starting all over or digging out previous version - shows active interest of original maintainers for original uploader benefit is that package doesn't loose its order in the NEW (IIRC). overall -- I am not sure what could be a benefit of REJECT+REUPLOAD -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140228172337.gq5...@onerussian.com
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2014 05:37 PM, Carlos Alberto Lopez Perez wrote: > I advise against this. The upload is to experimental, is OK if the > package has RC bugs. Why? If the maintainer has made some changes in the meantime while the package has been waiting in NEW and the FTP team hadn't yet the possibility to look at the package, why waste their time to review a package which is going to be redone anyway? > Let the ftp-master team accept the package first, and once that is > done we can upload a better version to unstable. But if you already start with a cleaner version in NEW, you have the chance to get a feedback on the current package revision instead of the old one. Makes much more sense to me. > In the meanwhile you can continue working on the package repository > as usual. I don't see how you couldn't when just asking for the package to be marked as REJECT. Like I said, I do that often and there is nothing wrong when the package hasn't even been looked at yet. I rather feel embarrassed about uploading a b0rked package into NEW. > However, I will wait for a resolution from ftp-master before > resuming my work on the package, because there is the possibility > of ftp-master not allowing the upload and I don't like to waste my > time. Just because your package is rejected doesn't mean you can't get it into unstable at all. Packages are rejected all the time. It just means the package is not *yet* fit for ACCEPT. Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEMAZAAoJEHQmOzf1tfkTHYMP/3iYWbT/9r/HdJ/eQLCNFyvv Xk0tb1fRWUsvDrO2h+9I4IqDMD3UWxLtMvrGDkUrJEv5jXFsuWiMRRMRQTIN5wnS ImnjMJgrtUIohGmn0UF8yDkNXduc9GWX/DToh/74n6hjXSRja+qxg8gTf/Ts3nxL Th9AJLwSod6idgyC/keY64TkFLy5GKP73icMbF6SZCfwFyn5kFzPxarU+eDVnDDT Ynog2VFkIu4oG7YNYkQQDVwljY7wxsxEAl82CZt7D+gAHOVt6qG65iDJ7OuacJ0c McA5ZOnjIUf1EkX2xTzml8CddaF9pkJoXndqOObdsejdtxrRW97rb0Vo8+B7t7H8 NF8pSjooruRxNv08gF7g0m08++6Kh+qFFQmtHlAIirHhanffajX8r/LfVnMsK1Ts IfJbSd8BzNPKeeAraQy9axeudkDUMpRFYHq6c1+tM2Bh0maZrATVtwdEm5UBk8yM YRP+JUQY7n3ZYv13bEu5Ar1k0tpsIm51RLNFVQSowBOikPwABWZS78pr0dJ24sG4 y6whiqUno+93H0Jt9U3kkfVJgskYYZkpgSorZQMWMNCWQnmn9xrzI57iQjk2GTXP pM5ENvTANpSPE2bdxciNteQI/o7wCP0F8FovBNGXfKa8V2DYPS/mrExynE7nmFfa fpqhw8S4Bd/OPFyiroGX =qeZj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5310c01f.7040...@physik.fu-berlin.de
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 28/02/14 17:23, John Paul Adrian Glaubitz wrote: > On 02/28/2014 04:13 PM, Turbo Fredriksson wrote: >> Is it ok/allowed to upload a new package, even though the initial one is >> still stuck in incoming? > > I suggest asking the FTP masters to mark the package as REJECT if you > want to change something again. As long the package is still stuck > in NEW (not incoming, this is where the package goes once it's > been ACCEPTED), you can always have it rejected. > > It's the cleaner solution in my opinion instead of uselessly bumping > the package revision to fix minor issues before the package isn't > even ACCEPTED. > > Adrian > I advise against this. The upload is to experimental, is OK if the package has RC bugs. Let the ftp-master team accept the package first, and once that is done we can upload a better version to unstable. In the meanwhile you can continue working on the package repository as usual. However, I will wait for a resolution from ftp-master before resuming my work on the package, because there is the possibility of ftp-master not allowing the upload and I don't like to waste my time. Regards! signature.asc Description: OpenPGP digital signature
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 02/28/2014 04:13 PM, Turbo Fredriksson wrote: > Is it ok/allowed to upload a new package, even though the initial one is > still stuck in incoming? I suggest asking the FTP masters to mark the package as REJECT if you want to change something again. As long the package is still stuck in NEW (not incoming, this is where the package goes once it's been ACCEPTED), you can always have it rejected. It's the cleaner solution in my opinion instead of uselessly bumping the package revision to fix minor issues before the package isn't even ACCEPTED. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5310b7f6.60...@physik.fu-berlin.de
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On Fri, 28 Feb 2014, Turbo Fredriksson wrote: > Is it ok/allowed to upload a new package, even though the initial one is > still stuck in incoming? yes! -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140228161630.gk5...@onerussian.com
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On Feb 28, 2014, at 1:29 PM, Robert Millan wrote: > The proposed package is poorly integrated with existing ZFS packages (e.g. > zfsutils for native > kFreeBSD support). > > First and foremost, there's a namespace grab which is likely to result in > trouble, as I explained > last November (and got no answer) Why is this a problem? Also, "eventually" _all_ open source ZFS implementations will be built from the source base. A couple of months ago, OpenZFS.org was created to merge all (Illumos, BSD*, ZoL etc) current implementations into one code tree. I don't exactly know the status of OpenZFS, Brian Behlendorf is active/the driving force in both OpenZFS and ZoL and might know more. ZoL is currently playing the catch-up game to get it in line with the rest, and I doubt there is some kind of time schedule but hopefully it won't take to many years :). So if we rename zfsutils for ZoL now, we'll have to rename it back later. With all the hassle that will entail (especially since we know going in that we will have to rename it). > There are also a number of implementation-independant add-ons which would be > good practice to > coordinate in some way with the other ZFS maintainers. I'll add those then, thanx. > And annoyingly, there's also been complaints that ZoL developers broke > partman-zfs by committing > porting updates that break existing support on kFreeBSD !! No "ZoL developer" have "committed porting updates" to partman-zfs !! _I_ have however, sent in patches to it/them for review, where I have clearly stated that discussion was needed - and warned about possible breaking it for kBSD and asked for input and comments on how it worked there so I could write a better patch. It's very flattering that people thought my stuff was good enough to accept without further review, but it's also a bit frightening - I'm good, but not THAT good (as we could see :). On Feb 28, 2014, at 2:00 PM, Carlos Alberto Lopez Perez wrote: > [14:34] it's not forgotten, we just haven't had a slice of time to > commune about it > [14:34] feel free to email ftpmaster@ and poke > [14:37] Liang Guo did that some weeks ago but he got not reply > (AFAIK) > > So, I don't know how more we can do other than wait. Six months and counting... Ah, well. There's some issues with the following package any way, so maybe we should take use the time and get it in good shape. Is it ok/allowed to upload a new package, even though the initial one is still stuck in incoming? -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/767f4094-13db-4567-ad54-bb2446c4e...@debian.org
Re: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 28/02/2014 10:20, Dimitri John Ledkov wrote: > Hello, > > On 28 February 2014 09:30, Turbo Fredriksson wrote: >> I'm basically Ccing half the world in this (only half sorry about that :) >> and I don't know who half >> of you are :), but there have been very little information on what's >> happening with ZoL in Debian >> GNU/Linux. >> >> Aron (and in some part Carlos) seems to have gone a-wall and the list have >> been VERY quiet. It seems >> like it's only Aron and me that is actually Debian GNU/Linux Developers >> (unless other things have >> happened outside the list that I'm not aware of - Carlos was/is a maintainer >> if I don't >> misremembering and Darik is in the wait queue?). And no actually status >> information/reason from the >> FTP maintainers about why it have been stuck in incoming for so long >> (accepted into incoming Sun, 07 >> Jul 2013 16:00:06 - that's more than six months ago!). Have it been >> rejected? Is it held up for some >> reason? What can I/we do to help move it along? Hi, The proposed package is poorly integrated with existing ZFS packages (e.g. zfsutils for native kFreeBSD support). First and foremost, there's a namespace grab which is likely to result in trouble, as I explained last November (and got no answer): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686447#117 There are also a number of implementation-independant add-ons which would be good practice to coordinate in some way with the other ZFS maintainers. I explained this in November too, and again got no answer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686447#112 And annoyingly, there's also been complaints that ZoL developers broke partman-zfs by committing porting updates that break existing support on kFreeBSD: https://lists.debian.org/debian-bsd/2014/02/msg00037.html I'm happy to see partman-zfs support more platforms, and I don't mind myself if those platforms are not yet part of Debian when support is merged. But I would at least find it reasonable that porting changes include an effort to avoid breaking existing production environments. We do this all the time when porting to kFreeBSD. I think it should work both ways. That I know of, nobody has spent the time to fix this particular mess yet :-( -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53108145.8030...@debian.org
