Re: Worthless descriptions for almost all of the recent node-* ITPs (was: Re: Worthless node-* package descriptions in ITPs)
Hi Praveen, I assume that all these ITPs are prompted by your crowd-funding effort. Today we have #850399 which plumbs new depths in that it has had both long and short descriptions trimmed from the body of the message. Please would you take responsibility for your packaging team by instructing them that it is simply unacceptable to have these packages with such useless descriptions. The fact that they all seem to be trimming off the FIX_ME that npm2deb includes for them, and are thus also removing the explanation of what Node.js is, seems like vandalism to me. Did you tell them to do that, or are they learning that from one another? TBH I find this whole approach rather worrying. Are you paying these people for their efforts? Are we supposed to expect them to remain interested in these packages when the money dries up? If not, what is the plan for providing maintenance for these packages for the time that they are going to be in stable? Cheers, Phil. P.S. While you're at it, I would suggest that you encourage your packaging team to contact the upstreams in order to discover whether they are happy for their current release to be preserved in Debian stable -- I can imagine that some of them might be unhappy with the prospect of having the latest release packaged, if there are bug fixes in the HEAD that they don't want bug reports about for the next 5 years. They could then push out a release quickly and you could package that instead. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: nodejs 6.9 in unstable, manual transition, schedule
Jérémy Lal writes: > 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin : >> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote: >>> i really think it would be best to have nodejs 6.9 in next debian release. >>> That version is currently in experimental and i was about to upload it >>> to unstable, but i tried to do things right and prepared the addons >>> that need to be rebuilt and binNMUed, then opened a transition bug >>> #849505. >>> No answer yet, people are busy, and the number of concerned packages >>> is low (a dozen or so), should i just rebuild and upload them myself ? >> The transition freeze was on Nov 5. > > This is not very smart - i'm talking about something that will make future > maintenance and security patches easier, something that is easy to do > and that i can even do alone. Your "This is not very smart" comment made me react fairly negatively at first reading. It's easy to assume bad things about the old version's stability reading that, although that's presumably not what you were saying. Having looked into it a little, I found this: https://github.com/nodejs/LTS which shows that the current packaged v4 packages will drop out of LTS in April, and out of maintenance a year later according to this: https://hackernoon.com/node-js-v6-transitions-to-lts-be7f18c17159 Version 6, which Jérémy is suggesting should be our stable release version, has been in LTS mode since October, and will be in LTS mode until Apr 2018, then maintenance (presumably until Apr 2019). I suspect that in a couple of years time, that Node.js programmers will not be that much more impressed with v6 than they will be with v4, since both will be astonishingly ancient, but at least v6 buys us an extra year of usefulness. I suspect that it might be better for all concerned if we simply encouraged people to use this via backports from the start, to avoid the problem of fast-moving projects getting preserved in amber by Debian. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: nodejs 6.9 in unstable, manual transition, schedule
Hi Phil, Thanks for looking into this! Quoting Philip Hands (2017-01-06 12:53:10) > Jérémy Lal writes: > > > 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin : > >> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote: > >>> i really think it would be best to have nodejs 6.9 in next debian release. > >>> That version is currently in experimental and i was about to upload it > >>> to unstable, but i tried to do things right and prepared the addons > >>> that need to be rebuilt and binNMUed, then opened a transition bug > >>> #849505. > >>> No answer yet, people are busy, and the number of concerned packages > >>> is low (a dozen or so), should i just rebuild and upload them myself ? > >> The transition freeze was on Nov 5. > > > > This is not very smart - i'm talking about something that will make future > > maintenance and security patches easier, something that is easy to do > > and that i can even do alone. > > Your "This is not very smart" comment made me react fairly negatively at > first reading. It's easy to assume bad things about the old version's > stability reading that, although that's presumably not what you were > saying. > > Having looked into it a little, I found this: > > https://github.com/nodejs/LTS > > which shows that the current packaged v4 packages will drop out of LTS > in April, and out of maintenance a year later according to this: > > https://hackernoon.com/node-js-v6-transitions-to-lts-be7f18c17159 > > Version 6, which Jérémy is suggesting should be our stable release > version, has been in LTS mode since October, and will be in LTS mode > until Apr 2018, then maintenance (presumably until Apr 2019). > > I suspect that in a couple of years time, that Node.js programmers will > not be that much more impressed with v6 than they will be with v4, since > both will be astonishingly ancient, but at least v6 buys us an extra > year of usefulness. Until this point I thought you would summarize with a suggestion that we get v6 included in next stable Debian release (i.e. a plea to the release team to make an exception from their general rules). > I suspect that it might be better for all concerned if we simply > encouraged people to use this via backports from the start, to avoid the > problem of fast-moving projects getting preserved in amber by Debian. Do I understand you correctly that you recommend that we all tell our users - e.g. in release notes - something like this: "We acknowledge that the Nodejs included in this release is outdated, and recommend that you avoid it: Please instead subscribe to our snapshot repository and use the newer (but lesser supported) version from there."? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Re: Worthless descriptions for almost all of the recent node-* ITPs (was: Re: Worthless node-* package descriptions in ITPs)
Hi Praveen, On Fri, Jan 06, 2017 at 10:16:37AM +0100, Philip Hands wrote: > Hi Praveen, > > I assume that all these ITPs are prompted by your crowd-funding effort. > > Today we have #850399 which plumbs new depths in that it has had both > long and short descriptions trimmed from the body of the message. > > Please would you take responsibility for your packaging team by > instructing them that it is simply unacceptable to have these packages > with such useless descriptions. > > The fact that they all seem to be trimming off the FIX_ME that npm2deb > includes for them, and are thus also removing the explanation of what > Node.js is, seems like vandalism to me. Did you tell them to do that, > or are they learning that from one another? > > TBH I find this whole approach rather worrying. > > Are you paying these people for their efforts? > > Are we supposed to expect them to remain interested in these packages > when the money dries up? > > If not, what is the plan for providing maintenance for these packages > for the time that they are going to be in stable? > > Cheers, Phil. > > P.S. While you're at it, I would suggest that you encourage your > packaging team to contact the upstreams in order to discover whether > they are happy for their current release to be preserved in Debian > stable -- I can imagine that some of them might be unhappy with the > prospect of having the latest release packaged, if there are bug fixes > in the HEAD that they don't want bug reports about for the next 5 years. > They could then push out a release quickly and you could package that > instead. fully seconded, after reading #850399 (no description at all) and #850398 and #850397 just now (and many similar useless descriptions before), I'm really curious for your answers to Philip's question above. Are you paying these people for their efforts? Are we supposed to expect them to remain interested in these packages when the money dries up? If not, what is the plan for providing maintenance for these packages for the time that they are going to be in stable? Please elaborate. -- cheers, Holger signature.asc Description: Digital signature
Re: nodejs 6.9 in unstable, manual transition, schedule
2017-01-06 12:53 GMT+01:00 Philip Hands : > Jérémy Lal writes: > >> 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin : >>> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote: No answer yet, people are busy, and the number of concerned packages is low (a dozen or so), should i just rebuild and upload them myself ? >>> The transition freeze was on Nov 5. >> >> This is not very smart - i'm talking about something that will make future >> maintenance and security patches easier, something that is easy to do >> and that i can even do alone. > > Your "This is not very smart" comment made me react fairly negatively at > first reading. It's easy to assume bad things about the old version's > stability reading that, although that's presumably not what you were > saying. I'm asking you to forgive me about that wording, it was driven by my disappointment, and the reason the package is in this situation is mainly my own fault and lack of time. Jérémy
Re: "not authorised" doing various desktoppy things [and 1 more messages]
On Fri, 2017-01-06 at 07:48 +0100, Adam Borowski wrote: > On Thu, Jan 05, 2017 at 12:19:08PM +0100, Ansgar Burchardt wrote: > > With elogind do you mean https://github.com/wingo/elogind? That > > project doesn't look very active. > > > > Is there any active project trying to reimplement the logind API? > > Consolekit2 for example; it suffers from being a fork of consolekit > codebase though. That one looks indeed still active. > > Including access to devices (which X wants these days)? > > That's just for ancient graphics cards (ie, with no KMS/DRM support) > without xserver-xorg-legacy, right? logind is required for drivers using KMS and *not* the legacy suid wrapper, see /usr/share/doc/xserver-xorg-core/NEWS.Debian.gz. I think wayland does the same (I haven't used it though). So eventually alternatives should probably provide an alternative for this part of logind too. Ansgar
Re: Bug#850254: ITP: node-extract-zip -- unzip a zip file into a directory using 100% pure gluten-free organic javascript
On Thu, Jan 05, 2017 at 05:21:11PM +0530, Sumedh Pendurkar wrote: > * Package name: node-extract-zip > * URL : https://github.com/maxogden/extract-zip > Description : unzip a zip file into a directory using 100% pure > gluten-free organic javascript uhm, could you please remove that "gluten-free organic" from the short description? It comes across as offensive plus I also cannot see those terms at https://github.com/maxogden/extract-zip :/ (most people who need to eat gluten-free food don't do so by choice, but because of medical indication, aka, they are sick. Not funny in a package description.) -- cheers, Holger signature.asc Description: Digital signature
Re: unattended-upgrades by default
Two months ago, Steve wrote:
> * enable it for installation via d-i by default. At installation
[it being unattended-upgrades]
What's the status of this? I do not like this idea, it interacts
poorly with desktops which handle upgrades via PackageKit (which
is the default) and since there are locking races in apt invoking
dpkg, it's not really a safe thing to do anyway, causing issues
like https://bugs.debian.org/850417
I'd really like to default this to disabled, and add a warning
about how it interacts with other systems and that people should
take care running apt manually when the unattended upgrades would
run, as that can break things.
I'm not subscribed to -devel, so please CC me on replies.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Re: "not authorised" doing various desktoppy things [and 1 more messages]
On Fri, Jan 06, 2017 at 01:58:50PM +0100, Ansgar Burchardt wrote: > > > Including access to devices (which X wants these days)? > > > > That's just for ancient graphics cards (ie, with no KMS/DRM support) > > without xserver-xorg-legacy, right? > > logind is required for drivers using KMS and *not* the legacy suid > wrapper, see /usr/share/doc/xserver-xorg-core/NEWS.Debian.gz. Nope, I don't have systemd (and thus logind) on any of my non-virtual machines, I don't have xserver-xorg-legacy either, yet X works fine. I've just pulled out the oldest box I have in my junk pile (a pre-amd64 Pentium4 with Intel 82915G/GV/910GL), installed current X on it -- works fine without logind. Non-KMS stuff you need xorg-legacy for sounds ISAish. On the other hand, hurd which has no KMS does need xorg-legacy. > I think wayland does the same (I haven't used it though). Me neither. > So eventually alternatives should probably provide an alternative for > this part of logind too. I guess that "relies on logind" part is true only under systemd? At least, other VT manipulating tools like "open" run into permissions problem there too. Meow! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11
Re: Converting to dgit
On Fri, 2017-01-06 at 00:41 -0500, Scott Kitterman wrote: > On Friday, January 06, 2017 12:29:54 AM IOhannes m zmölnig wrote: > > On 01/04/2017 05:42 AM, Colin Watson wrote: > > > git-dpm does too, and I agree it's nice. > > > > here's an opposite data point: > > > > being forced to use git-dpm by the python-modules-team policy - i > > haven't had a single joyful experience with git-dpm. > > so far, every import of a new upstream release turned into a nightmare > > with an extra working clone of the repository, and skimming through the > > same man- and webpages full of outdated documentation even though i'm > > pretty sure that the required information was there the last time i looked. > > > > git-dpm might be useful if you use it daily. > > as it stands, i'm a very happy gbp user (without fancy addons) for > > almost all of my packages, and the few python modules i maintain don't > > do releases that often (which explains why i don't get a routine for > > doing new upstream imports with git-dpm). > > I don't use it often enough to remember all the details either. I don't > recall the last time I had to do more than copy/paste a command from the man > page (OK, git-dpm tag I can remember). Besides, git-dpm usually tells you what command to run next, like: git-dpm import-new-upstream -> git-dpm rebase-patched -> git-dpm update-patches It did not take me much time to adapt to the git-dpm workflow as a result. I should say that I have been a happy git-dpm user so far. Ghis
Re: nodejs 6.9 in unstable, manual transition, schedule
Jonas Smedegaard writes: > Hi Phil, > > Thanks for looking into this! > > Quoting Philip Hands (2017-01-06 12:53:10) >> Jérémy Lal writes: >> >> > 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin : >> >> On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote: >> >>> i really think it would be best to have nodejs 6.9 in next debian >> >>> release. >> >>> That version is currently in experimental and i was about to upload it >> >>> to unstable, but i tried to do things right and prepared the addons >> >>> that need to be rebuilt and binNMUed, then opened a transition bug >> >>> #849505. >> >>> No answer yet, people are busy, and the number of concerned packages >> >>> is low (a dozen or so), should i just rebuild and upload them myself ? >> >> The transition freeze was on Nov 5. >> > >> > This is not very smart - i'm talking about something that will make future >> > maintenance and security patches easier, something that is easy to do >> > and that i can even do alone. >> >> Your "This is not very smart" comment made me react fairly negatively at >> first reading. It's easy to assume bad things about the old version's >> stability reading that, although that's presumably not what you were >> saying. >> >> Having looked into it a little, I found this: >> >> https://github.com/nodejs/LTS >> >> which shows that the current packaged v4 packages will drop out of LTS >> in April, and out of maintenance a year later according to this: >> >> https://hackernoon.com/node-js-v6-transitions-to-lts-be7f18c17159 >> >> Version 6, which Jérémy is suggesting should be our stable release >> version, has been in LTS mode since October, and will be in LTS mode >> until Apr 2018, then maintenance (presumably until Apr 2019). >> >> I suspect that in a couple of years time, that Node.js programmers will >> not be that much more impressed with v6 than they will be with v4, since >> both will be astonishingly ancient, but at least v6 buys us an extra >> year of usefulness. > > Until this point I thought you would summarize with a suggestion that we > get v6 included in next stable Debian release (i.e. a plea to the > release team to make an exception from their general rules). > >> I suspect that it might be better for all concerned if we simply >> encouraged people to use this via backports from the start, to avoid the >> problem of fast-moving projects getting preserved in amber by Debian. > > Do I understand you correctly that you recommend that we all tell our > users - e.g. in release notes - something like this: "We acknowledge > that the Nodejs included in this release is outdated, and recommend that > you avoid it: Please instead subscribe to our snapshot repository and > use the newer (but lesser supported) version from there."? I wasn't going as far as recommending anything -- I was just trying to cover various aspects of this in the hope that we might then discuss the pros and cons of the choices available before the release rather than drifting into doing something that doesn't really suit anyone very well. I don't know enough about the implications of upgrading to have any strong opinions about what the best course of action might be. It just struck me that to have v4 enter Debian stable just at the point that it drops out of Node.js LTS is unlikely to be the optimal choice. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: nodejs 6.9 in unstable, manual transition, schedule
Jérémy Lal writes: > 2017-01-06 12:53 GMT+01:00 Philip Hands : >> Jérémy Lal writes: >> >>> 2017-01-04 10:04 GMT+01:00 Andrey Rahmatullin : On Wed, Jan 04, 2017 at 09:54:34AM +0100, Jérémy Lal wrote: > No answer yet, people are busy, and the number of concerned packages > is low (a dozen or so), should i just rebuild and upload them myself ? The transition freeze was on Nov 5. >>> >>> This is not very smart - i'm talking about something that will make future >>> maintenance and security patches easier, something that is easy to do >>> and that i can even do alone. >> >> Your "This is not very smart" comment made me react fairly negatively at >> first reading. It's easy to assume bad things about the old version's >> stability reading that, although that's presumably not what you were >> saying. > > I'm asking you to forgive me about that wording, it was driven by my > disappointment, > and the reason the package is in this situation is mainly my own fault > and lack of time. Nothing to forgive from my point of view -- you just happened not to be making your case very persuasively. Feel free to tell us all how there's no problem rebuilding/testing the thousand-odd node-* packages, or that they don't need rebuilding or testing, or whatever the case might be, such that people might be moved to agree with you. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Feedback on 3.0 source format problems
Sean Whitton writes ("Re: Feedback on 3.0 source format problems"):
> Could you explain in general terms the difference between the
> interchange and packaging-only branches
See modified diagram below. Are the annotations I have added (and the
name change) any help ?
> Does the packaging-only branch contain debian/ alone?
No, it also contains a complete unmodified copy of the upstream code.
(Except that if upstream had a debian/ directory, it is completely
replaced.) Perhaps this is the wrong name. Let's try
`merging-baseline'
For `3.0 (quilt)' the merging-baseline branch contains roughly what
you would get if you untarred the origs and the debian.tar.gz, and
then deleted all the patches without applying them.
Not shown on the diagram is the commit `add patch queue to
debian/patches', which would be needed for `3.0 (quilt)'. This is
because the diagram is in terms of a sane source format, not `3.0
(quilt)'. For use with quilty sources, there would be such a commit
(probably dgit-generated) on top of the actual upstream change
commits:
--/--A!/--B3!--%--/--> interchange view
// / with debian/ directory
%% % all upstream changes applied
// /3.0 (quilt) has debian/patches
/2* 2*
// /
2* 2 2
// /
11 1`merging-baseline' branch
// / unmodified upstream code
---p-p--Ap--B--C--> plus debian/ (but no debian/patches)
/ / /
--#-#---#-> upstream
Key:
1,2,3 commits touching upstream files only
A,B,C commits touching debian/ only
B3 mixed commit (eg made by an NMUer)
# upstream releases
-p- special merge, takes contents of debian/ from the
/ previous `merging-baseline' commit and rest from upstream
-/- pseudomerge; contents are identical to
/ parent lower on diagram.
% dgit-generated commit of debian/patches.
`3.0 (quilt)' only; dropped by rebase tool.
* Maintainer's HEAD was here while they were editing,
before they said they were done, at which point their
tools generated [% and] -/- commit[s] to convert to
the fast-forwarding interchange branch. (Maybe the
tooling is simply `dgit push'.)
! NMUer's HEAD was here when they said `dgit push'.
Rebase branch launderer turns each ! into an
equivalent *.
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: nodejs 6.9 in unstable, manual transition, schedule
Quoting Philip Hands (2017-01-06 15:48:07) > Jonas Smedegaard writes: >> Do I understand you correctly that you recommend that we all tell our >> users - e.g. in release notes - something like this: "We acknowledge >> that the Nodejs included in this release is outdated, and recommend >> that you avoid it: Please instead subscribe to our snapshot >> repository and use the newer (but lesser supported) version from >> there."? > > I wasn't going as far as recommending anything -- I was just trying to > cover various aspects of this in the hope that we might then discuss > the pros and cons of the choices available before the release rather > than drifting into doing something that doesn't really suit anyone > very well. I don't know enough about the implications of upgrading to > have any strong opinions about what the best course of action might > be. > > It just struck me that to have v4 enter Debian stable just at the > point that it drops out of Node.js LTS is unlikely to be the optimal > choice. Makes sense. Thanks! - 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: Feedback on 3.0 source format problems
Sebastian Andrzej Siewior writes ("Re: Feedback on 3.0 source format problems"):
> On 2017-01-03 16:58:21 [+], Ian Jackson wrote:
> > Looked at another way, it is trying to be a version control system,
> > layered on top of the Debian archive. But it is only about a quarter
> > of a VCS. There are no formal interfaces to do proper VCS operations.
> > If there is a formal interface, it is quilt(1) (which is itself very
> > poor. NB that is not quilt's fault: quilt inevitably has a hard job
> > because can't make enough assumptions).
>
> there quilt push, pop and header which seems enough.
Well, it seems you don't really think so :-), because:
> I usually have git-dpm which creates the quilt series and I try to
> keep patches documented.
So you are using git operations to manipulate your patch stack.
git-dpm is one of the tools we have which lets you do that.
> > I think if we want to be storing patch queues we should be doing so in
> > a real version control system. Indeed, most people are doing that.
> > For now many people are using `3.0 (quilt)' as an interchange format,
> > but ideally we would switch to a useable git workflow that did a
> > similar thing, and then we could use git as our history interchange
> > format.
>
> I read this a few times in this thread that people want the patches in a
> VCS. I never saw this a missing feature or requirement on my side.
...
> I can't think of an example where having a patch history somewhere else
> than within the patch itself is useful. My thinking is probably limited
> by my workflow :) Would you have an example where and how this could be
> usefull?
You have misunderstood, I think. I don't mean (and I think most
other people don't mean) that they want the history _of_ a patch.
That is, we aren't saying we want to look at the output of
`git blame debian/patches/01-sponge.patch'.
Rather, we think manipulating a stack of patches is much easier if one
converts the patches to a git branch, with each patch becoming a
commit (using a tool morally equivalent to git-am, such as gbp pq
import).
Naturally that doesn't end up recording a history _of_ the patches,
because the patches _become_ `the history'. Then one manipulates the
patches with git-rebase (or similar tools), git-commit,
git-cherry-pick, etc.
Finally, when doing an upload, one converts the git branch back into
patches (with a tool morally equivalent to git-format-patch).
I think only a minority of people are actually using quilt on
debian/patches.
Regards,
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: Feedback on 3.0 source format problems
Ian Jackson writes ("Re: Feedback on 3.0 source format problems"):
> ! NMUer's HEAD was here when they said `dgit push'.
> Rebase branch launderer turns each ! into an
> equivalent *.
I mean it turns each % into an equivalent *, but it work on !s too.
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: Worthless descriptions for almost all of the recent node-* ITPs
On വെള്ളി 06 ജനുവരി 2017 02:46 വൈകു, Philip Hands wrote: > Hi Praveen, > > I assume that all these ITPs are prompted by your crowd-funding effort. You assumption is wrong. It is better to ask than assume. If it were part of the crowd funding campaign, I'd have updated the -devel thread. The initial crowd funding target was gulp and webpack. gulp is completed and we are skipping webpack for now because the target was not achived and also hoping rollup can be used instead. > Today we have #850399 which plumbs new depths in that it has had both > long and short descriptions trimmed from the body of the message. > > Please would you take responsibility for your packaging team by > instructing them that it is simply unacceptable to have these packages > with such useless descriptions. I have told them to try and write good descriptions. > The fact that they all seem to be trimming off the FIX_ME that npm2deb > includes for them, and are thus also removing the explanation of what > Node.js is, seems like vandalism to me. Did you tell them to do that, > or are they learning that from one another? I told them to write good descriptions, but its hard to write when README/upstream documentation is missing any description. > TBH I find this whole approach rather worrying. We have different severity levels for bugs for a reason. It is unsustainable to treat every bug as rc. If someone offers to help with better descriptions we will happily add them. TBH it is even hard for me to write more descriptions. I don't think it is meaningful to fill the descriptions with something for the sake for the sake of it. > Are you paying these people for their efforts? No. This is part of the workshop organized by a college (College of Engineering Pune). Only interested students turned up for the workshop. This was a follow up event of the mini debconf we organized in the same college (http://in2016.mini.debconf.org/). The college is paying me to take the workshop. We (I and Prof Abhijit who is organizing this workshop) offered a Free Software development elective earlier in 2012 and it is continuing this year as well. Since this was a local event, I posted only in debian-dug-in list and #debian-in irc channel. https://lists.debian.org/debian-dug-in/2016/12/msg1.html > Are we supposed to expect them to remain interested in these packages > when the money dries up? > > If not, what is the plan for providing maintenance for these packages > for the time that they are going to be in stable? You can see more discussion on pkg-javascript team mailing list on this topic http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2017-January/017217.html All these packages are required for packaging ava, which is required to run tests of many other node libraries we packaged for getting grunt and gulp in debian. https://wiki.debian.org/Javascript/Nodejs/Tasks/ava It is my intention to maintain these build tools in debian, since this is a huge task, I'm eager to find more people join that effort and I hope to find more people to help me in this effort through workshops like these. > Cheers, Phil. > > P.S. While you're at it, I would suggest that you encourage your > packaging team to contact the upstreams in order to discover whether > they are happy for their current release to be preserved in Debian > stable -- I can imagine that some of them might be unhappy with the > prospect of having the latest release packaged, if there are bug fixes > in the HEAD that they don't want bug reports about for the next 5 years. > They could then push out a release quickly and you could package that > instead. > There is much choice we have here as I was forced to package these. I'd have happily maintained diaspora if an exception was granted for ruby-handlebars-assets. You cannot ask people to do mutually exclusive things. signature.asc Description: OpenPGP digital signature
Re: Converting to dgit
Hello Nikolaus, On Thu, Jan 05, 2017 at 03:59:40PM -0800, Nikolaus Rath wrote: > On Jan 05 2017, Sean Whitton wrote: > > On Thu, Jan 05, 2017 at 12:39:25PM -0800, Nikolaus Rath wrote: > >> But, as far as I can tell, doing this work up-front is much easier: > > > > Yes, but you have to do it every single time you make changes that you > > want to be able to push (i.e. more than once per upload). > > What do you mean with "it"? You don't have to resolve any conflicts > unless you update to a new upstream that conflicts with your patches, or > unless you change a patch in such a way that it conflicts with a > different patch. Sorry to have been unclear. I meant the `gbp import`, (at a minimum) check things are right, `gbp export` dance. This is a lot more work than `git commit`! -- Sean Whitton signature.asc Description: PGP signature
Re: Feedback on 3.0 source format problems
On Fri, 06 Jan 2017 15:37:48 +, Ian Jackson wrote: > I think only a minority of people are actually using quilt on > debian/patches. I have a different impression (but no proof either of course). Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Die Quote: Tonight signature.asc Description: Digital Signature
Re: unattended-upgrades by default
On Fri, Jan 06, 2017 at 02:13:58PM +0100, Julian Andres Klode wrote: > Two months ago, Steve wrote: > > * enable it for installation via d-i by default. At installation > [it being unattended-upgrades] > > What's the status of this? I do not like this idea, it interacts > poorly with desktops which handle upgrades via PackageKit (which > is the default) and since there are locking races in apt invoking > dpkg, it's not really a safe thing to do anyway, causing issues > like https://bugs.debian.org/850417 > > I'd really like to default this to disabled, and add a warning > about how it interacts with other systems and that people should > take care running apt manually when the unattended upgrades would > run, as that can break things. I don't like it either. In addition to the reasons already explained, bandwidth is a precious resource that should not become mostly unavailable at random times by default. A sudden drop in available bandwidth could be as inappropriate as an anti-virus popping up. Imagine that happening during a presentation in which you expect all bandwidth to be available. If we want to be the Universal OS, we can't assume that any time (not chosen by the user) is ok to do an upgrade. Thanks.
Re: unattended-upgrades by default
On Jan 06 2017, Santiago Vila wrote: > If we want to be the Universal OS, we can't assume that any time > (not chosen by the user) is ok to do an upgrade. If we want to be the Universal OS, we can't assume that users will explicitly trigger an install of security upgrades either. Nor can we assume that running without security updates is acceptable. What now? (Sorry for not being constructive, but these "Universal OS" arguments can really be used to argue for and against anything). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Can we kill net-tools, please?
Hi, I'm confused... On Thu, Dec 29, 2016 at 09:01:51PM +0500, Andrey Rahmatullin wrote: > On Thu, Dec 29, 2016 at 10:30:26AM -0500, Theodore Ts'o wrote: > >Ifconfig has been deprecated; you should probably use "ip a show > >dev lo" instad of the shorter and more convenient "ifconfig lo" > ... and often wrong The BSD ifconfig can do this with ease, and since ages, too. Why is the Linux ifconfig _so_ different? Forking for the sake of it? Eg adding an IPv6 address: # ifconfig em0 inet6 address alias and removing it: # ifconfig em0 inet6 address -alias Just asking. Cheers, --Toni++ PS: http://man.openbsd.org/OpenBSD-current/man8/ifconfig.8
Re: unattended-upgrades by default
On Sat, Jan 7, 2017 at 6:29 AM, Nikolaus Rath wrote: > What now? Clearly the answer of unattended-upgrades or not is situation dependent and the solution should depend on who is running Debian in what context. Desktop users should get whatever UI is available for the particular desktop that is installed that installs upgrades on shutdown and suggests upgrades when available. Cloud users should get unattended-upgrades by default. etc -- bye, pabs https://wiki.debian.org/PaulWise
Re: Feedback on 3.0 source format problems
Le 06/01/2017 à 16:37, Ian Jackson a écrit :
> Sebastian Andrzej Siewior writes ("Re: Feedback on 3.0 source format
> problems"):
>> On 2017-01-03 16:58:21 [+], Ian Jackson wrote:
>>> Looked at another way, it is trying to be a version control system,
>>> layered on top of the Debian archive. But it is only about a quarter
>>> of a VCS. There are no formal interfaces to do proper VCS operations.
>>> If there is a formal interface, it is quilt(1) (which is itself very
>>> poor. NB that is not quilt's fault: quilt inevitably has a hard job
>>> because can't make enough assumptions).
>>
>> there quilt push, pop and header which seems enough.
>
> Well, it seems you don't really think so :-), because:
>
>> I usually have git-dpm which creates the quilt series and I try to
>> keep patches documented.
>
> So you are using git operations to manipulate your patch stack.
> git-dpm is one of the tools we have which lets you do that.
Well, just to say, I'm personally quite happy with '3.0 (quilt)'. I try
to maintain all my packages in git in unapplied state, because in my
opinion this is the sensible thing to do. When I do a
git diff upstream master
I want to see only debian/ in there. I much prefer to check a diff of
diff over a simple diff, because most of the time I want to see what
changed in the packaging, not in the final state. When I want to do the
later, I use debdiff.
For me the patch is the final product, I like the clear separation
between upstream and debian/, so it's for me a very appealing design to
have individual patches in debian/patches. I use git to keep the history
of the patch, not to manage it.
I manage my patches using quilt. I would really prefer if sbuild et al.
would revert the patches after building by default, but that's life. I
respect that other people have other views.
I'm not interested at the moment in dgit or other wrappers because
1- they seem to me to add complexity to the process;
2- I prefer to understand what I'm doing.
Kind regards, Thibaut.
--
* Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) *
* Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon *
* Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen*
* thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) *
smime.p7s
Description: Signature cryptographique S/MIME
Bug#850493: ITP: node-co-with-promise -- generator async control flow goodness
Package: wnpp Severity: wishlist Owner: Ravishankar Purne X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-co-with-promise Version : 4.6.0 Upstream Author : FIX_ME upstream author * URL : https://github.com/tj/co * License : Expat Programming Lang: JavaScript Description : generator async control flow goodness
