Re: website maintenance

[Michael Lustfield]

>>> Our users are really complaining about our look&feel in the web

I expect that less than ten people on earth would disagree with you.

> Unfortunately, I don't have the web abilities (web technologies,
> design, UX, whatever) that this task requires.
[..]
> Someone have suggested to invest a bit of our money into some paid
> work. I believe this idea is something worth exploring too.

I've been working on packaging gitea but I'm reaching a point where
too much needs to change in either unstable or experimental for it to
be sensible until after freeze, so I now have some time available.

I don't claim to be an expert by any means, but I do have some
background in website development and know of some resources that
could be helpful. (google can fill in any blanks here, no I'm not
proud of my PHP knowledge)

If we're going to seriously discuss reworking www.debian.org, can we
talk about what changes actually need to take place? Let's start the
requirements gathering phase, ya? What functions does the current
implementation not provide? What do we need to see out of the next
option? We have a lot of web services that share a similar theme. The
minimalistic design provides an easy way to keep a unified theme
across all services and makes it easy to render correctly across all
browsers regardless of the latest and greatest ecmascript or $foo. You
can safely assume Debian is a group of people that will not be okay
with requiring javascript to correctly render pretty much anything
[1].

I'm sure it's been discussed before, but I don't know what functional
requirements we face, what services utilize the same theme/design,
what their templates need to look like, what kind of resources are
typically accessed and under what load and why, how content updates
are deployed, etc. Before even beginning any work, I think it's
important the requirements phase for a project like this be completed
in relatively painful detail.

[1] That's why our updates are so clean. ;)

Re: website maintenance

[Michael Lustfield]

On Tue, May 16, 2017 at 2:22 AM, Michael Lustfield  wrote:
 Our users are really complaining about our look&feel in the web
[... blah blah ...]
For some reason, the entire other chunk of this thread found it's way
to my junk folder. I'm not sure why that happened but I see there's
actually been some discussion started so please ignore me.

I'll follow up when either I read through a wiki page or create one to
start keeping track of opinions. :)

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Jonathan Dowland]

On Mon, May 15, 2017 at 08:39:11AM +, Riku Voipio wrote:
> OTOH it might just not be worth to convert all project histories into
> git. Linus didn't do it for upstream kernel either. Convert the easy
> cases automatically and leave the rest ones for maintainers as an
> opportunity to do a clean start.
> 
> Else we risk delaying moving forward because time is spent supporting
> esoteric legacy workflows.

I agree completely. The ideal of converting all history has a chilling
effect on actually migrating at all; and in the meantime, there's a huge
opportunity cost IMHO, as we've had git for 10 years now there are plenty
of developers who have completely forgotten how to use SVN (like me) or
even never learned it at all.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Stéphane Aulery]

Le 16/05/2017 03:47, Nicholas D Steeves a écrit :

On Tue, May 16, 2017 at 02:17:40AM +0200, Stéphane Aulery wrote:


Yes, Debian is a community like another, and a community is build
with shared principles. Design isn't principle, it is just a shameful
exploitation of the idea of beauty, serving a precise purpose which
is not a shared principle. Wanting to do the number is not and should
never be a goal of Debian.

Debian say claim to be "The universal operating system". It should not 
be

understood that it is used by everyone but that is generalist
and at the service of all.

Design and advertising are one and the same, manipulating the mind 
through
the image to obtain consent. We are stuck in this rotten atmosphere 
since

the interwar period.


Much longer than that!  See "beauty" "deception" "kalon" vs "kallos"
in Plato's writing.  While some people use beauty to lie and cheat and
bend both truth and understanding, this is not always the case.
Something that is beautiful can be admirable and true.

If Debian's structure is all of these things, then shouldn't also be
its artwork and design?  Even website design...  Isn't this the point
of the Fibonacci logo?


I did not want to talk about philosophers, it would have been 
pretentious.
But you understood the message. Yes, beautiful, truth and being are one 
thing.


I think that Debian does not especially need aesthetic beauty research 
because
it already has the accents of truth for it, and since it is one the same 
thing

it already has a little intrinsically.

Do we need to make a very beautiful site to bring people to us? No,
because Debian already has real principles that have attracted thousands 
of people.

Do we need to make a better site? Yes, because it goes together.

What I really want to say is that the original message calls for an 
aesthetic
among others that is the one of the moment, but that is not what we 
should aim
for as this kind of beauty does not fit the timeless beauty of the 
principles

of Debian since it is so quickly obsolete.

Regards,

--
Stéphane Aulery

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Pirate Praveen]

On ചൊവ്വ 16 മെയ് 2017 05:20 രാവിലെ, Sean Whitton wrote:
> Thank you for updating us, Alex.
> 
> On Mon, May 15, 2017 at 09:13:11AM +0200, Alexander Wirt wrote:
>> - Git Hosting - we want to give pagure [1] a try, which uses gitolite, which 
>> is a
>>   nice git solution.
> 
> Ah, that's nice.
> 
>> Pagure also has issue tracking.
> 
> Is it possible to turn this off?
> 
> I think it would be bad if we ended up with some people filing issues on
> the BTS, and others filing them on Pagure.
> 

I think issue tracking and merge/pull requests go together. The main
attraction of the github/gitlab/pagure workflow is merge/pull requests.



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)

[Raphael Hertzog]

On Mon, 15 May 2017, Adrian Bunk wrote:
> The contents of the Gentoo homepage is similar to what Debian has but 
> presented with a different CSS - something like that would be a good 
> improvement.

I took a look at the Gentoo website and there's more than just better CSS.
I find it much better than the Debian one.

The things which are improvements compared to Debian:

- the frontpage is really only a (dynamic) portal to many other services,
  the main content does not duplicate what's already in the
  header/footer, they do not waste real estate uselessly

- every time that a somewhat lengthy explanation is needed, they direct
  users to their Handbook so that they do not duplicate instructions
  in multiple places

- they have more pictures and icons to illustrate and make it easier on the eyes

- their "get started" and "download" page are really visually appealing
  and very clear whereas our simple "bullet list" look like unstructured in
  comparison

- the two menu bars show clearly where you are within the website (in
  Debian we have no such visual indication), the headers/footers are
  easily identified compared to the main content
  
The only downside of Gentoo's website is the lack of translations.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#862725: ITP: python-parse-type -- Extends the parse module

[Brian May]

Package: wnpp
Severity: wishlist
Owner: Brian May 

* Package name: python-parse-type
  Version : 0.3.4
  Upstream Author : Jens Engel
* URL : https://github.com/jenisys/parse_type
* License : BSD-3-clause
  Programming Lang: Python
  Description : Extends the parse module

parse_type extends the parse module (opposite of string.format()) with
the a number of additional features.

This is required for packaging pytest-bdd. See #825071.

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Игорь Пашев]

2017-05-15 13:12 GMT+03:00 lumin :
> Especially look at the homepage of Gentoo


It's ugly, seriously.

Bug#862726: ITP: printer-driver-oki -- printer driver for OKI Data printers

[Balint Reczey]

Package: wnpp
Owner: Balint Reczey 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: printer-driver-oki
  Version : 1.0.1
  Upstream Author : Oki Data Corporation
* URL : https://github.com/rbalint/printer-driver-oki
* License : GPL-2.0+
  Description : printer driver for OKI Data printers

CUPS filters and drivers supporting OKI Data printers.

This driver is known to support these printers:
 * OKI 24 Pin
 * OKI 9 Pin
 * OKI B2200 / B2400 PCL
 * OKI B4000 / B400 / MB400 PCL
 * OKI B4000 / B400 / MB400 PS
 * OKI B6250 / B6500
 * OKI B6300
 * OKI B710 / B720 / B730
 * OKI B930
 * OKI C330 / C530
 * OKI C3600
 * OKI C5550 MFP / MC560 MFP / CX2032 MFP / CX2033 MFP
 * OKI C6050 / C6150
 * OKI C610 / C710 / C711
 * OKI C830 / MC860 MFP / CX2633 MFP
 * OKI C910 / C9600 / C9650
 * OKI MB471 MFP / MB491 MFP
 * OKI MC361 MFP / MC561 MFP / CX2731 MFP

This package contains the CUPS filter driver and PPDs for the
supported printers.

--

I would happily move the package under Printing Team's umbrella.

-- 
Balint Reczey
Debian & Ubuntu Developer

Bug#862727: RFP: libjasper -- JasPer JPEG-2000 runtime library

[Adam Cecile]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: libjasper
Version: 2.0.12
Upstream: Michael David Adams
License: JasPer License
Description: This package has been scheduled for removal after Stretch 
release but is very important to me as it can be used to add JPEG 2000 
to OpenCV (many satellite images comes as JPEG 2000). The new upstream 
on GitHub provides frequent updates as well as a decent CMake build 
system so I see no reason to not get it back in the archive :)


In the meanwhile, I made my own package to rebuild OpenCV and it's 
available here:

https://cloud.le-vert.net/index.php/s/2Ci3X1ARrZiONK4

I could easily finish the package to get it in a perfect state but are 
no DM and got no sponsor so if someone is interrested in uploading the 
package for me, just drop me a mail and I'll make a proper release.


Best regards,

Adam.

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Zlatan Todoric]

On 05/16/2017 04:56 AM, lumin wrote:
>> I'll take any day a sort animations that explains things rather then
>> going through forest of information to figure out what is it, but I
>> guess these all are personal opinions.
> A tiny bit of animations should be enough for our homepage. The style
> of lxde.org does not fit Debian's style and I think the style of the
> old lxde homepage is a better fit at this point.

I didn't say we should become YouTube channel, I just pointed the
difference from one to another opinion regarding what is better for
easier understanding of particular things.

>
> Too much animation and loud web page elements are too fancy but
> actually somewhat annoying, and lack solemnity.
>
 I believe that what we are actually looking for is a bit of
 improvement in the marketing side.
 Modern and fancy things.

 The LXDE example is good on that.
>>> http://lxde.org/ seems to be the site in question. I agree with
>> Paul,
>>> I don't like it, and when I encounter pages in that style, I tend
>> to
>>> close the window.
>> Then lets forget about getting newcomers (fresh blood) to Debian as
>> you're so close minded to modern/new things - the same way they
>> probably
>> close the window when they see '90 style with a lot of text that
>> actually says nothing. We are strange with our talks last few
>> debconfs -
>> we want new people but we don't want to break our precious habits nor
>> do
>> we want to give freedom to others to express themselves if they don't
>> fit into our circle of thinking which must be the best one.
> LXDE is a desktop environment so it's fine to craft a fancy homepage
> to attract people. However that style does not fit Debian.

What is the style of Debian?

>
> Most of modern business websites are fancy. New bloods may like
> them.
> However if we craft a fancy page alike, they will forget
> it immediately
> after closing the window. And many of you don't
> like that to happen,
> aren't you?
>
> What exactly scares newbies away is the feeling of rigidness but
> not the solemnity and simplicity. We value our common value,
> we appreciate the hard work you've done via bugs.d.o and
> ftp-master and many others alike, but what a newbie can see
> about Debian is its face. I know that new users who value
> only "pretty face" are less likely to catch the common value
> of Debian, and people with love to this community can bear
> any "ugly face" of it.  No one dislike a proper and better design.

We don't want only users who will value what you value, nor users who
can contribute to Debian - we also should be perfectly capable to catch
average users like my grandma and not see her slip to Windows, Mac or
Debian derivative.

>
> IMHO there are two good examples, the Gentoo homepage and the kernel
> homepage https://www.kernel.org/ .(Remember the old kernel page?)
> These pages are pretty but not annoying. An ideal homepage for Debian
> should be 1. solemn and silent (as few loud elements/animations
> as possible) 2. informative (dense but not exhausting one's eyes)
> 3. well-designed (e.g. https://www.kernel.org/ is visually simple,
> but not too simple. Visitors sense a well-designed style.)
>
> On the other hand, I think the CD image link of Sid should be added
> to the Debian image download page, maybe with some tags say
> "for expert".
>
I don't agree with sid image (I don't think we even produce those) but
testing one should be fine (with short explanation how to upgrade to sid
if one wants or even add experimental branch - we have it, we could as
well show it more).

Re: Bug#862727: RFP: libjasper -- JasPer JPEG-2000 runtime library

[Mathieu Malaterre]

Hi,

On Tue, May 16, 2017 at 11:40 AM, Adam Cecile  wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
>
> Package name: libjasper

Just keep the old naming convention please: 'jasper'.

> Version: 2.0.12
> Upstream: Michael David Adams
> License: JasPer License
> Description: This package has been scheduled for removal after Stretch
> release but is very important to me as it can be used to add JPEG 2000 to
> OpenCV (many satellite images comes as JPEG 2000). The new upstream on
> GitHub provides frequent updates as well as a decent CMake build system so I
> see no reason to not get it back in the archive :)

At the very least you'll need to address the old CVEs in that case:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=jasper

- CVE-2016-8693
- CVE-2016-8691
- CVE-2016-8692
- CVE-2016-8690

I personally fought against having duplicate JPEG 2000 libraries in
Debian (esp. since jasper seems dead upstream). I still believe you
should invest some time in replace jasper with OpenJPEG throughout
your OpenCV codebase, since OpenJPEG is used to manipulate satellite
image in professional environment.


2cts
-M

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Wookey]

On 2017-05-15 13:42 +0200, Hans wrote:

> Maybe other things, that people do not know yet, which show the power of 
> debian, should be mentioned (I think of biggest community, best documentation,

'Best documentation' is a strong claim that I don't think many would agree with 
:-)

Debian is many good things, but 'well documented', especially for
newcomers, is not one of them. Several other distros demonstrably do a
better job on this (Arch, Ubuntu spring to mind).

I will refrain from making further comments on the website except that
I like Debian's style much more than the lxde 'vertical sliding pane
minimal-info' thing that is quite popular these days. But then I am
old, favour substance over style, and don't use a tiny phone screen to
read the net. The more I see of the modern web, the more I become
convinced of the long-term advantages of 30K of HTML over 1MB of
javascript to convey essentially the same info.

I will observe that the debian wiki is a lot more up-to-date than the
website because it is much easier to update (much as I admire wml as
a tool/language).

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: When do we update the homepage to a modern design? - Extreme proposal No.1

[Zlatan Todoric]

So I think that we mostly agree (and this is kinda thing that goes in
circle for years) that Debian web presence needs a redesign. Current
Debian presence is huge and this affects us bad because - it is not
possible I think for anyone to pay attention to entire web presence, so
the text/docs will become sometimes old and inaccurate which doesn't
serve anyone. It also doesn't serve that we can't maintain such huge
piece of work. It also doesn't help that it is in CVS.
What it does help is that is usually just chunk of text and nothing more.

So one thing could be: hire some good known designer or designer team or
send a callout to community and see if anyone is good and willing from
it to work on Debian website design, explain them our values and what we
want from it, listen to their proposals (our values should stay but
maybe we should shift paradigm on how we present them - that is why I
think we need the re-design), lets pick most relevant part of web, copy
the text and re-write it (I would feed Russ Albery with books so he does
some ninja writing as the man has ways to trigger people into reading
all what he writes) to make it better and simpler but than add links to
wiki's or Debian handbook or other part of website, add some
infographics on pages (reuse all the time so the ecosystem is dozen of
pages, not thousands of them).

Basically we could have first page (debian.org) having simple but modern
layout that shows in infographic style that Debian is used in NASA, on
ISS, the space robot, most of web servers, have drop down or slide from
right/left menu for things like "Why Debian", "Download" (with simple
direct link to amd64 image and then "Not a 64-bit device? Find your
architecture"), "Contribute to Debian", "Debian Community" (make it
could go under Contribute to Debian), "DebConf" (lets link to out
cons!), "Debian Security" and then just all other pages simple text
(maybe occasionally some image) that has proper fonts and font sizes (so
we don't go blind on bigger screens).

And lets make it fun, lets talk to creator of xkcd so he gives us images
for our pages!

Btw, just add note - GNOME is the most popular DE out there but I am
sure many here hate it. And I am certain that if GNOME wasn't, it would
be KDE. It will never be MATE (though they do awesome work), LXDE,
xmonad, i3, awesome (no matter how awesome it is), ratpoison etc. Maybe
i3 is the best for our hackers, but Debian isn't OS for hackers - it is
universal OS for everyone - so at least we could pretend that we are
really trying to make it good for all and not only sysadmins, hackers or
(as joeyh wrote it) a "superstore" for derivatives.

Let the /bin/bash start!

Z

P.S. if you have non-constructive comment or you have the need to be
offensive, don't post it to the list, just send me personally the msg
and I promise you I will read it and I assure you, I will not care about
it at all.

Re: Bug#862727: RFP: libjasper -- JasPer JPEG-2000 runtime library

[Alastair McKinstry]

Hi
>> Version: 2.0.12
>> Upstream: Michael David Adams
>> License: JasPer License
>> Description: This package has been scheduled for removal after Stretch
>> release but is very important to me as it can be used to add JPEG 2000 to
>> OpenCV (many satellite images comes as JPEG 2000). The new upstream on
>> GitHub provides frequent updates as well as a decent CMake build system so I
>> see no reason to not get it back in the archive :)
> At the very least you'll need to address the old CVEs in that case:
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=jasper
>
> - CVE-2016-8693
> - CVE-2016-8691
> - CVE-2016-8692
> - CVE-2016-8690
>
> I personally fought against having duplicate JPEG 2000 libraries in
> Debian (esp. since jasper seems dead upstream). I still believe you
> should invest some time in replace jasper with OpenJPEG throughout
> your OpenCV codebase, since OpenJPEG is used to manipulate satellite
> image in professional environment.
Hi,

Which file formats are you using ?
I've faced the similar problem earlier in GRIB files in Stretch, and
replaced Jasper with OpenJPEG2
to phase out Jasper. I've patches included in the two grib libaries
(grib_api, now eccodes, and g2clib)
for openjpeg2. I can help with porting

Regards
Alastair

>
> 2cts
> -M
>
-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 




signature.asc
Description: OpenPGP digital signature

Re: Bug#862727: RFP: libjasper -- JasPer JPEG-2000 runtime library

[Adam Cecile]

Hi,

Thanks for the feedback. I think the CVEs have been addressed upstream 
but ofc, it has to be verified first.
Btw, I'not involved at all in OpenCV so sadly, my biggest concern is to 
have a working python3 OpenCV package...


Regards, Adam.


On 05/16/2017 12:05 PM, Mathieu Malaterre wrote:

Hi,

On Tue, May 16, 2017 at 11:40 AM, Adam Cecile  wrote:

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: libjasper

Just keep the old naming convention please: 'jasper'.


Version: 2.0.12
Upstream: Michael David Adams
License: JasPer License
Description: This package has been scheduled for removal after Stretch
release but is very important to me as it can be used to add JPEG 2000 to
OpenCV (many satellite images comes as JPEG 2000). The new upstream on
GitHub provides frequent updates as well as a decent CMake build system so I
see no reason to not get it back in the archive :)

At the very least you'll need to address the old CVEs in that case:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=jasper

- CVE-2016-8693
- CVE-2016-8691
- CVE-2016-8692
- CVE-2016-8690

I personally fought against having duplicate JPEG 2000 libraries in
Debian (esp. since jasper seems dead upstream). I still believe you
should invest some time in replace jasper with OpenJPEG throughout
your OpenCV codebase, since OpenJPEG is used to manipulate satellite
image in professional environment.


2cts
-M

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Benjamin Drung]

Am Dienstag, den 16.05.2017, 13:47 +0530 schrieb Pirate Praveen:
> On ചൊവ്വ 16 മെയ് 2017 05:20 രാവിലെ, Sean Whitton wrote:
> > Thank you for updating us, Alex.
> > 
> > On Mon, May 15, 2017 at 09:13:11AM +0200, Alexander Wirt wrote:
> > > - Git Hosting - we want to give pagure [1] a try, which uses
> > > gitolite, which is a
> > >   nice git solution.
> > 
> > Ah, that's nice.
> > 
> > > Pagure also has issue tracking.
> > 
> > Is it possible to turn this off?
> > 
> > I think it would be bad if we ended up with some people filing
> > issues on
> > the BTS, and others filing them on Pagure.
> > 
> 
> I think issue tracking and merge/pull requests go together. The main
> attraction of the github/gitlab/pagure workflow is merge/pull
> requests.

No. They are not necessarily go together. For example, GitHub allows
projects to disable issue tracking, but allow merge proposals. This is
what I would expect for a VCS hosting for Debian.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
Web: https://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Achim Weiss.


signature.asc
Description: This is a digitally signed message part

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Boyuan Yang]

在 2017年5月16日星期二 +08 下午2:51:16，Benjamin Drung 写道：
> Am Dienstag, den 16.05.2017, 13:47 +0530 schrieb Pirate Praveen:
> > On ചൊവ്വ 16 മെയ് 2017 05:20 രാവിലെ, Sean Whitton wrote:
> > > Thank you for updating us, Alex.
> > > 
> > > On Mon, May 15, 2017 at 09:13:11AM +0200, Alexander Wirt wrote:
> > > > - Git Hosting - we want to give pagure [1] a try, which uses
> > > > gitolite, which is a
> > > >   nice git solution.
> > > 
> > > Ah, that's nice.
> > > 
> > > > Pagure also has issue tracking.
> > > 
> > > Is it possible to turn this off?
> > > 
> > > I think it would be bad if we ended up with some people filing
> > > issues on
> > > the BTS, and others filing them on Pagure.
> > 
> > I think issue tracking and merge/pull requests go together. The main
> > attraction of the github/gitlab/pagure workflow is merge/pull
> > requests.
> 
> No. They are not necessarily go together. For example, GitHub allows
> projects to disable issue tracking, but allow merge proposals. This is
> what I would expect for a VCS hosting for Debian.

I've got some different ideas. While it makes sense that packaging-only 
projects on the new VCS hosting system should not enable the issue tracking 
system (people should use Debian BTS instead. Pull Requests should be enabled 
to allow external contribution.), there are many semi-native and native 
packaging projects directly related to Debian.

For example, there are documentation projects like debian-reference and 
debian-handbook, native packages like dpkg, apt and reportbug. In that case, 
the issue tracking *should* be enabled and used. Issue tracking here will act 
as the replacement of mailing lists from lists.alioth.debian.org. (Issue 
tracker acts just like mailling lists. The sole difference is that you must 
start a thread on web interface.)

My opinion is that the use of issue tracking systems should be decided by the 
maintenance/packaging team (for team-maintained pkg) or the repository owner.

--
Boyuan Yang

signature.asc
Description: This is a digitally signed message part.

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Mattia Rizzolo]

On Tue, May 16, 2017 at 09:11:07PM +0800, Boyuan Yang wrote:
> For example, there are documentation projects like debian-reference and 
> debian-handbook, native packages like dpkg, apt and reportbug. In that case, 
> the issue tracking *should* be enabled and used. Issue tracking here will act 
> as the replacement of mailing lists from lists.alioth.debian.org. (Issue 
> tracker acts just like mailling lists. The sole difference is that you must 
> start a thread on web interface.)

Except that those projects are *expected* to use the official Debian BTS
to track issues, and not any other bug tracker of their choice, nor a
simple ML.

-- 
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?

[Boyuan Yang]

在 2017年5月16日星期二 +08 下午3:15:31，Mattia Rizzolo 写道：
> On Tue, May 16, 2017 at 09:11:07PM +0800, Boyuan Yang wrote:
> > For example, there are documentation projects like debian-reference and
> > debian-handbook, native packages like dpkg, apt and reportbug. In that
> > case, the issue tracking *should* be enabled and used. Issue tracking
> > here will act as the replacement of mailing lists from
> > lists.alioth.debian.org. (Issue tracker acts just like mailling lists.
> > The sole difference is that you must start a thread on web interface.)
> 
> Except that those projects are *expected* to use the official Debian BTS
> to track issues, and not any other bug tracker of their choice, nor a
> simple ML.

All right. If that is the case, disabling issue tracking / ticketing function 
is doable on the new VCS hosting platform. Pagure has separate global config 
switch on those functions. [1]

...but I believe we must enable the Pull Request system (if there's any). 
That's one of the killer features current Alioth is lacking. Sending patches 
onto Debian BTS or maillists is really painful and that prevents people from 
making contributions, especially for those not that familiar with Debian's 
development.

[1] https://docs.pagure.org/pagure/configuration.html#enable-tickets

--
Boyuan Yang

signature.asc
Description: This is a digitally signed message part.

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Antonio Terceiro]

On Tue, May 16, 2017 at 10:25:54AM +0800, Paul Wise wrote:
> On Tue, May 16, 2017 at 12:39 AM, Antonio Terceiro wrote:
> 
> > Right. IIRC that was said to me at Debconf16 about Debian-specific
> > services (such as ci.debian.net which was the context of my question).
> 
> Yeah, for codebases maintained by the service maintainer not having
> packages seems reasonable (but not for dependencies of that codebase)
> and that seems to be the current feeling within DSA.
> 
> Personally I'm leaning towards the feeling that all configuration,
> code and dependencies for Debian services should be packaged and
> subjected to the usual Debian QA activities but I acknowledge that the
> current archive setup (testing migration plus backporting etc) doesn't
> necessarily make this easy. The PPA/bikeshed mechanism might make it
> more feasible if that happens.

That makes sense.

I am currently working on a personal project that involves deployment to
my private server. I have Debian packaging for it, and I have a make
target that will take the most current code, apply the Debian packaging,
build a binary package, scp it to my server, and install it.  Whenever I
am ready to deploy a new version, doing it is just on command away.

An alternative to waiting for bikesheds and for waiting for the full
archive dance could be DSA providing a similar system for service
maintainers. They would upload one or more binary packages (alongside a
signed .changes, and maybe we also want the corresponding full source)
for their service. On the receiving end, the system would install those
binary packages after verifying signatures, and perhaps also a whitelist
of binary packages that the service maintainer in question can submit.


signature.asc
Description: PGP signature

Q: Node.js on stretch

[Hideki Yamane]

Hi,

 During translation of Stretch release note, it says "Lack of security
 support for the ecosystem around libv8 and Node.js"
 
https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#libv8

 Then, I'm curious that what is the best way for Debian users, "how to
 create and maintain Node.js environment on Debian Stretch", can anyone
 tell me, please?

 And if it isn't not so large, adding it to release note is better, IMO.


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Bug#862754: ITP: libhfi1 -- Userspace driver for Intel Omni-Path fabric interface

[Brian T. Smith]

Package: wnpp
Severity: wishlist
Owner: "Brian T. Smith" 

* Package name: libhfi1
  Version : 0.5-23
  Upstream Author : Intel Corporation 
* URL : http://www.intel.com
* License : GPL or BSD
  Programming Lang: C
  Description : Userspace driver for Intel Omni-Path fabric interface 
(HFI1).

libhfi1 is a device-specific driver for Intel Omni-Path fabric 
interface hardware for the libibverbs library. This allows 
userspace processes to access the HFI1 hardware directly with
low latency and low overhead.
.
This package contains the loadable plug-in.
.
I am an employee of System Fabric Works. SFE has the experience, 
hardware and resources to maintain and test this package.

Re: Bug#862698: ITP: minecraft -- blocks to build anything you can imagine

[Russ Allbery]

Simon McVittie  writes:

> If this package downloads proprietary files automatically, here are some
> issues that should be considered:

> * minimizing amount of code run as root (downloading the Minecraft
>   launcher per-user is probably better - the launcher will download
>   Minecraft itself once per user anyway, so sharing files between users
>   to reduce disk space usage is not straightforward)
> * not executing code that was not obtained in a way that can be trusted:
>   downloading via https with correct certificate validation, or checking
>   the launcher against known-good cryptographic hashes like
>   game-data-packager does, or similar
> * not preventing offline apt updates in which packages are downloaded
>   while online, then installed at a later time without Internet access

> game-data-packager/doc/why.mdwn might be interesting reading.

Another thing that would be a really neat addition to a wrapper around
Minecraft would be to run it inside a restrictive namespace by default.
Minecraft has a pretty well-understood file access pattern, and there's
really no reason to allow it to read, say, your Firefox cookie database,
or something else that's in your home directory.  You could probably also
cut off quite a lot of syscalls with seccomp without changing the
functionality.

I played around with configurations for a server and can confirm that the
following systemd jailing configuration works for the server, but I'm
quite sure that one could get more restrictive than this with some work
(for example, I didn't even start on syscall filtering).

PrivateUsers=true
ProtectSystem=full
ProtectHome=true
ProtectKernelTunables=true
ProtectControlGroups=true
NoNewPrivileges=true
ProtectKernelModules=true

-- 
Russ Allbery (r...@debian.org)   

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Sean Whitton]

Hello Boyuan,

On Tue, May 16, 2017 at 09:11:07PM +0800, Boyuan Yang wrote:
> I've got some different ideas. While it makes sense that packaging-only
> projects on the new VCS hosting system should not enable the issue tracking
> system (people should use Debian BTS instead. Pull Requests should be enabled
> to allow external contribution.), there are many semi-native and native 
> packaging projects directly related to Debian.
> 
> For example, there are documentation projects like debian-reference and 
> debian-handbook, native packages like dpkg, apt and reportbug. In that case, 
> the issue tracking *should* be enabled and used. Issue tracking here will act 
> as the replacement of mailing lists from lists.alioth.debian.org. (Issue 
> tracker acts just like mailling lists. The sole difference is that you must 
> start a thread on web interface.)
>
> My opinion is that the use of issue tracking systems should be decided by the 
> maintenance/packaging team (for team-maintained pkg) or the repository owner.

Firstly, as noted by Benjamin, disabling issue tracking does not mean
losing the merge/pull request workflow (which is what we really want out
of all this).  You do lose some integration between issues and
pull/merge requests, but that's minor.

I think that we should disable issue tracking across the Pagure
instance.  I disagree that it should be up to the package maintainers.
This is for two reasons.

(1) Please don't underestimate the confusion and inconvenience of having
two issue trackers for Debian.  This is not a migration: we will not
drop the Debian BTS because it is heavily customised for our needs --
even for native and pseudopackages, which you suggest replacing.  So we
should try really, really hard to avoid the situation where code
contributors have to look in two places.

I'm even more concerned for those who only report bugs and test fixes,
who might not know where to report.  If it is clear that pagure is for
code/doc contributors only, and those who only report bugs never need
look at pagure, we can minimise the frustration of our pure bug
reporters, who are an extremely valuable group of contributors.

(2) A web interface is much less accessible than our BTS.  We have
contributors on poor network connections, and we shouldn't force them to
use pagure's interface.  Perhaps it has GitHub-style e-mail support, but
in my experience you always end up having to access the web issue tracker.

-- 
Sean Whitton

Re: Bug#862698: ITP: minecraft -- blocks to build anything you can imagine

[Simon McVittie]

On Tue, 16 May 2017 at 09:58:11 -0700, Russ Allbery wrote:
> Another thing that would be a really neat addition to a wrapper around
> Minecraft would be to run it inside a restrictive namespace by default.

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.

However, as long as Minecraft and other proprietary software requires
X11[1], it's going to be hard to put it in a sandbox that actually
protects you very much - and that's equally true with or without
Flatpak. Using a separate games-playing uid, together
with the support for "fast user switching" (Ctrl+Alt+Fx with a nice
GUI) in desktop environments like GNOME[2], and systemd-logind's
ability to grant and revoke hardware access as this switching occurs,
seems a lot safer for the medium term.

This is of course a trade-off: banishing all untrusted software to
separate hardware would be safer (resistant to kernel vulnerabilities
and permissions misconfiguration) but less convenient, whereas assuming
X11 isn't being abused is more convenient but less safe. Choose your
preferred safety/convenience balance.

S

[1] Also, as long as it requires networking and X11 uses abstract Unix
sockets, since abstract Unix sockets are mediated by network
namespaces, not filesystem namespaces
[2] I'm sure other desktop environments also do this, I just don't use
them frequently enough to know how

Bug#862775: ITP: visitors -- OCaml syntax extension for object-oriented visitors

[Ralf Treinen]

Package: wnpp
Severity: wishlist
Owner: Ralf Treinen 

* Package name: visitors
  Version : 20170404
  Upstream Author : François Pottier 
* URL : https://gitlab.inria.fr/fpottier/visitors
* License : LGPL 2.1
  Programming Lang: OCaml
  Description : OCaml syntax extension for object-oriented visitors

Visitors is a syntax extension for the OCaml programming language. It
allows you to annotate your type definitions, such that a visitor class
will be automatically generated. This visitor class contains methods
for the traversal of your data structure, like iter, map, fold, etc. It
is then easy to override these methods for your needs. This is very
convenient when programming with complex algebraic data structures.


This package will be maintained by the Debian Ocaml Maintainers team.

-Ralf.

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Gunnar Wolf]

Arturo Borrero Gonzalez dijo [Mon, May 15, 2017 at 01:42:09PM +0200]:
> Hi Paul,
> 
> I believe that what we are actually looking for is a bit of
> improvement in the marketing side.
> Modern and fancy things.
> 
> The LXDE example is good on that.

Is a good example on how to craft content-void websites that look well
on mobile devices but are useless for finding information.

I guess that if you click around enough, you will get to a decent web
site in it that actually contains information.

Bug#862776: ITP: libblockdev -- library for manipulating block devices

[Martin Pitt]

Package: wnpp
Severity: wishlist
Owner: Martin Pitt 

* Package name: libblockdev
  Version : 2.6
  Upstream Author : Vratislav Podzimek 
  URL : https://github.com/rhinstaller/libblockdev
* License : GPL-2+
  Programming Lang: C
  Description : Library for manipulating block devices
  libblockdev is a C library supporting GObject introspection for manipulation 
of
  block devices. It has a plugin-based architecture where each technology (like
  LVM, Btrfs, MD RAID, Swap,...) is implemented in a separate plugin, possibly
  with multiple implementations (e.g. using LVM CLI or the new LVM DBus API).

This will soon be used by udisks [1], see that PR for details of the rationale.
In short, this will replace the coarse/brittle command line tool interfacing
with a proper library which will also be used in different storage management
related tools.

Peter and Andreas did the brunt of the packaging at [2], I'll give it a review
and some fine-tuning soon. This will be maintained under the Utopia umbrella,
the project which already maintains udisks, upower, libatasmart, and other
hardware related plumbing stack parts.

If anyone else is interested, co-maintenance is highly welcome and appreciated!

Thanks,

Martin

[1] https://github.com/storaged-project/udisks/pull/260
[2] https://github.com/rhinstaller/libblockdev

Re: Bug#862775: ITP: visitors -- OCaml syntax extension for object-oriented visitors

[Paul Wise]

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.

https://packages.qa.debian.org/v/visitors.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise