Re: Bug#862698: ITP: minecraft -- blocks to build anything you can imagine
On May 16, Simon McVittie wrote: > Yes, that's why I suggested Flatpak. It would also be possible to use > a long bwrap command-line - that's what Flatpak does internally. > One day I should try making game-data-packager's games (mostly the quake > family) use bwrap like that. This would be easier if we had and could > rely on "the /usr merge" - Flatpak runtimes always use merged-/usr > for that reason. Sure you can: just depend on the usrmerge package. :-) -- ciao, Marco signature.asc Description: PGP signature
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
On 16/05/2017 07:07, Mechtilde wrote: > these two questions come into my mind: > > What does a "newcomer" expect from > such a website? > what do we expect from a newcomer? > > To go from user to dev is a gliding way. > > "Want To Become Debian Developer" is the last step for a dev not the > first one. IMO > > We should try to differ into the different tasks for the user e.g: > > * Installation > * Configuration > * Applications > * ... > * How can I help > * Structure of the Packages > * Packaging > * ... > > +1 And there is a confusion over "dynamic web sites" (maybe problematic) with "non-static content" (must have). We should vividly demonstrate on our home page that we are just that - alive and developing. If we could have users contribute success stories like "I switched my Granny from Windows to Debian and she likes it" or "We autoconfigure our HPC cluster in the cloud with Debian and Ansible, saving us 30 grand this year" then we have enough to get people hooked and invest to dig deeper into the site, I tend to think. So, I see: * something along the lines of Mechthilde * dynamic user-provided feedback that we can annotate further with references to HOWTOs etc for new users that want to share that experience, i.e. a smaller Debian+Derivatives-centric stackoverflow kind of thing that starts off with a success rather than with a problem Steffen
Bug#862809: ITP: node-set-immediate-shim -- Simple setImmediate shim
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-set-immediate-shim Version : 1.0.1 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/set-immediate-shim * License : Expat Programming Lang: JavaScript Description : Simple setImmediate shim setImmediate allows scripts to yield to the browser, executing a given operation asynchronously, in a manner that is typically more efficient and consumes less power than the usual setTimeout(..., 0) pattern. This library provides a simple setImmediate shim. . This library is a dependency of readdirp. Even though we have setimmediate packaged, patching readdirp to use it is more work. . Node.js is an event-based server-side JavaScript engine. This situation was discussed in the pkg-javascript-devel list and packaging it was considered the better option. http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2017-May/018996.html signature.asc Description: OpenPGP digital signature
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
Steffen Möller writes ("Re: When do we update the homepage to a modern design?
(was Re: Moving away from (unsupportable) FusionForge on Alioth)"):
> And there is a confusion over "dynamic web sites" (maybe problematic)
> with "non-static content" (must have).
I don't know what these terms mean. I see four kinds of ways in which
a website might be `dynamic' as opposted to `static':
* Content which is updated fairly frequently and relates to recent
events, such as news stories, blog posts, and testimonials.
I have no objection to this kind of thing and I can see how it
might make our website seem more exciting.
* Websites which reorganise themselves through CSS and/or JavScript
to try to produce a better selection of visibloe bits depending on
the screen size.
I find these mildly annoying, but I don't use a smartphone and
apparently smartphones are terrible at laying out ordinary web
pages (because wtf?). I don't really object to this kind of
approach so long as all features remain accessible (perhaps through
extra clicks) even on small screens, and there is sensible fallback
if JavaScript and/or CSS are not supported.
* Websites with elements which, when you move the mouse, pop up
menus, change shape or colour, etc. etc. I find these intensely
irritating. Often they are buggy too.
* Websites with elements which move even when you don't touch the
computer. This is an outrage - an outrage, I tell you! That
web browsers even honour this kind of thing by default is a
travesty. Rant rant rant.
Can some webby person please tell me the conventional names for these
four levels of dynamism ?
> We should vividly demonstrate on our home page that we are just that -
> alive and developing. If we could have users contribute success stories
> like "I switched my Granny from Windows to Debian and she likes it" or
> "We autoconfigure our HPC cluster in the cloud with Debian and Ansible,
> saving us 30 grand this year" then we have enough to get people hooked
> and invest to dig deeper into the site, I tend to think.
That sounds like it would be nice, but it shouldn't take away from the
navigation parts of our site. We have a lot of information; the
problem I find is that it can be difficult to find.
Ian.
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
On Wed, 17 May 2017 at 13:33:06 +0100, Ian Jackson wrote: > * Websites which reorganise themselves through CSS and/or JavScript >to try to produce a better selection of visibloe bits depending on >the screen size. > >I find these mildly annoying, but I don't use a smartphone and >apparently smartphones are terrible at laying out ordinary web >pages (because wtf?). The jargon term for this is *responsive design*. It's essentially the same principles as Web 1.0 best-practices - graceful degradation and willingness to re-flow for arbitrary viewport widths - together with some CSS magic to hide or shrink non-essential content, reduce margins, or convert multi-column designs into a single-column stack when viewed on a small screen. The problem, apart from smartphone screens just not being very big, is that mobile browsers and websites are engaged in a "do what I mean" loop where each side works around bugs in the other. If not told otherwise, mobile browsers assume that websites were designed with the "requires Internet Explorer on 1024x768" mindset and render the page at a width similar to a traditional desktop browser, because if they didn't, badly designed websites would be unreadable and so nobody would use that browser. As a result, if a website *is* designed to scale gracefully to narrow widths, it has to announce that in metadata so that mobile browsers will stop applying that workaround. It looks as though the Debian website (or at least its front page) already has responsive design and the necessary runes to make mobile browsers make use of it, although it could perhaps benefit from dropping more content (requiring extra clicks instead) at small sizes. S
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
Simon McVittie writes ("Re: When do we update the homepage to a modern design?
(was Re: Moving away from (unsupportable) FusionForge on Alioth)"):
> On Wed, 17 May 2017 at 13:33:06 +0100, Ian Jackson wrote:
> > * Websites which reorganise themselves through CSS and/or JavScript
> >to try to produce a better selection of visibloe bits depending on
> >the screen size.
...
> The jargon term for this is *responsive design*. [...]
Thanks for the explanation.
> The problem, apart from smartphone screens just not being very big,
> is that mobile browsers and websites are engaged in a "do what
> I mean" loop where each side works around bugs in the other.
Gagh, world is so shit. Fine, whatever.
> It looks as though the Debian website (or at least its front page)
> already has responsive design and the necessary runes to make mobile
> browsers make use of it, although it could perhaps benefit from
> dropping more content (requiring extra clicks instead) at small sizes.
OK, good.
I don't have any clear idea show close the views of the Debian project
as whole are to the ones I expressed in my article, but I'm pretty
sure that my views as expressed there are at least those of a
significant and vocal minority :-). They might even be the majority
view, but we sowouldn't be able to tell without a GR - and let's not.
Thanks,
Ian.
Bug#862828: ITP: quorum -- QUality Optimized Reads of genomic sequences
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: quorum Version : 1.1.1 Upstream Author : Guillaume Marçais, Aleksey Zimin * URL : https://github.com/gmarcais/Quorum * License : GPL Programming Lang: C++ Description : QUality Optimized Reads of genomic sequences QuorUM enables to obtain trimmed and error-corrected reads that result in assemblies with longer contigs and fewer errors. QuorUM provides best performance compared to other published error correctors in several metrics. QuorUM is efficiently implemented making use of current multi- core computing architectures and it is suitable for large data sets (1 billion bases checked and corrected per day per core). The third-party assembler (SOAPdenovo) benefits significantly from using QuorUM error- corrected reads. QuorUM error corrected reads result in a factor of 1.1 to 4 improvement in N50 contig size compared to using the original reads with SOAPdenovo for the data sets investigated. Remark: I'm not very happy about the generic name - any suggestions for a better choice? The package will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/quorum.git
Re: Bug#862775: ITP: visitors -- OCaml syntax extension for object-oriented visitors
On Wed, May 17, 2017 at 11:28:12AM +0800, Paul Wise wrote: > On Wed, May 17, 2017 at 3:51 AM, Ralf Treinen wrote: > > > * Package name: visitors > > Version : 20170404 > > FYI, there was already a visitors source package in Debian (RMed after > jessie) so I would suggest using a less generic source name, maybe > ocaml-visitors. OK, will do. -Ralf.
Re: Moving away from (unsupportable) FusionForge on Alioth?
Hi, On Mon, May 15, 2017 at 02:43:56PM +0200, Johannes Schauer wrote: > > The top 10 teams with packages in SVN are: > > 347 Debian Med Packaging Team > This number contains possibly 150 packages that *could* be migrated - provided somebody wants to take the time for some unproductive work. However, we intentionally do packaging of new R CRAN packages in SVN since in this case packaging is brain dead simple and we keep only the debian/ dir and not the upstream source in VCS. This is a sensible and established workflow and currently there is no short term plan to change this. In short: There is no doubt that Git is the better VCS but spending developer time simply to switch lots of packages from an old VCS to a modern one has zero effect on users desktops and has no high priority. Kind regards Andreas. -- http://fam-tille.de
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Wed, May 17, 2017 at 10:19:24PM +0200, Andreas Tille wrote: > In short: There is no doubt that Git is the better VCS but spending > developer time simply to switch lots of packages from an old VCS to a > modern one has zero effect on users desktops and has no high priority. I wonder... The problem here is about fusionforge only, in fact. If we were to move git (i.e. the vast majority of its usage) to another place, and took down fusionforge (i.e. no more guest user management), I do not think there is a reason to shut down the rest. SVN could stay there, with viewvc and everything, and let packages and project migrate whenever they need something not provided by old-alioth (f.e. direct contribution from a non-DD that won't be possible without fusionforge running to create its user and dealing with groups). @tille: please have a look at pkg-haskell and their DHG_packages repository. I've never interacted with it, and I find it highly unusual and non-standard that I doubt the usual tooling can deal with it, but it might of ispiration about how to deal with R packages maybe? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Wed, May 17, 2017 at 10:19:24PM +0200, Andreas Tille wrote:
> In short: There is no doubt that Git is the better VCS but spending
> developer time simply to switch lots of packages from an old VCS to a
> modern one has zero effect on users desktops and has no high priority.
I think that in the mid-term (probably even in short term) you'll *save*
developer time by switching to git, so that actually right now your choice
to not switch to git has an effect on users desktops: they get stuff later.
And also you're imposing a stupid tool to anyone who wants to help out or
do security fixes.
I'd be happy if Debian would enforce git for every source package now!
git clone https://src.fedoraproject.org/cgit/rpms/${srcpkg}.git is really
awesome and works for every package in Fedora! (*)
https://fedoraproject.org/wiki/Packaging:Guidelines says:
Spec Maintenance and Canonicity
Fedora's git repository is the canonical location for Fedora spec files.
Maintainers MUST expect that other maintainers and automated tooling will
make changes to their packages, potentially without communicating prior to
doing so (though communication is always encouraged). If some maintainers
are also attempting to keep copies of a spec in an outside repository, they
MUST be prepared to merge changes made to the spec in Fedora's repository,
and MUST NOT overwrite those changes with a copy from an external repository
or using fedpkg import.
Debian aims to be the universal OS, but that doesn't mean we have to support
an universe of workflows and tools. Everybody should be using version
control for their packages. Really. And probably we should all just use git.
And work together nicely.
--
cheers,
Holger
(*) even though I wonder why it's not even more simply
git.fedoraproject.org/git/${srcpkg} ;)
signature.asc
Description: Digital signature
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
But responsive design does not only matters for mobile, it also matters on bigger screen, like high resolution or hi dpi screen, which is what Debian lack of. Like what I said the website is bizarre on a bigger screen. You can try reading the website with the window maximized on 1920x1080 screen. On Wed, 17 May 2017 at 22:02 Ian Jackson wrote: > > > It looks as though the Debian website (or at least its front page) > > already has responsive design and the necessary runes to make mobile > > browsers make use of it, although it could perhaps benefit from > > dropping more content (requiring extra clicks instead) at small sizes. > > OK, good. > > I don't have any clear idea show close the views of the Debian project > as whole are to the ones I expressed in my article, but I'm pretty > sure that my views as expressed there are at least those of a > significant and vocal minority :-). They might even be the majority > view, but we sowouldn't be able to tell without a GR - and let's not. > > Thanks, > Ian. > >
Re: Moving away from (unsupportable) FusionForge on Alioth?
Hi Tzafir, On Thu, May 18, 2017 at 06:04:09AM +0200, Tzafrir Cohen wrote: > > > The top 10 teams with packages in SVN are: > > > > > > 347 Debian Med Packaging Team > > > > > > > This number contains possibly 150 packages that *could* be migrated - > > provided somebody wants to take the time for some unproductive work. > > However, we intentionally do packaging of new R CRAN packages in SVN > > since in this case packaging is brain dead simple and we keep only the > > debian/ dir and not the upstream source in VCS. This is a sensible and > > established workflow and currently there is no short term plan to change > > this. > > Just an obvious question: have you looked into > > gbp buildpackage --git-export I wonder in how far is the question obvious when I tried to explain that I do not see a good reason to spent time into a migration from SVN to Git. I have converted lots of packages where I had good reasons. I admit that it would be a good reason if the project would decide to support Git exclusively - but I for myself do not see any reason to drive this decision. Kind regards Andreas. -- http://fam-tille.de
