Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

[intrigeri]

Paul Wise:
> There doesn't appear to be anything like devilspie in Debian for GNOME
> on Wayland.

The "Auto Move Windows" GNOME Shell extension (in the
gnome-shell-extensions package) provides parts of
devilspie's functionality.

Cheers,
-- 
intrigeri

Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline

[Mo Zhou]

Hi Guillem,

Thanks for your helpful pointers.

On Sat, Apr 06, 2019 at 10:55:35PM +0200, Guillem Jover wrote:
> If what you are interested in though is just a small subset of the
> archive, another option that would benefit everyone and is perhaps
> less cumbersome than having to jugle around with multiple archives
> and package rebuilds/variants, is to make use of libc's hwcaps [H]
> support, which means the dynamic linker will automatically load the
> best optimized shared object for the current hardware. This of course
> can complicate a bit the packaging, and bloat it, but if the performance
> improvement is substantial, it might be a very good trade-off.
>   [H] man ld.so "NOTES" / "Hardware capabilities"

This sounds like a nice feature. However, unfortunately, the "avx2" and
"avx512" features I wanted didn't show up in the list... IIRC in my
original post I presented a C++ example with Eigen (a header-only
library). Reverse deps such as TensorFlow would benefit from this HWCAPS
feature if ld.so supported amd64's avx2 and avx512.
 
> Another option which requires upstream code changes (and ideally them
> being complicit) is to add run-time selection for the more suitable
> optimized functions, for example via the __target__ and __ifunc__ [I]
> function __attribute__ (and __builtin_cpu_supports or __builtin_cpu_is),
> or the __target_clone__ function __attribute__. Perhaps also of
> interest is the __simd__ function __attribute__.
> 
>   [I] info gcc "Function Attributes";
>   

This compiler feature (which has been considered in the past) is a quite
good solution for small projects.  However this is not easy to enforce for
projects like TensorFlow ...

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

[Bastian Blank]

On Tue, Apr 09, 2019 at 08:44:45AM +0800, Paul Wise wrote:
> On Fri, Apr 5, 2019 at 11:25 PM Mo Zhou wrote:
> > I second that since I always refuse to use Wayland, due to
> I'm currently using GNOME on Xorg because:
> Under Wayland applications seem to have a problem displaying
> fullscreen, for example totem only displays video in the upper left
> corner of the screen, on both Intel and nouveau drivers.

You use your display in HiDPI mode or, worse, in fractional HiDPI mode?

At least with the later setting I had problems as well.  But usually all
the tools behave sane and my mpv knows about the real resolution and can
use it.

> There doesn't appear to be anything like devilspie in Debian for GNOME
> on Wayland.

This package is maintained by QA.

Regards,
Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0

Bug#926692: ITP: fluentd -- Fluentd event collector

[Hideki Yamane]

Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 

* Package name: fluentd
  Version : 1.4.2
  Upstream Author : Sadayuki Furuhashi 
* URL : https://www.fluentd.org/
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Fluentd event collector

 Fluentd is an open source data collector designed to scale and simplify
 log management. It can collect, process and ship many kinds of data in near
 real-time.

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Vincent Bernat]

 ❦  9 avril 2019 08:41 +10, Ben Finney :

>> >> yes, it can be done, but it is a lot more work for individual
>> >> packagers.
>> >
>> > Sure. And, on the other hand, providing an APT repository for arbitrary
>> > packages of unknown copyright status is also a lot of work to expect
>> > disinterested volunteers to do without motivation.
>>
>> Disinterested volunteers are never forced to work for Debian.
>
> Yes, that's why I said “expect” and not “force”.

Being forced is the definition of expect.

"to consider bound in duty or obligated they expect you to pay your
bills" 

>> What is the point of being so negative?
>
> Not sure who you're addressing here, and I'm sorry if the discussion
> appears negative to you.

I am addressing you. You try to dissuade people on the basis this is
work you are not interested to do. If someone was implementing PPA/DPA,
what would be the downside for people not interested in them? None. You
can just ignore the feature.
-- 
Must I hold a candle to my shames?
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

[prototype] Debian User Repository Toolkit 0.0a release

[Mo Zhou]

Hi list,

I drafted a 0.0 alpha release[1] for the toolkit, and created a logo for
the DUPR project. From now on I'll try to add more packaging scripts
(maybe I should call them recipes) to the default collection[2].
Packaing plans are tracked here[3], and maybe further discussion about
the DUPR (DUR, whatever.) should be redirected to a dedicated issue[4].
And, I hope someone could put forward a better name for these prototypes
(naming issue tracked here: [6]).

The prototype implementation[5] needs time to grow, evolve, and listen
to the others. Time will see everything. Please help me spread the
underlying idea and the reference implementation[5] if you agree with my
original motivation.

Thanks for your patient, and support,
Mo

[1] https://github.com/dupr/duprkit/releases/tag/0.0a
[2] https://github.com/dupr/DefaultCollection
[3] https://github.com/dupr/DefaultCollection/issues
[4] https://github.com/dupr/duprkit/issues/9
[5] https://github.com/dupr
[6] https://github.com/dupr/duprkit/issues/2

Handling Japanese new era "令和 (Reiwa)"

[Hideki Yamane]

Hi,

 I've noticed that Japan renews its era from 平成 (Heisei) to 令和 (Reiwa)
 (U+32FF) at 1st May and it's necessary to update some packages to deal
 with it. 

 > To Release Managers
 How do we handle with it for buster? (and stretch?)

 > Folks
 Some packages list to be updated as far as I know
 Please let me know if you've noticed more

  - glibc [1]
  - unicode-data [2]
  - mozc (IME) [3]
  - libreoffice [4]
  - openjdk [5]
  - icu [6]
  - fonts! (Noto, VLgothic, etc...)

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=22964
(debian)$ LC_ALL=ja_JP.utf8 date +%EY -d 20190501
   平成31年
(fedora)$ LC_ALL=ja_JP.utf8 date +%EY -d 20190501
   令和元年
[2] Unicode 12.1 contains "令和"
[3] https://salsa.debian.org/debian/mozc/merge_requests/3
[4] 
https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-1&id=39de7d73fdab86a1531f19076ab1d07fcff97b55
[5] https://bugs.openjdk.java.net/browse/JDK-8205432
[6] https://bugzilla.redhat.com/show_bug.cgi?id=1677093


-- 
Hideki Yamane 

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

[Paul Wise]

On Fri, Apr 5, 2019 at 11:25 PM Mo Zhou wrote:

> I second that since I always refuse to use Wayland, due to

I'm currently using GNOME on Xorg because:

Under Wayland applications seem to have a problem displaying
fullscreen, for example totem only displays video in the upper left
corner of the screen, on both Intel and nouveau drivers.

There doesn't appear to be anything like devilspie in Debian for GNOME
on Wayland.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: duprkit User Repository

[Mo Zhou]

Hi,

On Mon, Apr 08, 2019 at 10:22:42AM -0400, Roberto C. Sánchez wrote:
> 
> Two suggestions:
> 
> - Stop claiming that what you propose is "zero-cost", "only 1 second of
>   work", etc.*

And, I'm already tired of saying that again and again.

> - Find the individuals who currently experience the greatest pain
>   associated with the problem you are trying to solve and whose pain is
>   relieved by your solution.  Get them to adopt it.  If it works as well

/me. The packaging work for at least cudnn, bazel, pytorch, tensorflow
and their dependencies will stall if one targets on high quality and
policy-compliant work, because I believe they don't worth investing huge
amount of time to be made policy-compliant.

>   as you say it does, they will be enthusiastic adopters and will have
>   no problem telling others, in concrete terms, how much better your
>   solution is than whatever the current situation is.

This idea, or the prototype, needs to be lucky enough to be properly
spreaded among the targeted users. However, if nobody believed in
the insight or the motivation, the idea has failed at the beginning.
 
> * Even in a perfect world, nothing is "zero-cost."  To a community of
>   contributors whose purpose it is to build an operating system
>   distribution a deep understanding of the components that compose the
>   system and the components used to build the system are effectively a
>   requirement.  Thus, if I came along and said, "here, I have a drop-in
>   replacement for utility 'foo', and I call the replacement 'bar', and
>   it supports all the same options as 'foo' so that you can use it
>   without having to think about any differences" I would still expect
>   that there would be a need for me to convince potential adopters that
>   things really work that way.  Experience tells us that even "drop in"
>   replacements for things are seldom that "perfect" when it comes to
>   compatibility with whatever they are replacing.

Fair enough. Since both traditional debian/ layout and the single-file
cruft are supported explicitly, I'll stop replying comments on preference.

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Ben Finney]

Vincent Bernat  writes:

>  ❦  8 avril 2019 14:46 +10, Ben Finney :
>
> >> yes, it can be done, but it is a lot more work for individual
> >> packagers.
> >
> > Sure. And, on the other hand, providing an APT repository for arbitrary
> > packages of unknown copyright status is also a lot of work to expect
> > disinterested volunteers to do without motivation.
>
> Disinterested volunteers are never forced to work for Debian.

Yes, that's why I said “expect” and not “force”.

> What is the point of being so negative?

Not sure who you're addressing here, and I'm sorry if the discussion
appears negative to you.

-- 
 \  “When I get real bored, I like to drive downtown and get a |
  `\ great parking spot, then sit in my car and count how many |
_o__)people ask me if I'm leaving.” —Steven Wright |
Ben Finney

RE:RE:[Idea] Debian User Repository? (Not simply mimicing AUR)

[PICCA Frederic-Emmanuel]

After a build, you get this 

https://salsa.debian.org/science-team/python-xrayutilities/-/jobs/147913/artifacts/browse/debian/output/

Is it enought for you.
Mayve you can discuss with the salsa pipeline team and request a target in 
order to produce a better repo.

cheers

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Ansgar]

Paul Wise writes:
> On Mon, Apr 8, 2019 at 3:34 PM Mo Zhou wrote:
>
>> However, the translator itself is not trivial, as it might need
>> it's own shell parser or something alike to be reliable enough.
>
> Couldn't you just run makepkg (with some hooks) and dpkg-deb to
> convert the results to Debian packages?

How should this handle dependencies (probably named differently in
Debian) or maintainer scripts?

Tools like `alien` to convert RPM and Debian packages have similar
limitations and I don't remember them working that well.

Ansgar

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

[Shengjing Zhu]

> from PPA (source+binary-based).

If people just want a PPA which supports Debian, please just take a
look at OBS[1].

I've seen many upstreams provide packages with OBS, and most
distributions are supported.
Not only deb, but also rpm, from Debian/Ubuntu to OpenSuse/Fedora, and
even Archlinux, in a uniform way.

[1] https://build.opensuse.org/


--
Shengjing Zhu

Re: RE:[Idea] Debian User Repository? (Not simply mimicing AUR)

[Kyle Edwards]

On Mon, 2019-04-08 at 16:05 +, PICCA Frederic-Emmanuel wrote:
> now we have the salsa pipeline.
> 
> does it fit your needs ?

Does this allow non-DD's to host packages? Nobody at Kitware is a DD,
we just host an unofficial third-party repository, similar to PPA.

Kyle

Re: Using Jenkins Debian Glue to setup personal repos really quick (Was: [Idea] Debian User Repository?)

[Ondřej Surý]

That repository is more of a remote backup, but I would be happy to collaborate 
on something more useful to general DD public...

There’s some additional content in this ticket that might go into the readme: 
https://github.com/oerdnj/deb.sury.org/issues/1092

Ondrej
--
Ondřej Surý 

> On 8 Apr 2019, at 18:30, Ondřej Surý  wrote:
> 
> Hey,
> 
> check https://jenkins.rfc1925.org and f.e. https://packages.sury.org/php/
> 
> --
> Ondřej Surý 
> 
>> On 8 Apr 2019, at 18:22, Holger Levsen  wrote:
>> 
>> Hi Ondřej,
>> 
>>> On Mon, Apr 08, 2019 at 06:14:57PM +0200, Ondřej Surý wrote:
>>> It’s fairly easy nowadays with debian-jenkins-glue and jenkins-job-builder:
>>> 
>>> https://salsa.debian.org/ondrej/jenkins-job-builder.git
>>> 
>>> The launchpad PPAs are still slightly better (I cant rebuild individual 
>>> matrix combinations from Jenkins), but only slightly. With qemu-user-static 
>>> the even the armhf and arm64 builds works (mostly) fine.
>> 
>> that sounds pretty interesting. What sources.lists does this produce?
>> Could you maybe add a short README file to your repo? :)
>> 
>> 
>> -- 
>> tschau,
>>   Holger
>> 
>> ---
>>  holger@(debian|reproducible-builds|layer-acht).org
>>  PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Re: Using Jenkins Debian Glue to setup personal repos really quick (Was: [Idea] Debian User Repository?)

[Ondřej Surý]

Hey,

check https://jenkins.rfc1925.org and f.e. https://packages.sury.org/php/

--
Ondřej Surý 

> On 8 Apr 2019, at 18:22, Holger Levsen  wrote:
> 
> Hi Ondřej,
> 
>> On Mon, Apr 08, 2019 at 06:14:57PM +0200, Ondřej Surý wrote:
>> It’s fairly easy nowadays with debian-jenkins-glue and jenkins-job-builder:
>> 
>> https://salsa.debian.org/ondrej/jenkins-job-builder.git
>> 
>> The launchpad PPAs are still slightly better (I cant rebuild individual 
>> matrix combinations from Jenkins), but only slightly. With qemu-user-static 
>> the even the armhf and arm64 builds works (mostly) fine.
> 
> that sounds pretty interesting. What sources.lists does this produce?
> Could you maybe add a short README file to your repo? :)
> 
> 
> -- 
> tschau,
>Holger
> 
> ---
>   holger@(debian|reproducible-builds|layer-acht).org
>   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

RE:[Idea] Debian User Repository? (Not simply mimicing AUR)

[PICCA Frederic-Emmanuel]

now we have the salsa pipeline.

does it fit your needs ?

Re: Using Jenkins Debian Glue to setup personal repos really quick (Was: [Idea] Debian User Repository?)

[Holger Levsen]

Hi Ondřej,

On Mon, Apr 08, 2019 at 06:14:57PM +0200, Ondřej Surý wrote:
> It’s fairly easy nowadays with debian-jenkins-glue and jenkins-job-builder:
> 
> https://salsa.debian.org/ondrej/jenkins-job-builder.git
> 
> The launchpad PPAs are still slightly better (I cant rebuild individual 
> matrix combinations from Jenkins), but only slightly. With qemu-user-static 
> the even the armhf and arm64 builds works (mostly) fine.

that sounds pretty interesting. What sources.lists does this produce?
Could you maybe add a short README file to your repo? :)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Using Jenkins Debian Glue to setup personal repos really quick (Was: [Idea] Debian User Repository?)

[Ondřej Surý]

It’s fairly easy nowadays with debian-jenkins-glue and jenkins-job-builder:

https://salsa.debian.org/ondrej/jenkins-job-builder.git

The launchpad PPAs are still slightly better (I cant rebuild individual matrix 
combinations from Jenkins), but only slightly. With qemu-user-static the even 
the armhf and arm64 builds works (mostly) fine.

Cheers,
Ondřej 
--
Ondřej Surý 

> On 8 Apr 2019, at 18:01, Kyle Edwards  wrote:
> 
> On Mon, 2019-04-08 at 00:02 -0400, Peter Silva wrote:
>>> If one needs to keep a close eye on changes to make sure they can still
>>> be installed even on a years-old OS, the resulting packages can be
>>> placed in a custom repository set up with the instructions at
>>> https://wiki.debian.org/DebianRepository/Setup>. What am I missing?
>>> 
>> 
>> yes, it can be done, but it is a lot more work for individual packagers.
>> 
>> launchpad.net combines:
>>- very few clicks to build custom repositories.
>>- a build environment for each OS, so that it runs "debuild" in the 
>> currently patched version of the OS for which the package it built.
>> 
>> It saves people from having to build their own custom repository, and from 
>> having to maintain a build environment for all supported OS versions and 
>> architectures.  on Ubuntu,  packages are built for 14.04, 16,04, 18.04, 
>> 18.10, 19.04, and I get all those just from clicking one box for each one. I 
>> think it also propagates re-building of packages when a build-dependency 
>> changes, without my knowledge or interaction.  It leverages the ubuntu 
>> build-farm for third-party packages.
>> 
>> With debian, it's kind of all or nothing.  Etiher you're in Debian, and it 
>> gets built on every platform using the build farm, or it's not, so you get 
>> no help at all. Launchpad gives a nice middle road that suits us right now, 
>> and if something similar were available for debian, it would provide a 
>> stepping stone to being in Debian proper.
> 
> CMake and VTK upstream here. This was my exact observation a while back when 
> I tried to package VTK for Debian and Ubuntu. Packaging for Ubuntu was very 
> easy: just upload your packaging script to launchpad.net and you're done. For 
> Debian, I had to set up a build machine and an Aptly repository on a virtual 
> machine that pulls in built packages from "incoming", inserts them into the 
> Aptly repo, and rsyncs them to a web server, basically mimicking what the 
> Debian repo infrastructure does. This was non-trivial to set up, and I found 
> it frustrating that Launchpad-like infrastructure did not exist for Debian. 
> (Building lots of packages is easy once you have the infrastructure, but the 
> initial investment is rather high.) Just my $0.02.
> 
> Kyle

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Kyle Edwards]

On Mon, 2019-04-08 at 00:02 -0400, Peter Silva wrote:
> > If one needs to keep a close eye on changes to make sure they can
> > still
> > be installed even on a years-old OS, the resulting packages can be
> > placed in a custom repository set up with the instructions at
> > https://wiki.debian.org/DebianRepository/Setup>;. What am I
> > missing?
> > 
> yes, it can be done, but it is a lot more work for individual
> packagers.
> 
> launchpad.net combines:
>    - very few clicks to build custom repositories.
>    - a build environment for each OS, so that it runs "debuild" in
> the currently patched version of the OS for which the package it
> built.
> 
> It saves people from having to build their own custom repository, and
> from having to maintain a build environment for all supported OS
> versions and architectures.  on Ubuntu,  packages are built for
> 14.04, 16,04, 18.04, 18.10, 19.04, and I get all those just from
> clicking one box for each one. I think it also propagates re-building 
> of packages when a build-dependency changes, without my knowledge or
> interaction.  It leverages the ubuntu build-farm for third-party
> packages.
> 
> With debian, it's kind of all or nothing.  Etiher you're in Debian,
> and it gets built on every platform using the build farm, or it's
> not, so you get no help at all. Launchpad gives a nice middle road
> that suits us right now, and if something similar were available for
> debian, it would provide a stepping stone to being in Debian proper.
CMake and VTK upstream here. This was my exact observation a while back
when I tried to package VTK for Debian and Ubuntu. Packaging for Ubuntu
was very easy: just upload your packaging script to launchpad.net and
you're done. For Debian, I had to set up a build machine and an Aptly
repository on a virtual machine that pulls in built packages from
"incoming", inserts them into the Aptly repo, and rsyncs them to a web
server, basically mimicking what the Debian repo infrastructure does.
This was non-trivial to set up, and I found it frustrating that
Launchpad-like infrastructure did not exist for Debian. (Building lots
of packages is easy once you have the infrastructure, but the initial
investment is rather high.) Just my $0.02.
Kyle

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

[Andrey Rahmatullin]

On Sun, Apr 07, 2019 at 05:59:38PM +0200, Adam Borowski wrote:
>   * nvidia proprietary: doesn't work with new kernels.  
It does, even nvidia-legacy-304xx-kernel-dkms says "Building the kernel
modules has been tested up to Linux 4.20.".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

[Andrey Rahmatullin]

On Sun, Apr 07, 2019 at 01:08:42PM -0400, Peter Silva wrote:
> https://www.cnx-software.com/2018/08/27/rockpro64-rk3399-board-linux-review-ubuntu-18-04/
> 
> 71fps or es2gears?
Is es2gears a benchmark, unlike glxgears?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

[Alf Gaida]

DUR is fine, DPA is fine PPA is not - as it is used before in a totally 
different context.


The idea just to require git is really nice, putting all the things into 
a single file is not. Not even Arch does it. (patches, install, config 
...) - so the default debian dir should be enough.


Please think a bit further - which files are really needed?
* control
* rules
* watch

There was discussions to make rules obsolete in standard packages - if 
there is no rules file, just assume/use the default. compat is obsoleted 
if one use debhelper-compat, copyright would be nice to have, but might 
not be needed for a possible dur. Same for all other things.


Things become a bit different if one want to use patches. So why don't 
use the debian standards. Same for packages that result in more than one 
binary package.


If anything else fails just add a file with a special set of things for 
the DUR/DPA - should be dead easy, i use something similar for years now 
to build things from several git sources.


Cheers Alf

Re: duprkit User Repository

[Roberto C . Sánchez]

On Mon, Apr 08, 2019 at 12:57:56PM +, Mo Zhou wrote:
> On Mon, Apr 08, 2019 at 08:36:45AM -0400, Roberto C. Sánchez wrote:
> > On Mon, Apr 08, 2019 at 11:02:35AM +, Mo Zhou wrote:
> > In such a large community of volunteers it may not be enough to propose
> > something that is only marginally better because the cost (even just in
> > cognitive terms) and effort required for so many individuals to overcome
> > inertia is relatively high.
> 
> Linus said that "Talk is cheap, show me the code."
> Now I have shown the code and nobody read that.
> 
> The single-file format is not mandatory, and two convertion tools
> enables zero-cost convertion:
> https://github.com/dupr/duprkit/blob/master/bin/fold
> https://github.com/dupr/duprkit/blob/master/bin/unfold
> 
> And the prototype implementation is compatible to the traditional debian/
> directory. See 
> https://github.com/dupr/DefaultCollection/tree/master/rover-traditional
> for the example.
> 
> BOTH single-file format and traditional format are supported. People
> could choose and use what they like.
> 
> I admit that I'm quite fond of the proposed single-file format, and
> hence didn't mention and compatiblity with traditional format in design.
>  
> > I am not trying to discourage you from your effort, but rather advising
> > you that the chances of success would improve if you address the
> > principal obstacles to adoption in a holistic way.  (As I already
> > pointed out, your current approach misses a great deal.)
> 
> What else can I do? Both traditional and single-file formats  are
> explicitly supported now.
> 

Two suggestions:

- Stop claiming that what you propose is "zero-cost", "only 1 second of
  work", etc.*
- Find the individuals who currently experience the greatest pain
  associated with the problem you are trying to solve and whose pain is
  relieved by your solution.  Get them to adopt it.  If it works as well
  as you say it does, they will be enthusiastic adopters and will have
  no problem telling others, in concrete terms, how much better your
  solution is than whatever the current situation is.

* Even in a perfect world, nothing is "zero-cost."  To a community of
  contributors whose purpose it is to build an operating system
  distribution a deep understanding of the components that compose the
  system and the components used to build the system are effectively a
  requirement.  Thus, if I came along and said, "here, I have a drop-in
  replacement for utility 'foo', and I call the replacement 'bar', and
  it supports all the same options as 'foo' so that you can use it
  without having to think about any differences" I would still expect
  that there would be a need for me to convince potential adopters that
  things really work that way.  Experience tells us that even "drop in"
  replacements for things are seldom that "perfect" when it comes to
  compatibility with whatever they are replacing.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

[Jonathan Dowland]

On Mon, Apr 08, 2019 at 11:18:14AM +, Mo Zhou wrote:

The proposed idea is source-only-based, and is totally different
from PPA (source+binary-based). I'm a PPA user and I don't have
any reason to re-invent yet another PPA.


Sorry I appreciate that *your* idea is different, and effectively
my sub-thread is a hijack, but to be clear what I was referring to
was the naming of the pre-existing "Bikeshed" proposal for Debian,
which is equivalent to PPAs.

--

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

Re: is Wayland mature enough to be the default desktop choice in Buster?

[Jonathan Dowland]

Dear Simon

On Sat, Apr 06, 2019 at 10:20:26PM +0100, Simon McVittie wrote:

It's perhaps important to point out before this thread gets much further
that Wayland is not like Xorg


Apologies for not being clearer in my original message. Thank you for clearing
that up.


GNOME in buster has defaulted to Wayland mode since August 2017. The
default could presumably be swapped back to X11, as we did for stretch,


Apparently Ubuntu decided that it was not suitable (yet) as the default
for 18.04, which was an LTS release, and still stuck with Xorg for 18.10.

I don't know what criteria they used to make that decision, but I would imagine
it should be very similar to ours. Especially for an LTS release. I also don't
know what the status is for 19.04 which is presumably expected soon.


but I'm not sure whether post-hard-freeze is necessarily an appropriate
time to do that.


The freeze is a tool we use to try and ensure a quality and orderly release.
If we collectively agree that this change is necessary for the quality of our
release, then I'd hope the release team would also agree that such a change was
worthy of a freeze exception. But both of these hypotheticals are a few steps
ahead of where we are now.


If I understand correctly, the pattern that led to synaptic's removal is
that it runs its full GUI as root, which isn't supported by the way many
(all?) Wayland environments set up Xwayland.


I think that's right. I appreciate that this is has been considered a bad
approach to the problem for a long time, long before Wayland. I suspect,
but have not confirmed, that it is not the only program that will fail to
work properly in a Wayland environment. It's probably one of the more high
profile programs to break in Debian, though. Another I'd like to verify is
gparted.

Would the GNOME team kindly share with this thread the criteria that you folks
use to make your decision as to whether to default to Wayland in Debian?


Best wishes

--

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

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Mo Zhou]

Hi,

On Mon, Apr 08, 2019 at 01:59:04PM +0200, W. Martin Borgert wrote:
> Quoting Mo Zhou :
> > Plus, letting users write PKGBUILD doesn't help them learn
> > Debian packaging at all...
> 
> Then I would try to diverge as little as possible
> from the classical way how Debian packaging works.
 
If you didn't read the code of fold/unfold and don't understand
why I declare that the cost of the proposed single-file format
has nearly zero-cost, please refer to the traditional style
alternative:

https://github.com/dupr/DefaultCollection/tree/master/rover-traditional
I expect no one to argue about this "traditional" style.
This "traditional" style is exactly what you do for the
official debian development, in the "debian-directory-only"
git workflow.

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

[Mo Zhou]

On Mon, Apr 08, 2019 at 03:50:19PM +0300, Tzafrir Cohen wrote:
> Hi,
> 
> The README states a directory structure with a top-level collection
> directory, but the repository currently does not include one.

The github.com:dupr/DefaultCollection.git repo is indeed a specification
compliant if you mangle the first layer of directory structure.

```
--- a/README
+++ b/README
@@ -17,7 +17,7 @@ name. Plus, no one prevents you from submitting a debian 
directory.

 For example:

-A-Certain-Collection/
+A-Certain-Collection/  # For example, this git repository.
 library-foo/
 library-foo.durpkg
 library-foo-ubuntu.durpkg
```

> Looking at:
> 
> 
> https://github.com/dupr/DefaultCollection/blob/master/rover/rover.durpkg
> 
> I see that the name of the directory repeats quite a number of times.
> The clean function needs to state 'rm -rf' explicitly, which I hope
> won't lead to typos.

The repetition of "pushd" and "popd" is something that could be improved
later. So the same as the 'rm -rf' hook. The two problems have been
tracked here:
https://github.com/dupr/duprkit/issues/3
https://github.com/dupr/duprkit/issues/4

Please don't expect too much from a prototype rushed within several
hours. That's used for presenting the idea instead of presenting
a graceful implementation.

> The changelog is buried deep inside the package an needs to be updated
> whenever a version number is bumped.

AUR's PKGBUILD doesn't record changes. If you feel like that the dch
has been deeply buried, the usage of traditional debian/ directory
layout is still supported:
https://github.com/dupr/DefaultCollection/tree/master/rover-traditional
https://github.com/dupr/DefaultCollection/blob/master/rover-traditional/debian/changelog

One could easity convert the packaging between single-file format and
debian/ directory with a single-command-cost (virtually zero-cost).

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

[Tzafrir Cohen]

Hi,


On 08/04/2019 14:18, Mo Zhou wrote:
> Hi,
>
> The proposed idea is source-only-based, and is totally different
> from PPA (source+binary-based). I'm a PPA user and I don't have
> any reason to re-invent yet another PPA.
>
> The proposed idea is to take some advantages from source-based
> software distribution tools. Examples are available here:
> https://github.com/dupr/duprkit
> https://github.com/dupr/DefaultCollection

The README states a directory structure with a top-level collection
directory, but the repository currently does not include one.


Looking at:


https://github.com/dupr/DefaultCollection/blob/master/rover/rover.durpkg


I see that the name of the directory repeats quite a number of times.
The clean function needs to state 'rm -rf' explicitly, which I hope
won't lead to typos.


The changelog is buried deep inside the package an needs to be updated
whenever a version number is bumped.


-- Tzafrir

Re: duprkit User Repository

[Mo Zhou]

On Mon, Apr 08, 2019 at 08:36:45AM -0400, Roberto C. Sánchez wrote:
> On Mon, Apr 08, 2019 at 11:02:35AM +, Mo Zhou wrote:
> In such a large community of volunteers it may not be enough to propose
> something that is only marginally better because the cost (even just in
> cognitive terms) and effort required for so many individuals to overcome
> inertia is relatively high.

Linus said that "Talk is cheap, show me the code."
Now I have shown the code and nobody read that.

The single-file format is not mandatory, and two convertion tools
enables zero-cost convertion:
https://github.com/dupr/duprkit/blob/master/bin/fold
https://github.com/dupr/duprkit/blob/master/bin/unfold

And the prototype implementation is compatible to the traditional debian/
directory. See 
https://github.com/dupr/DefaultCollection/tree/master/rover-traditional
for the example.

BOTH single-file format and traditional format are supported. People
could choose and use what they like.

I admit that I'm quite fond of the proposed single-file format, and
hence didn't mention and compatiblity with traditional format in design.
 
> I am not trying to discourage you from your effort, but rather advising
> you that the chances of success would improve if you address the
> principal obstacles to adoption in a holistic way.  (As I already
> pointed out, your current approach misses a great deal.)

What else can I do? Both traditional and single-file formats  are
explicitly supported now.

Re: duprkit User Repository

[Mo Zhou]

Hi,

The use of single-file format is not mandatory to the whole idea.
With no effort I transformed the single-file format into the traditional
format which you like:
https://github.com/dupr/DefaultCollection/tree/master/rover-traditional

Please choose use whatever you like.

On Mon, Apr 08, 2019 at 08:26:53AM -0400, Roberto C. Sánchez wrote:
> On Mon, Apr 08, 2019 at 10:47:20AM +, Mo Zhou wrote:
> If I interpret this correctly, your idea becomes, "use a single file
> package specification, except for the parts that live somewhere
> completely external and separate from the package."  That seems like you
> have *increased* the complexity of the packaging format, rathern than
> decreased it.

It doesn't take more than 1 second to convert between a traditional
debian/ directory of the proposed single file format:
https://github.com/dupr/duprkit/blob/master/bin/fold
https://github.com/dupr/duprkit/blob/master/bin/unfold
And I don't prevent anybody from submitting a debian directory:
https://github.com/dupr/DefaultCollection/commit/6ba5e0a310dc287dbd8ff1b276e1c3da0d896ebd
I encourage people do whatever they like to get the thing done.

Strictly speaking the single-file format has indeed introduced a little
overhead but it's not mandatory.

> Even these other points seem like they require some effort to "prep" the
> packaging so that it exists in a single file and would require similar
> effort to separate the components out.
 
If such 1-second workload is unacceptable, just go in the traditional
way please.
https://github.com/dupr/DefaultCollection/commit/6ba5e0a310dc287dbd8ff1b276e1c3da0d896ebd

> All of this for "copy & pasting from webpages" seems like the epitome of
> "style over substance".  Why on earth is copying and pasting from
> webpages *so* important that the entire packaging format has to be
> reworked?

I don't ask anybody to use it if you don't like the single-file format.
If such 1-second workload is unacceptable, just go in the traditional
way please.

> If somebody is challenged by the obstacle of 'apt-get source ...' or
> 'debcheckout ...' then perhaps making the packaging into a single file
> so that it can be copy/pasted from a webpage might not be solving the
> correct problem.

AUR users are expected to be able to take care of themselves.
If the users cannot even solve the error from "apt-get source"
or "debcheckout", why should they even try a "recipe-only" (or
packaging-script-only, source-only, whatever) way to build or
install something?

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Roberto C . Sánchez]

On Mon, Apr 08, 2019 at 12:29:56PM +, Mo Zhou wrote:
> Hi,
> 
> On Mon, Apr 08, 2019 at 08:18:53AM -0400, Roberto C. Sánchez wrote:
> > On Mon, Apr 08, 2019 at 06:49:10AM +, Mo Zhou wrote:
> > > Hi,
> > > 
> > > As you wish, I added a disclaimer to the toolkit, and replaced every
> > > single "Debian" keyword in the repo with "D**ian", except for those
> > > in disclaimer.
> > 
> > Perhaps using ".deb" instead of "Debian" or "D**ian" might be more
> > practical.  After all, the whole exercise seems to be more focused on
> > the packaging and distribution of said packages, rather than "Debian the
> > GNU/Linux distribution" as a project.  If there are places where the
> > leading dot might be impractical or confusing, then perhaps "dotdeb" or
> > "dot-deb" might be more workable.
> 
> However the idea involves no distribution of any single ".deb" file.
> That's more likely a "User Recipe Repository", instead of a "User dishes
> Repository". People will ask "where on earth are your .deb files?" if
> I put ".deb" to the title.
> 
OK.  Thanks for the explanation.  It seems like I did not properly grasp
that aspect of it.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: duprkit User Repository

[Roberto C . Sánchez]

On Mon, Apr 08, 2019 at 11:02:35AM +, Mo Zhou wrote:
> Hi,
> 
> On Mon, Apr 08, 2019 at 12:37:36PM +0200, Ondřej Surý wrote:
> >
> > I very much dislike the idea of inventing yet another format. Your
> > energy would be much better used if you rather added support for
> > external tarballs to the packaging tools (with hashes, etc.) and turn
> > this into DEP.
> 
> There is merely a tiny overhead in the plain text formats. Well, people
> have different preferences and I still need time to see whether such
> proposed formats are fine.
> 
> I found some existing problem, as what I said in the very first
> paragraph of the original post. And I think I've already made the
> motivation clear there. If the motivation turns to be useful enough,
> why should we reject thinking about something new?
>  
> > Debian is not Fedora/Arch/... and whacking the debian/ into a single
> > file doesn’t feel like something that would help anything at all. Just
> > require git (as AUR4 does).
> 
> Debian is different from the other distros. Particularly, Debian is a
> binary-based distribution. By creating such a user packaging repo, some
> advantages of source-based distributions could be introduced.
> 
> And most importantly, anyone who dislike the single-file format
> could just commit the debian directory to the repo, and remove
> the do_unfold() hook from the header script. That's not recommended
> but it still work without the single-file format. Anyway the
> single-file format is only a part of the idea, and we can remove
> it if most people don't like it.
> 

Let me make a suggestion based on something that I learned quite some
years ago as a young engineer fresh from school: the best technical
solution is only the best overall solution if it also addresses all (or
most) of the relevant non-technical factors.

Rather than focus on the "tiny" technical overhead, focus on the
quality and value of the improvements that justify to a community of
thousands of contributors why they should willingly accept the
additional cognitive burden of the change you are proposing.

If you think about the proposals that have succeeded in becoming de
facto or de jure (in the form of debian-policy) standards within Debian,
every one of them has required lots of people see why *additional work*
for them was beneficial to them *and everyone else* as well.  They also
had to agree that they themselves and the project as a whole saw
sufficient benefit to warrant the change/additional work.

In such a large community of volunteers it may not be enough to propose
something that is only marginally better because the cost (even just in
cognitive terms) and effort required for so many individuals to overcome
inertia is relatively high.

I am not trying to discourage you from your effort, but rather advising
you that the chances of success would improve if you address the
principal obstacles to adoption in a holistic way.  (As I already
pointed out, your current approach misses a great deal.)

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Mo Zhou]

Hi,

On Mon, Apr 08, 2019 at 08:18:53AM -0400, Roberto C. Sánchez wrote:
> On Mon, Apr 08, 2019 at 06:49:10AM +, Mo Zhou wrote:
> > Hi,
> > 
> > As you wish, I added a disclaimer to the toolkit, and replaced every
> > single "Debian" keyword in the repo with "D**ian", except for those
> > in disclaimer.
> 
> Perhaps using ".deb" instead of "Debian" or "D**ian" might be more
> practical.  After all, the whole exercise seems to be more focused on
> the packaging and distribution of said packages, rather than "Debian the
> GNU/Linux distribution" as a project.  If there are places where the
> leading dot might be impractical or confusing, then perhaps "dotdeb" or
> "dot-deb" might be more workable.

However the idea involves no distribution of any single ".deb" file.
That's more likely a "User Recipe Repository", instead of a "User dishes
Repository". People will ask "where on earth are your .deb files?" if
I put ".deb" to the title.

Re: duprkit User Repository

[Roberto C . Sánchez]

On Mon, Apr 08, 2019 at 10:47:20AM +, Mo Zhou wrote:
> Hi,
> 
> On Mon, Apr 08, 2019 at 03:31:21PM +0500, Andrey Rahmatullin wrote:
> > On Mon, Apr 08, 2019 at 09:58:26AM +, Mo Zhou wrote:
> > > AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild,
> > > all of them are single-file format. The advantages of single-file
> > > format includes easy distribution, e.g. copying & pasting from
> > > webpages (you cannot copy a directory from a webpage).
> >
> > This only works when you don't need patches.
> 
> The design of "duprkit" didn't forget patches at all.
> 
> There are many ways to apply apply patches:
> 
> 1. Put separated patches to the Collection repository, as per the
>collection specification: https://github.com/dupr/DefaultCollection
>Then apply it manually in the header script of .durpkg .
>This is similar to what AUR does.
> 
If I interpret this correctly, your idea becomes, "use a single file
package specification, except for the parts that live somewhere
completely external and separate from the package."  That seems like you
have *increased* the complexity of the packaging format, rathern than
decreased it.

> 2. If one like, just fold the patches into the .durpkg, which may result
>in some extra lines in the .durpkg:
> 
>^ debian/patches/series
>foobar.patch
>^ debian/patches/foobar.patch
>-foo bar
>+foobar
> 
>And you may beed to change the source/format accordingly.
> 
>The fact is, any plain file, as long as none of its lines starts with
>a single '^', could be folded into the .durpkg or the .f822 file.
>Detailed file format specification can be found in the code comments[1]
> 
> 3. Fold the patches into .durpkg, but not in the quilt format.
> 
>^ some-working-directory/xxx.patch
>-foo bar
>+foobar
> 
>The header script of .durpkg is able to use it.
> 
> 4. may be more? ...
> 
Even these other points seem like they require some effort to "prep" the
packaging so that it exists in a single file and would require similar
effort to separate the components out.

All of this for "copy & pasting from webpages" seems like the epitome of
"style over substance".  Why on earth is copying and pasting from
webpages *so* important that the entire packaging format has to be
reworked?

If somebody is challenged by the obstacle of 'apt-get source ...' or
'debcheckout ...' then perhaps making the packaging into a single file
so that it can be copy/pasted from a webpage might not be solving the
correct problem.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Roberto C . Sánchez]

On Mon, Apr 08, 2019 at 06:49:10AM +, Mo Zhou wrote:
> Hi,
> 
> As you wish, I added a disclaimer to the toolkit, and replaced every
> single "Debian" keyword in the repo with "D**ian", except for those
> in disclaimer.

Perhaps using ".deb" instead of "Debian" or "D**ian" might be more
practical.  After all, the whole exercise seems to be more focused on
the packaging and distribution of said packages, rather than "Debian the
GNU/Linux distribution" as a project.  If there are places where the
leading dot might be impractical or confusing, then perhaps "dotdeb" or
"dot-deb" might be more workable.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[W. Martin Borgert]

Quoting Mo Zhou :

Plus, letting users write PKGBUILD doesn't help them learn
Debian packaging at all...


Then I would try to diverge as little as possible
from the classical way how Debian packaging works.

Re: duprkit User Repository

[Johannes Schauer]

Hi,

Quoting Mo Zhou (2019-04-08 11:58:26)
> The header script is not really what debian/rules does. For example,
> when you are going to build some official Debian package, you may want
> to do the following:
> 
>   $ debcheckout foobar
>   $ cd foobar; gbp export-orig; debuild -S -nc
>   $ sbuild -j4 foobar.dsc
>   $ rm -rf foobar

OT to this thread but just as general info: If you are already using sbuild
then all of this can be reduced to:

$ sbuild -d unstable foobar

The -d option chooses your configured schroot distribution, but you can as well
pass any other (s)chroot with the -c option instead.

You can also build source packages from other archives (like a PPA) even if the
respective source URLs do not exist in your build chroot. For example here I'm
building the non-free package "arb" from the non-free repository:

$ sbuild -d unstable --extra-repository="deb-src 
http://ftp.de.debian.org/debian/ unstable non-free" arb

So if you end up just having a deb-src archive somewhere, then building
packages from it in a chroot is just a single command.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

[Mo Zhou]

Hi,

The proposed idea is source-only-based, and is totally different
from PPA (source+binary-based). I'm a PPA user and I don't have
any reason to re-invent yet another PPA.

The proposed idea is to take some advantages from source-based
software distribution tools. Examples are available here:
https://github.com/dupr/duprkit
https://github.com/dupr/DefaultCollection

Only "packaging scripts" are provided. Upstream source are
downloaded by the scritps locally before the build. The proposed
idea will never involve "distributing resulting binary .deb packages".

Again, the idea is totally different from PPA.

On Mon, Apr 08, 2019 at 10:32:46AM +, Holger Levsen wrote:
> On Mon, Apr 08, 2019 at 10:18:39AM +0100, Jonathan Dowland wrote:
> > > At the first glance I interpreted the sentence as
> > >  "This will only lead to flamewars"
> > > due to the meaning of bikeshed[1].
> > > 
> > > However, I got a hint from a fellow developer and learned that
> > > "Bikeshed" has its own meaning under Debian's context, according
> > > to some old mailing list fragments[2][3] -- which refers to a
> > > dak feature (This is the first time I heard of such thing).
> > This supports my (thus far) private feeling that naming this initiative
> > "Bikeshed" is a bad idea.
> 
> +1
> 
> I also think that using the name "D**ian" is a bad idea.
> 
> Just call it PPAs... millions of people know that term.

Re: duprkit User Repository

[Mo Zhou]

On Mon, Apr 08, 2019 at 12:51:15PM +0200, Jonathan Carter wrote:
> On 2019/04/08 12:37, Ondřej Surý wrote:
> 
> Indeed. I can see why Mo would want to put it in one file, but the
> Debian package format can work just fine if you work from git
> repositories as you suggest, plus if it looks like a more or less usual
> debian source package, then it's a smaller leap to turn it into a real
> package that can graduate into making its way into Debian.

There is really shockingly small overhead for the single-file format.
At the mean time, converting things between the debian-folder and
single-file formats is really quick, smooth and easy with fold[1] and
unfold[2]. The only problem there is the conversion will fail if binary
blobs exist (not supported yet).

[1] https://github.com/dupr/duprkit/blob/master/bin/fold
#!/bin/sh
for file in $(find $1 -type f | sort); do
echo "^ $file"
cat $file
done
[2] https://github.com/dupr/duprkit/blob/master/bin/unfold

Re: duprkit User Repository

[Mo Zhou]

Hi,

On Mon, Apr 08, 2019 at 12:37:36PM +0200, Ondřej Surý wrote:
>
> I very much dislike the idea of inventing yet another format. Your
> energy would be much better used if you rather added support for
> external tarballs to the packaging tools (with hashes, etc.) and turn
> this into DEP.

There is merely a tiny overhead in the plain text formats. Well, people
have different preferences and I still need time to see whether such
proposed formats are fine.

I found some existing problem, as what I said in the very first
paragraph of the original post. And I think I've already made the
motivation clear there. If the motivation turns to be useful enough,
why should we reject thinking about something new?
 
> Debian is not Fedora/Arch/... and whacking the debian/ into a single
> file doesn’t feel like something that would help anything at all. Just
> require git (as AUR4 does).

Debian is different from the other distros. Particularly, Debian is a
binary-based distribution. By creating such a user packaging repo, some
advantages of source-based distributions could be introduced.

And most importantly, anyone who dislike the single-file format
could just commit the debian directory to the repo, and remove
the do_unfold() hook from the header script. That's not recommended
but it still work without the single-file format. Anyway the
single-file format is only a part of the idea, and we can remove
it if most people don't like it.

Bug#926638: ITP: python-pure-sasl -- pure Python client SASL implementation

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-pure-sasl
  Version : 0.5.1
  Upstream Author : Tyler Hobbs 
* URL : https://github.com/thobbs/pure-sasl
* License : Expat
  Programming Lang: Python
  Description : pure Python client SASL implementation

 Pure-sasl is a pure python client-side SASL implementation. At the moment, it
 supports the following mechanisms: ANONYMOUS, PLAIN, EXTERNAL, CRAM-MD5,
 DIGEST-MD5, and GSSAPI. Support for other mechanisms may be added in the
 future. Only GSSAPI supports a QOP higher than auth.

Note: This is a new dependency of Kazoo, itself needed for OpenStack.

Re: duprkit User Repository

[Jonathan Carter]

On 2019/04/08 12:37, Ondřej Surý wrote:
> I very much dislike the idea of inventing yet another format. Your energy 
> would be much better used if you rather added support for external tarballs 
> to the packaging tools (with hashes, etc.) and turn this into DEP.
> 
> Debian is not Fedora/Arch/... and whacking the debian/ into a single file 
> doesn’t feel like something that would help anything at all. Just require git 
> (as AUR4 does).

Indeed. I can see why Mo would want to put it in one file, but the
Debian package format can work just fine if you work from git
repositories as you suggest, plus if it looks like a more or less usual
debian source package, then it's a smaller leap to turn it into a real
package that can graduate into making its way into Debian.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: duprkit User Repository

[Mo Zhou]

Hi,

On Mon, Apr 08, 2019 at 03:31:21PM +0500, Andrey Rahmatullin wrote:
> On Mon, Apr 08, 2019 at 09:58:26AM +, Mo Zhou wrote:
> > AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild,
> > all of them are single-file format. The advantages of single-file
> > format includes easy distribution, e.g. copying & pasting from
> > webpages (you cannot copy a directory from a webpage).
>
> This only works when you don't need patches.

The design of "duprkit" didn't forget patches at all.

There are many ways to apply apply patches:

1. Put separated patches to the Collection repository, as per the
   collection specification: https://github.com/dupr/DefaultCollection
   Then apply it manually in the header script of .durpkg .
   This is similar to what AUR does.

2. If one like, just fold the patches into the .durpkg, which may result
   in some extra lines in the .durpkg:

   ^ debian/patches/series
   foobar.patch
   ^ debian/patches/foobar.patch
   -foo bar
   +foobar

   And you may beed to change the source/format accordingly.

   The fact is, any plain file, as long as none of its lines starts with
   a single '^', could be folded into the .durpkg or the .f822 file.
   Detailed file format specification can be found in the code comments[1]

3. Fold the patches into .durpkg, but not in the quilt format.

   ^ some-working-directory/xxx.patch
   -foo bar
   +foobar

   The header script of .durpkg is able to use it.

4. may be more? ...

[1] https://github.com/dupr/duprkit/blob/master/bin/unfold

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

[Ondřej Surý]

Or DPA (Debian Personal Archive)...

Ondrej
--
Ondřej Surý 

> On 8 Apr 2019, at 12:32, Holger Levsen  wrote:
> 
> On Mon, Apr 08, 2019 at 10:18:39AM +0100, Jonathan Dowland wrote:
>>> At the first glance I interpreted the sentence as
>>> "This will only lead to flamewars"
>>> due to the meaning of bikeshed[1].
>>> 
>>> However, I got a hint from a fellow developer and learned that
>>> "Bikeshed" has its own meaning under Debian's context, according
>>> to some old mailing list fragments[2][3] -- which refers to a
>>> dak feature (This is the first time I heard of such thing).
>> This supports my (thus far) private feeling that naming this initiative
>> "Bikeshed" is a bad idea.
> 
> +1
> 
> I also think that using the name "D**ian" is a bad idea.
> 
> Just call it PPAs... millions of people know that term.
> 
> 
> -- 
> tschau,
>Holger
> 
> ---
>   holger@(debian|reproducible-builds|layer-acht).org
>   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Re: duprkit User Repository

[Ondřej Surý]

I very much dislike the idea of inventing yet another format. Your energy would 
be much better used if you rather added support for external tarballs to the 
packaging tools (with hashes, etc.) and turn this into DEP.

Debian is not Fedora/Arch/... and whacking the debian/ into a single file 
doesn’t feel like something that would help anything at all. Just require git 
(as AUR4 does).

Ondrej
--
Ondřej Surý 

> On 8 Apr 2019, at 11:58, Mo Zhou  wrote:
> 
> Hi,
> 
>> On Mon, Apr 08, 2019 at 08:54:27AM +0100, Phil Morrell wrote:
>> On Mon, Apr 08, 2019 at 05:00:21AM +, Mo Zhou wrote:
>> 
>> Obviously working implementation > perfect theoretical, but I'm confused
>> by your insistence on a single file without abstraction. Even an
>> uncompressed tarball can be cat'ed to read the contents, without
> 
> AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild,
> all of them are single-file format. The advantages of single-file
> format includes easy distribution, e.g. copying & pasting from
> webpages (you cannot copy a directory from a webpage).
> 
> The single-file format doesn't accept binary blobs since they
> are not review-able.
> 
>> requiring a custom format. With a custom format, why not hide
>> implementation details like source format in "unfold"?
> 
> Explicitness. Source code is short, and users can quickly understand
> what's happending when nothing is hidden. Besides, there is nearly
> no overhead in the "unfold" plain text format, right?
> 
>> For the DefaultCollection example, don't we have a standardised download
>> tool in debian/watch? 
> 
> Whether to use debian/watch and uscan depends on the .durpkg author.
> The nature of AUR's PKGBUILD is that, whoever use the package
> is the one who update it. Maybe this is what should be improved
> in the future but it doesn't block anything.
> 
>> Similarly, the build script is essentially a debian/rules in its 
>> construction.
>> Could you get by with a `cat debian/{watch,control,rules}`?
> 
> The header script is not really what debian/rules does. For example,
> when you are going to build some official Debian package, you may want
> to do the following:
> 
>  $ debcheckout foobar
>  $ cd foobar; gbp export-orig; debuild -S -nc
>  $ sbuild -j4 foobar.dsc
>  $ rm -rf foobar
> 
> And the header script defines things like the above commands. I changed
> the shell function name "do_build" -> "do_trigger_build", because the
> header script only defines "how to trigger the build", and the
> definition of "how to build" is still in debian/rules.
> 

Re: Seeking hardening flag / blhc expoert

[Otto Kekäläinen]

Hello!

Thanks everybody for the pointers. I fixed it now with:

Subject: [PATCH] Ensure cmake builds also apply CPPFLAGS flags for hardening
 to fully work

---
 debian/rules | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debian/rules b/debian/rules
index 3a16f8bfa..2e7536b9c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,11 @@ export DH_VERBOSE=1
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/default.mk
+# CPPFLAGS are nor read by CMake, so copy them to CXXFLAGS
+# See why at https://cmake.org/Bug/view.php?id=12928
+# This is needed for e.g. all automatic Debian hardening flags to
apply on all cmake builds.
+CFLAGS+=$(CPPFLAGS)
+CXXFLAGS+=$(CPPFLAGS)

 # Only do a strict symbol checking on Linux
 ifneq (,$(filter linux,$(DEB_HOST_ARCH_OS)))

https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/fc4f33cf40d0a10ef5d1992accd2af734ba96356

Results at:
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/154355

PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))

[Holger Levsen]

On Mon, Apr 08, 2019 at 10:18:39AM +0100, Jonathan Dowland wrote:
> > At the first glance I interpreted the sentence as
> >  "This will only lead to flamewars"
> > due to the meaning of bikeshed[1].
> > 
> > However, I got a hint from a fellow developer and learned that
> > "Bikeshed" has its own meaning under Debian's context, according
> > to some old mailing list fragments[2][3] -- which refers to a
> > dak feature (This is the first time I heard of such thing).
> This supports my (thus far) private feeling that naming this initiative
> "Bikeshed" is a bad idea.

+1

I also think that using the name "D**ian" is a bad idea.

Just call it PPAs... millions of people know that term.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Ondřej Surý]

I don’t think you need to avoid using “Debian” in the name.

This is the least problem your proposal have.

Ondrej
--
Ondřej Surý 

> On 8 Apr 2019, at 12:27, Mo Zhou  wrote:
> 
> Hi,
> 
> D**ian may be pronounced as "Dasteriskian", i.e. "D-asterisk-ian"
> (Still sounds ugly). I'm really bad at naming things, neither.
> 
> AUR is not targeted on new Archlinux users. Likewise, the D**bian
> term is not expected to cause confusion to people who really
> need to use these scripts/tools. That said, I want a better name
> too.
> 
>> On Mon, Apr 08, 2019 at 12:05:56PM +0200, W. Martin Borgert wrote:
>> Quoting Mo Zhou :
>>> As you wish, I added a disclaimer to the toolkit, and replaced every
>>> single "Debian" keyword in the repo with "D**ian", except for those
>>> in disclaimer.
>> 
>> Pardon, but replacing letters with '*' looks like Debian were a
>> swearword ("f*ck", "sh*t", ...) one likes to avoid. Also, it is
>> not a good name, because nobody knows how to pronounce it nor
>> which letters exactly were replaced. I'm bad at naming, sorry,
>> but please find something else before people get used to it :-)
> 

Re: duprkit User Repository

[Andrey Rahmatullin]

On Mon, Apr 08, 2019 at 09:58:26AM +, Mo Zhou wrote:
> AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild,
> all of them are single-file format. The advantages of single-file
> format includes easy distribution, e.g. copying & pasting from
> webpages (you cannot copy a directory from a webpage).
This only works when you don't need patches.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Mo Zhou]

Hi,

D**ian may be pronounced as "Dasteriskian", i.e. "D-asterisk-ian"
(Still sounds ugly). I'm really bad at naming things, neither.

AUR is not targeted on new Archlinux users. Likewise, the D**bian
term is not expected to cause confusion to people who really
need to use these scripts/tools. That said, I want a better name
too.

On Mon, Apr 08, 2019 at 12:05:56PM +0200, W. Martin Borgert wrote:
> Quoting Mo Zhou :
> > As you wish, I added a disclaimer to the toolkit, and replaced every
> > single "Debian" keyword in the repo with "D**ian", except for those
> > in disclaimer.
> 
> Pardon, but replacing letters with '*' looks like Debian were a
> swearword ("f*ck", "sh*t", ...) one likes to avoid. Also, it is
> not a good name, because nobody knows how to pronounce it nor
> which letters exactly were replaced. I'm bad at naming, sorry,
> but please find something else before people get used to it :-)

Re: Bug#926229: New QoS defaults break systems running on VMWare

[Colin Watson]

On Tue, Apr 02, 2019 at 12:32:52PM +0100, Colin Watson wrote:
> If it were just the VMware issue, then my inclination would be to leave
> OpenSSH as it is: it's proprietary software and the only leverage we
> have to get them to fix it is to have their customers complaining.

A VMware employee popped up on
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370 and
reports that this has been fixed in as-yet-unreleased versions of VMware
Workstation and Fusion.

> However, the iptables issue in #923879 seems thornier and it's outside
> my field of expertise.
> 
> I'm slightly leaning towards reverting this on a temporary basis for
> buster, but CCing debian-devel: does anyone have opinions on this?

After a bit of private conversation about this and due to the lack of
movement on the iptables bug, I'm indeed going to revert this on a
temporary basis for buster, and review later.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Mo Zhou]

On Mon, Apr 08, 2019 at 03:46:15PM +0800, Paul Wise wrote:
> On Mon, Apr 8, 2019 at 3:34 PM Mo Zhou wrote:
> 
> > However, the translator itself is not trivial, as it might need
> > it's own shell parser or something alike to be reliable enough.
> 
> Couldn't you just run makepkg (with some hooks) and dpkg-deb to
> convert the results to Debian packages?

Worth a try. I'll dig into this on the weekend.
The enhancement is tracked here:
https://github.com/dupr/duprkit/issues/1

Re: duprkit User Repository

[Mo Zhou]

Hi,

On Mon, Apr 08, 2019 at 08:54:27AM +0100, Phil Morrell wrote:
> On Mon, Apr 08, 2019 at 05:00:21AM +, Mo Zhou wrote:
> 
> Obviously working implementation > perfect theoretical, but I'm confused
> by your insistence on a single file without abstraction. Even an
> uncompressed tarball can be cat'ed to read the contents, without

AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild,
all of them are single-file format. The advantages of single-file
format includes easy distribution, e.g. copying & pasting from
webpages (you cannot copy a directory from a webpage).

The single-file format doesn't accept binary blobs since they
are not review-able.

> requiring a custom format. With a custom format, why not hide
> implementation details like source format in "unfold"?

Explicitness. Source code is short, and users can quickly understand
what's happending when nothing is hidden. Besides, there is nearly
no overhead in the "unfold" plain text format, right?
 
> For the DefaultCollection example, don't we have a standardised download
> tool in debian/watch? 

Whether to use debian/watch and uscan depends on the .durpkg author.
The nature of AUR's PKGBUILD is that, whoever use the package
is the one who update it. Maybe this is what should be improved
in the future but it doesn't block anything.

> Similarly, the build script is essentially a debian/rules in its construction.
> Could you get by with a `cat debian/{watch,control,rules}`?

The header script is not really what debian/rules does. For example,
when you are going to build some official Debian package, you may want
to do the following:

  $ debcheckout foobar
  $ cd foobar; gbp export-orig; debuild -S -nc
  $ sbuild -j4 foobar.dsc
  $ rm -rf foobar

And the header script defines things like the above commands. I changed
the shell function name "do_build" -> "do_trigger_build", because the
header script only defines "how to trigger the build", and the
definition of "how to build" is still in debian/rules.

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Jonathan Dowland]

On Sun, Apr 07, 2019 at 02:17:00PM +, Mo Zhou wrote:

This single sentence is quite ambiguous to non-native english speakers.

At the first glance I interpreted the sentence as
 "This will only lead to flamewars"
due to the meaning of bikeshed[1].

However, I got a hint from a fellow developer and learned that
"Bikeshed" has its own meaning under Debian's context, according
to some old mailing list fragments[2][3] -- which refers to a
dak feature (This is the first time I heard of such thing).


This supports my (thus far) private feeling that naming this initiative
"Bikeshed" is a bad idea.

--

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

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Ole Streicher]

Paul Wise  writes:
> On Sun, Apr 7, 2019 at 10:14 PM Peter Silva  wrote:
>> We would love to be able to upstream to debian, but haven't figured it out
>
> The process is pretty simple, but reliant on the limited number of
> Debian members who do package sponsorship. The ones we do have are
> fairly active though. The process is essentially; fix any quality
> issues, upload source packages to mentors.d.n, file a request for
> sponsor and reply to any responses you get.

For some fields, there are also additional possibilities: If you put
your packages into a Debian Pure Blend (like Debian Science, or Debian
Astro) and follow their rules, chances are big that someone from there
does the mentorship rather quickly.

Best

Ole

Re: duprkit User Repository

[Phil Morrell]

On Mon, Apr 08, 2019 at 05:00:21AM +, Mo Zhou wrote:
> Plus, it's super important to write every packaging bit into a single
> file. That would enable simple copy&pasting from github or any other
> resources. If you provide a directory, things will become more
> complicated. More impotantly, the proposed single file specification
> virtually adds NO overhead.

Obviously working implementation > perfect theoretical, but I'm confused
by your insistence on a single file without abstraction. Even an
uncompressed tarball can be cat'ed to read the contents, without
requiring a custom format. With a custom format, why not hide
implementation details like source format in "unfold"?

For the DefaultCollection example, don't we have a standardised download
tool in debian/watch? Similarly, the build script is essentially a
debian/rules in its construction. Could you get by with a `cat
debian/{watch,control,rules}`?
--
Phil Morrell


signature.asc
Description: PGP signature

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Paul Wise]

On Mon, Apr 8, 2019 at 3:34 PM Mo Zhou wrote:

> However, the translator itself is not trivial, as it might need
> it's own shell parser or something alike to be reliable enough.

Couldn't you just run makepkg (with some hooks) and dpkg-deb to
convert the results to Debian packages?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Mo Zhou]

Hi Paul,

I've ever thought about a PKGBUILD->Deb translator, and in this
way we can directly reuse all existing code in AUR without change.

However, the translator itself is not trivial, as it might need
it's own shell parser or something alike to be reliable enough.

The current (virtually) zero-overhead naive prototype, still allows the
reuse of existing debian packaging scripts and documentations.
Plus, letting users write PKGBUILD doesn't help them learn
Debian packaging at all...

On Mon, Apr 08, 2019 at 03:29:12PM +0800, Paul Wise wrote:
> On Sun, Apr 7, 2019 at 9:26 PM Mo Zhou wrote:
> 
> > Such idea about informal packaging repository has been
> > demonstrated successful by the Archlinux User Repository (AUR).
> > Hence, it should be valuable to think about it for Debian.
> 
> Seems like a PKGBUILD-to-deb script would be a simple way to do this
> and would also allow leveraging the existing PKGBUILD archive that is
> AUR and prevent splitting the community of people who make informal
> packaging.
> 
> In 2007 there was something similar for Gentoo ebuilds:
> 
> http://penta.debconf.org/dc7_schedule/events/69.en.html
> https://www.youtube.com/watch?v=Hy9ugWUuNBM
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Paul Wise]

On Sun, Apr 7, 2019 at 9:26 PM Mo Zhou wrote:

> Such idea about informal packaging repository has been
> demonstrated successful by the Archlinux User Repository (AUR).
> Hence, it should be valuable to think about it for Debian.

Seems like a PKGBUILD-to-deb script would be a simple way to do this
and would also allow leveraging the existing PKGBUILD archive that is
AUR and prevent splitting the community of people who make informal
packaging.

In 2007 there was something similar for Gentoo ebuilds:

http://penta.debconf.org/dc7_schedule/events/69.en.html
https://www.youtube.com/watch?v=Hy9ugWUuNBM

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

[Paul Wise]

On Sun, Apr 7, 2019 at 10:14 PM Peter Silva  wrote:

> We would love to be able to upstream to debian, but haven't figured it out

The process is pretty simple, but reliant on the limited number of
Debian members who do package sponsorship. The ones we do have are
fairly active though. The process is essentially; fix any quality
issues, upload source packages to mentors.d.n, file a request for
sponsor and reply to any responses you get.

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise