Re: ZFS in Buster
Mo Zhou writes ("Re: ZFS in Buster"):
> I made a mistake at this point. There is no SIMD bug in zfs
> 0.7.12-2. The true bug lies in the stable kernel update that
> breaks stuff. We debian ZoL maintainers decided to do nothing
> before the Buster release, and file an RC bug against the
> kernel when 10.1 comes out.
I am hoping I have misunderstood.
Here is what I read from your message:
* Prior to Daniel (ganc...@gmail.com)'s message of last Tuesday, the
Debian ZoL maintainers were aware of this precise difficulty
surrounding the upstream __*fpu* symbols and ZoL.
* The Debian ZoL maintainers collectively knew that this problem
would not affect buster immediately, but would very likely affect a
Linux kernel version which the kernel team would want to ship in a
buster point releease.
* The intention seems perhaps to have been to allow this latent
problem to release with buster; and, then, to use the "released"
status of ZoL in buster contrib, as a lever to try to have the
kernel symbol change reverted in Debian's version of a forthcoming
buster Linux kernel update, in that expected buster point
release. [1]
* The Debian ZoL maintainers did not seek a conversation with Debian
kernel maintainers or the wider Debian project about this issue.
* This lack of communication was deliberate.
I have a lot of respect for the energy you personally have brought to
your Debian work and the contributions you have made. But I would
find behaviour such as I have described, if that is what occurred,
totally unacceptable.
If any of us in Debian become aware that any kind of problem or
adverse interaction will arise between our work, and that of other
contributors, it is our duty to promptly and candidly inform those
other contributors.
That is true even if we think those other contributors may disagree
with us, and if their likely response will be difficult for us.
Indeed, if we expect that their likely response will be adverse,
hiding the information is *more* rather than less serious.
It is very much Not OK to try to create Facts On The Ground while our
co-contributors remain in ignorance of our intent.
Please tell me I have misunderstood your message.
Regretfully,
Ian.
[1] As a matter of practical politics, I think any such strategy would
be clearly doomed, and not just because of the evidence of bad faith,
but also because Debian's overall attitude to GPL compliance issues
like this one is, as others have noted, very firm, and because of the
secondary status of contrib.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Do we want to Require or Recommend DH
I would very much like to argue that not using dh is not a bug, but Joey Hess, with his credentials ☺, did that already (and much better than I could): http://joeyh.name/blog/entry/80_percent/ tl;dr: dh started as 80% solution, it’s maybe an 96% solution now, but it’s not intended as, and won’t be, a 100% solution. I’d also throw in that monocultures are not good, and that people in general are happier when they aren’t forced into anything. Just yesterday I had a bug that wouldn’t have happened with a non-dh7 rules file (incidentally, ordering matters, so I had to add a call to mkdir -p debian/binarypackagename/some/directory into an over‐ ride). And finally, rules with too many overrides are actually worse readable than classic debhelper style. I also have packages where the automatic build system detection of dh is wrong. Understandably wrong, but wrong nevertheless. Oh, and… to learn, automagisms are not so good, because you don’t see what’s going on, and can’t change it on an intuitive or more fine-granular level (though with DH_VERBOSE=1 mandated by default by recent Policy changes, this may have improved a little). So… to each their own. I’d make a case for non-debhelper to be allowed, but I know that’s not majority-capable… but if people wish to use debhelper, dh7, or even *shudder* dbs or cdbs, fine. Remember people make this often in their spare time and aren’t getting paid for it so please keep the fun factor. Thanks, //mirabilos -- This space for rent. https://paypal.me/mirabilos to support my work.
Re: Do we want to Require or Recommend DH
On Tue, Jun 04, 2019 at 01:37:46PM +, Thorsten Glaser wrote: > I’d also throw in that monocultures are not good, and that people > in general are happier when they aren’t forced into anything. Yet people in general are also happier when they don't need to learn all ways to do something. > Just yesterday I had a bug that wouldn’t have happened with a non-dh7 > rules file (incidentally, ordering matters, so I had to add a call to > mkdir -p debian/binarypackagename/some/directory into an over‐ ride). dh_installdirs runs pretty early in the install target, what needed that directory before dh_installdirs? > I also have packages where the automatic build system detection > of dh is wrong. Understandably wrong, but wrong nevertheless. It's a feature of dh_auto_* and not of dh. > Oh, and… to learn, automagisms are not so good, because you don’t > see what’s going on, You see what helpers are executed. You don't always see what do they do but that's unrelated to dh(1). > (though with DH_VERBOSE=1 mandated by default by recent Policy changes, > this may have improved a little). If you mean "The package build should be as verbose as reasonably possible" then it doesn't really mandate DH_VERBOSE=1. -- WBR, wRAR signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
Quoting Andrey Rahmatullin (2019-06-04 15:58:33) > On Tue, Jun 04, 2019 at 01:37:46PM +, Thorsten Glaser wrote: > > I’d also throw in that monocultures are not good, and that people in > > general are happier when they aren’t forced into anything. > Yet people in general are also happier when they don't need to learn > all ways to do something. Who says people need to learn _all_ ways? Must we all learn the ways of Java and DKMS and Haskell and and...? Nice if we can _generally_ handle _most_ packages. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Do we want to Require or Recommend DH
> "Thorsten" == Thorsten Glaser writes: Thorsten> I would very much like to argue that not using dh is not a Thorsten> bug, but Joey Hess, with his credentials ☺, did that Thorsten> already (and much better than I could): Thorsten> http://joeyh.name/blog/entry/80_percent/ He doesn't actually make that argument. >Not being part of Debian anymore, I'm in the position of needing to >point out something important about it anyway. So this post is less >about pointing in a specific direction as giving a different angle to >think about things. He argues that dh may have evolved to be around a 96% solution at this point. That's entirely consistent with the idea that not using dh could be a bug absent an exceptional situation. (Appologies for not looking up the wording from Ian's message; I mean what Ian calls unusual here.) Thorsten> tl;dr: dh started as 80% solution, it’s maybe an 96% Thorsten> solution now, but it’s not intended as, and won’t be, a Thorsten> 100% solution. Nor have we claimed that it is. There are several reasons for not using dh we've already identified. Thorsten> I’d also throw in that monocultures are not good, and that Thorsten> people in general are happier when they aren’t forced into Thorsten> anything. Agreed. Working on new tooling clearly needs to be one of the reasons for not using dh to allow for development of new things. Thorsten> Just yesterday I had a bug that wouldn’t have Thorsten> happened with a non-dh7 rules file (incidentally, ordering Thorsten> matters, so I had to add a call to mkdir -p Thorsten> debian/binarypackagename/some/directory into an over‐ Thorsten> ride). And finally, rules with too many overrides are Thorsten> actually worse readable than classic debhelper style. Thorsten> I also have packages where the automatic build system Thorsten> detection of dh is wrong. Understandably wrong, but wrong Thorsten> nevertheless. Thorsten> Oh, and… to learn, automagisms are not so good, because Thorsten> you don’t see what’s going on, and can’t change it on an Thorsten> intuitive or more fine-granular level (though with Thorsten> DH_VERBOSE=1 mandated by default by recent Policy changes, Thorsten> this may have improved a little). Thorsten> So… to each their own. I’d make a case for non-debhelper Thorsten> to be allowed, but I know that’s not majority-capable… but Thorsten> if people wish to use debhelper, dh7, or even *shudder* Thorsten> dbs or cdbs, fine. Remember people make this often in Thorsten> their spare time and aren’t getting paid for it so please Thorsten> keep the fun factor. The fun factor is important. My reading of the community consensus is that the points you bring up have been consider by the community. You did not bring up new issues. my reading is that the community believes that the fun factor of more uniformity when dealing with a lot of packages justifies the restriction of maintainer preference when there's not a sufficient justification for a tool other than dh. You're absolutely right that there is a tradeoff here. And I think that Debian of 10 or 15 years ago would have evaluated the tradeoff between the needs of a single maintainer and the needs of people doing work across a lot of packages differently. --Sam
Re: Do we want to Require or Recommend DH
> "Jonas" == Jonas Smedegaard writes: Jonas> Quoting Andrey Rahmatullin (2019-06-04 15:58:33) >> On Tue, Jun 04, 2019 at 01:37:46PM +, Thorsten Glaser wrote: >> > I’d also throw in that monocultures are not good, and that >> people in > general are happier when they aren’t forced into >> anything. Yet people in general are also happier when they don't >> need to learn all ways to do something. Jonas> Who says people need to learn _all_ ways? Jonas> Must we all learn the ways of Java and DKMS and Haskell and Jonas> and...? no, but some of us must or at least must be prepared to.
Re: Do we want to Require or Recommend DH
On Tue, Jun 04, 2019 at 04:10:38PM +0200, Jonas Smedegaard wrote: > > > I’d also throw in that monocultures are not good, and that people in > > > general are happier when they aren’t forced into anything. > > Yet people in general are also happier when they don't need to learn > > all ways to do something. > > Who says people need to learn _all_ ways? > > Must we all learn the ways of Java and DKMS and Haskell and and...? > > Nice if we can _generally_ handle _most_ packages. To be able to handle most packages we must mandate that most packages use an uniform workflow. That's different from "monocultures are not good" etc. -- WBR, wRAR signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
Sam Hartman dixit: >He doesn't actually make that argument. Hmm. Right, he doesn’t spell it out, but I got the impression. Perhaps my reading was wrong. >There are several reasons for not using dh we've already identified. Sure… but… >The fun factor is important. … that. >My reading of the community consensus is that the points you bring up >have been consider by the community. >You did not bring up new issues. This is diametral opposite to: >my reading is that the community believes that the fun factor of more >uniformity when dealing with a lot of packages justifies the restriction >of maintainer preference when there's not a sufficient justification for >a tool other than dh. No. A maintainer normally deals with their own packages, or with .dsc and debdiff, for NMU. (This is also an answer to the reply from wrar. Oh, jonas also said so, reloading the list index page.) Yes, some must learn those ways, but I don’t mind; that doesn’t mean I’m more comfortable in dh7. Usually I’m not except for extremely simple packages, or, partially, really new packages. >You're absolutely right that there is a tradeoff here. >And I think that Debian of 10 or 15 years ago would have evaluated the >tradeoff between the needs of a single maintainer and the needs of >people doing work across a lot of packages differently. Is “the Debian of today” the *Debian* of today, or just a couple of very involved people? Do you consider all those people who just take care of their own package, or couple of packages, in what little spare time they have? I doubt those very involved people, with hundreds of packages in their DDPO already (don’t laugh, I saw that), could shoulder the burden, were those others to leave disgruntled by things being forced onto them. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Re: Do we want to Require or Recommend DH
Thorsten Glaser writes ("Re: Do we want to Require or Recommend DH"):
> No. A maintainer normally deals with their own packages, or with
> .dsc and debdiff, for NMU. (This is also an answer to the reply
> from wrar. Oh, jonas also said so, reloading the list index page.)
"Maintainer" is precisely the hat we wear when working on our own
packages. But working with Debian is much more than just working on
our own packages.
There is QA work on the many packages with no specific maintainer;
there are cross-archive campaigns such as reproducible builds,
architecture support, init system diversity, i18n/l10n, and so on.
There is RC bugfixing etc. to try to make a release. There is
security support, stable release management, and backports.
And of course as users and downstreams we wish to exercise our
software freedom: ie to modify the programs that run on our computer.
That freedom being the point of Debian.
For all these tasks, we often need to interact with or modify the
package's build machinery (to varying extent). That means learning
the build machinery of every package we work on - at least well enough
to accomplish the task at hand.
> Is 'the Debian of today' the *Debian* of today, or just a couple of
> very involved people?
Well, Sam posed a consultation here on debian-devel. My assessment of
the rough consensus of the discussion here is very similar to Sam's.
Do you agree with Sam's assessment of the apparent consensus on this
list ?
If not, how do you think the question you pose should be answered ?
Since it is a question of tradeoffs, with no definite right or wrong
answer, perhaps we should hold a GR ? What do you think the result of
such a GR would be ?
I think such a GR would be a collosal waste of time. This issue is
not important enough. In particular, because the consensus is *not*
that you will *have to* change your packages. What this discussion
has mostly concluded is that we should issue a *recommendation*.
*Not* a mandate.
You may be gently encouraged to change your packages. In practice if
you refuse, it is not likely that anyone will want to fight you over
it. You will probably be able to leave the bug open "wontfix", if
there is a bug at all, indefinitely.
> I doubt those very involved people, with hundreds of packages in their
> DDPO already (don't laugh, I saw that), could shoulder the burden, were
> those others to leave disgruntled by things being forced onto them.
So, nothing will be forced onto you and you do not need to fight this.
But I would like you to consider this: the primary responsibility of
the maintainer of a Debian package is a *management* responsibility.
Our job as maintainer is not to do all the work. If we like to do the
work ourselves, great. If we don't and the work goes undone, well,
c'est la vie; maybe someone else will have the energy.
But our one un-shirkable responsibility is that of creating an
environment where *others* can contribute.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: ZFS in Buster
In our code of conduct we all made a commitment to start by assuming good faith of of our community. I'd like to remind us all to do that. Ian, the zfs maintainers have definitely been working in good faith. There was an unblock request filed May 9 attempting to address this issue. If you had been following debain-release you would have known that it was unlikely to be approved. And in fact it was not approved. However, it's in line with a number of other unblock requests that we'd all agree were submitted in good (if perhaps wishful) faith by people trying to value their packages. I'm not happy with the tone of the message from the zfs maintainers to the kernel team. But no, the zfs maintainers have been struggling to address this as best they are able, and they have been public with their comments in the right fora throughout the process. There has been no hiding here. There's a lot of frustration. I could wish for better communication. I could wish for a lot of things. For example, I could wish that Oracle would license zfs under the GPL and make a lot of us happier about the whole thing. Please have some respect and work with people who are trying to make Debian great in the ways that matter to them. Whether that's protectingcopyleft, the stability of our releases, or the needs of our users hoping for the latest and fastest features.
Re: Do we want to Require or Recommend DH
On Tue, Jun 04, 2019 at 02:27:03PM +, Thorsten Glaser wrote: > No. A maintainer normally deals with their own packages, or with > .dsc and debdiff, for NMU. (This is also an answer to the reply > from wrar. Oh, jonas also said so, reloading the list index page.) A maintainer normally deals with their own packages, except those people who actually prepare that NMU debdiff, yeah. Not sure what did you mean by this. > Yes, some must learn those ways, but I don’t mind; Does this mean "some must learn many different things to be able to make NMUs, but I don’t mind" or am I mistaken? -- WBR, wRAR signature.asc Description: PGP signature
Re: Do we want to Require or Recommend DH
Ian Jackson dixit: >There is QA work on the many packages with no specific maintainer; Sure, in that case I’ll have to take it over or deal with it. >there are cross-archive campaigns such as reproducible builds, >architecture support, init system diversity, i18n/l10n, and so on. These are done by specialists. I didn’t say *nobody* would need to learn the others, just that not *everyone* needs, especially not at first. >There is RC bugfixing etc. to try to make a release. There is This is either a good learning chance, or just tackle an RC bug in another package. >security support, stable release management, and backports. Again, specialists. >Well, Sam posed a consultation here on debian-devel. My assessment of >the rough consensus of the discussion here is very similar to Sam's. My point was to raise concerns of mine. >Do you agree with Sam's assessment of the apparent consensus on this >list ? I’ve not read the entire discussion here. I stumbled upon this by reading the DPL news and thus posted because I feared that the point important to me might be underrepresented. >Since it is a question of tradeoffs, with no definite right or wrong >answer, perhaps we should hold a GR ? What do you think the result of >such a GR would be ? Hmm, did not consider it, but a GR could fight being forced to use dh7 if needed. Thanks for the idea. >You may be gently encouraged to change your packages. In practice if >you refuse, it is not likely that anyone will want to fight you over >it. You will probably be able to leave the bug open "wontfix", if Perhaps. Perhaps not. Perhaps, if that’s acceptable, it’ll be enough. >there is a bug at all, indefinitely. If. If it isn’t, leaving it wontfix or closing is guaranteed to be acceptable. If it is, some clarification that it is acceptable is needed or we’re entering vague territories (such as, where people who don’t like a maintainer file RM requests against their packages because they don’t follow this-and-that latest fad). >So, nothing will be forced onto you and you do not need to fight this. If optimistic, yes. >But I would like you to consider this: the primary responsibility of >the maintainer of a Debian package is a *management* responsibility. Oh sure. But I just want to make the world better by packaging some software for Debian, some of which I happen to be upstream of, some of which I happen to have become upstream because of packaging it. I occasionally join in teams, but mostly just wish to quietly do my thing, undisturbed. >But our one un-shirkable responsibility is that of creating an >environment where *others* can contribute. Oh, sorry, but, I disagree. Others can contribute in other packages, I can do mine just fine. (Of course, the occasional contribution is welcome, but I’m not going to bend my ways for it.) Just like when I contribute somewhere, I’m, sometimes extremely rudely, asked to take my problem (or even patch) upstream myself or go sod off. bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: Do we want to Require or Recommend DH
❦ 4 juin 2019 15:47 +01, Ian Jackson : > If not, how do you think the question you pose should be answered ? > Since it is a question of tradeoffs, with no definite right or wrong > answer, perhaps we should hold a GR ? What do you think the result of > such a GR would be ? > > I think such a GR would be a collosal waste of time. This issue is > not important enough. In particular, because the consensus is *not* > that you will *have to* change your packages. What this discussion > has mostly concluded is that we should issue a *recommendation*. > *Not* a mandate. Well, a GR can be quick and it would help to know where people stand instead of having a few vocal people decide for everyone. I think we should impose the use of "dh" for bullseye (with an exception for teams with more then 50 packages), but I honestly don't know how much this opinion is shared. It seems there is a pattern to dissuade people to hold a GR. The last GR I remember is about changing "Chairman" to "Chair" in our constitution. I don't remember it was a waste of time and it was pretty quick. And the last "technical" GR was for systemd in 2014. We are in a project where it is very hard to be heard because you can only participate in endless debates. -- Let him choose out of my files, his projects to accomplish. -- Shakespeare, "Coriolanus" signature.asc Description: PGP signature
Re: ZFS in Buster
Sam Hartman writes ("Re: ZFS in Buster"):
> Ian, the zfs maintainers have definitely been working in good faith
...
> There has been no hiding here.
OK, good. Thank you. I am very glad to hear that I got the wrong end
of the stick.
I wrote that mail yesterday so I could sleep on it. Today I got a
number of people to review it before I sent it. I was very much not
the only person who read the message from Mo Zhou that bad way.
So thank you for the clarification, which I think is important.
I'm sorry if my message was a ham-fisted or offensive way of getting
that clarification. I'm particularly sorry to Mo Zhou for positing a
wrong allegation.
> However, it's in line with a number of other unblock requests that we'd
> all agree were submitted in good (if perhaps wishful) faith by people
> trying to value their packages.
That is of course fine. I have no problem with that. Indeed, it is
sometimes only by asking for what you really want that you find out
what is possible.
I would like to encourage people to ask for things even if they think
the answer is quite likely to be No. (NB this is not the same thing
as asking the same or very similar question again, after getting No.)
And those of us with gatekeeper roles should tolerate that, and when
we say No we should give reasons, state clearly any boundaries that
need reinforcing, and if possible make helpful alternative
suggestions.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: @debian.org mail
Hi On 2019/06/03 10:40, Daniel Lange wrote: We (debian/DSA) do not provide email hosting. We provide email forwarding. DSA should re-evaluate that. I strongly support this. I recall this being an issue during debconf 15 and 16 orga, and the situation has only gotten worse since. To do better, we should really offer SMTP submission/IMAP services for @debian.org as soon as possible and - after a grace period - publish a mx -all SPF record. I would certainly make use of SMTP for sending @debian.org email. I can't see the advantage of IMAP over forwarding though, would you explain how you see it working, or who would use it? Regards Graham
Using GRs
I definitely think that we should use GRs more. I think that the DPL can use their power to propose GRs to put a GR on the table with the common set of ballot options in a way that I hope might be seen as facilitating a discussion rather than trying to override people. I absolutely am happy using that power to break deadlocks and end endless discussions. I don't see a deadlock that needs breaking on the dh issue at this time. Right now we seem to be on track for being done June 16. --Sam
Re: Do we want to Require or Recommend DH
I think such a GR would be a collosal waste of time. This issue is not important enough. In particular, because the consensus is *not* GR's can be man made a collosal waste of time. Well, a GR can be quick and it would help to know where people stand instead of having a few vocal people decide for everyone. I think we should impose the use of "dh" for bullseye (with an exception for teams with more then 50 packages), but I honestly don't know how much this opinion is shared. I followed the discussion closely but i don't get some points. I assume that "dh" is here to stay - so in that case new packages should be done with "dh", older packages should be converted. There might be some packages which are not worth the additional work. Just leave a note why and everyone is happy. So a GR would be a appr. tool to solve this endless discussion fast. last "technical" GR was for systemd in 2014. We are in a project where it is very hard to be heard because you can only participate in endless debates. I for myself have no time for endless debates - i have things to do in Debian and upstream. And it's just boring to read the same arguments pro and esp. contra again and again. I was quiet until now because the debate don't change anything for me firsthand. I use dh for all my packages already and don't think i will change it in the future. The very most packages i'm interested in are dh - so no problem for me to read and maybe fix them if needed. Will i touch complex things written in cdbs? Hell no. Will i touch other complex things not in dh - hell, no, not worth the time. One might think of as a bit stubborn or short sighted, but to be true: It's lack of motivation - learning a bunch of things i'm not interested in to change things i'm not that interested in? Sounds nuts. A solution could be: Deprecate some thing like cdbs an others if they are really deprecated, be verbose about why and don't let packages that using these things go into the repository. Can be done stepwise. My 2¢ Alf
Re: @debian.org mail
On 2019-06-04 17:51:56, Graham Inggs wrote: > Hi > > On 2019/06/03 10:40, Daniel Lange wrote: > > To do better, we should really offer SMTP submission/IMAP services for > > @debian.org as soon as possible and - after a grace period - publish a > > mx -all SPF record. > > I would certainly make use of SMTP for sending @debian.org email. I can't > see the advantage of IMAP over forwarding though, would you explain how you > see it working, or who would use it? +1 on both counts.
Re: Do we want to Require or Recommend DH
On Tue, Jun 04, 2019 at 03:06:13PM +, Thorsten Glaser wrote: > Ian Jackson dixit: > >But our one un-shirkable responsibility is that of creating an > >environment where *others* can contribute. @Ian: I really like that quote that could define a modernised Debian. > Oh, sorry, but, I disagree. Others can contribute in other packages, > I can do mine just fine. (Of course, the occasional contribution is > welcome, but I’m not going to bend my ways for it.) IMHO this specifies Debian 15 years ago. I fear this attitude will decrease the relevance of Debian in future if we do not have the power to change. Kind regards Andreas. -- http://fam-tille.de
