Debian on Aakash tablets project (Fwd: Re: [Aakash-hackers] Bootstrapping for Aakash)

[Pirate Praveen]

Aakash is the low cost tablet project of Indian government. Aakash-2 is
the next generation in Aakash project. Aakash tablets run Android 4.0.4
and this project is an experiment of running Debian on Aakash range of
tablets.

DebianAakash project is subset/subproject of Debian which can be used as
an Operating system for Aakash-2 and similar low cost tablets.

More https://wiki.debian.org/DebianAakash
Mailing list https://lists.alioth.debian.org/mailman/listinfo/aakash-hackers

Inviting everyone interested to join the mailing list and help out. This
tablet is going to be the first computer for many students in India.

Thanks
Praveen

 Original Message 
Subject:Re: [Aakash-hackers] Bootstrapping for Aakash
Date:   Sun, 2 Feb 2014 05:12:00 +0530
From:   Srikant 
To: Aakash Hackers 



Hello Vasudev and others,

1. We were unable to install LIMA previously. Yes, it would be good to
have a Debian package.
Also, we need to do following (no particular order, based on recall):
a) Enable camera
b) Suspend to RAM
c) sleep (screen off, not display off with backlight on)
d) Wifi discovery issue (unable to connect same network)
e) Battery monitor(works only in 13.10)
f) Touchscreen driver for gsl1680 and one more (@Sachin, do you
remember ?)
g) Touchscreen issues, enable long press right click in gt811 and ft5x
h) Boot logo in Uboot, it takes around ~3s to get kernel logo
i)  Freeing 128MB reserved memory for MALI
j) One image for all variants of Aakash (same specs, different
touchscreens, 5 so far)


2. Yes, we will make bootstrap rootfs. We should discuss about what DE
we should provide
this time. Previously, it was badly customized LXDE. Should we
continue with that? or, shall we
invest time and resources on a better touch optimized DE, say fork
of LXDE or E18. There is
plasma-active for tablets, but its KDE, quite heavy for 512MB RAM.
Basically, we should
have at least good virtual keyboard which should popup
automatically, touch optimized
window manager, and of course RAM efficient. If you suggest, let's
create a separate topic for
this ?

Also, would you recommend to us to go with Debian-Jessie or Wheezy.
Manoj found a good
comparison [1].

So far we don't have any special repository to enable.

[1]
http://www.phoronix.com/scan.php?page=article&item=ubuntu_1404_jessie&num=1

Srikant



On Sat, Feb 1, 2014 at 8:32 PM, Vasudev Kamath mailto:kamathvasu...@gmail.com>> wrote:


Hi Srikant and others,

So I'm just wondering what are the requirements at the momemnt you
people are looking to get Debian on Aakash running.

1. We came to know from Srikant that LIMA drivers need to be ported to
  A13 alwinner SOC but from one of our Debian collegue (Paul Wise) LIMA
  already supports Alwinner A13 SOC. So do you want it to be
packaged for
  Debian?

2. Also we need to go ahead and bootstrap the rootfs for Aakash so if
   you have any specific customization in mind do let us know. We have
   Jonas who is specialist in Debian Pure blends and he can give us
   hints on how to go ahead.

Looking forward for your reply.

PS: If you have any source code which you want to share we can enable
the source repositories for this project and it can be pushed to Git
repositories provided by Debian. Let me know if you need this and I will
enable it.

Cheers,
--
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de  |
vasudev.homelinux.net }
IRC nick: copyninja | vasudev {irc.oftc.net  |
irc.freenode.net }
GPG Key: C517 C25D E408 759D 98A4  C96B 6C8F 74AE 8770 0B7E

___
Aakash-hackers mailing list
aakash-hack...@lists.alioth.debian.org

https://lists.alioth.debian.org/mailman/listinfo/aakash-hackers




___
Aakash-hackers mailing list
aakash-hack...@lists.alioth.debian.org
https://lists.alioth.debian.org/mailman/listinfo/aakash-hackers

Re: Why Debian

[Pirate Praveen]

2014-04-12 21:46 GMT+05:30, Alberto Salvia Novella :
> Why you choose to develop in Debian over any other distribution?

Because my contributions are respected equally, in most other
distributions my contributions will be treated second class, subject
to wishes of managers, even those who don't contribute technically in
that area. There was a concrete example when I tried to get emacs
installed by default when a user chooses my language (Malayalam),
because at that time only emacs terminal emulator could display
Malayalam correctly. But it was rejected because the desktop team did
not want to support another terminal emulator. It would have still be
acceptable if a manager working on i18n made that decision.

The reason I switched to Debian was when another distribution which
took everything from debian refused to contribute back something
better it developed. I want to spent my efforts on someone who treats
me as their own member rather than just free work.

I love democracy, where everyone has a say and have a chance to make
the changes they want rather than depending on someone.
-- 
പ്രവീണ്‍ അരിമ്പ്രത്തൊടിയില്‍
You have to keep reminding your government that you don't get your rights
from them; you give them permission to rule, only so long as they follow the
rules: laws and constitution.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caoo+evpdpza1pqpc+2_9+1+qb9ndodjmvmasw+uxlr2xtwj...@mail.gmail.com

Re: Why Debian

[Pirate Praveen]

2014-04-13 16:58 GMT+05:30, Chris Bannister :
> On Sun, Apr 13, 2014 at 10:43:29AM +0530, Pirate Praveen wrote:
>> I love democracy, where everyone has a say and have a chance to make
>> the changes they want rather than depending on someone.
>
> Just remember that Democracy is where 13 lions and 5 sheep vote for what
> to have for dinner. :(

Well, even if it were 2 lions and 16 sheep, they would still vote for
sheep to be the dinner, its kind of sad though.

But in debian there is another layer and it is better called a
do-o-cracy, or only those who do the work gets to vote.
-- 
പ്രവീണ്‍ അരിമ്പ്രത്തൊടിയില്‍
You have to keep reminding your government that you don't get your rights
from them; you give them permission to rule, only so long as they follow the
rules: laws and constitution.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOo+eVquFq=kw7ezqqymcmcztb1yaue76odnwxedxt3l4c1...@mail.gmail.com

Re: is sarovar.org dead ?

[Pirate Praveen]

2014-04-14 19:26 GMT+05:30, Jerome BENOIT :
> Hello List:
>
> Today I realised that sarovar.org cannot be reached:
> is it temporary ? is it definitely dead ?

unfortunately, yes, dead forever :( they shut it down when they
realized they cannot maintain it anymore. They had given notice for
people to take backup before they shut it down.
-- 
പ്രവീണ്‍ അരിമ്പ്രത്തൊടിയില്‍
You have to keep reminding your government that you don't get your rights
from them; you give them permission to rule, only so long as they follow the
rules: laws and constitution.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caoo+evr8fcxf7lly6v_u47uibz7lbzq7jqgzvjhyzozcpbx...@mail.gmail.com

Re: Non-source Javascript files in upstream source

[Pirate Praveen]

On Sunday 27 April 2014 09:37 PM, Nicolas wrote:
> Hi all,
>
> I'm a bit disapointed. I don't know what to do. I try to fix following
> bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744317
> Two files are pointed to have no upstream source. Theses files are
> html template files used by a javascript engine. If I understood, the
> problem is that theses files seems to be minified. The real problem is
> that it cannot works if theses are not in that format. How can it be
> fixed ?
>
>
Jo Nicolas,

You could generate the minified javascript from normal javascript files.

Thanks
Praveen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535d2cb0.5050...@debian.org

packaging diaspora, final steps, looking for collaborators

[Pirate Praveen]

Hi,

We've been working on packaging diaspora since last 2+ years. It is
written in ruby on rails framework and has 206 dependencies
https://people.debian.org/~praveen/diasbar/ So far we packaged around
86% of the dependencies.

Now I created a diaspora package with remaining dependencies uploaded in
my people.debian.org account.

You can follow the steps listed at https://wiki.debian.org/Diaspora to
install it right now.

I'm looking for some help to complete this packaging.

Some tasks I need help are,

1. Complete packaging of remaining gem dependencies

2. Test the installation by going ahead with next steps listed at
diaspora installation manual

3. Create debconf templates for pod configuration.

4. Help keep the gem versions in sync. If deb version of a library is
older than required by diaspora (run 'bundle install --local' on a
develop branch checkout of diaspora upstream), update the deb version.
If debian already has a new version of a library, update the
corresponding gem version in diaspora.

5. Create a tracker to check the dependency status in debian with
diaspora develop branch.

Once diaspora package is completed, this will be a boost to Freedom Box
efforts. Hoping to get some collaborators in this final push.

We hangout at #debian-diaspora on oftc.

Thanks
Praveen



signature.asc
Description: OpenPGP digital signature

Re: debian github organization ?

[Pirate Praveen]

On Thursday 16 April 2015 08:34 PM, Dimitri John Ledkov wrote:
> I'd rather see gitlab.debian.net  :)

gitlab folks are willing to sponsor gitlab.debian.net I will try to take
that offer forward.



signature.asc
Description: OpenPGP digital signature

Re: debian github organization ?

[Pirate Praveen]

It will be an instance of gitlab CE, under MIT license and managed by Debian. 
Gitlab folks will just sponsor the hosting.

Nicolas Dandrimont എഴുതി:
> Hi,
>
> * Pirate Praveen  [2015-04-21 20:24:09 +0530]:>> On 
> Thursday 16 April 2015 08:34 PM, Dimitri John Ledkov wrote:>>> I'd rather see 
> gitlab.debian.net <http://gitlab.debian.net> :)>> gitlab folks are willing to 
> sponsor gitlab.debian.net I will try to take
>> that offer forward.> I sure hope that won't mean getting Debian onboard the 
>> proprietary edition of
> their software, but rather them helping the proper packaging of their 
> software.
>
> Cheers,> -- 
> Nicolas Dandrimont
>
> BOFH excuse #82:
> Yeah, yo mama dresses you funny and you need a mouse to delete files.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1429672743241.c656ee42a5b94@mozgaia

Re: GitLab B.V. to host free-software GitLab for Debian project (was: debian github organization ?)

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I will be working on it. First task is to complete gitlab packaging. See 
balasankarc.in/gitlab for current status. Gitlab folks sponsored 60 days of 
work with 3000 usd. I post updates at poddery.com/tags/debian-gitlab-months


On 2015, ജൂലൈ 11 6:51:22 PM IST, Alessio Treglia  wrote:
>On Wed, Apr 22, 2015 at 3:08 PM, Neil McGovern 
>wrote:
>>> > It will be an instance of gitlab CE, under MIT license and managed
>by
>>> > Debian. Gitlab folks will just sponsor the hosting.
>>>
>>> Much appreciated, thank you to GitLab B.V. for this generous offer.
>
>Just out of curiosity, has anybody made any progress on this?
>Is GitLab's kind offer still on the table?
>
>Cheers!
>
>--
>Alessio Treglia  | www.alessiotreglia.com
>Debian Developer | ales...@debian.org
>Ubuntu Core Developer|  quadris...@ubuntu.com
>0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A
>
>
>--
>To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact
>listmas...@lists.debian.org
>Archive:
>https://lists.debian.org/CAMHuwox+0mwkJhZBPahNEoc-2ax74MZE8oyGJ0BAjuq3t3=d...@mail.gmail.com

- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-BEGIN PGP SIGNATURE-

iQJWBAEBCABAORxQcmF2ZWVuIEFyaW1icmF0aG9kaXlpbCAocGlyYXRlcGluKSA8
cHJhdmVlbkBkZWJpYW4ub3JnPgUCVaEaJQAKCRDOH5xnRRLCKtd5EACKaaWBsqdd
VLMy969C+3+jFZz2acmDivHrGx+06JUIErTANeoooYczOa/nL7c+1VE97tlaF7N3
aV7jDfjmkDjr5D+GV58GKwYVTJXq1nqurndzW+ZMB0RkfLMbioM8qSvi9b+iIsP7
cDcilU7twfJhC8aEznZIrzUaIyWzwjF+1crDsmL64AqNZBJhkyGfmZfv5UwXcn0A
0q0LgfnDbnMGbv5Qip269ME4Vhi6vlaRqZiDUIaVADH5iUv7NgdcNkaoYWlfkXDe
CsZWSe5fq5LZdlAUqmY5c1eK8MYOfR+oq5CzdPaR1CB00JkwjpMUrMJrZ9gBwNbX
b8K4YZ/onYUlxSO5nTIMnYCqEoiGS2C0+TfVtHlNA7qt/gzfeBCPPU6DS5jgMJTd
PKKareVTIJAjyk2W8ZcIucwKHz2eWC5nQmObTnzTJxULypCP3bbLfns6sYBlzq/z
GPrItaX68KpB3ffvIVw+BoZTBHu4i8Cib4egKJxawjxdKvaJMYhmblExW0fOg/PR
oNvuBYY79TpvcwHhURttB6fZTcBbeogvyY5M3bqJZb6VU8NDiKExDAbiXf4JeOvI
N8CgYTF/+JTmig5sMJ3RkVVty6dlXu+mDGlp4Fjdbq3f/HRpITabIOXMfPfNa6ke
ZsLUyamNk/C7MRJO9N9NH+HkmQzR2fYlrg==
=fyk4
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/116622b1-1bac-4b98-9c1b-72e6c8bcd...@onenetbeyond.org

diaspora packaging crowd funded work summary

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I ran a successful crowd funding campaign to work full time for a
month on diaspora packaging
(http://www.indiegogo.com/at/debian-diaspora) and here is the summary
of work done.

diaspora init script updated, diaspora-installer uploaded, diaspora
package is almost ready to upload (two minified js files blocking
upload https://github.com/diaspora/diaspora/issues/5939)
∘ configures postgres database using dbconfig-common and nginx
∘ handle package updates
• 23 new gems packaged
• 34 existing packages updated
• moved many packages to unstable from experimental after jessie release
• bootstrap-sass 2 is embedded (debian moved to bootstrap-sass 3)
• debian packaging session at IIT Bombay mini debconf
• diaspora yatra campaign (29 Jan - May 5) - All districts except
Kannore in Kerala; Mysore, Bangalore in Karnataka; Chennai, Trichy in
Tamil Nadu
• Launched first diaspora pod hosted in India https://diasp.in
• Setup chat using prosody xmpp server on https://poddery.com

Day by day updates
diaspora yatra https://poddery.com/tags/debian-diaspora-month

diaspora packaging https://poddery.com/tags/diasporayatra

Originally posted at https://poddery.com/posts/1898205
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVp2ovAAoJEM4fnGdFEsIqV1MP/0D9hJqLkMCxLgGLAgQWPvnT
uFzhGIv5cEamgZe7zPCPLgLdf9sMqQG9OQGD0KVZDEFSlGDopeQTtOBTiABwyNyR
K24hXQliDOQeeE2fpjZnyQ9ZzTibJpGDK/UY1DrVczt0u8KgL5aW6Mtxs1Ii1nuP
a+wspmlPAK+eNK6SiYa+mGrxFPk2ad4T81hb3LlTd4oHz0LFr1zvTkS2cOs69vT/
fV/JRe1oLKtbtGGRBQsiAtKt+K3Dd3OMQFcf9GbQVJ0K+OaP+CtmcESgmn/JKEBc
cNC+HjK0SOa5pdpokFoGL+P2u7Q0KWTxjvC5yEAxADnKB4Xgsa9VMqqnNBFM+Fhd
Ell0DMBbmWuKaNnCwP8o7bQoRCMSZPag8UqJSKpeC6TC2LTAlIx6Hfgo8IJOyOIW
GObWIncCwjTKNBhhNVXb9P+g6JWzGlmcXiqsPgYSa11DVmYPBY7HXX5UdV4lE7c0
8XDFGHJVKSliLuSM1veB4Ha9UqtU5ycAO4u1KDXRHvWpNx7/1tBtgNcmVFrGR2Me
5RP/jo4ffbDcOfyim0BmJQYOExEBTCvSARcIcMestOjCfawR+VlSuns/DR7hflGy
J1bpHKYP11NACDijJ4gG/qI3yj/vymKILwWHh9ohtZ00bgUrhjQysEp+6l33XQBz
ZSV+L+SMaQBFc4ti8e+N
=bNWZ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55a76a2f.5020...@debian.org

Re: diaspora packaging crowd funded work summary

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 2015, ജൂലൈ 18 5:54:04 PM IST, Antonio Terceiro  wrote:
>That's really nice, thanks for keeping us updated.
>
>What is the current status with regards to having a proper diaspora
>package in the debian archive (with all its dependencies also in the
>archive)?

1. This issue about 2 minified js files needs to be solved upstream
https://github.com/diaspora/diaspora/issues/5939

After updating to 0.5.1.2 few more dependencies needs handling

2. Need rails 4.2 (jquery-rails 4 chain dependency needs it)
3. Logging-rails needs to be packaged

Possibly a few more, but I can test only after fixing jquery-rails.


- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-BEGIN PGP SIGNATURE-

iQJWBAEBCABAORxQcmF2ZWVuIEFyaW1icmF0aG9kaXlpbCAocGlyYXRlcGluKSA8
cHJhdmVlbkBkZWJpYW4ub3JnPgUCVapQsQAKCRDOH5xnRRLCKjB9EACdyn/KjzUU
6KYhBWeSE+X/O66fNVF6QHbc96yw+1Uq+9+XhClqh/IrrAoXb9DZ1a6wql1C40Nv
QOuSqXs72K2eM8DqjQjjcfu1ufLPLJTbGQsbFjQ4VnOgz3l3RJ+HFc2CHbplgRzc
51tF0RK/hOHpoNaHzIDkoc2COcyhVQ2718SG76X78ChE9sZR78OEDBtDwVn7ayz5
kxa+wsT8y4nRwLLUnaG7cO4HIdEp9umMVxVvgqBtj6W8ai1TVCe/YutEHZDYF9cl
u5sf2Coi7SPvoZ1/qYDgOx2VQ0VhqLzkNlkFF/BpLSksLEi7GJou8PmIKi0zRRB3
/5CMIWwyOa3+VH0IzfW89OiG02wni8o4cVTcWGNz2df6zuBADmBvewPlZ+qWhEHu
h4sq1ER7dERvkBSUfTSl8YWM7OQrtLEC0fZjdlKUKFstWKq7ZlR2Og8xT99EyE3v
Q3ImCZFw3mYVAs3fBY3Hvyl1oSc/0tyIUqMcjXkvtWzxLw290s/b1DY9N5hU9FHr
xI2lmes4zis7O6w5PytC7jqy+Ow1fsjMrXpMCQ3iYXmfnQn5ffgpgDEWLXpvmZmH
7+VyL1+iLyn7/rPKFwElZRIeAbb/CiJdNWfcolhjoxMXVyzqkkmutgpqSRXcj5dk
ozMa7ZBsMBeDEzLjSSLpSYFJ2qrQpcR9Rg==
=0saV
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/491adc69-d11f-4e33-b8dc-020b68e76...@onenetbeyond.org

Re: Summary of the DebConf firmware discussion

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 2015, ആഗസ്റ്റ് 30 4:27:00 AM IST, Anthony Towns  wrote:
>Also, having a hardware database that you could query before purchasing
>a new computer would be even better, no?

We already have one h-node.org

Praveen
- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-BEGIN PGP SIGNATURE-

iQJWBAEBCgBAORxQcmF2ZWVuIEFyaW1icmF0aG9kaXlpbCAocGlyYXRlcGluKSA8
cHJhdmVlbkBkZWJpYW4ub3JnPgUCVeJ+6AAKCRDOH5xnRRLCKoMnEACglaYMdgka
phJgcXlzN9SuAkYdaddl11d2QEEj0YdnSF7AOCyQ4bB45W7vCsufXsAVNegyxA/T
ko7bxKJPYoUkDWrriIHtk/CEAWZb/GksIS3PqS+QjIRLhACVu/9K2BefGg8fBJrS
dvl23wlHDWUHYIb0NcQB7T3haD4xdDOeCOmb4SvGorD9wfz7zC1ItcgD3AU6YrRh
UONFbSRkpKz3G/x+pgvJK1lHgcNuE2NEw7+cckD6gUv3vjcv0NjPBsJZAc5i9OvR
+Bg/cAGNkA39BOfP5CEPASbtdr+6KtAIZ/gEWNzY5+mXYec5D2Vh/amLNkNp6hcm
gCq5v+KdHu3jjiqn/miqirLqxTaSHNArMSn2A754xO2MYtVpMNmHGzL9VLnXcce9
HrYqCbf4ukLCn0UeobKOd7KQm51ns5HkQaOpouvrC7uDHJJEGz8J4XdxOkCyWLNW
ovnIge/zR+oWfkKOME0GxOFoyHuXOoP+Se9QQETFTWehweCEyxH9MsnZ9hh9iAfk
DzC6BO6Gu6xrJZDrmNnu6kmJnEGAMO0E/9hlRAX3P4u9UlSWylEP04P00JYu0XMF
E/gGGoZU+RtNACVFdkM+BCt+jvc/d+ksnz+yCIQuD47ySdMmlkU/XDKHI2olu8RD
tzmpyIY+2JH8W3fLqybiUjsBHy6CaR7VfQ==
=Bogw
-END PGP SIGNATURE-

Re: Rebuilding reverse-deps in salsa pipeline?

[Pirate Praveen]

On 12/15/18 4:11 AM, Bernd Zeimetz wrote:
> Hi,
> 
> I'm wondering if somebody implemented a salsa pipeline to rebuild the
> reverse-deps of a library?
> 
> Is there some example/docker image to build on?

https://salsa.debian.org/ruby-team/meta/blob/master/build-and-upload
does this, may be you can just include this in a docker image.



signature.asc
Description: OpenPGP digital signature

Bug#916742: ITP: golang-github-namsral-flag -- Parse flags, environment variables and config files

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-namsral-flag
  Version : 1.7.4~alpha+git20170814.67f268f-1
  Upstream Author : Lars Wiegman
* URL : https://github.com/namsral/flag
* License : BSD-3-clause
  Programming Lang: Go
  Description : Parse flags, environment variables and config files

 Flag is a drop in replacement for Go's flag package with the
 addition to parse files and environment variables. If you support the
 twelve-factor app methodology (http://12factor.net), Flag complies with
 the third factor; "Store config in the environment".

This package is a build dependency of gitlab-pages.



signature.asc
Description: OpenPGP digital signature

Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Pirate Praveen]

[adding -devel to cc]

On 12/3/18 8:11 PM, Dominik George wrote:
>> well, Debian is using gitlab!!! so this sentence has no sense. The
>> problem here
>> is that is a complex software that depends of a lot of pieces and it's
>> not
>> easy/possible to fit the definition. So, maybe we should create another
>> category
>> of software.
> 
> Yes, and that Debian officially uses GitLab, from a foreign source, without 
> being able to support it in Debian, does make me feel ashamed for the project.
> 
>> maybe creating another kind of repo. debian-contributuions
>> debian-blabla, whatever.
>>
> 
> We had volatile, which, redefined properly, could help. I am trying to draft 
> such a definition.

Did you get a chance to work on it?

I think it has to be an extension of backports with dependencies that
fall within the backports criteria being maintained in backports and
only packages that cannot be in backports maintained in volatile.

Original definition of volatile from https://www.debian.org/volatile/:
"Some packages aim at fast moving targets, such as spam filtering and
virus scanning, and even when using updated data patterns, they do not
really work for the full time of a stable release. The main goal of
volatile is allowing system administrators to update their systems in a
nice, consistent way, without getting the drawbacks of using unstable,
even without getting the drawbacks for the selected packages. So
debian-volatile will only contain changes to stable programs that are
necessary to keep them functional."

Proposed definition:
"Some packages aim at fast moving targets, such as complex web based
software with very small release cycles and new dependencies, they do
not receive security support or bug fixes for the full time of a stable
release. This means backporting targeted fixes are impossible.  The main
goal of volatile is allowing system administrators to update their
systems in a nice, consistent way, without getting the drawbacks of
using unstable, even without getting the drawbacks for the selected
packages. New dependencies introduced can be maintained in backports
repository. So debian-volatile will be an extension of debian-backports,
with dependencies that fall within the criteria maintained in
debian-backports."





signature.asc
Description: OpenPGP digital signature

Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Pirate Praveen]

On 2018, ഡിസംബർ 18 7:14:14 PM IST, Rhonda D'Vine  wrote:
> And yes, I'm with Alexander, the volatile maintenance can't be dumped
>on the backports team.  It's a different workflow anyway.

My proposal for backports is to have only the dependencies of packages in 
volatile that fall in the current definition of backports kept there, ie,

1. They are already in testing and
2. will be part of next stable.

And use volatile only for packages that cannot fit this criteria. I'd be happy 
to join the backports team to help with the extra load. I hope others will join 
too.

But if that is not possible, volatile as a separate archive is also fine. It is 
just that many packages will have to be in both archives and that is a lot of 
extra work, which I think can be avoided.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Pirate Praveen]

On 12/18/18 8:41 PM, Holger Levsen wrote:
> On Tue, Dec 18, 2018 at 08:38:39PM +0530, Pirate Praveen wrote:
>> But if that is not possible, volatile as a separate archive is also fine. 
> 
> instead of volatile we need PPAs.

I think a redefined volatile is the best option for sharing work. But
PPA approach is best in case of conflicts.

I'm leaning towards volatile and hence I proposed it. If you feel
strongly about PPAs, please propose and drive it. Either option will
work for me.



signature.asc
Description: OpenPGP digital signature

Re: Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Pirate Praveen]

On 12/19/18 1:05 AM, Philipp Kern wrote:
> In the Ubuntu PPA case you get free reign over what's in that archive
> and what you backport as part of offering the package. Obviously this
> might conflict with the existing set. But the same is true for a
> centralized volatile archive if you need to backport a large set of
> build dependencies to make the whole thing work in the first place. And
> I'm sure you wouldn't just go for a gitlab source package with bundled
> build dependencies.

That is why I prefer it as an extension of backports where the
dependencies still follow the regular release cycle, they should be in
testing and that means doing proper transitions for breaking changes and
only the gitlab package itself be kept in volatile.

> Now the policy question of who can ship what in a way that looks
> semi-officially as being part of Debian is tricky. I personally find the
> notion that testing should just be the staging ground for the next
> release to be unfortunate but at the same time know how we ended up with
> it. Maybe there's a place for packages that cannot usefully be supported
> for a stable release and hence need to live in parallel. But then again
> I wonder if the answer wouldn't be an archive where the input is built
> for all suites and where the dependencies are bundled - if only because
> you'd track upstream closely and would through that (hopefully) pull in
> necessary security updates.

I think it is still possible to maintain dependencies without bundling
if it is like backports, ie, we can update them to newer upstream
versions. Hence the requirement to redefine volatile. If they are not
accepted in backports, a lot of packages will be duplicated, but even
that is okay if backports team is not happy to take the new packages.

And if this discussions go no where, the only option would be to make it
an installer package, like diaspora-installer. But I'm not sure if it'd
add much value over upstream provided omnibus packages.

> Kind regards
> Philipp Kern
> 
> [1] And to some degree I am unhappy with backports' team's antagonistic
> view on volatile here. Stuff like gitlab would have been rejected in the
> same way it would've been in backports. The useful bits live on, it
> wasn't abandoned to cause more work for backports. At the same time
> backports can serve as a replacement of a subset of use cases too, where
> its rules fit just fine.

Thanks for sharing this.



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Repository for fast-paced package backports

[Pirate Praveen]

On 2018, ഡിസംബർ 26 2:16:07 AM IST, Dominik George  
wrote:
>Heisann, alle sammen,
>
>as announced in the recent thread about maintaining, I hereby propose a
>repository that allows making “backports” of packages available to
>users
>of the stable distribution, if those packages cannot be maintained in
>testing and backported in the usual way. If you are interested in what
>lead up to that, please see bug #915050. I will give a short summary of
>it here.
>
>
>Reasons for having a special place for some packages
>
>
>(You may want to skip this part if you are familiar with the
>situation.)
>
>As all developers know (but passers-by may not), for software to enter
>the Debian archive, it is always uploaded to the unstable distribution,
>then migrates to testing (hopefully ;)), which is at some point
>snapshot
>and made the new stable release. From there on, maintainers have two
>obligations: Firstly, keep the package in stable good and secure, e.g.
>by uploading security fixes for it once they become available upstream,
>or even backport fixes themselves. Secondly, provide the package in
>unstable with updates and ensure its migration, to keep it ready for
>the
>next stable release.
>
>Now, for some software packages, this process is problematic, because
>upstream may have another idea about software lifecycles. Concerning
>the
>GitLab example, upstream provides security fixes for three months for
>their stable releases. Backporting fixes from newer versions is very
>hard or impossible because the massive amounts of changes to the
>software in every new versions. This is something that also affects
>other packages, like Mozilla Firefox, which has a firefox package in
>unstable, and a separate firefox-esr package, with the ESR version of
>Firefox. Only the latter migrates to testing.
>
>Users of Debian honour it for its stability, but as an agile software
>lifecycle is adapted by more and more very popular software packages,
>not being able to install these packages in the trusted, well-known
>fashion through the official apt repositories is becoming more and more
>of a drawback.
>
>It can easily be assumed that the normal release and maintenance cycle
>of Debian stable will not change, which is very good, so we should find
>a way to still provide such software as described above to users.
>
>
>Why backports is not enough
>===
>
>This also is well-known, but for completeness: Formal backports in
>stable-backports are required to be direct backports from testing, and
>are a stepping stone within the upgrade from stable to stable+1. Thus,
>a
>version of a package that is not in testing can never be in
>stable-backports.
>
>
>Name of the new repository
>==
>
>In the past, the name “volatile” was used for a similar repository, but
>with a different scope (limited to data packages for things like virus
>scanners). I will thus use the working title volatile throughout this
>proposal, although this may change.
>
>Other ideas: fastlane, unsupported
>
>(Please feel free to add other ideas.)
>
>
>Requirements for a package to go into stable-volatile
>=
>
>The new volatile proposal is not intended to ease life for package
>maintainers who want to bypass the migration and QA requirements of the
>regular stable lifecycle, so special need must be taken to ensure only
>packages that need it go into volatile. I want to summarise the
>requirements like so:
>
>- The package must be maintained in unstable, like every other package.
> - The package must not be in testing, and care must be taken for the
>   package not to migrate to testing.
> - Regular maintenance for the lifetime of stable must be impossible
>   or unnecessarily hard, and this requirement should be assessed in
>   a verifiable manner, e.g. referring to upstream’s lifecycle model.
> - There must be notable need for the package. Like for backports, user
>   requests might be an indicator.
> - Should the package be removed from unstable, it must also be removed
>   from volatile.
> - Should the package begin to migrate to testing again, it must
>   be moved to stable-backports.
>
>Before starting to maintain a volatile package, the maintainer shall
>seek consent (or doubt) on debian-devel.
>
>
>Building packages and package dependencies
>==
>
>Packages for volatile are built the same way as formal backports, only
>that the source is taken from unstable rather than testing. In
>particular:
>
> - Changes shall be kept as small as possible.
> - The package is rebuilt against stable.
>- The package may depend on packages in stable, stable-backports or
>stable-volatile.
>
>Dependencies on other packages in volatile should be avoided if
>possible. Especially, dependencies of the package that also need
>backporting must not be added to volatile just because they are
>dependencies —

Re: Proposal: Repository for fast-paced package backports

[Pirate Praveen]

[As requested, keeping it to -devel only]

On 12/26/18 7:35 PM, Antonio Terceiro wrote:
> On Wed, Dec 26, 2018 at 01:04:44PM +0530, Pirate Praveen wrote:
>> If it has to be completely separate from -backports, it means some packages 
>> will need to be maintained twice, even when they meet the criteria for 
>> backports fully, just because a package in volatile declare a dependency on 
>> them.
> 
> There is nothing that stops you, or whoever wants to maintain this newn
> repository from doing it in a way that 1) reuses what's already in
> backports, even automatically and 2) adds the bits that are not deemed
> appropriate for backports.
> 

The -backports team does not want the dependencies of gitlab to be in
-backports even though it meets the criteria for backports. So we will
end up adding it to volatile. Now if some one else wants the same in
-backports, they will have to repeat the process.

Take nodejs or npm for example, which I backported now. In buster the
-backports team does not want it in backports if I'm doing it for
gitlab, even though they satisfy the requirement for -backports. So we
will end up uploading these to volatile, if someone else wants it in
-backports, they will have to do it again.

It is one way (volatile can use -backports, but -backports can't use
volatile). I'm fine with that if people don't want our work for volatile
not added to -backports.

Dominik,

I think we can go ahead with volatile as separate suite and take
packages from -backports if exist but add all new dependencies to -volatile.

This,

"Dependencies on other packages in volatile should be avoided if
possible. Especially, dependencies of the package that also need
backporting must not be added to volatile just because they are
dependencies — every dependency that is needed to be backported to
support the volatile package must be considered on its own and in all
but unprobable edge cases be maintained as a formal backport. Obviously,
the unprobable edge case occurs when the package depends on another
package that also fully qualifies for volatile, as described above."

should be changed to,

"Dependencies of the package that also need backporting must be added to
volatile."




signature.asc
Description: OpenPGP digital signature

Re: Proposal: Repository for fast-paced package backports

[Pirate Praveen]

On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George  
wrote:
>No. The dpendencies of gitlab not being accepted into backports right
>now is an entirely different issue. I am repeating myself: This
>proposal
>is not intended to ease the life of maintainers whose packages qulify
>for -backports. The only difference between -backports and -volatile in
>this draft proposal is that -volatile can take packages that are not in
>testing due to the exact one reason that hey have a shorter lifespan.
>No
>single other thing qualifies a package for -volatile if it is not
>qualified for -backports.
>
>If there are other issues to solve than the lifespan of the package
>version, they must be solved in another way.

I agree with you, it is the best outcome. But when people with power 
(-backports ftp masters) are not willing to consider it, we have to go with 
plan B, which is less than ideal, but can move things forward.

>On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote:
>> As I said, gitlab was not about manpower. This new repo is completly
>against
>> our vision of what backports is. Therefore we don't want it within
>the
>> backports suite. 
>

If people argue both ways, how can we answer? Either it adds more work for 
-backports team or it does not. Some people say its not fair to add more load 
while ftp masters say its not about load.

If it does not add extra load, then I don't see why it can be kept out of 
-backports when it qualifies except for being a dependency of -volatile. They 
say it does not match with their vision. So what option is left for us? We have 
to take their word for it and move forward without inconveniencing them. I 
don't think -backports ftp masters is going to accept this proposal (from the 
responses we already received), so I can live with all dependencies in 
-volatile.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Proposal: Repository for fast-paced package backports

[Pirate Praveen]

On 12/28/18 11:06 AM, Thomas Goirand wrote:
> If the problem is hardware and connectivity, then IMO you can easily
> find a sponsor for it. My company could well offer it for example
> (hosted in Geneva with very nice connectivity to almost everywhere).
> 
> Setting-up a repository isn't hard. And for a start, I don't think you
> really need a buildd network, just amd64 is ok-ish.

I'd like go ahead with this offer and create rolling.debian.net (as
someone suggested already to avoid reusing volatile). I think we can
take the setup discussions offlist.

>> If you know how to start with a new service at
>> {volatile,fastpaced,whatever}.debian.net without having to reinvent the
>> wheel for acceptign uploads, getting packages built, etc., please
>> enlighten me.
> 
> Setting-up reprepro, or even Dak, isn't that hard.

I already use reprepro
https://people.debian.org/~praveen/gitlab/

and will continue to use the same (as the number of packages would be
small and it is pretty simple to setup).



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Repository for fast-paced package backports

[Pirate Praveen]

On 2018, ഡിസംബർ 31 5:19:22 PM IST, Jonas Meurer  wrote:
>Pirate Praveen:
>> On 12/28/18 11:06 AM, Thomas Goirand wrote:
>>> If the problem is hardware and connectivity, then IMO you can easily
>>> find a sponsor for it. My company could well offer it for example
>>> (hosted in Geneva with very nice connectivity to almost everywhere).
>>>
>>> Setting-up a repository isn't hard. And for a start, I don't think
>you
>>> really need a buildd network, just amd64 is ok-ish.
>> 
>> I'd like go ahead with this offer and create rolling.debian.net (as
>> someone suggested already to avoid reusing volatile). I think we can
>> take the setup discussions offlist.
>
>Please don't name it 'rolling'. This term is used a lot in the sense of
>'rolling releases' by other distributions, and also in discussions
>about
>constantly usable testing.

Well, it only makes things clear as the packages in this repo will be rolling.

>From all names that got suggested so far, 'fastpaced' is the only one
>that doesn't have a special meaning in Debian context yet, at least to
>my knowledge. That's why I would prefer that one.
>
>Thanks for pushing that effort, Nik and Pirate! I really like the idea
>of having a repository that provides newer releases of fast-moving
>software built for stable.
>
>Cheers,
> jonas

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Proposal: Repository for fast-paced package backports

[Pirate Praveen]

On 1/1/19 3:42 PM, Scott Leggett wrote:
> To continue the bikeshedding, what about "express"? Seems quite fitting
> as the packages don't make the usual stop through testing...

I think STS (Short term support) will fit nicely with LTS. If there is
no serious objections, I'd go with this.



signature.asc
Description: OpenPGP digital signature

Bug#930219: ITP: node-dagre-layout -- Graph layout for JavaScript

[Pirate Praveen]

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

* Package name : node-dagre-layout
 Version : 0.8.8
 Upstream Author : Tyler Long 
* URL : https://github.com/tylingsoft/dagre-layout#readme
* License : Expat
 Programming Lang: JavaScript
 Description : Graph layout for JavaScript
This library is an out-of-box replacement for dagre and it is based on
original dagre.
.
Dagre is a JavaScript library that makes it easy to lay out directed 
graphs on

the client-side.

This library is a dependency of gitlab. Since it needs babel and 
webpack to build es5 code, it is not suitable for embedding.

Bug#930223: ITP: node-dagre-d3-renderer -- D3-based renderer for Dagre

[Pirate Praveen]

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

* Package name : node-dagre-d3-renderer
 Version : 0.5.8
 Upstream Author : Liad Yosef
* URL : https://github.com/tylingsoft/dagre-d3-renderer#readme
* License : Expat
 Programming Lang: JavaScript
 Description : D3-based renderer for Dagre
This library is an out-of-box replacement for dagre-d3 and it is based 
on the

original dagre-d3 project.
.
Dagre is a JavaScript library that makes it easy to lay out directed 
graphs on
the client-side. The dagre-d3 library acts as a front-end to dagre, 
providing

actual rendering using D3.
.
Node.js is an event-based server-side JavaScript engine.

This library is a dependency of gitlab. Since it uses babel and webpack 
to generate ES5 code, it is not suitable for embedding.

Bug#930246: ITP: node-rollup-plugin-sourcemaps -- Rollup plugin for grabbing source maps from sourceMappingURLs

[Pirate Praveen]

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

* Package name : node-rollup-plugin-sourcemaps
 Version : 0.4.2
 Upstream Author : Max Davidson 
* URL : https://github.com/maxdavidson/rollup-plugin-sourcemaps#readme
* License : Expat
 Programming Lang: JavaScript
 Description : Rollup plugin for grabbing source maps from 
sourceMappingURLs
Useful for working with precompiled modules with existing source maps, 
without

resorting to sorcery (another library).
.
Inspired by webpack/source-map-loader library.
.
Node.js is an event-based server-side JavaScript engine.

Bug#930262: ITP: node-apollo-link -- Flexible, lightweight transport layer for GraphQL

[Pirate Praveen]

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

* Package name : node-apollo-link
 Version : 1.2.11
 Upstream Author : Evans Hauser 
* URL : https://github.com/apollographql/apollo-link#readme
* License : Expat
 Programming Lang: JavaScript
 Description : Flexible, lightweight transport layer for GraphQL
This library is a standard interface for modifying control flow of 
GraphQL
requests and fetching GraphQL results, designed to provide a simple 
GraphQL

client that is capable of extensions.
.
The high level use cases of `apollo-link` are highlighted below:
 * fetch queries directly without normalized cache
 * network interface for Apollo Client
 * network interface for Relay Modern
 * fetcher for GraphiQL
.
The apollo link interface is designed to make links composable and 
easy to
share, each with a single purpose. In addition to the core, this 
package

contains links for the most common fetch methods—http, local schema,
websocket—and common control flow manipulations, such as retrying 
and polling.

.
Node.js is an event-based server-side JavaScript engine.

This package is a dependency of gitlab. Since it uses rollup and 
typescript to generate code, it is not suitable for embedding.

Bug#930265: ITP: node-rollup-plugin-invariant -- Rollup plugin to strip invariant(condition, message) strings in production

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org
Control: block 930262 by -1

* Package name : node-rollup-plugin-invariant
 Version : 0.5.6
 Upstream Author : Ben Newman 
* URL : https://github.com/apollographql/invariant-packages
* License : Expat
 Programming Lang: JavaScript
 Description : Rollup plugin to strip invariant(condition, message) 
strings in production

Packages for working with invariant(condition, message) assertions.
.
This package includes ts-invariant and rollup-plugin-invariant 
libraries.

.
Node.js is an event-based server-side JavaScript engine.

This package is a build dependency of apollo-link, which is a 
dependency of gitlab. Since it uses rollup and typescript to generate 
code, it is not suitable for embedding.

Bug#930635: ITP: node-immutable -- Immutable Data Collections

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org
Control: block 930634 by -1

* Package name : node-immutable
 Version : 3.8.2
 Upstream Author : Lee Byron (https://github.com/leebyron)
* URL : https://facebook.github.com/immutable-js
* License : Expat
 Programming Lang: JavaScript
 Description : Immutable Data Collections
Immutable data cannot be changed once created, leading to much simpler
application development, no defensive copying, and enabling advanced
memoization and change detection techniques with simple logic. 
Persistent data
presents a mutative API which does not update the data in-place, but 
instead

always yields new updated data.
.
Immutable.js provides many Persistent Immutable data structures 
including:

List, Stack, Map, OrderedMap, Set, OrderedSet and Record.
.
These data structures are highly efficient on modern JavaScript VMs by 
using
structural sharing via [hash maps tries][] and [vector tries][] as 
popularized

by Clojure and Scala, minimizing the need to copy or cache data.
.
Immutable also provides a lazy Seq, allowing efficient chaining of 
collection
methods like map and filter without creating intermediate 
representations.

Create some Seq with Range and Repeat.
.
Node.js is an event-based server-side JavaScript engine.

Re: Please help me to create Debian package

[Pirate Praveen]

On 2019, ജൂലൈ 4 8:50:25 PM IST, himanshu Singh  wrote:
>Hi, I am working on a project named Osdag. It is open-source software
>for
>the design of steel structures. I'm trying to create a Debian package
>for
>it and planning to add to Debian package repository. It would be a
>great
>help if someone could create a package for us or help us to create
>that.

I regularly guide new people to learn packaging. We usually hangout at 
#debian-browserify on irc (you can also join via matrix/riot 
#debian-browserify:poddery.com). We teach basics with nodejs, but once you pick 
up the basics, you should be able to package software in any language.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Proposal: Repository for fast-paced package backports

[Pirate Praveen]

On 2019, ജൂലൈ 28 6:36:21 PM IST, Phil Morrell  wrote:
>On Tue, Jan 01, 2019 at 05:49:37PM +0530, Pirate Praveen wrote:
>> I think STS (Short term support) will fit nicely with LTS. If there
>is
>> no serious objections, I'd go with this.
>
>As debconf is finishing, though I don't know if either of you attended
>this year, has there been any progress on this idea? Is there an
>evergreen/sts/fasttrack destination I can put in my dput.cf to support
>normally unsuitable packages like jenkins/virtualbox/firefox/gitlab?

Hi Phil,

It stalled for a long time and we restarted work on it recently. We are in the 
process of getting server space to setup dak.

Praveen
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Pirate Praveen]

On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers  wrote:
>I can already trigger all the autopkgtests in unstable for packages
>that
>are in experimental, so if you interested in this, please contact me.
>This would enable library maintainers to at least have an overview of
>what would happen. I could even activate this by default.

Yes, please do this by default so we can have a better picture of the 
transition. Though for many libraries we also need to rebuild reverse build 
dependencies. I have been using salsa.debian.org/ruby-team/meta/build for this. 
Right now I'm interested in libgit2, grpc and protobuf transitions.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 2 1:26:51 AM IST, Paul Gevers  wrote:
>Hi Pirate, and other interested parties,
>
>On 09-08-2019 08:22, Pirate Praveen wrote:
>> On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers 
>wrote:
>>> I can already trigger all the autopkgtests in unstable for packages
>>> that
>>> are in experimental, so if you interested in this, please contact
>me.
>>> This would enable library maintainers to at least have an overview
>of
>>> what would happen. I could even activate this by default.
>> 
>> Yes, please do this by default so we can have a better picture of the
>transition.
>
>It's not running 100% automatically and it has a bit (600 tests) of
>backlog, but it's here already:
>https://release.debian.org/britney/pseudo-excuses-experimental.html
>
>I'll cron it probably tomorrow evening.
>
>Paul

Thanks a lot, it is really helpful for transitions. Now I can see a list of 
packages blocking gitlab upload to unstable in one place.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Git Packaging Round 2: When to Salsa

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 13 1:06:13 AM IST, Marc Haber 
 wrote:
>alioth.debian.org, anyone? That one went away pretty fast.

I wonder why people keep repeating this. This was migrated to salsa and also 
archived, so nothing was lost. This was a planned move to a better solution 
(gforge was unmaintained), there was enough time to move things around.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 14 4:21:16 AM IST, Thomas Goirand  wrote:
>On 9/12/19 2:47 PM, Sam Hartman wrote:
>> 1) there are significant problems we'd run into if we forbid non-free
>tools in
>> Debian work
>
>Sorry, WHAAAT ? That's shocking to read this from the DPL.
>Are you sure you didn't do a mistake in this sentence?
>
>There's absolutely no problem within the Debian project to forbid using
>non-free software. That's what I've signed-up for (ie: "debian will
>remain 100% free", aka the FIRST LINE of the social contract), and what
>I want, and I'm sure the vast majority of DDs agree.
>
>In the long run, there's going to be significant problems if we open
>then Pandora box of using non-free stuff to build Debian. To some
>degree, it has already been partially opened.
>
>Indeed, I'm being increasingly frustrated with what's going on in Salsa
>in general, and especially when it comes to using Google's
>infrastructure. We *must* get out of this. If going through a GR helps
>Salsa admins to realize a point of view that I believe I share with a
>large amount of people within Debian, then I'm all for it.
>
>On 9/12/19 3:07 PM, Ian Jackson wrote:
>> We should resolve this with a GR.  Something like:
>
>I would second that GR. My opinion was that we would need a GR to
>enforce things, with this discussion, I'm even more convince we do need
>one. My problem was that I'm not as good writing nice English texts as
>you are. Good if you can do it.
>
>On 9/12/19 3:07 PM, Ian Jackson wrote:
>> Non-Debian services are
>> acceptable here so long as they are principally Free Software.
>
>s/principally/fully/
>
>Please, no compromise here. (or is it that I'm badly reading your
>English, and that "principally" means something else than in French?)
>
>On 9/12/19 4:37 PM, Enrico Zini wrote:
>> I see you keep pushing things with a strong cohercive slant rather
>> than working on creating useful and attractive infrastructure to make
>> everyone's work easier.
>
>What exactly do you propose here? The Salsa admins look like not
>accepting more contributors, neither seem open to suggestions. They
>just
>do "their way". I've countless times wrote to both them and in public
>that I'd love to be involved to make things more free. They also
>refused
>to use a packaged version of Gitlab even before it was a thing. They
>decided to use Google service, without prior communication about it and
>agreement of the community. When some of us pointed out it wasn't ok,
>it
>was strongly rejected, despite any possible offer to use something else
>(like Swift storage of other providers).
>
>So, exactly what do you think one can do, given the current situation?
>Or are you suggesting someone opens a solution that would compete
>what's
>been done on Salsa? This sounds counter-productive to me.
>
>On 9/12/19 4:51 PM, Ian Jackson wrote:
>> The latter is what I am trying to do.  I'm sorry that the opposite is
>> occuring.
>
>Ian, you're doing just right. I'm 100% with you on this. We shall not
>compromise, we did enough of that already, and in my opinion, we are
>already leaning too much on the wrong direction with Salsa.
>
>On 9/13/19 9:39 AM, Enrico Zini wrote:
>> Sam showed you how the situation in Debian seems to be different from
>> what you understood, and your response was not to acknowledge, try to
>> understand, and map the current status quo, but to consider of a GR
>to
>> force the status quo to fit to your expectations.
>
>I very much don't agree on this. If 7% of the packages with VCS fields
>are using Github, we *MUST* do something about it. And that's not just
>to fit Ian's own malicious agenda, or to please him. If this has to go
>through a GR, to make the small minority understand that the vast
>majority of us don't agree, then let's do it!

I will also support such a GR. I started packaging gitlab so we don't have to 
compromise on ease of use compared to github.

>On 9/13/19 9:39 AM, Enrico Zini wrote:
>> This cannot be the discussion culture of a group where I can be
>> comfortable working with others.
>
>I'm feel sorry to read these lines, though, I don't see how we can
>compromise on how much free Debian should be. I'm very surprised read
>you're not comfortable working in a group where some of us are pointing
>this out. Now, this makes *me* uncomfortable. That's not what I thought
>Debian was about then. I thought we all signed up on "Debian will
>remain
>100% free"... How come we don't have a strong consensus on this then?
>Have some of us just given-up on software freedom?

>Thomas Goirand (zigo)

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 14 3:46:43 PM IST, Adam Borowski  
wrote:
>On Sat, Sep 14, 2019 at 09:37:00AM +0530, Pirate Praveen wrote:
>> I will also support such a GR.  I started packaging gitlab so we
>don't
>> have to compromise on ease of use compared to github.
>
>And, despite a massive amount of efforts from you and others, packaged
>gitlab is not fit for Salsa use.  It hasn't also ever been in a stable
>release of Debian, despite being around since a year before Stretch's
>freeze.

I don't think looking at our current stable release cycle as holy standard for 
evaluating a software is the right approach. Backports was evolved to cater to 
a different need, it was not official when it was started. Similarly we now 
have http://fasttrack.debian.net being setup which includes gitlab.

>Looking at the number and complexity of packages needed solely for
>gitlab,
>I'd say that they'll collapse the moment you get busy with other tasks.

I understand this risk, that is the reason why I make sure more people join the 
team maintaining gitlab. I'm always mentoring new people and if you look at the 
tracker.debian.org for gitlab and dependencies, you will see more names 
uploading packages now. If you look at last 10 uploads of gitlab, 5 of it was 
not done by me. Initially gitlab inc was funding only me to work on gitlab 
packaging, now they fund me, Sruthi and Abhijith.

Earlier the gitlab package backports were only available from my 
people.debian.org repo which only I had access to. Now 3 people have access to 
fasttrack.debian.net already and the last upload was not done by me.

>This doesn't say anything good about Gitlab's design.
>
>(I'm quite obviously not bashing you, but your upstream.)
>
>I don't trust Gitlab's prolonged support.  Let's let it prove itself by
>being a part of a couple of stable releases -- and _then_ we can build
>upon
>its foundation.  That'd be a time frame already much accelerated
>compared to
>other core software projects.

That is not going to happen, instead we need to adapt ourselves to this fast 
paced development and fasttrack.debian.net is a step in that direction.

>Until then, I'll use git (which has greatly proven itself) but strongly
>refuse any ties to any particular platform.
>
>
>Meow!

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Git Packaging Round 2: When to Salsa

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 15 12:35:18 AM IST, Holger Levsen  
wrote:
>On Fri, Sep 13, 2019 at 11:30:51AM +0530, Pirate Praveen wrote:
>> On 2019, സെപ്റ്റംബർ 13 1:06:13 AM IST, Marc Haber
> wrote:
>> >alioth.debian.org, anyone? That one went away pretty fast.
>> I wonder why people keep repeating this. 
>
>I guess because according to https://trends.debian.net/#vcs-hosting
>there's 
>*still*, today, almost 1 source packages in unstable which declare
>they
>are maintained in git on alioth.
>
>I wouldn't call that (part) a success.

Don't they get redirected to salsa?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 14 3:46:43 PM IST, Adam Borowski  
wrote:
>On Sat, Sep 14, 2019 at 09:37:00AM +0530, Pirate Praveen wrote:
>> I will also support such a GR.  I started packaging gitlab so we
>don't
>> have to compromise on ease of use compared to github.
>
>And, despite a massive amount of efforts from you and others, packaged
>gitlab is not fit for Salsa use.  It hasn't also ever been in a stable
>release of Debian, despite being around since a year before Stretch's
>freeze.

And the huge amount of work we put in to maintain gitlab is improving the base 
package quality of Debian, especially nodejs. We have packaged many core build 
tools like webpack, rollup, gulp, grunt etc which makes it easier to build many 
JavaScript libraries from source (we had to reverse engineer the build process 
before these were packaged, look at d3-format and jquery for example). rails is 
another example which is useful beyond gitlab. Also all the new people who 
joins gitlab team strengths the underlying ruby, js and golang teams.

I think I have to repeat these in regular intervals in -devel and probably a 
better way is to add it to gitlab wiki page and share link.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 15 12:57:08 AM IST, Sean Whitton  
wrote:
>Hello Pirate,
>
>On Sun 15 Sep 2019 at 12:27AM +0530, Pirate Praveen wrote:
>
>> That is not going to happen, instead we need to adapt ourselves to
>> this fast paced development and fasttrack.debian.net is a step in
>that
>> direction.
>
>It's not just a matter of adapting workflows -- without real stable
>releases, however good your workflows are, packaging GitLab and
>administering GitLab installations demands more of people's time than
>it
>would if there were real stable releases.
>
>Real stable releases are freedom-enhancing when they free up people's
>time to work on other stuff.

Well, gitlab is not the only git based collaboration platform out there. I'm 
sure some of the alternatives will have a longer release cycle compatible with 
Debian stable releases. Those who care about it can certainly contribute to 
those and promote them. The fast paced development also means it brings out new 
features faster and apparently many people take that tradeoff currently with 
gitlab (not just Debian, other Free Software projects like gnome, KDE are 
either moved or moving to gitlab).

Also if there is a strong interest in LTS releases, gitlab is Free Software and 
others can maintain backports of security releases.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Hosting the original youtube-dl sources on salsa?

[Pirate Praveen]

On 2020, ഒക്‌ടോബർ 30 1:46:21 PM IST, Philip Hands  wrote:
>We could presumably consult a lawyer, but the RIAA would need to be even
>more moronic than I think they are to have a go at us, given that nobody
>in the wider world has ever heard of us, and we're going to have no
>trouble raising funds to defend a case, and we're very clearly not
>making a cent out of publishing this stuff, so they're going to have fun
>trying to calculate the damages. Also, see the recent Gnome case[1] for
>how well these things can go when people who don't know the first thing
>about Free Software start trying to throw lawyers at the situation.
>
>Overall even if the law managed to be sufficiently deranged to result in
>us losing a case against the RIAA, the light that would shed on the
>situation seems likely to do more harm to them, and more good to us than
>not getting involved in the first place.
>
>The alternative world where we stop doing good things because of people
>like the RIAA seems much worse.

Very well articulated. I agree.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#974753: ITP: golang-honnef-go-tools -- Collection of golang tools and libraries

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name : golang-honnef-go-tools
 Version : 2020.1-1
 Upstream Author : Dominik Honnef
* URL : https://github.com/dominikh/go-tools
* License : Expand
 Programming Lang: Go
 Description : Collection of golang tools and libraries

keyify - Transforms an unkeyed struct literal into a keyed one. |
rdeps - Find all reverse dependencies of a set of packages |
staticcheck - Go static analysis, detecting bugs, performance issues, 
and much more.
structlayout - Displays the layout (field sizes and padding) of 
structs. |
structlayout-optimize - Reorders struct fields to minimize the amount 
of padding.
structlayout-pretty - Formats the output of structlayout with ASCII 
art.
In addition to the aforementioned tools, this package contains the 
libraries necessary to implement these tools.


These are currently vendored in gitaly and I'd like to remove the 
vendored version in favour of the packaged version.

Re: Split Packages files based on new section "buildlibs"

[Pirate Praveen]

On Fri, Nov 13, 2020 at 19:28, Tomas Pospisek  
wrote:
This solution seems to be too trivial that nobody would have though 
of it, so what is it that I (and I guess many Debianers) are missing?

*t


Additionally these libraries change too fast and most of the time, 
there is no long term supported releases (sometimes not even any 
releases, people just use git commits). You will be stuck at a version 
used by another package or you will have to keep changing the library 
version (and your application) as other packages change these 
dependencies.

Bug#974862: ITP: golang-gocloud -- The Go Cloud Development Kit (Go CDK)

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name : golang-gocloud
 Version : 0.20.0-1
 Upstream Author : The Go Cloud Development Kit Authors
* URL : https://github.com/google/go-cloud
* License : Apache-2.0
 Programming Lang: Go
 Description : The Go Cloud Development Kit (Go CDK)

The Go Cloud Development Kit (Go CDK) Write once, run on any cloud 
☁️


This is a new build dependency of gitlab-workhorse 8.46 and only the 
required subset of Go CDK is currently included in the deb file 
(packaging more will require packaging more build dependencies).

MiniDebConf India 2021: Call for Proposals

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Debianites,

The MiniDebConf India Content team would like to call for proposals for 
the MiniDebConf India 2021[1] conference, which will take place online, 
from January 23rd to 24th, 2021.


# Introduction
MiniDebConf India, organised by the Debian India community and 
supported by Debian, will be streamed online so you can participate 
wherever you are.
Aims to introduce and propagate Debian and Free Software in Indian 
subcontinent.
We are currently set up for talks in English, Hindi and Malayalam. 
However, if you are more comfortable presenting in another language 
from the subcontinent, we would be more than happy to consider your 
proposal!
The event will run from 1000 to 2100 hours IST (0430-1530 UTC) over two 
days.


# Submitting an Event
You can now submit an event proposal[2]. Events are not limited to 
traditional presentations or informal sessions (BoFs): we welcome 
submissions of tutorials, performances, art installations, debates, or 
any other format of event that you think would be of interest to the 
Debian community.


Regular sessions may either be 20 or 45 minutes long (including time 
for questions), other kinds of sessions (workshops, demos, lightning 
talks, …) could have different durations. Please choose the most 
suitable duration for your session and explain any special requests.


In order to submit a talk, you will need to create an account on the 
site. We suggest that Debian Salsa account holders (including DDs and 
DMs) use their Salsa login when creating an account. However, this 
isn’t required, as you can sign up with an e-mail address and 
password.


# Timeline
- - Talk Submission deadline: Sunday, January 10th 2021
- - Acceptance notification: Monday, January 11th 2021

# Topics can be anything that is relevant to Debian and Free Software.

# Online Talks
We expect speakers to pre-record their talks in advance. Live talks at 
an online conference are prone to technical problems, resulting in bad 
quality videos. We strongly encourage you to record your presentations 
as instructed here[3]. You can interact with the audience on the IRC 
channel.


# Code of Conduct
The event is covered by a Code of Conduct[4] designed to ensure 
everyone’s safety and comfort. The code applies to all attendees, 
including speakers, and to the content of all presentations. Do not 
hesitate to contact us at india.m...@debconf.org if you have any 
questions or are unsure about certain content you’d like to present.


# Video Coverage
As this is an online conference, talks will be streamed live over the 
Internet. Unless speakers opt-out, all scheduled talks will be recorded 
and published later under the DebConf license[5] (MIT/Expat), as well 
as presentation slides and papers whenever available.


Please note that, although we will make your wishes known to the 
participants, we cannot control whether attendees record and publish 
your talk from the live stream.


# Questions/Queries
In case of any queries or issues that require redressal, reach out to 
the organizers at india.m...@debconf.org


See you all at the conference!

MiniDebConf India Team

[1] https://in2021.mini.debconf.org
[2] https://in2021.mini.debconf.org/talks/new/
[3] 
https://debconf-video-team.pages.debian.net/docs/advice_for_recording.html#advice-for-recording

[4] https://in2021.mini.debconf.org/about/coc/
[5] https://meetings-archive.debian.net/pub/debian-meetings/LICENSE
-BEGIN PGP SIGNATURE-

iQJZBAEBCgBDPBxQcmF2ZWVuIEFyaW1icmF0aG9kaXlpbCAoUGlyYXRlKSA8cHJh
dmVlbkBvbmVuZXRiZXlvbmQub3JnPgUCX9IYOAAKCRCPU+AZOylLdTOCD/4gvucN
hQ7BTf2B4osTnAtSyqr3Di8wBE5ta/lJECjPoCIwSEbG1zZL7T26vVa7iOyJGuEW
PuT7r5I6U8e+YQYhAdvIzaSOuK09e4DnNZxOgVVjHm/Avjb5XBKAtOYJ8Ecq+A4h
zMSas7UaBN5hxYwBmNWqob24Rq6P9AeusY5DWiz18vvf3HzoAPykOtPIQHzADaD5
VQGV+5GW78hlRcFdEoyH5ffe+kJlc1ZP3Pu4dCnL3LWb5i3ts+Bdh0iMo6SFxvk/
QoZJWi6OJQ7jVUGNvVX7vgNlxTz8aWIGD3wijVY2NnHhlasHnRHkAP6Dm3+lI+wM
p1EtKwrXjeVc2b4IIC7jqVCdWK3I60doh5a6Ddp5yz9elHRE8i8WOiCX4ZBYTo5l
vrSqdzEoMRQqtpo78JMVo01Vy/grFeaFpJAmDu44BtWuWHZ4mGLO+HMCTh/0oEo7
5BBCCTUHnH9q6kdUczbUzOnc8hpvmqmS9EjzM+fOgTdo8cY//EEN4opX5tDjW8mB
lubs2HOa9W3ORx+WUKgZVmX5AnnYNapwA/226e5OsocIufnXILAn+IdGLk8GwPIE
pHndvpIytxJaPn3rSjAKw8SrgcLFo8KChXSdUCPdy22+b7VaSL/K6wRCc8Y696xX
ctY5A/j6iC8lfs2rWNJJNZXgtbd9ACW6jEYPiw==
=jVOW
-END PGP SIGNATURE-

MiniDebConf India 2021: Call for Proposals

[Pirate Praveen]

[resending with correct signature, sorry for duplicate message]

Dear Debianites,

The MiniDebConf India Content team would like to call for proposals for
the MiniDebConf India 2021[1] conference, which will take place online,
from January 23rd to 24th, 2021.

# Introduction
MiniDebConf India, organised by the Debian India community and supported
by Debian, will be streamed online so you can participate wherever you are.
Aims to introduce and propagate Debian and Free Software in Indian
subcontinent.
We are currently set up for talks in English, Hindi and Malayalam.
However, if you are more comfortable presenting in another language from
the subcontinent, we would be more than happy to consider your proposal!
The event will run from 1000 to 2100 hours IST (0430-1530 UTC) over two
days.

# Submitting an Event
You can now submit an event proposal[2]. Events are not limited to
traditional presentations or informal sessions (BoFs): we welcome
submissions of tutorials, performances, art installations, debates, or
any other format of event that you think would be of interest to the
Debian community.

Regular sessions may either be 20 or 45 minutes long (including time for
questions), other kinds of sessions (workshops, demos, lightning talks,
…) could have different durations. Please choose the most suitable
duration for your session and explain any special requests.

In order to submit a talk, you will need to create an account on the
site. We suggest that Debian Salsa account holders (including DDs and
DMs) use their Salsa login when creating an account. However, this isn’t
required, as you can sign up with an e-mail address and password.

# Timeline
- - Talk Submission deadline: Sunday, January 10th 2021
- - Acceptance notification: Monday, January 11th 2021

# Topics can be anything that is relevant to Debian and Free Software.

# Online Talks
We expect speakers to pre-record their talks in advance. Live talks at
an online conference are prone to technical problems, resulting in bad
quality videos. We strongly encourage you to record your presentations
as instructed here[3]. You can interact with the audience on the IRC
channel.

# Code of Conduct
The event is covered by a Code of Conduct[4] designed to ensure
everyone’s safety and comfort. The code applies to all attendees,
including speakers, and to the content of all presentations. Do not
hesitate to contact us at india.m...@debconf.org if you have any
questions or are unsure about certain content you’d like to present.

# Video Coverage
As this is an online conference, talks will be streamed live over the
Internet. Unless speakers opt-out, all scheduled talks will be recorded
and published later under the DebConf license[5] (MIT/Expat), as well as
presentation slides and papers whenever available.

Please note that, although we will make your wishes known to the
participants, we cannot control whether attendees record and publish
your talk from the live stream.

# Questions/Queries
In case of any queries or issues that require redressal, reach out to
the organizers at india.m...@debconf.org

See you all at the conference!

MiniDebConf India Team

[1] https://in2021.mini.debconf.org
[2] https://in2021.mini.debconf.org/talks/new/
[3]
https://debconf-video-team.pages.debian.net/docs/advice_for_recording.html#advice-for-recording
[4] https://in2021.mini.debconf.org/about/coc/
[5] https://meetings-archive.debian.net/pub/debian-meetings/LICENSE



OpenPGP_signature
Description: OpenPGP digital signature

MiniDebConf India 2021: Call for Proposals

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[sorry if you got another copy earlier, it seems pgp/mime is not
recognized by the lists as signed mail and I had to use an older
version of thunderbird with enigmail to get inline pgp working]

Dear Debianites,

The MiniDebConf India Content team would like to call for proposals for
the MiniDebConf India 2021[1] conference, which will take place online,
from January 23rd to 24th, 2021.

# Introduction
MiniDebConf India, organised by the Debian India community and supported
by Debian, will be streamed online so you can participate wherever you
are.
Aims to introduce and propagate Debian and Free Software in Indian
subcontinent.
We are currently set up for talks in English, Hindi and Malayalam.
However, if you are more comfortable presenting in another language from
the subcontinent, we would be more than happy to consider your proposal!
The event will run from 1000 to 2100 hours IST (0430-1530 UTC) over two
days.

# Submitting an Event
You can now submit an event proposal[2]. Events are not limited to
traditional presentations or informal sessions (BoFs): we welcome
submissions of tutorials, performances, art installations, debates, or
any other format of event that you think would be of interest to the
Debian community.

Regular sessions may either be 20 or 45 minutes long (including time for
questions), other kinds of sessions (workshops, demos, lightning talks,
…) could have different durations. Please choose the most suitable
duration for your session and explain any special requests.

In order to submit a talk, you will need to create an account on the
site. We suggest that Debian Salsa account holders (including DDs and
DMs) use their Salsa login when creating an account. However, this isn’t
required, as you can sign up with an e-mail address and password.

# Timeline
- - - Talk Submission deadline: Sunday, January 10th 2021
- - - Acceptance notification: Monday, January 11th 2021

# Topics can be anything that is relevant to Debian and Free Software.

# Online Talks
We expect speakers to pre-record their talks in advance. Live talks at
an online conference are prone to technical problems, resulting in bad
quality videos. We strongly encourage you to record your presentations
as instructed here[3]. You can interact with the audience on the IRC
channel.

# Code of Conduct
The event is covered by a Code of Conduct[4] designed to ensure
everyone’s safety and comfort. The code applies to all attendees,
including speakers, and to the content of all presentations. Do not
hesitate to contact us at india.m...@debconf.org if you have any
questions or are unsure about certain content you’d like to present.

# Video Coverage
As this is an online conference, talks will be streamed live over the
Internet. Unless speakers opt-out, all scheduled talks will be recorded
and published later under the DebConf license[5] (MIT/Expat), as well as
presentation slides and papers whenever available.

Please note that, although we will make your wishes known to the
participants, we cannot control whether attendees record and publish
your talk from the live stream.

# Questions/Queries
In case of any queries or issues that require redressal, reach out to
the organizers at india.m...@debconf.org

See you all at the conference!

MiniDebConf India Team

[1] https://in2021.mini.debconf.org
[2] https://in2021.mini.debconf.org/talks/new/
[3]
https://debconf-video-team.pages.debian.net/docs/advice_for_recording.ht
ml#advice-for-recording
[4] https://in2021.mini.debconf.org/about/coc/
[5] https://meetings-archive.debian.net/pub/debian-meetings/LICENSE
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE0whj4mAg5UP0cZqDj1PgGTspS3UFAl/Tcv0ACgkQj1PgGTsp
S3WZ6Q/+MEK5B5PGKl0jWgeFcJDOwUlFqnyxZviDN0vrTKSvPaALHLc2cDNBCaHP
203bDqXsoYEBcaKpUqp7W7mMTX6+aHEEzdTWmAj1pwXAES82cvxPHc0+w2X9Ni4+
LNCKcQJc8VjKvgsdeOP+EZx4vm5PQh2s0ZhlyZ5c3vy9s3VGsjTu/dZlhuP7nBVy
sX93o3UkpZeGpXz3uVYjEwi9M6ycmReyG6xkipUTxX25G570fMqsjfgfCrZyoObb
B2SxZM1JJfTqGpZi8OuM28SdtbhXwz4nRnELfpKbLXf/iCxTsca690jg+ygbxvGM
q0Lg+5UimHzPvoH5cr8iqjDLFpnBsRenLHhsnFjIwGiNtvRO9T9WTDoNI5aCcMLL
OAiTmsHzXJMky6MpPHlW9VFykm/Dr1awGFHy273e6qmnTOoUCreGP1/yEGPUaCPI
XkE46Z12iE/mqeRRzfkDlwii5UzoP5echZm6N+TpAvp+Qrs5XPiypwflX3oRqUdc
Ty+yngblW34VHmQfonnKQIw5HdZcwqE04bkdLi5CS3Go51RsKHqXKlEm1rpalDot
Bnc1sd992RJZUScujq2epwwoVrG+6Yzm1tPqK/as+dewA+Uzk7PExgBFhN5ig3Ji
uw4JMlCsXwJyiMoL9nfv58oY+ubRH8VS5d4un++VjU+YuMrFWZ8=
=SaLf
-END PGP SIGNATURE-

Bug#977144: ITP: node-inflected -- port of ActiveSupport's inflector to Node.js

[Pirate Praveen]

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

* Package name : node-inflected
 Version : 2.1.0
 Upstream Author : Martin Andert
* URL : https://github.com/martinandert/inflected#readme
* License : Expat
 Programming Lang: JavaScript
 Description : port of ActiveSupport's inflector to Node.js

This library transforms words from singular to plural, class names to 
table
names, modularized class names to ones without, and class names to 
foreign

keys.
.
Node.js is an event-based server-side JavaScript engine.

This module is a dependency of miragejs which is in turn a dependency 
of gitlab.

Bug#977197: ITP: node-route-recognizer -- library that matches paths against registered routes

[Pirate Praveen]

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

* Package name : node-route-recognizer
 Version : 0.3.4
 Upstream Author : Yehuda Katz
* URL : https://github.com/tildeio/route-recognizer
* License : Expat
 Programming Lang: JavaScript
 Description : library that matches paths against registered routes

route-recognizer is a lightweight JavaScript library (under 2k!) that
can be used as the recognizer for a more comprehensive router system
(such as router.js).
.
In keeping with the Unix philosophy, it is a modular library that does 
one

thing and does it well.
.
Node.js is an event-based server-side JavaScript engine.

This module is a dependency of miragejs module which is in turn a 
dependency of gitlab.

Bug#977200: ITP: node-miragejs -- client-side server to build, test and demo JavaScript apps

[Pirate Praveen]

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

* Package name : node-miragejs
 Version : 0.1.41
 Upstream Author : Sam Selikoff
* URL : https://github.com/miragejs/miragejs
* License : Expat
 Programming Lang: JavaScript
 Description : client-side server to build, test and demo JavaScript 
apps


Mirage JS is an API mocking library that lets one build, test and 
share a
complete working JavaScript application without having to rely on any 
backend

services.
.
Node.js is an event-based server-side JavaScript engine.

This module is a dependency of gitlab.

Re: How should we handle greenbone-security-assistant?

[Pirate Praveen]

On 2020, ഡിസംബർ 16 11:57:04 PM IST, Raphael Hertzog  wrote:
>Hello,
>
>in the pkg-security team we have greenbone-security-assistant (gsa)
>which is a web interface for gvm (former openvas-manager), the
>version currently in Debian no longer works with the latest gvm
>so we have to update it to the latest upstream release... but the
>latest upstream release has significant changes, in particular
>it now relies on yarn or npm from the node ecosystem to download
>all the node modules that it needs (and there are many of them,
>and there's no way that we will package them individually).
>
>The Debian policy forbids download during the build so we can't
>run the upstream build system as is.
>
>As I see it we have three options:
>
>1/ download all the node modules and add them to the source package, but
>then it's just impossible to write a copyright file to document the source
>package. That would be the best option though, the yarn.lock file
>effectively locks a very specific version of each node module so
>even though it's downloaded the net effect is very similar to "vendoring"
>as is done by other projects.

This will only work for a subset of modules because most modules will not be 
just source (unlike golang), it will contain prebuilt files. The original 
source is usually ES6 or typescript usually and you need to build them using 
babel/rollup/typescript.

Though the build tools situation is much better than a few years ago when I 
started with diaspora and gitlab. I had to start with packaging these tools 
first.

>2/ disable this download during the package build, move the package
>to contrib, and add some code in the postinst to download the required
>node modules at package installation time (possibly with a debconf
>confirmation prompt and a command that the user can rerun afterwards
>to do it later).

I use this option for gitlab, but I want to eventually move it to main once I 
package all of them. Out of 1700+ node modules, I'm left with 270+ node modules 
pulled outside of main. I remove already packaged modules from package.json.

>3/ get rid of greenbone-security-assistant in debian and keep it in kali
>only (all the work I do in pkg-security is part of my Kali work), that
>would be a regression from the current situation and is something that I'd
>like to avoid. We try to contribute back to Debian, but there's only so
>much busy-work that I'm willing to do to achieve this goal.
>
>What option shall we pick?
>
>Shouldn't we relax some requirements to avoid having to resort to that
>kind of hackery?
>
>Cheers,

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: How should we handle greenbone-security-assistant?

[Pirate Praveen]

On Thu, Dec 17, 2020 at 2:19 pm, Raphael Hertzog  
wrote:

Hello,

On Thu, 17 Dec 2020, Pirate Praveen wrote:
 >1/ download all the node modules and add them to the source 
package, but
 >then it's just impossible to write a copyright file to document 
the source

 >package. That would be the best option though, the yarn.lock file
 >effectively locks a very specific version of each node module so
 >even though it's downloaded the net effect is very similar to 
"vendoring"

 >as is done by other projects.

 This will only work for a subset of modules because most modules 
will
 not be just source (unlike golang), it will contain prebuilt files. 
The

 original source is usually ES6 or typescript usually and you need to
 build them using babel/rollup/typescript.


I don't understand what you mean. Are you trying to say that this 
won't
help much because we will have another DFSG-freeness problem in the 
sense
that what we would embed is not the source and that DFSG requires us 
to

provide the sources?



yes. Most modules now ship files generated by tools like 
babel/rollup/webpack/typescript etc. So we will have to get their 
preferred source code from their source repos and build them in debian.


For example d3-color module ships files generated by rollup, which we 
rebuild in debian.


https://salsa.debian.org/js-team/node-d3-color/-/blob/master/debian/rules#L8

You may still be able to vendor the original source of these modules 
and only build the final app with tools like webpack, but that would be 
different from what upstream does (upstream pulls all prebuilt modules 
from npmjs.com) and some modules may even have other custom build 
steps/tools.


add-node-component from pkg-js-tools makes it easy to vendor original 
source code.


So even if you can't vendor all modules easily in one shot, I think you 
can still manage a lot of modules that way and package only the smaller 
subset that you can't vendor.


We also have tools to build vendored code.

For example, pirates is module vendored in node-babel using their 
preferred source and built in debian


https://salsa.debian.org/js-team/node-babel/-/blob/master/debian/gbp.conf

https://salsa.debian.org/js-team/node-babel/-/blob/master/debian/nodejs/pirates/build

Older modules were simpler and did not require any build steps.

So it was easy to vendor these modules in node-gulp,

https://salsa.debian.org/js-team/node-gulp/-/blob/master/debian/gbp.conf

 I use this option for gitlab, but I want to eventually move it to 
main

 once I package all of them. Out of 1700+ node modules, I'm left with
 270+ node modules pulled outside of main. I remove already packaged
 modules from package.json.


I appreciate all the efforts that you are doing here but to me it 
seems

like a dead end. Much like the idea of adding another repository to
accomodate the ever-growing list of go modules that nobody will ever
want to use except as a build-dependency.

To me it seems that we must adapt our rules, our expectations and our
tooling to cope with this paradigm shift where dependencies are 
downloaded

at build time.


Well, its indeed a conflict of different values. It may indeed be a 
losing fight, but I prefer to still fight this as much as I can. Many 
developers want the distributions to be just base for containerized 
apps, but I don't like that vision. It is indeed easier for developers 
this way, but I don't necessarily think that is the best way for users.


I think reproducible builds and the guarantee that every package is 
built from source by debian and anyone can rebuild easily are still 
valuable goals from a security perspective.


I try to bring in more people to traditional packaging side and if we 
are able to get more people to realize the value in what we do, we can 
still manage. But it is no way an easy task.

Re: How should we handle greenbone-security-assistant?

[Pirate Praveen]

On Thu, Dec 17, 2020 at 2:55 pm, Raphael Hertzog  
wrote:
I know this, but I also know that such an analysis is very 
time-consuming
and needs a good knowledge of the language and of the upstream 
package,

which I don't have.



Most of the time Semantic Versioning works (https://semver.org) so you 
don't really need to know the code.


 In your original post you seemingly already ruled out proper 
packaging

 as a premise, and it seems you continue to use absolutes like
 "everything" and "never".  I find that discouraging - plase 
consider a

 less negative tone.


Sorry, I don't want to discourage you. But I'm also sure that I will 
never

be able to justify spending days and weeks on packaging (and then
maintaining) all those node modules for the benefit of pushing a 
single

package to Debian when said package was updated in Kali in a matter of
hours.


Though that is not entirely correct. Many of the build tools and 
libraries I had to package for gitlab are reused by other packages.


By trying to shoehorn node/go modules into Debian packages we are 
creating

busy work with almost no value. We must go back to what is the value
added by Debian and find ways to continue to provide this value while
accepting the changed paradigm that some applications/ecosystems have
embraced.

And for me selling points are:

- ensurance that we use DFSG free code only
  => we can have tool to review licenses of what has been
  downloaded during build and embedded in the binary packages



Then there would not be any value for Debian with such a scenario as 
people can do such analysis on any distro/container.


It would make debian irrelevant.


- ease of installation and reliability
  => we are doing bad now because many useful things are not packaged
  (due to the mismatch between our rules and those not-longer-so-new
  ecosystems) and when users have to manually install, the reliability
  goes down...



This I agree, but this could be achived by a mix of vendoring and 
individual packages. We can vendor modules that are specific to a 
single app and package more useful libraries as individual packages.



- possibility to rebuild from source
  => we could have some sort of proxy that would store everything
  downloaded and let us rebuild an identical package without net 
access

  even if the remote resources disappear



Why would anyone need to use debian in such a scenario?

All the current trends are making it easy for developers to ship code 
directly to users. Which encourages more isolation instead of 
collaboration between projects. It also makes it easy for shipping more 
proprietary code, duplication of security tracking or lack of it. 
Debian and other distributions have provided an important buffer 
between developers and users as we did not necessarily follow the 
priorities or choices of upstream developers exactly always.


We need to be doing what is the buzz of the time. Free Software was not 
a mainstream idea when we started.

Re: How should we handle greenbone-security-assistant?

[Pirate Praveen]

On Fri, Dec 18, 2020 at 8:59 am, Raphael Hertzog  
wrote:

On Thu, 17 Dec 2020, Pirate Praveen wrote:

 > - ensurance that we use DFSG free code only
 >   => we can have tool to review licenses of what has been
 >   downloaded during build and embedded in the binary packages

 Then there would not be any value for Debian with such a scenario 
as people

 can do such analysis on any distro/container.

 It would make debian irrelevant.


I don't think so. First the tool is here to help the maintainer do the
assertion, it's unlikely to be 100% automated, it will likely point
out files to inspect manually and so on.

And, as a user, even if the tool exists, I wouldn't want to run it 
manually,
I would continue to rely on Debian for the vetting process. I don't 
want

to have to do this on my own.



Even with that tool, if we have to change any modules, we will have to 
create forks of these modules and publish them and also modify 
package.json to use these forks.


gitlab has to do that many times with many rubygems when upstream is 
not responsive to pull requests.


 >   => we are doing bad now because many useful things are not 
packaged
 >   (due to the mismatch between our rules and those 
not-longer-so-new
 >   ecosystems) and when users have to manually install, the 
reliability

 >   goes down...

 This I agree, but this could be achived by a mix of vendoring and 
individual
 packages. We can vendor modules that are specific to a single app 
and

 package more useful libraries as individual packages.


For this to work at scale, you need to work with the upstream 
ecosystem so
that this works out of the box... AFAIK right now adding the required 
node
modules in build-depends will not avoid those modules to be 
downloaded by
the upstream build system and there's no simple flag that you can 
just add

to enable that behaviour. Is that correct ?


You will have to create a patch that removes the packaged node modules 
from package.json


See this patch in gitlab,
https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/patches/0740-use-packaged-modules.patch#L94

Additionally, you will have to tell webpack/rollup to take modules 
installed by apt


https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/patches/0740-use-packaged-modules.patch#L35

You may able to also add a plugin to yarn to automate this. If there is 
a yarn plugin that checks and prefers the apt installed modules, then 
that would work without having to patch the upstream build files. Ruby 
does that already with rubygems-integrations package. bundle install 
--local will take the apt installed modules without any change in 
upstream build tools.





 > - possibility to rebuild from source
 >   => we could have some sort of proxy that would store everything
 >   downloaded and let us rebuild an identical package without net 
access

 >   even if the remote resources disappear

 Why would anyone need to use debian in such a scenario?


I don't know for you but the reasons to use Debian would not be 
changed
by the addition of this mechanism. I know that I use only free 
software,

that all the tools are easy to install, that some sane default
configuration has been provided by the maintainer, that further
instructions are in README.Debian, etc.

 All the current trends are making it easy for developers to ship 
code
 directly to users. Which encourages more isolation instead of 
collaboration
 between projects. It also makes it easy for shipping more 
proprietary code,

 duplication of security tracking or lack of it. Debian and other
 distributions have provided an important buffer between developers 
and users
 as we did not necessarily follow the priorities or choices of 
upstream

 developers exactly always.


This I agree with. And I believe it still stays true even if we 
accept to

vendor large amount of stuff.

 We need to be doing what is the buzz of the time. Free Software was 
not a

 mainstream idea when we started.


I don't understand what you are trying to say here.


The mainstream idea seems to be isolating every project without any 
coordination with any other projects, including downstream 
distributions. The trend is to ship only one configuration (typically 
as a docker container - some projects don't even support building from 
source).


With distributions like debian, we care for the whole Free Software 
ecosystem. When we do transitions, we make sure every free software 
using a library or tool is updated. None of those are mainstream views.


Mainstream view is continue using a dependency version till eternity 
and nothing really breaks once it works on the developers machine. 
There is even a joke about docker being a way to make sure if it works 
on the developers system, then lets ship the developers system to 
everyone.


Yes, it is a lot work, but it makes the whole Free Software better by 
having up

Bug#979576: ITP: node-babel-plugin-lodash -- Modular Lodash builds without the hassle

[Pirate Praveen]

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

* Package name : node-babel-plugin-lodash
 Version : 3.3.4
 Upstream Author : Graeme Yeates  
(https://github.com/megawac)

* URL : https://github.com/lodash/babel-plugin-lodash#readme
* License : Expat
 Programming Lang: JavaScript
 Description : Modular Lodash builds without the hassle
A simple transform to cherry-pick Lodash modules so one don’t have 
to.
This is a plugin for babel transpiler to make using modular lodash 
easy.

.
Babel is a JavaScript compiler to use next generation JavaScript, 
today.

.
Node.js is an event-based server-side JavaScript engine.

This is a dependency of gitlab and uses babel during build (also need 
to use rollup to bootstrap build to avoid a circular build dependency 
on itself).

Bug#988506: ITP: node-terser-webpack-plugin -- Terser plugin for webpack

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org
Control: block 980316 by -1

* Package name : node-terser-webpack-plugin
 Version : 3.1.0
 Upstream Author : webpack Contrib Team
* URL : https://github.com/webpack-contrib/terser-webpack-plugin
* License : Expat
 Programming Lang: JavaScript
 Description : Terser plugin for webpack

This is a build dependency of yarn 2/corepack

Bug#988941: ITP: node-rollup-plugin-sass -- Rollup plugin for .sass files

[Pirate Praveen]

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

* Package name : node-rollup-plugin-sass
 Version : 1.2.2
 Upstream Author : BinRui.Guan 
* URL : https://github.com/differui/rollup-plugin-sass#readme
* License : Expat
 Programming Lang: JavaScript
 Description : Rollup plugin for .sass files

This plugin can help handling sass stylesheets with rollup.
.
Node.js is an event-based server-side JavaScript engine.
 .
Node.js is an event-based server-side JavaScript engine.

This is a build dependency of tributejs. Since sass module is not 
packaged (it is written in dart lang which is also not packaged yet), 
node-sass module (node-node-sass package) will be used instead.

Bug#989717: ITP: node-postcss-preset-evergreen -- postcss preset for modern css syntaxes

[Pirate Praveen]

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

* Package name : node-postcss-preset-evergreen
 Version : 0.2.1
 Upstream Author : Eric Chen 
* URL : https://github.com/best-shot/postcss-preset-evergreen
* License : Expat
 Programming Lang: JavaScript
 Description : `postcss` preset for modern css syntaxes

 This would embed all the presets this module depends on. This will be 
used instead of node-postcss-preset-env for building node-katex as 
node-postcss-preset-env does not support postcss 8 yet.

Re: Reconsider sending ITP bugs to debian-devel: a new list?

[Pirate Praveen]

On Fri, Jun 11, 2021 at 11:17 am, Jonathan Dowland  
wrote:

Hi,

ITP bugs are copied to debian-devel@. The intention, I think, is to 
make
sure that they have many eyes on them.  ITP bugs often get feedback 
from

readers of debian-devel.

I think this is valuable. However, it's one job/task/role, and 
sometimes
One wishes to focus on other jobs/tasks/roles instead. When I 
subscribed
to debian-devel directly, I most often filtered ITP mail into a 
separate

mailbox, to read at separate times. Nowadays, I read most Debian lists
via NNTP gateways, and filtering ITPs is not quite so convenient (not
least, because I don't easily have an analogue of the ITP-dedicated
mailbox I used to.). But besides me, I think a better "default" for
debian-devel would be not to have the ITPs.

I think the ITP mails can make reading the rest of the list difficult
without extra local filtering or steps.  Some times they are the
majority of the list traffic. I think it would be better if
ITP mail went to a separate, dedicated list, e.g. "debian-itp" to 
which

contributors are encouraged to subscribe and participate.

Does anyone have any strong feelings about this, either for or 
against?


I think this is a good idea. We probably need to do this more widely in 
teams as well (some teams already split discussion and automated mails 
in separate lists and I think more teams should do it).

Bug#989747: ITP: node-postcss-loader -- PostCSS loader for webpack

[Pirate Praveen]

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

* Package name : node-postcss-loader
 Version : 6.1.0
 Upstream Author : Andrey Sitnik 
* URL : https://github.com/webpack-contrib/postcss-loader
* License : Expat
 Programming Lang: JavaScript
 Description : PostCSS loader for webpack
This package is a loader for webpack to process CSS with PostCSS.
.
Node.js is an event-based server-side JavaScript engine.

This is a build dependency of node-katex 0.13

Bug#991260: ITP: node-dompurify -- DOM-only, super-fast, uber-tolerant XSS sanitizer

[Pirate Praveen]

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

* Package name : node-dompurify
 Version : 2.3.0
 Upstream Author : Mario Heiderich  
(https://cure53.de/)

* URL : https://github.com/cure53/DOMPurify
* License : (MPL-2.0 OR Apache-2.0)
 Programming Lang: JavaScript
 Description : DOM-only, super-fast, uber-tolerant XSS sanitizer
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for 
HTML,
MathML and SVG. It's written in JavaScript and works in all modern 
browsers
(Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as 
well as
almost anything else using else using Blink or WebKit. It doesn't 
break on
MSIE6 or other legacy browsers. It either uses a fall-back or simply 
does

nothing.
.
Node.js is an event-based server-side JavaScript engine.

This is a dependency of @gitlab/ui which is a dependncy of gitlab.

Re: Steam Deck: good news for Linux gaming, bad news for Debian :(

[Pirate Praveen]

2021, ഓഗസ്റ്റ് 12 8:51:55 AM IST, Timothy M Butterworth 
ൽ എഴുതി
>I am fine with Debian's release cycle but It would be nice to see more
>packages. For example Debian is missing KDE's Amarok music manager. I
>am happy to see Debian 11 gained KDE Elisa music manager. I am sad to
>see that VirtualBox is not available on Debian 11. I had to jerry-rig
>it using the Ubuntu Focal repo from Oracle.
>

We have https://fasttrack.debian.net and currently gitlab, matrix synapse and 
virtual box is available there in buster-fasttrack suite (though only gitlab is 
available via bullseye-fastrack now, I hope other two will come soon). Packages 
that don't fit in regular backports can be shipped via Fast Track.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Debian choice of upstream tarballs for packaging

[Pirate Praveen]

On 17/08/21 1:43 am, Sean Whitton wrote:
> I agree with this, and already do it for all or almost all of the
> packages I maintain.  There will probably need to be lots of exceptions,
> however. 

Many node modules don't tag their releases so its really hard to get
exact source code corresponding to an npmjs.com release. We have to
search for hints in commit messages to find the correct commit and then
take the snapshot of that commit.

Also with mono repos becoming more popular (many modules are developed
in the same git repo with each module having a different version but
there is no way to get tarballs of individual modules), now we not only
need to download tarballs corresponding to tags and then exclude all the
other modules we don't need from the monorepo tarball.



signature.asc
Description: OpenPGP digital signature

Proposal to create unstable-proposed-updates suite for use during freeze

[Pirate Praveen]

Hi,

Problem: Currently uploading new upstream versions to unstable during freeze is 
discouraged. It means users using unstable don't get new updates and developers 
are forced to upload to experimental. Using experimental directly is risky as 
it can have changes not ready for unstable also.
Proposed solution: open unstable-proposed-updates with freeze and close it when 
freeze is lifted. The packages in this suite can migrate to testing, this 
avoids manual reuploads to unstable after freeze is lifted.
Optional: create a companion testing suite say rolling which may be used during 
this time and a second Britney instance can manage migration to this suite.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Debian choice of upstream tarballs for packaging

[Pirate Praveen]

2021, ഓഗസ്റ്റ് 17 12:18:00 PM IST, Paul Wise ൽ എഴുതി
>On Mon, Aug 16, 2021 at 8:25 PM Pirate Praveen wrote:
>
>> Many node modules don't tag their releases so its really hard to get
>> exact source code corresponding to an npmjs.com release.
>
>It is probably worth filing upstream issues when you discover that.

We do file issues but response is not guaranteed.

>> Also with mono repos becoming more popular (many modules are developed
>> in the same git repo with each module having a different version but
>> there is no way to get tarballs of individual modules), now we not only
>> need to download tarballs corresponding to tags and then exclude all the
>> other modules we don't need from the monorepo tarball.
>
>Could you package the monorepo instead of each module?
>

Sometimes we do but it has the risk of packaging
 unleased changes. So it is similar to packaging git main branch.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Proposal to create unstable-proposed-updates suite for use during freeze

[Pirate Praveen]

On Wed, Aug 18, 2021 at 10:14 pm, Samuel Thibault 
 wrote:

Nilesh Patra wrote:
 Using experimental directly is risky as it can have changes not 
ready for unstable also.


No. Enabling experimental in your sources.list doesn't actually change
anything. You have to explicitly request installing a given package 
from
experimental to pull it from experimental, and only that will be 
getting

updated from experimental, you won't inadvertently pull other packages
from experimental.

Well, you have to inspect each package to decide if it is a 
only-uploaded-because-freeze or actually an experimental release. You 
don't get the guarantees of unstable - at least the maintainer thinks 
it is ready for a release.



Samuel

Re: Proposal to create unstable-proposed-updates suite for use during freeze

[Pirate Praveen]

On 20/08/21 4:51 pm, Nilesh Patra wrote:
> Or, instead, if you have a u-p-u suite, and stuff that passes there migrates 
> to t-p-u,
> this could be completely mitigated.

No, that will defeat the purpose of freeze. t-p-u is targeted at testing
without going via unstable.

If this has to happen then t-p-u should be completely disconnected from
testing during freeze.



signature.asc
Description: OpenPGP digital signature

Re: Proposal to create unstable-proposed-updates suite for use during freeze

[Pirate Praveen]

On 20/08/21 7:22 pm, Nilesh Patra wrote:
> Well, I meant u-p-u and t-p-u as disconnected suites during freeze. Upload to 
> u-p-u, stuff passing there migrates to t-p-u.

We already have testing-proposed-updates with a different set of rules.
See https://wiki.debian.org/TestingProposedUpdates

> When freeze ends, packages from u-p-u and t-p-u auto-migrate to unstable and 
> (new) testing respectively.
> Do I miss some context here?

See above.




signature.asc
Description: OpenPGP digital signature

Re: Finding rough consensus on level of vendoring for large upstreams

[Pirate Praveen]

2021, സെപ്റ്റംബർ 3 8:22:51 AM IST, Jonas Smedegaard ൽ എഴുതി
>I am very worried about how complex node-* packages in Debian have 
>become since ftpmasters explicitly stated a not-too-small rule and we 
>began more aggressively embedding.  E.g. version of each embedded 
>project is hidden by default, and those packages manually adding virtual 
>packages has no mechanism to ensure that versions don't jump backwards 
>or disappear due to a typos.

Apparently reducing package metadata size is more important than every other 
consideration. It has become very difficult to get new people into js team 
after we started embedding as the complexity has increased very much from 
earlier days. 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Require packages to build without any configured DNS

[Pirate Praveen]

On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു 
+0200 +0200, Thomas Goirand  wrote:

Therefore, I am in the opinion that we should let the package run its
test as much as possible, especially considering that it's not doing
actual network outbound connections.


Can't we run these tests as autopkgtests?

Re: Require packages to build without any configured DNS

[Pirate Praveen]

On ബു, സെപ്റ്റം 8 2021 at 06:10:56 വൈകു 
+0300 +0300, Adrian Bunk  wrote:

On Wed, Sep 08, 2021 at 07:57:20PM +0530, Pirate Praveen wrote:
 On ബു, സെപ്റ്റം 8 2021 at 04:18:46 വൈകു 
+0200 +0200, Thomas Goirand  wrote:
 > Therefore, I am in the opinion that we should let the package run 
its
 > test as much as possible, especially considering that it's not 
doing

 > actual network outbound connections.

 Can't we run these tests as autopkgtests?


That would only move the problem elsewhere, since this creates a 
similar

question whether such tests should need a "needs-internet" restriction
for autopkgtest which might result in them being skipped in most 
cases.




I don't think the default autopkgtest environment should be as 
restrictive as the build environment. So adding this to default 
autopkgtest enviroment is not the same as adding it to default build 
environment.

Re: Bug#992692: general: Use https for {deb,security}.debian.org by default

[Pirate Praveen]

2021, സെപ്റ്റംബർ 9 4:42:18 AM IST, Michael Stone ൽ എഴുതി
>On Wed, Sep 08, 2021 at 01:09:13PM +0200, Helmut Grohne wrote:
>>Enabling https by default quite simply breaks the simple recipe of
>>installing auto-apt-proxy. Would you agree with auto-apt-proxy's
>>postinst automatically editing your sources.list to drop the s out of
>>https? The answer repeatedly given in this thread to do so manually is
>>very unsatisfying.
>
>Why not simply automate setting it at install time using preseed? I'm 
>honestly not sure who the target audience for auto-apt-proxy 
>is--apparently someone who has an infrastructure including a proxy, 
>possibly the ability to set dns records, etc., but can't change defaults 
>at install time or via some sort of runtime configuration management?
>

Why can't auto-apt-proxy ask this as a debconf question? I also like 
auto-apt-proxy but I agree with  this, someone needing auto-apt-proxy should be 
able to change the default as well.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Not running tests because tests miss source code is not useful

[Pirate Praveen]

[adding -devel]

On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, 
Jonas Smedegaard  wrote:

Quoting Yadd (2021-10-06 11:43:40)

 On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
 > Source: src:node-lodash
 > Version: 4.17.21+dfsg+~cs8.31.173-1
 > Severity: serious
 > Justification: do not compile from source
 >
 > Dear Maintainer,
 >
 > The vendor directory should be emptied
 >
 > The debug version is compiled without source (lintian warn) and 
moreover the

 > rest of file are already packaged
 >
 > grep -R vendor * gives only a few hit that could be cured by 
symlinking

 >
 > Bastien
 Hi,

 this files are used for test only, maybe severity could be 
decreased.


I find the severity accurate: Relying on non-source code is a severe
violation of Debian Policy, not matter the purpose of relying on it.


I think we should change the policy here. Running tests helps improve 
the quality of the software we ship. Many times the vendored code is 
used to ensure the code does not break in a specific situation. I don't 
think reducing test coverage in such situations is really helpful.

Re: Not running tests because tests miss source code is not useful

[Pirate Praveen]

On 7 October 2021 3:02:55 am IST, Thomas Goirand  wrote:
>On 10/6/21 6:53 PM, Pirate Praveen wrote:
>> [adding -devel]
>> 
>> On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, Jonas Smedegaard
>>  wrote:
>>> Quoting Yadd (2021-10-06 11:43:40)
>>>>  On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
>>>>  > Source: src:node-lodash
>>>>  > Version: 4.17.21+dfsg+~cs8.31.173-1
>>>>  > Severity: serious
>>>>  > Justification: do not compile from source
>>>>  >
>>>>  > Dear Maintainer,
>>>>  >
>>>>  > The vendor directory should be emptied
>>>>  >
>>>>  > The debug version is compiled without source (lintian warn) and
>>>> moreover the
>>>>  > rest of file are already packaged
>>>>  >
>>>>  > grep -R vendor * gives only a few hit that could be cured by
>>>> symlinking
>>>>  >
>>>>  > Bastien
>>>>  Hi,
>>>>
>>>>  this files are used for test only, maybe severity could be decreased.
>>>
>>> I find the severity accurate: Relying on non-source code is a severe
>>> violation of Debian Policy, not matter the purpose of relying on it.
>> 
>> I think we should change the policy here. Running tests helps improve
>> the quality of the software we ship. Many times the vendored code is
>> used to ensure the code does not break in a specific situation. I don't
>> think reducing test coverage in such situations is really helpful.
>
>Right, running tests helps improve the quality of software we ship.
>Which is why you probably need to test using what's shipped in Debian
>rather than using a vendored source-less code.

We are not shipping the source less code. This is used only during tests. I 
don't think we are not gaining anything by removing tests here. Just making it 
harder for the package maintainer to run tests.

>If we rely on non-free code for tests, that's really bad too, and that
>must be avoided just like we're avoiding source-less code everywhere
>else in Debian. The policy shall not change, please.
>

The code is not non-free here, just a specific version of a Free Software code 
built outside Debian.

I think tools required for tests should be considered separately from tools 
required to compile. I think it should be treated similar to test data.

What you are proposing would require the package maintainer to adapt these 
tests to versions available (many times with different API versions) in Debian 
and the easier choice is disabling tests.

I think blindly applying a rule without thinking of any consequences is bad 
too. Just because it is bad in one situation does not mean it will be bad in 
every situation. We should evaluate pros and cons of each situation before 
making a decision. Blind faith is more suitable for religions and not for a 
project like ours.

I think a nocheck build profile which excludes these files from build is 
sufficient to ensure we are not using these to create binary package. This way 
we guarantee only packages in main is used to generate the binary, but still 
allows to run tests optionally making it easy to find problems, especially 
during transitions. Currently when tests are missing transitions are harder 
because we can't find breakages easily since tests are disabled.

The current policy is not making Debian better.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Not running tests because tests miss source code is not useful

[Pirate Praveen]

On വ്യാ, ഒക്ടോ 7 2021 at 11:43:52 രാവിലെ 
-0700 -0700, Russ Allbery  wrote:

Jonas Smedegaard  writes:

 Right: It is ok to use upstream-provided pre-minified code, as long 
as

 that code is DFSG-free, which requires the source of that code must
 exist in Debian.



 ...and because that is often complicated to ensure (not because it
 violates DFSG in itself), it is easier to avoid upstream-provided
 pre-minified code.


Test suites are often a licensing mess.  Another common case that's 
not in
play here but that I've seen before is that long-standing projects 
that

have been used commercially often have test snippets with unclear
licensing that check for regressions that were previously seen in
proprietary environments.

Debian historically has erred on the side of maintaining clear source
availability and licensing status for everything in Debian (which 
includes
everything in any source package) at the cost of not availing 
ourselves of
test suites that would otherwise be useful.  That's unfortunately 
probably
the easy path here as well, until someone has time to find 
non-minified
versions of the test dependencies and either package them or include 
them
in the package.  It's frustrating to remove the tests, but the DFSG 
source
requirements as currently applied do not distinguish between code 
shipped

only in source packages and code also shipped in binary packages.

I can see an argument that we should not worry about minified files in
main that are (a) only in the source package and not in any binary
package, and (b) only used to run tests, not to build the binary 
packages.
(I'm not saying I agree or disagree, just that I can see the 
argument.)
But given the apparent consensus on this in past discussions, I 
suspect

that changing that rule would be GR material rather than debian-devel
thread material.  Making that sort of change without a GR to be sure 
the
project is behind it feels like the kind of thing that's likely to 
spawn

endless arguments that will sap everyone's will to live.


Thanks for this summary. I wanted to first see what everyone thinks 
here first. I will propose a GR.

Re: Not running tests because tests miss source code is not useful

[Pirate Praveen]

On വെ, ഒക്ടോ 8 2021 at 10:31:16 രാവിലെ +0200 
+0200, Thomas Goirand  wrote:

On 10/7/21 11:40 AM, Pirate Praveen wrote:



 On 7 October 2021 3:02:55 am IST, Thomas Goirand  
wrote:

 On 10/6/21 6:53 PM, Pirate Praveen wrote:

 [adding -devel]

 On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 
+0200, Jonas Smedegaard

  wrote:

 Quoting Yadd (2021-10-06 11:43:40)

  On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
  > Source: src:node-lodash
  > Version: 4.17.21+dfsg+~cs8.31.173-1
  > Severity: serious
  > Justification: do not compile from source
  >
  > Dear Maintainer,
  >
  > The vendor directory should be emptied
  >
  > The debug version is compiled without source (lintian warn) 
and

 moreover the
  > rest of file are already packaged
  >
  > grep -R vendor * gives only a few hit that could be cured by
 symlinking
  >
  > Bastien
  Hi,

  this files are used for test only, maybe severity could be 
decreased.


 I find the severity accurate: Relying on non-source code is a 
severe
 violation of Debian Policy, not matter the purpose of relying on 
it.


 I think we should change the policy here. Running tests helps 
improve
 the quality of the software we ship. Many times the vendored code 
is
 used to ensure the code does not break in a specific situation. I 
don't

 think reducing test coverage in such situations is really helpful.


 Right, running tests helps improve the quality of software we ship.
 Which is why you probably need to test using what's shipped in 
Debian

 rather than using a vendored source-less code.


 We are not shipping the source less code.


You are: Debian also ships source code.


I meant, not shipping in any binary package. Though as Russ mentioned 
in his reply. I will propose a GR.


 This is used only during tests. I don't think we are not gaining 
anything by removing tests here. Just making it harder for the 
package maintainer to run tests.


You would not gain anything by removing tests, but you would win by
making these tests completely free software.


I am just saying it increases the work required to run tests and when 
disabling tests is an option, the incentive is to disable tests.


 If we rely on non-free code for tests, that's really bad too, and 
that
 must be avoided just like we're avoiding source-less code 
everywhere

 else in Debian. The policy shall not change, please.



 The code is not non-free here, just a specific version of a Free 
Software code built outside Debian.


We build from source...


We build the binary packages from source. I don't think it is useful to 
extend that to tests without considering the tradeoffs involved.


 I think tools required for tests should be considered separately 
from tools required to compile. I think it should be treated similar 
to test data.


I don't agree.


ok, lets see how the whole project feels via a GR and settle it. I just 
expressed my opinion, you expressed yours and we need to make a 
decision now.


 What you are proposing would require the package maintainer to 
adapt these tests to versions available (many times with different 
API versions) in Debian and the easier choice is disabling tests.


No. I believe it's ok to have an embedded version of the JS files in 
the
upstream code. This is a *very* different issue, please do not mix 
them.

What I don't like is using a minified version of the JS files. That's
*very* easy (hum... trivial?) to add a non-minified version in your
Debian folder, and use that for tests. You don't care if running the
tests is a little bit slower (because using a source-full version), 
do you?


I don't think you really understand the complexities here. Building the 
minified version is not just running the minifier against the non 
minified code. The non minified code itself is generated using many 
other tools (typescript, transpiled using babel, bundled using rollup 
or webpack etc - many times the versions of these tools are very much 
different versions as well).




However, there's this:

On 10/7/21 6:17 PM, Richard Laager wrote:
 Running tests against vendored dependencies one isn't going to use 
at

 run-time is of limited usefulness.


Best is, if you can, use the library packaged separately, in Debian,
both for tests, and runtime. This way, you do ensure that:
- patching Debian for security is still a thing
- the package can run with the Debian version of the lib



You are completely missing the reality here as well. The runtime 
dependencies are already used from the packaged versions. These 
vendored libraries are used only to create specific test cases or 
sometimes using alternative implementations to test the shipped code.


I think it's less grave than just saying "oh, we don't care about 
these

binary blobs, there's just for tests...". It's even worse, because by
using a different version for tests a

Re: Not running tests because tests miss source code is not useful

[Pirate Praveen]

Draft text for the GR (this is my first time proposing a GR text, so 
help is welcome to make the text clearer).


We should not worry about minified files in main that are (a) only in 
the source package and not in any binary package, and (b) only used to 
run tests, not to build the binary packages.


To ensure these are not used during generation of binary packages, a 
nocheck build profile should be provided which will remove these files 
from the build environment.


Rationale: Most of the time these minified files create a specific 
instance of a test case and these tests are not the only way to ensure 
functionality of the code we ship. Even though upstream runs these 
tests, during transitions we deviate from upstream for runtime 
dependencies and a way to ensure the functionality is not broken by a 
dependency change is essential. Insisting these test cases are built 
using only packages in main just makes running tests harder and 
disabing tests is choosen as an easier option. Treating the code used 
to run only tests is the same as generated code we ship is not useful. 
In case of the code we ship missing sources, our users can't modify the 
software. But if these sourceless code is used during tests, only 
ability to modify the test cases is lost. A test case is an arbitrary 
combination of the code and we have many different ways of testing a 
code.


Option 1: Agree, we should allow these files in main
Option 2: Disagree, we should not allow these files in main
Option 3: Further discussion

Re: Epoch bump for golang-github-valyala-fasthttp

[Pirate Praveen]

On 12 November 2021 12:38:23 am IST, Guillem Jover  wrote:
>Hi!
>
>The golang-github-valyala-fasthttp package used to have date-based
>release numbers (current Debian version 20160617-2). Upstream has
>since switched to semver (latest upstream version 1.31.0).
>
>So the version scheme has been reset, and unfortunately given that no
>prefix was used when initially packaging this, an epoch seems to be in
>order now.
>
>I'm planning on updating in the coming days to the latest upstream
>release and bump the version using an epoch.

How about golang-github-valyala-fasthttp-v1 ?
Though it won't match import path, it can avoid the epoch.

Most projects change import paths on incompatible bumps.

>Thanks,
>Guillem
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Adding new language/locale to system via a graphical interface

[Pirate Praveen]

Hi,

I'm looking for a way to add a new locale/language to system from gnome 
(think about gnome on mobile like Purism Librem 5 or Pine Phone). I can 
do that from a terminal by running dpkg-reconfigure locales but want to 
provide an easier option to users. Is there a way to force gtk 
interface of debconf and launch it from graphical interface? In Ubuntu, 
there is separate add language tool which can add new languages.


Thanks
Praveen

Re: Adding new language/locale to system via a graphical interface

[Pirate Praveen]

On തി, ജനു 3 2022 at 12:09:10 രാവിലെ +0200 +0200, 
Peter Pentchev  wrote:

On Mon, Jan 03, 2022 at 02:59:26AM +0530, Pirate Praveen wrote:

 Hi,

 I'm looking for a way to add a new locale/language to system from 
gnome
 (think about gnome on mobile like Purism Librem 5 or Pine Phone). I 
can do
 that from a terminal by running dpkg-reconfigure locales but want 
to provide
 an easier option to users. Is there a way to force gtk interface of 
debconf
 and launch it from graphical interface? In Ubuntu, there is 
separate add

 language tool which can add new languages.


The debconf(7) manual page suggests that setting DEBIAN_FRONTEND=gnome
after installing the libgtk3-perl package ought to work, and it seems 
to

work for me:

  sudo env DEBIAN_FRONTEND=gnome dpkg-reconfigure locales

...brings up a GTK+ interface.



Thanks! I need to run xhost + to be able to launch this. Is there 
another way to lauch this graphically without having to run xhost +. 
May be something using policykit?


I remember there used to be a gksu or gksudo but can't find this now

apt-file find bin/gksu
apt-file find bin/gksudo

pkexec env DEBIAN_FRONTEND=gnome /usr/sbin/dpkg-reconfigure locales
Unable to init server: Could not connect: Connection refused

(dpkg-reconfigure:159177): Gtk-WARNING **: 15:28:06.343: cannot open 
display:

debconf: unable to initialize frontend: Gnome
debconf: (DISPLAY problem?)
debconf: falling back to frontend: Dialog



G'luck,
Peter

--
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Re: Adding new language/locale to system via a graphical interface

[Pirate Praveen]

2022, ജനുവരി 6 2:26:33 PM IST, Wouter Verhelst ൽ എഴുതി
>Hi,
>
>On Mon, Jan 03, 2022 at 03:29:06PM +0530, Pirate Praveen wrote:
>> 
>> 
>> On തി, ജനു 3 2022 at 12:09:10 രാവിലെ +0200 +0200, Peter Pentchev
>>  wrote:
>> > On Mon, Jan 03, 2022 at 02:59:26AM +0530, Pirate Praveen wrote:
>> > >  Hi,
>> > > 
>> > >  I'm looking for a way to add a new locale/language to system from
>> > > gnome
>> > >  (think about gnome on mobile like Purism Librem 5 or Pine Phone). I
>> > > can do
>> > >  that from a terminal by running dpkg-reconfigure locales but want
>> > > to provide
>> > >  an easier option to users. Is there a way to force gtk interface of
>> > > debconf
>> > >  and launch it from graphical interface? In Ubuntu, there is
>> > > separate add
>> > >  language tool which can add new languages.
>> > 
>> > The debconf(7) manual page suggests that setting DEBIAN_FRONTEND=gnome
>> > after installing the libgtk3-perl package ought to work, and it seems to
>> > work for me:
>> > 
>> >   sudo env DEBIAN_FRONTEND=gnome dpkg-reconfigure locales
>> > 
>> > ...brings up a GTK+ interface.
>> > 
>> 
>> Thanks! I need to run xhost + to be able to launch this. Is there another
>> way to lauch this graphically without having to run xhost +. May be
>> something using policykit?
>
>If you drop the "env" in that command, then the XAUTHORITY environment
>variable will be retained and you shouldn't need to muck about with X
>authorization.
>

In Pure OS, the plan is to use systemd-localed and it was just a regression 
https://source.puri.sm/Librem5/gnome-control-center/-/issues/124#note_183751 so 
we don't need to reconfigure locales for adding locale.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: The future of src:ntp

[Pirate Praveen]

2022, ജനുവരി 19 5:27:28 PM IST, Paride Legovini ൽ എഴുതി
>Richard Laager wrote on 19/01/2022:
>> On 1/18/22 11:21 AM, Paride Legovini wrote:
>>  > I'd prefer making ntp a dummy package depending on ntpsec rather than
>>  > having src:ntpsec takeover bin:ntp.
>> 
>> If I understand correctly, you're suggesting src:ntp builds bin:ntp that 
>> is a dummy package which depends on ntpsec?
>
>That's what I had in mind, but the other option:
>
>> Another option would be to have src:ntpsec build the bin:ntp dummy 
>> package and remove src:ntp entirely.
>
>also looks sensible to me after all. No strong opinion.

Do we really need a dummy package for upgrades to work? Can't ntpsec binary 
package just add Provides: ntp (=$source:Version) ?

>Paride
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Do we need to hide packages in NEW queue

[Pirate Praveen]

On തി, ജനു 31 2022 at 10:07:32 രാവിലെ +0100 
+0100, Stephan Lachnit  wrote:

On Sun, Jan 30, 2022 at 8:35 PM Russ Allbery  wrote:


 I do think that the amount of effort that the project puts into this
 pre-screening is of sufficiently high magnitude that it would be 
worth
 paying a lawyer for a legal opinion about whether or not we need to 
do
 it.  The savings to the project if we found out that we didn't, or 
that we
 could do something simpler and more easily automated, would be more 
than

 the cost of the legal opinion.


+1

Looking at the last financial numbers I found [1], we have at least
~750k USD we could use for this purpose. I don't really know how
expensive lawyers are, but I doubt that this would cost more than 10k.
Heck, we could even hire two lawyers without any significant financial
impact (maybe in the US and EU as I think these are probably the most
prominent areas for potential copyright lawsuits), even if it costs
50k.

IMHO that would be totally worth it. And instead of investing scarce
man-hours into pre-screening, we could create a money pool for
financial support in case there is a copyright lawsuit. The
pre-screening in NEW doesn't prevent someone from claiming copyright
infringement anyway, there is just a smaller chance that the lawsuit
is justified. But sadly even winning a lawsuit can still cost a
significant amount of money.


I agree. We should get real lawyers involved, pay and settle this issue 
once and for all. As a maintainer who maintains a large number of 
packages, NEW queue is big friction point for me personally and I'd be 
very happy to see a solution for it, other than the status quo. Even if 
the status quo is correct, I'd like this to be backed by a legal 
opinion that we can rely on.

Re: What are the most important projects that Debian ought to work on?

[Pirate Praveen]

On തി, ജനു 24 2022 at 10:31:01 രാവിലെ +0100 
+0100, Sébastien Delafond  wrote:


Hello,

As part of an upcoming survey that we are preparing, we plan to ask
Debian developers to rank, by order of importance, the most popular
ideas of improvements for Debian.

However, there's no easy way to identify what are the most popular 
ideas

of improvements that Debian ought to make. We know of the
"grow-your-ideas" project on Salsa, but it's far from exhaustive:

  https://salsa.debian.org/debian/grow-your-ideas

That's where you come into play: it would be nice if you could share
what are — according to you — the most important 
projects/improvements
that Debian ought to make. You can share your ideas here by replying 
to

this email, but it would be interesting to file them as new issues in
the "grow-your-ideas" project and then reply here pointing to your new
issue:

  https://salsa.debian.org/debian/grow-your-ideas/-/issues

I have added an idea to create unstable-proposed-updates for use during 
freeze to avoid reuploading to unstable from experimental after freeze.


https://salsa.debian.org/debian/grow-your-ideas/-/issues/25

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Pirate Praveen]

2022, ഫെബ്രുവരി 13 9:36:11 PM IST, Roger Shimizu ൽ എഴുതി
>On Sat, Feb 12, 2022 at 2:12 AM Andres Salomon  wrote:
>> Yes, that's the error. "String.matchAll is only available from Node.js
>> 12.0 onwards", according to
>> https://stackoverflow.com/questions/58558257/string-matchall-is-undefined
>> , which also says that String.match is available. I didn't put any
>> effort into working around it (either backporting a newer nodejs or
>> replacing all String.matchAlls with something else), since I wanted to
>> get chromium shipped for bullseye.
>
>Thanks for your confirmation!
>So we're on the same page.
>I tried to backport nodejs 12 from bullseye to buster, but seems
>nodejs 12 cannot coexist with nodejs 10, which means unless I backport
>all the nodejs related packages, which has quite a long list ...
>That's out of my capacity, so I give up.

I think using babel (already packaged) to transpile the js to run on nodejs 10 
could be another option.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Keep both images but stop pretending no-free is unofficial

[Pirate Praveen]

2022, ഏപ്രിൽ 20 2:19:21 AM IST, Bastian Blank ൽ എഴുതി
>> Similarly, I think it would be reasonable for someone to want to provide
>> entirely free Debian media along with a libre laptop.
>
>Does this exist in the real world?  Which hardware would such a system
>contain?

liberated.computer it is refurbished and some components like wifi cards 
replaced so it works with 100% free software.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Firmware - what are we going to do about it?

[Pirate Praveen]

2022, ഏപ്രിൽ 19 5:57:46 AM IST, Steve McIntyre ൽ എഴുതി
>This tension extends to our installation and live media. As non-free is
>officially not considered part of Debian, our official media cannot include
>anything from non-free. This has been a deliberate policy for many years.
>Instead, we have for some time been building a limited parallel set of
>"unofficial non-free" images which include non-free firmware. These non-free
>images are produced by the same software that we use for the official images,
>and by the same team.
>
>There are a number of issues here that make developers and users unhappy:
>
> 1. Building, testing and publishing two sets of images takes more effort.

Can we reduce the tests? Do we really need to test both images for all cases?

> 2. We don't really want to be providing non-free images at all, from a
>philosophy point of view. So we mainly promote and advertise the preferred
>official free images. That can be a cause of confusion for users. We do
>link to the non-free images in various places, but they're not so easy to
>find.

I'm fine making it easier to find.

> 3. Using non-free installation media will cause more installations to use
>non-free software by default. That's not a great story for us, and we may
>end up with more of our users using non-free software and believing that
>it's all part of Debian.

So a separate non-free firmware section as you proposed could work.

> 4. A number of users and developers complain that we're wasting their time by
>publishing official images that are just not useful for a lot (a majority?)
>of users.

Isn't voluntary work being able to work on things you care and not necessarily 
what majority wants?

I can understand if the current volunteers that produce and test fully free 
images don't want to continue and no one else step up. Shouldn't this be a call 
for volunteers ?

May be more people step in to maintain the free images if there is a call for 
volunteers.

>We should do better than this.
>
>Options
>===
>
>The status quo is a mess, and I believe we can and should do things
>differently.
>
>I see several possible options that the images team can choose from here.
>However, several of these options could undermine the principles of Debian. We
>don't want to make fundamental changes like that without the clear backing of
>the wider project. That's why I'm writing this...
>
> 1. Keep the existing setup. It's horrible, but maybe it's the best we can do?
>(I hope not!)
>

As I said earlier, making non-free more prominent and more volunteers to 
maintain fully free images could work to reduce load on existing volunteers.

> 2. We could just stop providing the non-free unofficial images altogether.
>That's not really a promising route to follow - we'd be making it even
>harder for users to install our software. While ideologically pure, it's
>not going to advance the cause of Free Software.

I think we should continue creating non-free images.

> 3. We could stop pretending that the non-free images are unofficial, and maybe
>move them alongside the normal free images so they're published together.
>This would make them easier to find for people that need them, but is
>likely to cause users to question why we still make any images without
>firmware if they're otherwise identical.

This should be fine. This could be used as an opportunity to educate users and 
recommending to choose hardware which works with free images. We can highlight 
h-node.org here.

> 4. The images team technically could simply include non-free into the official
>images, and add firmware packages to the input lists for those images.
>However, that would still leave us with problem 3 from above (non-free
>generally enabled on most installations).

I don't think we should do this.

> 5. We could split out the non-free firmware packages into a new
>non-free-firmware component in the archive, and allow a specific exception
>only to allow inclusion of those packages on our official media. We would
>then generate only one set of official media, including those non-free
>firmware packages.

I'm okay with it only if we don't get enough volunteers to maintain two images.

>(We've already seen various suggestions in recent years to split up the
>non-free component of the archive like this, for example into
>non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement
>(bike-shedding?) about the split caused us to not make any progress on
>this. I believe this project should be picked up and completed. We don't
>have to make a perfect solution here immediately, just something that works
>well enough for our needs today. We can always tweak and improve the setup
>incrementally if that's needed.)
>
>These are the most likely possible options, in my opinion. If you have a better
>suggestion, please let us know!

As mentioned earlier, call

Re: Keep both images but stop pretending no-free is unofficial

[Pirate Praveen]

2022, ഏപ്രിൽ 20 1:14:14 PM IST, Andrey Rahmatullin ൽ എഴുതി
>On Wed, Apr 20, 2022 at 12:55:44PM +0530, Pirate Praveen wrote:
>> >> Similarly, I think it would be reasonable for someone to want to provide
>> >> entirely free Debian media along with a libre laptop.
>> >
>> >Does this exist in the real world?  Which hardware would such a system
>> >contain?
>> 
>> liberated.computer it is refurbished and some components like wifi cards 
>> replaced so it works with 100% free software.
>
>Intel Core i5-3320M CPU (dual-core, four threads, 3rd Gen)
>
>So no.
>

What is no here? This project don't exist or they don't want to provide a libre 
image?

Debian's free image works on these laptops and if we make only non-free images 
they won't be able to provide a fully free image. 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Keep both images but stop pretending no-free is unofficial

[Pirate Praveen]

2022, ഏപ്രിൽ 20 1:52:45 PM IST, Ansgar ൽ എഴുതി
>On Wed, 2022-04-20 at 12:55 +0530, Pirate Praveen wrote:
>> liberated.computer it is refurbished and some components like wifi
>> cards replaced so it works with 100% free software.
>
>No, it doesn't. It just *hides* the fact that you use non-free
>software. If you are happy with that, fine, but please don't claim it
>uses 100% free software.

So are our official images not 100% free? If so what are we even proposing to 
change?

This question was about a desire to ship libre version of the image with a 
laptop that can work with that image. Someone asked if such a laptop exist in 
reality and I pointed out to someone doing that actually.

>And everything from keyboard, mice, storage (SD cards, SSD, rotating
>disks, controllers), ... has firmware. I don't expect them to have done
>much about that. Of course some devices come with preinstalled
>firmware, so it's easy to ignore the firmware exists. However, that
>does not "free" you from the restrictions of proprietary software that
>comes from using non-free firmware in any way compared to having the OS
>supply the firmware data.

There are many layers of issues regarding firmware. I did not oppose creating a 
non free image. I was only asking to keep creating the free image for those who 
want it.

https://forums.puri.sm/t/does-respects-your-freedom-certification-allow-updating-of-proprietary-firmware/9484/6

This has a pretty in depth analysis. I tend to agree with the criteria FSF set 
for RYF certification relating to firmware.

"The rational is that the particular bit pattern which constitutes the firmware 
is relatively fixed, and so is essentially hardware. Of course, just like the 
company need not glue the case shut to prevent the end user from using a 
shunt-mod to overclock the GPU, they similarly don’t have to clip off the JTAG 
pins to prevent the user from rearranging those bits however they like. They 
just must not expect the user to do so (or have software on the machine to do 
it for the user automatically) in order to have a correctly functioning 
machine."

Specifically this,
They just must not expect the user to do so (or have software on the machine to 
do it for the user automatically) in order to have a correctly functioning 
machine.

So a person with RYF certified hardware should be a able to use an image 
without the proprietary firmware. As I already clarified, I just want to keep 
the free image option and not opposed to the separate non-free image.

>Ansgar
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Change package source name

[Pirate Praveen]

2022, മേയ് 9 5:33:18 PM IST, Yadd ൽ എഴുതി
>On 09/05/2022 13:54, Yadd wrote:
>> 
>> 
>> On 09/05/2022 12:56, Jonas Smedegaard wrote:
>>> Quoting Yadd (2022-05-09 12:39:37)
 I just pushed to experimental node-regenerator (via NEW queue, thanks
 to ftpmasters!) which replaces two packages still existing in
 unstable: node-regenerator-runtime and node-regenerator-transform.
 These packages were downloaded from npm registry but the real source
 repository is node-regenerator which builds 4 packages.
 
 I also filed two BTS-ROM-RM against these two old packages.
 
 My question is about this transition. What is the process, wait for
 old packages removals then push node-regenerator to unstable or can I
 push directly node-regenerator to unstable?
 
 Note that node-regenerator-runtime and node-regenerator-transform have
 reverse dependencies (many via node-babel7...).
>>> 
>>> Switching *source* package need no coordination.
>
>That's the goal of this discussion ;-) and that's the reason I pushed 
>node-regenerator to experimental.
>node-regenerator-* were not built from sources. src:node-regenerator builds 
>those 2 packages and provides 2 new ones.
>
>>> Do you perhaps ask because at the same time you also bumped major
>>> version of *binary* packages?  If that's the case then (independent of
>>> the change of source package) those should be properly tested before
>>> pusing to unstable, and any breaking changes should be coordinated with
>>> affected reverse dependencies.
>
>There is no major update here, just an update from 0.13 to 0.15 (no changes 
>for regenerator-runtime, little changes for regenerator-transform without any 
>API changes).
>
Please at least assume compliance with semver.org which says 0.x version 
indicates development version and there is no guarantee minor versions don't 
break compatibility. So for 0.x version libraries even minor versions should be 
treated similar to major versions. Only when upstream has at least 1.0 release 
or higher we can assume backward compatible minor versions.

So please test all reverse (build) dependencies and file bugs if any breaks, 
wait for at least 2 weeks to give time for fixes (or fix them) and then only 
upload to unstable.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Adding epoch to node-markdown-it to correct a wrong upstream version

[Pirate Praveen]

Hi,

While embedding @types/markdown-it in node-markdown-it we made a 
mistake in calculating the resulting upstream version (since uscan was 
not working for downloading current version it was calculated manually).


So current version in the archive is 22.2.3+dfsg+~12.2.3-1

The fixed version we want is 10.0.0+dfsg+~cs16.6.17-1

As per 
https://salsa.debian.org/izzygala/node-markdown-it/-/blob/master/debian/changelog


So to do it cleanly we should add 1:10.0.0+dfsg+~cs16.6.17-1 as an 
epoch to fix this mistake.


Thanks
Praveen

Re: Adding epoch to node-markdown-it to correct a wrong upstream version

[Pirate Praveen]

On വ്യാ, മേയ് 19 2022 at 04:39:23 വൈകു 
-05:00:00 -05:00:00, Richard Laager  wrote:

On 5/19/22 05:42, Pirate Praveen wrote:

So current version in the archive is 22.2.3+dfsg+~12.2.3-1

The fixed version we want is 10.0.0+dfsg+~cs16.6.17-1


I have no dog in this fight as they say, but...

How fast does upstream bump versions? With a 10.x, I wonder if it 
might be relatively frequently. Would they likely exceed 22 in the 
near future? If so, you might just do 
22.3+really10.0.0+dfsg+~cs16.6.17-1 and when they get to 23, it goes 
back to normal, without the epoch.




You can see the release history here 
https://www.npmjs.com/package/markdown-it?activeTab=versions


13.0.0 - a month ago
12.0.0 - 2 years ago
11.0.0 - 2 years ago
10.0.0 - 3 years ago

So I don't think waiting ~10 years (or even 5 years) is a reasonable 
option here.

Re: Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470

[Pirate Praveen]

2022, മേയ് 28 8:42:22 PM IST, Thomas Goirand ൽ എഴുതി
>On 5/27/22 09:26, Andreas Tille wrote:
>> Am Thu, May 26, 2022 at 08:47:20AM +0200 schrieb Nilesh Patra:
>>> Would it be possible to manually remove this item from the list that 
>>> generates
>>> autoremovals?
>> 
>> ... or generate a blacklist of packages that should not trigger those 
>> removals.
>> 
>> The autoremoval warnings are pretty helpful in general but if I'm forced to 
>> mass
>> remove this subject from my mailbox I might loose other sensible autoremoval
>> warnings.
>
>In general, it's massively spamming me, just it should be spamming you as well 
>(well, anyone maintaining a large amount of packages).
>
>I recieved 536 mails (2 days ago)...
>
>On 5/27/22 09:48, Paul Gevers wrote:
>> Patches welcome. Code is here:
>> https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
>>  
>
>IMO, if nobody has time to do it, the person who designed the tool should take 
>care of fixing it. Instead of sending 536 mail, it should be sending a single 
>mail with 536 entries in it... And it's not the first time I'm writing this.

If we don't have volunteers, may be we can fund this? I also got 1000s of 
emails from js team. I think this is a horribly broken design with very high 
impact on contributors. Some just don't contribute in js team because of high 
volume emails.

https://salsa.debian.org/debian/grow-your-ideas/-/issues/36
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: how about telegram channel

[Pirate Praveen]

On Tue, Jul 19 2022 at 09:01:22 PM +02:00:00 +02:00:00, Bartosz Fenski 
 wrote:

Hey folks.

Anyone interested in switching to some more modern channels of 
communication?


I'm tired of keeping VPS just to have IRC client and to be honest I 
think modern solutions like Telegram are simply easier and much more 
practical nowadays.


Both Matrix and XMPP has bridges to IRC and both have built-in 
browsers. From philosophical point of view both Matrix and XMPP are 
fine (free software on client plus server and federated).


Self hosting Matrix requires much more resources compared to XMPP (more 
disk space, processing, memory and constant updating). Matrix 
definitely have more appealing clients and XMPP clients still need more 
work in this area. As some one who self host both (at 
https://poddery.com), I prefer hosting XMPP over Matrix. There are also 
bridges between XMPP and Matrix too.


For using the xmpp irc bridge, see https://irc.cheogram.com for the 
mapping syntax. For example #debconf%irc.oftc@irc.cheogram.com will 
connect you to #debconf on OFTC IRC.

Re: how about telegram channel

[Pirate Praveen]

On Wed, Jul 20 2022 at 03:39:40 PM +02:00:00 +02:00:00, Pirate Praveen 
 wrote:



On Tue, Jul 19 2022 at 09:01:22 PM +02:00:00 +02:00:00, Bartosz 
Fenski  wrote:

Hey folks.

Anyone interested in switching to some more modern channels of 
communication?


I'm tired of keeping VPS just to have IRC client and to be honest I 
think modern solutions like Telegram are simply easier and much 
more practical nowadays.


Both Matrix and XMPP has bridges to IRC and both have built-in 
browsers.


Correction: both have built-in bouncers

Also IRC v3 [1] provides built-in bouncer functionality implemneted by 
Ergo ircd and it is already live in some netowrks like pirateirc.net[2] 
and ergo.chat[3] so if we can explore the possibility of updating oftc 
irc server to an ircv3 compliant server (like Ergo), that would be 
another way to solve this problem.


[1] https://ircv3.net/
[2] https://pirateirc.net/
[3] https://ergo.chat/about-network

Re: Epoch for node-markdown-it

[Pirate Praveen]

On Fri, Aug 19 2022 at 05:50:46 PM +02:00:00 +02:00:00, Andrej Shadura 
 wrote:

Hi,

On Fri, 19 Aug 2022, at 17:45, Nilesh Patra wrote:
 I agree, adding an epoch in this package doesn’t seem 
appropriate or necessary.


 JTFR - Upstream released 12.0.4 in 2020, and they have reached 
13.0.1

 _now_ (after two years)
 Going by previous releases, the delta between one major release is
 atleast an year.

 And so reaching to 22.2.3 will take a very long time as well, if 
not _forever_

 and that would mean keeping up with +really for several years. I do
 not think tagging this along with really is much better than adding 
in an epoch.

 (I personally find the former a bit more ugly for my taste)


As Jonas said, an epoch cannot be undone, +really can, regardless 
when this is going to happen. Both are ugly solutions, but an epoch 
is also evil, unlike +really 🙂


Are we going to deny every epoch request or this is going to be 
subjective?


I don't know if waiting potentially 10+ years for upstream to catch up 
is not a reasonable request, what exactly is reasonable?


In cases of reverting to an older version +really is appropriate, but 
with such big version difference if epoch cannot be used, why are we 
keeping the option of epoch at all?

Re: Epoch for node-markdown-it

[Pirate Praveen]

On ശ, ഓഗ 20, 2022 at 3:53 വൈകു, Holger Levsen 
 wrote:

On Sat, Aug 20, 2022 at 03:29:59PM +, Stefano Rivera wrote:

 > > Epochs cause problems, [...]
 > which are? (I agree they are ugly and should often be avoided, 
but I don't

 > see any unsolved problems with them, which is why I'm asking.)
 The standard one is that people use them to revert an upload.


ok, I agree that's bad. (but not the case here.)

 But, epochs aren't used in the upstream tarball filename, so you 
then

 easily get a conflict between the old and the new one.


I'd replace 'easily' with 'theoretically in rare cases' but I can see 
how

this is a valid point, sometimes.


I think the only real consequence for this is a dak reject which can be 
fixed by a new upload with +debian suffix.


Say when upstream again release 22.3 version, 1:22.3 orig.tar will have 
a different checksum from 22.3 orig.tar. If at all dak keeps history of 
the tar after so many releases. At that point, just uploading 
1:22.3+debian will allow dak to accept the new tarball. Am I missing 
something here?


If this is indeed the case, it feels like many people are blindly 
chanting epoch is evil without really understanding what is at stake 
really.

Re: Epoch for node-markdown-it

[Pirate Praveen]

On വെ, ഓഗ 19, 2022 at 6:00 വൈകു, Simon McVittie 
 wrote:

On Fri, 19 Aug 2022 at 21:36:24 +0530, Pirate Praveen wrote:
 Are we going to deny every epoch request or this is going to be 
subjective?


If there was a correct objective rule for what to do, we'd be applying
that rule mechanically, not asking our fellow developers for advice.
Epochs cause problems, but sometimes the alternatives are worse. 
Deciding
which is the least-bad option is inherently a subjective question and 
you

are not going to get an objective answer to it.



I think we can document the most commonly occuring cases and their pros 
and cons for the epoch, only if something is not covered by the common 
case we should ask in -devel. Current way of long thread on -devel for 
every epoch bump is too much demotivating and time draining for very 
little benefit. People just repeat the same boilerplate arguments 
without even looking at the specifics of the case most of the time. Is 
the opinions on -devel binding? What if when conflicting opinions are 
there? For example I'm convinced we need an epoch here, there are 
people who objected, can I still go ahead and upload with epoch?



I do not have a strong opinion either way on this particular situation
without knowing where 22.2.3 came from. As a way to mitigate this sort
of thing in future, I'd suggest that maintainers/sponsors should 
confirm

whether upstreams were intentionally doing a multi-version jump like
that one before uploading the new version.



I don't think this is going to be foolproof.

smcv

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

[Pirate Praveen]

On Sun, Aug 28 2022 at 07:39:12 AM +02:00:00 +02:00:00, Andreas Tille 
 wrote:
BTW, the vast amount of new packages I'm packaging are new 
dependencies

for existing packages to get their new versions.


May be we should be able to tag packages with in NEW into categories 
like this (similar to how a DD can give back a failed build via web 
interface). This may need to go through a GR. If we prioritize packages 
in NEW required for updating other dependencies, that can help things 
faster. When I upload packages to NEW, I know some packages are 
priority and some are not, but there is no way to express that 
currently.

Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation

[Pirate Praveen]

On Mon, Aug 29 2022 at 12:33:44 PM +05:30:00 +05:30:00, Pirate Praveen 
 wrote:



On Sun, Aug 28 2022 at 07:39:12 AM +02:00:00 +02:00:00, Andreas Tille 
 wrote:
BTW, the vast amount of new packages I'm packaging are new 
dependencies

for existing packages to get their new versions.


May be we should be able to tag packages with in NEW into categories 
like this (similar to how a DD can give back a failed build via web 
interface). This may need to go through a GR. If we prioritize 
packages in NEW required for updating other dependencies, that can 
help things faster. When I upload packages to NEW, I know some 
packages are priority and some are not, but there is no way to 
express that currently.


Or we may also be able to reuse the urgency field in changelog if the 
idea that "uploaders should be able to prioritize some packages in 
NEW and ftp masters should check the priority queue before the normal 
queue" is acceptable to the project.