Bug#1078798: ITP: node-webpack-stream -- Run webpack as a stream

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: Bastien Roucariès 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: node-webpack-stream
  Version : 7.0.0
  Upstream Contact: https://github.com/shama
* URL : https://github.com/shama/webpack-stream
* License : Expat
  Programming Lang: javascript
  Description : Run webpack as a stream

Run webpack as a NodeJS stream to conveniently integrate with gulp.

This package is a build tool needed for building other tools

Need to package in order to avoid circular deps


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

Re: RFC: Sensible-editor sensible-utils alternative and update

[Bastien Roucariès]

Le lundi 12 août 2024, 21:05:17 UTC Richard Lewis a écrit :
> Bastien Roucariès  writes:
> 
> >> b) but if im in a terminal (even if running in gnome) then i want a
> >>  terminal-based editor (based on what i installed)
> >
> > depends for me I prefer to run under emacsclient so you could do
> > something like
> > SENSIBLE_EDITOR='if [ -t 0 ]; then sensible-editor-GNOME ; else
> > sensible-editor-tty; fi;'
> 
> Couldnt i already put that it in ~/bin/editor and set
> EDITOR to that script?
Yes but it does not change the need that the editor called should block and be 
more like ex or vi

BTW it is better on debian system to set both EDITOR and SENSIBLE_EDITOR to 
~/bin/editor  in this case

Bastien
> 
> 
> 
> 



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

Re: RFC: Sensible-editor sensible-utils alternative and update

[Bastien Roucariès]

Le lundi 12 août 2024, 16:04:30 UTC Simon McVittie a écrit :
> On Mon, 12 Aug 2024 at 08:44:51 -0700, Russ Allbery wrote:
> > What this is telling me is that ideally someone should tighten the
> > definition of EDITOR in Policy 11.4, which is the specification satisfied
> > by sensible-editor, to make it clear that GUI editors with these sorts of
> > properties are not valid things to set EDITOR to point to unless flags are
> > present to make them behave in a way that satisfies the expectations of
> > programs that use EDITOR.
> 
> I agree. A backgrounding editor like `gvim` shouldn't be considered to be
> a suitable EDITOR (but `gvim -f` would be).

Yes and wrapper sensible-editor-gvim will do for you


> 
> Many other GUI editors behave like `gvim` and not like `gvim -f`, so they
> are also perfectly reasonable text editors in general, but not suitable
> to be the value of EDITOR; and I suspect quite a lot of GUI editors have
> no equivalent of gvim's -f option at all.

I have checked quite a few have some flag to do the intended behavior

> 
> The Desktop Entry and MIME Apps specifications leave it unspecified which
> way a MIME handler will behave, so anything that is an implementation
> of those specifications (like `xdg-open` or `gio open`) is not suitable
> as an EDITOR either, because the caller can't know whether the resulting
> application is going to wait or not.
> 
> > I think the
> > Policy language was written in a time where we just assumed there was an
> > obvious way for editors to behave that didn't include things like
> > backgrounding themselves.
> 
> Yes, I think so. Not backgrounding makes a lot of sense for a
> line-oriented editor (ed, ex) or a TUI editor (nano, vi) which will
> typically occupy the terminal[1] and prevent it from being used for other
> purposes *anyway*, but is a lot less obviously desirable for a GUI
> editor that will appear elsewhere in a windowing system and can be used
> in parallel with the terminal.

Yes

Bastien
> 
> smcv
> 
> [1] yes I know about screen(1) and similar, but interacting with those
> would require special setup that a typical TUI editor doesn't do
> 
> 



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

Re: RFC: Sensible-editor sensible-utils alternative and update

[Bastien Roucariès]

Le lundi 12 août 2024, 15:44:51 UTC Russ Allbery a écrit :
> Simon McVittie  writes:
> 
> > The approach to this that will work consistently is to launch the
> > handler asynchronously (in the background), and not attempt to find out
> > whether it has exited or not. So for example an interactive shell script
> > might do something like this:
> 
> > #!/bin/bash
> > # note that disown is a bashism
> 
> > xdg-open "$document" &
> > disown $!
> > echo "Press Enter when you have finished editing $document..."
> > read
> 
> What this is telling me is that ideally someone should tighten the
> definition of EDITOR in Policy 11.4, which is the specification satisfied
> by sensible-editor, to make it clear that GUI editors with these sorts of
> properties are not valid things to set EDITOR to point to unless flags are
> present to make them behave in a way that satisfies the expectations of
> programs that use EDITOR.

Yes and what why I ask to add sensible-editor wrapper. At least it will do 
something
sensible and it is optional

Bastien
> 
> I don't have any strong opinion on the merits of trying to figure out how
> to invoke the editor with the proper flags to make it follow the
> expectations of EDITOR if EDITOR is not set, but we do need to be careful
> to not invoke programs that would cause, e.g., git commit --amend to
> immediately exit with no changes to the commit message, and to do that we
> probably need to write down what those expectations are.  I think the
> Policy language was written in a time where we just assumed there was an
> obvious way for editors to behave that didn't include things like
> backgrounding themselves.
> 
> 



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

Re: RFC: Sensible-editor sensible-utils alternative and update

[Bastien Roucariès]

Le lundi 12 août 2024, 15:17:00 UTC Simon McVittie a écrit :
> On Mon, 12 Aug 2024 at 14:23:51 +0000, Bastien Roucariès wrote:
> > Yes I want sensible-editor to open kate on kde and gnome-editor on gnome.
> > 
> > Thinks about running latex and typing e for editing, it should run the 
> > desktop editor of choice.
> > 
> > I do not want to change desktop user choice
> 
> This use-case doesn't need a Debian-specific mechanism, because there
> are already many implementations of the Desktop Entry and MIME App
> specifications, such as:
> 
> xdg-open "$document"# from xdg-utils
> gio open "$document"# from libglib2.0-bin
> 
> or, ideally, calling into a library in your implementation language
> that implements those specifications without needing a CLI layer
> in between. (For example `gio open` is basically a CLI wrapper
> around g_app_info_launch_default_for_uri_async(), so in C code that
> already depends on GLib for some other reason, it's better to call
> g_app_info_launch_default_for_uri_async() directly.)

Yes it will work but legacy code exist and run EDITOR therefore sensible-editor 
is here...

SENSIBLE_EDITOR="xdg-open" will work 

> 
> One limitation of this (which is unsolvable in anything based on .desktop
> files) is that it's considered equally valid for the handler to daemonize,
> run in the background and exit immediately (like `gvim $file`), or to
> run "in the foreground" until the user exits, and then exit (like
> `gvim -f $file`). So you can't rely on using something like this if
> you want your process to block until the user has saved the file and
> exited. But that isn't something you can rely on from GUI editors anyway,
> because not all GUI editors even have that as a concept - some are
> "single-instance" and expect to open all files in one instance of the
> editor app.
> 
> The approach to this that will work consistently is to launch the handler
> asynchronously (in the background), and not attempt to find out whether
> it has exited or not. So for example an interactive shell script might
> do something like this:
> 
> #!/bin/bash
> # note that disown is a bashism
> 
> xdg-open "$document" &
> disown $!
> echo "Press Enter when you have finished editing $document..."
> read

Yes so If I do EDITOR= xdg-open" git commit it give some interesting result

note that EDITOR="kate -b" git commit will work


> > I have other problem with unsupported terminal that fail... Even nano does 
> > not
> > fail gracefully on some terminal (try dumb terminal)
> 
> Yes, running a text editor in an environment that is not supported by
> that text editor will not work. I don't see why that would be unexpected.
> 
> > kate does not fallback nicely to other editor on linux console for instance.
> 
> No: falling back from the implementation of some class of application
> that you asked for to a different implementation is not behaviour that
> I would expect. If you run a GUI file manager like Nautilus or Dolphin
> from a Linux virtual console, it doesn't try to "do what you mean"
> and run mc instead. Text editors are no different.

It is the spec of sensible editor fallback gracefully...

Bastien
> 
> smcv
> 



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

Re: RFC: Sensible-editor sensible-utils alternative and update

[Bastien Roucariès]

Le lundi 12 août 2024, 12:52:43 UTC Simon McVittie a écrit :
> On Mon, 12 Aug 2024 at 12:36:37 +0100, Richard Lewis wrote:
> > Bastien Roucariès  writes:
> > > Sensible-editor could now use EDITOR="emacsclient -n -c" and accept
> > > that sh -c accept
> > >
> > > My goal is to create a sensible-editor.desktop that will lauch by
> > > default the sensible-editor of choice
> 
> Echoing what Richard asked: what problem are you aiming to solve with
> this? I think designs need to start by stating the problem that they
> are solving, instead of jumping directly to a solution.
> 
> The way to open any existing file, in a GUI environment, is to look
> up the preferred handler for the MIME type of the file (which might
> be text/plain or might be something else), and then launch it. This is
> equally true for text files and non-text files.
> 
> This is a general mechanism across all Linux distributions (and other
> Unixes such as *BSD), using the freedesktop.org Desktop Entry and
> MIME Apps specifications:
> <https://specifications.freedesktop.org/desktop-entry-spec/latest/>,
> <https://specifications.freedesktop.org/mime-apps-spec/latest/>.
> 
> This is also not specific to text files, and doesn't require creating
> one .desktop file per desktop environment per file type (which would
> scale poorly); it's a generic mechanism that can work for any MIME type,
> and includes a concept of fallbacks like "prefer gnome-text-editor if
> installed, or try gedit as a second preference, or fall back to any
> other editor".
> 
> If there's a use-case for which these are insufficient, please talk to
> these specifications' upstreams and get consensus on an improvement that
> can be adopted upstream by everything that participates in the MIME apps
> spec (GLib, Qt, xdg-open, ...), instead of inventing a Debian-specific
> mechanism that we would have to patch into various packages against
> upstreams' objections.
> 
> > a) opening a file with the mouse should use gnome's default (which can
> >  change in settings)
> 
> One important point here is that if you have (for example) both GNOME and
> KDE Plasma installed on the same machine, and you have not customized
> settings, then clicking on a text file in a GNOME session will open it in
> GNOME's default text editor, but clicking on the same text file in a
> Plasma session will open it in KDE's default text editor.
> 
> This is a desirable feature, particularly for shared machines (for example
> Gerald and Karen share a computer, Gerald prefers to use GNOME, Karen
> prefers to use KDE, and by default they should both get an editor whose
> appearance and behaviour matches their preferred desktop environment).

Yes I want sensible-editor to open kate on kde and gnome-editor on gnome.

Thinks about running latex and typing e for editing, it should run the desktop 
editor of choice.

I do not want to change desktop user choice

> 
> > > I will also like to allow sensible-editor-STUFF to support +4:3 FILE
> > > command line, so
> > > editor +4:3 somefile.txt will open somefile.txt and if possible go to
> > > line 4 column 3 (and silently ignore if not possible)
> > 
> > sounds great (and separate to the above), although i wonder how you will
> > tell whether the underlying editor supports it.
> 
> This convention is somewhat common in (mainly older) CLI-focused,
> programmer-oriented text editors, but rare in GUI editors, and I'm not
> aware of any way to discover programmatically whether a particular editor
> supports that syntax. In editors that don't support that syntax, the result
> is not "silently ignore": instead, the most likely result is a confusing
> erorr message about being unable to open a file named "+4:3".

Yes that why I ask for creating shell wrapper.
kate for instance could open line column if you pass --line --column 

I have other problem with unsupported terminal that fail... Even nano does not
fail gracefully on some terminal (try dumb terminal)

kate does not fallback nicely to other editor on linux console for instance.
Try it. kate for instance return 0
gedit block

> 
> We shouldn't adopt new features for the benefit of "power users" if they
> come at the expense of making it appear to less experienced users that
> the overall system is broken, because first impressions matter.
> 
> In principle it would be possible to *define* a way to discover whether
> an editor supports that syntax - for instance defining a new field in
> .desktop files, with the default being "assume it's unsupported" - but
> if that's done, it should be do

Re: RFC: Sensible-editor sensible-utils alternative and update

[Bastien Roucariès]

Le lundi 12 août 2024, 11:36:37 UTC Richard Lewis a écrit :
> Bastien Roucariès  writes:
> 
> > Sensible-editor could now use EDITOR="emacsclient -n -c" and accept
> > that sh -c accept
> >
> > My goal is to create a sensible-editor.desktop that will lauch by
> > default the sensible-editor of choice
> >
> > For this I plan:
> > - to allow by alternative mechanism to have an sensible-editor-tty
> > (may be better wording) sensible-editor-$XDG_CURRENT_DESKTOP
> > in order to allow default customization
> > - SENSIBLE_EDITOR is not set, sensible-editor will first try
> > sensible-editor-$XDG_CURRENT_DESKTOP XDG_CURRENT_DESKTOP (if
> > $XDG_CURRENT_DESKTOP
> > is set) then  sensible-editor-tty (using if needed sensible-terminal)
> >
> 
> Can you set out how this affects users
> 
> If i am using gnome, i want something pretty simple
> 
> a) opening a file with the mouse should use gnome's default (which can
>  change in settings)

No change except if you associate to sensible-editor
> 
> b) but if im in a terminal (even if running in gnome) then i want a
>  terminal-based editor (based on what i installed)

depends for me I prefer to run under emacsclient so you could do something like
SENSIBLE_EDITOR='if [ -t 0 ]; then sensible-editor-GNOME ; else 
sensible-editor-tty; fi;'

For now I have some gui program that try to run editor from gui and fail, 
because you should attach a console.

> 
> (b) also means no failures if i get a dpkg "edit conffile" situation
> while upgrading -- graphical editors may fail to start, or i might be on
> the linux console when dist-upgrading.

Yes and sensible editor will try fallback, I do for now for nano that fail on 
DUMP terminal, and I have also corner case with other editor
so I should write wrapper...

>  
> 
> i think this all works great today, will it still work with your
> proposal?  what extra cases are you proposing to support?

do not fail to run sensible-editor from a GUI, and if run a console of choice 
before with the editor on it.
 
> > I will also like to allow sensible-editor-STUFF to support +4:3 FILE
> > command line, so
> > editor +4:3 somefile.txt will open somefile.txt and if possible go to
> > line 4 column 3 (and silently ignore if not possible)
> >
> 
> sounds great (and separate to the above), although i wonder how you will
> tell whether the underlying editor supports it.

Yes that why I propose wrapper

editor in a POSIX sense is a wrapper against vi. minimal command line is 
documented for ex.

It could only open one file passed as last argument

so for me editor is
editor [file]

I only propose to add

editor [+line[:column]] [file] for the wrapper

bastien

> 
> 
> 



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

RFC: Sensible-editor sensible-utils alternative and update

[Bastien Roucariès]

Hi

Sensible-editor could now use EDITOR="emacsclient -n -c" and accept that sh -c 
accept

My goal is to create a sensible-editor.desktop that will lauch by default the 
sensible-editor of choice

For this I plan:
- to allow by alternative mechanism to have an sensible-editor-tty (may be 
better wording) sensible-editor-$XDG_CURRENT_DESKTOP
in order to allow default customization
- SENSIBLE_EDITOR is not set, sensible-editor will first try 
sensible-editor-$XDG_CURRENT_DESKTOP XDG_CURRENT_DESKTOP (if 
$XDG_CURRENT_DESKTOP
is set) then  sensible-editor-tty (using if needed sensible-terminal)

I will also like to allow sensible-editor-STUFF to support +4:3 FILE command 
line, so
editor +4:3 somefile.txt will open somefile.txt and if possible go to line 4 
column 3 (and silently ignore if not possible)

Any comments ?

rouca

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

Re: lintian.debian.org off ?

[Bastien Roucariès]

Le vendredi 9 août 2024, 12:08:29 UTC Lucas Nussbaum a écrit :
> On 09/08/24 at 07:54 +0000, Bastien Roucariès wrote:
> > Le vendredi 9 août 2024, 06:39:04 UTC Lucas Nussbaum a écrit :
> > > On 08/08/24 at 18:40 +, Bastien Roucariès wrote:
> > > > > > It is not meant to replace the corresponding UDD link, in fact I 
> > > > > > added a link to it in the page of each tag, to see all the affected 
> > > > > > packages. But I think it is better to first arrive on a very fast 
> > > > > > to load page that simply explains the tag, and then be able to 
> > > > > > follow a link to see the list of affected packages.
> > > > 
> > > > What will be wonderfull is to retrieve number of package affected and 
> > > > do a svg graph along time... Using a static script
> > > 
> > > Hi Bastien,
> > > 
> > > Are you aware of https://trends.debian.net/ ?
> > No but the same with every tag will be really really nice
> 
> The raw data used by trends.d.n is not publicly available (mainly
> because it's a bit too large). By if you are interested in specific
> tags, I can probably look into extending trends.d.n to cover those tags.

Yes

- source-is-missing
- source-include*

And all ftp reject tags


> Note that trends.d.n works by running a given lintian version over all
> packages (fetched from snapshot.d.o), not by running lintian on a
> regular basis, because when lintian changes, the list of generated tags
> also changes.

We have here a mapping of renamed tag in a file in order to ease this kind of 
stuff.

If you could put vertical bar every lintian version change, it will give clue 
about breaking series

Bastien
> 
> Lucas
> 



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

Re: lintian.debian.org off ?

[Bastien Roucariès]

Le vendredi 9 août 2024, 06:39:04 UTC Lucas Nussbaum a écrit :
> On 08/08/24 at 18:40 +0000, Bastien Roucariès wrote:
> > > > It is not meant to replace the corresponding UDD link, in fact I added 
> > > > a link to it in the page of each tag, to see all the affected packages. 
> > > > But I think it is better to first arrive on a very fast to load page 
> > > > that simply explains the tag, and then be able to follow a link to see 
> > > > the list of affected packages.
> > 
> > What will be wonderfull is to retrieve number of package affected and do a 
> > svg graph along time... Using a static script
> 
> Hi Bastien,
> 
> Are you aware of https://trends.debian.net/ ?
No but the same with every tag will be really really nice

It is a really nice tool
> 
> Best,
> 
> Lucas
> 



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

Re: lintian.debian.org off ?

[Bastien Roucariès]

Le mercredi 7 août 2024, 17:05:01 UTC Nicolas Peugnet a écrit :
> Hi all,
> 
> Pierre-Elliott Bécue  on Wed, 27 Sep 2023 14:19:20:
> > Otto Kekäläinen  wrote on 27/09/2023 at 06:35:07+0200:
> > 
> >> Hi!
> >>
> >> Thanks for the context - so there is no need technical incompatibility
> >> at play, but mostly a matter of having resources and time to do it.
> >> ..
> >>> Regarding the 301 redirection I'll see with the interested parties (DSA
> >>> and Lintian maintainers) if this option is fine with everyone.
> >>
> >> I could easily write Ansible code to maintain a simple Nginx server,
> >> with 302 redirects https://lintian.debian.org/tags/(.*)/?$ ->
> >> https://udd.debian.org/lintian-tag.cgi?tag=$1, use same Ansible style
> >> as salsa.debian.org is maintained on
> >> (https://salsa.debian.org/salsa/salsa-ansible), and also donate a tiny
> >> virtual machine for Debian project if needed. Is there some special
> >> bureaucracy on top of that work to do to be able to contribute with
> >> this?
> > 
> > Don't worry, the server still exists, it's just down, and reputting the
> > DNS takes little to no time.
> > 
> > Regarding apache config, I'm fine with doing it. It's a matter of
> > checking with everyone that we want to do that as the plan was nuking
> > the server from orbit.
> > 
> > Providing debian.org infrastructure requires to be a member of the
> > Debian System Administrators (DSA) team, which in turn requires to be a
> > Debian Developer, so, sadly, you can't really help on that part.
> > 
> > That being said, thank you for offering your time.
> 
> I sent the following email in reply to Bug#1042428 but I didn't see it 
> was archived, so I repost it here:
> 
> > As I just recently started making Debian packages, I clicked multiple times 
> > on links to  that led me to a dead end, for 
> > instance from mentors.debian.org, or on the hyperlinks that lintian itself 
> > produce in the terminal output. It was not a very pleasant experience, 
> > especially for a newbie.
> > 
> > In my opinion, redirecting lintian.debian.org to the UDD links posted above 
> > is not a good option, because as I understand it, they only were intended 
> > to show the extended explanation for each tag. Having the list of all the 
> > affected packages in this page it not helpful, and it makes the pages very 
> > slow to load (and to produce).
> > 
> > So instead I thought that it would be quite easy to generate a static 
> > website that would be very fast to generate once, and then to serve and 
> > load. So I made my own implementation that generates a website that could 
> > be directly uploaded to lintian.debian.org, as it follows strictly the 
> > previous URL structure (I also added the manual of lintian as I also 
> > stumbled on links to it).
> > 
> > For now I hosted it on my server so you can see the result there:
> > 
> >   
> > 
> > For instance the link above translates to:
> > 
> >   
> > 
> > 
> > And here are the sources:
> > 
> >   
> > 
> > It is not meant to replace the corresponding UDD link, in fact I added a 
> > link to it in the page of each tag, to see all the affected packages. But I 
> > think it is better to first arrive on a very fast to load page that simply 
> > explains the tag, and then be able to follow a link to see the list of 
> > affected packages.

What will be wonderfull is to retrieve number of package affected and do a svg 
graph along time... Using a static script

nicolas did you contact the the infrasture team ?

Bastien
> > 
> > Please telle me what you think about it and if you think it can be uploaded 
> > to lintian.debian.org? 
> 
> In the meantime I added some features and hosted it on its own domain to 
> make the custom 404 page work correctly: . 
> So, do you think it could be used to make the lintian.debian.org website 
> back up?
> 
> P.S. I'm not subscribed to this list, so please CC me.
> 
> Regards
> 



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

Bug#1077769: ITP: node-path-scurry -- Fast and cached directory traversal for javascript building tool

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: Bastien Roucariès 
X-Debbugs-Cc: debian-devel@lists.debian.org

 Package name: node-path-scurry
 Version : 1.9.2
 Upstream Contact: ttps://github.com/isaacs/path-scurry#readme
 URL : https://www.example.org/
 License : BlueOak-1.0.0
 Programming Lang: typescript
 Description : Fast and cached directory traversal for javascript building
tool

Extremely high performant utility for building tools that read
 the file system, minimizing filesystem and path string munging
 operations to the greatest degree possible, using cache as long
 as possible.
 .
 Cache as long as possible" approach means that changes to the
 filesystem may not be reflected in the results of repeated
 PathScurry operations.

This is needed for typescript compiler tshy, used by some other projet like npm

maint with js team


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

Re: Pause /usr-merge moves

[Bastien Roucariès]

Le vendredi 1 décembre 2023, 21:04:12 UTC Helmut Grohne a écrit :
> Hi developers,
> 
> I have unfortunate news regarding /usr-merge. I uncovered yet another
> problem that we haven't seen mentioned earlier. We do not yet know how
> to deal with it and it may take some time to come up with a good
> compromise. As a result, please pause further moves from / to /usr.
> Exceptions:
>  * With more uploads, more systemd units will move. While such moves may
>trigger the new problem, I expect that to be rare.
>  * Continue fixing RC bugs, in particular those that are due to
>dh_installsystemd or systemd.pc having moved to /usr.
>  * Continue applying DEP17P7 mitigations for udev rules. Patches for
>these have been sent by Christian Hofstaedler and a few people from
>the Cambridge miniconf. These are unrelated.
> 
> The rest of this mail is lots of funky details for those interested in
> understanding what went wrong here. Others are encouraged to do
> something more joyful :)
> 
> Before we go, let me express sincere thanks to so many people that
> helped me track this down. In particular, the input of David
> Kalnischkies, Guillem Jover and Julian Andres Klode was invaluable.
> 
> Fundamentally, Conflicts do not reliably prevent concurrent unpacking of
> packages as policy §7.4 may suggest. I have reported this as #1057199.
> Consequently, what we look at here is situations where Conflicts are
> used to mitigate file loss in the face of aliasing changes. Debian
> policy §6.6 is more precise and details that when unpacking a package,
> conflicting packages may be deconfigured and removed after the unpack.
> In theory, the difference should not be noticeable, because dpkg
> accurately tracks ownership of files with respect to packages. Aliasing
> changes this and can cause file loss. The situation arises when
> installing or upgrading a package to a version that happens to be in
> conflict with another package to be removed. A simple example is
> upgrading a bookworm system with molly-guard and systemd-sysv to sid and
> in the process deleting molly-guard. A similar issue happens when
> upgrading a bookworm system with busybox-static to sid and in that
> process installing busybox and thus removing busybox-static. The
> situation is hard to come by, because apt tends to remove the package
> that goes away early when it can. I have implemented a reproducer
> without apt for systemd-sysv #1057220. There are also situations where
> apt reproduces this available from the policy bug mentioned earlier. In
> particular, when one package has versioned Conflicts for another and the
> other has versioned Breaks for the former, this reproduces with apt.
> This essentially breaks DEP17 proposed mitigations M7 and M18.
> 
> I have also locally extended dumat to produce a report of affected
> Conflicts and am attaching it to this mail. The only packages that have
> not yet migrated and have this problem are systemd-sysv,
> busybox/busybox-static and resolvconf and I have filed RC bugs for them.
> There are other instances in trixie already.

Could we have a list of trixie affected ?
> 
> I welcome ideas for solving these problems. Let me summarize those I
> already am aware of.
> 
> Julian Andres Klode proposes adding a "barrier package" that we may call
> usrmerge-support (or repurpose usr-is-merged). Affected Conflicts can be
> moved to the barrier package and the conflicting package would then
> express Pre-Depends on the barrier package. When the barrier's postinst
> runs, any conflicting package definitely has been removed and due to
> using Pre-Depends, the conflicting package definitely has not been
> unpacked yet.

Why not creating per package a barrier package ?


> 
> Another option is duplicating affected files (e.g. using hard links) in
> the data.tar and then restoring lost files during postinst.
> 
> Depending on what problem we are solving, we may also move to protective
> diversions (DEP17 M8).
> 
> It also is not clear how easy it is to reproduce this bug class in an
> actual upgrade. It took long to find the issue for a reason. Depending
> on what files go missing, we may get away with asking users to dpkg
> --audit and then apt reinstall affected packages.
> 
> That barrier package approach sounds relatively promising to me, but
> there is no implementation of that approach as of this writing.
> 
> If you want to support finding a solution, please contribute to this
> email thread of join #debian-usrmerge on oftc.
> 
> Helmut
> 

Bug#1055585: ITP: node-envinfo -- Generate reports of the common details used by Node.js packages

[Bastien Roucariès]

Package: wnpp
Severity: important
Owner: Bastien Roucariès 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: node-envinfo
  Version : 7.11.0+~cs13.4.1
  Upstream Contact: https://github.com/tabrindle/envinfo#readme
https://github.com/sindresorhus/os-name/tags
https://github.com/sindresorhus/macos-release/tags
https://github.com/sindresorhus/windows-release/tags
https://registry.npmjs.org/yamlify-object
* URL : https://github.com/tabrindle/envinfo#readme
https://github.com/sindresorhus/os-name/tags
https://github.com/sindresorhus/macos-release/tags
https://github.com/sindresorhus/windows-release/tags
https://registry.npmjs.org/yamlify-object
* License : Expat
  Programming Lang: Typescript/javascript
  Description : Generate reports of the common details used by Node.js
packages

Generate reports of the common details used by Node.js packages
 This package generate reports of common software installed on our computer,
 including browser version, Node.js version, Operating System and programming
 language support.
 .
 This is used by webpack a javascript module bundler, for generating build
 time report.
 .
 Node.js is an event-based server-side JavaScript engine.

This package is needed for rebuild from source webpack that is an essential
package of javascript team

Re: HFS/HFS+ are insecure

[Bastien Roucariès]

Le vendredi 21 juillet 2023, 10:28:00 UTC Bastien Roucariès a écrit :
> Le vendredi 21 juillet 2023, 10:17:13 UTC Marco d'Itri a écrit :
> > On Jul 21, Bastien Roucariès  wrote:
> > 
> > > Ok found it call mountlo outdated 
> > > will need a small patch for linux uml, but may be worthwhile
> > > Last version seems to be outdated 0.6 and carried by slitaz distribution.
> > > May be time to revive it
> > It looks like a good long term solution, but as long as there are 
> > insecure file systems in the kernel they should be disabled by default 
> > so these are really different issues.
> 
> No it is not a long term solution. Long term solution will be to push under 
> fuse these filesystem. This a (short term)/(medium term band aid) solution.
> 
> I agree with you about disabling these modules
> 
> linux uml work on i386/amd64/ppc (by memory) so it could help for some 
> filesystem particularly hfs
> 
> I do not understand why uml is not part of main kernel build maybe it is time 
> to get it.
> 
> The plan could be:
> - build uml along the main kernel (if possible)
> - try to get merged old mountlo kernel support
> - push to uml only these insecure filesystem
> - long term try to push these to pure userspace or drop

According to the other thread only these fs should be supported using this 
method:
- hfs (not hfs+) but pure user space tools exist
-sysv
-affs
-ecryptfs
- jffs2
- jfs
- bfs
- reiserfs

Rouca

> 
> What do you think ?
> 
> rouca
> 
> > 
> > I remember noise from the systemd people about mounting removable media 
> > using user space drivers, but I do not think that anybody is working on 
> > this.
> > 
> > 
> 
> 



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

Re: HFS/HFS+ are insecure

[Bastien Roucariès]

Le vendredi 21 juillet 2023, 10:52:17 UTC Bastien Roucariès a écrit :
> Le vendredi 21 juillet 2023, 08:55:39 UTC Marco d'Itri a écrit :
> > efs
> https://pypi.org/project/qnxmount/ claim to mount it. Check
> > hfs
> https://github.com/0x09/hfsfuse
Corrected not supported by this package may be emulated by using user space hfs 
tools ?
> > hfaplus
> https://github.com/0x09/hfsfuse
> > qnx6
> Fuse ro filesystem https://pypi.org/project/qnxmount/ better support then 
> kernel one
> > sysv
> no fuse equivalent may be easier to port from (net)?bsd source to fuse or use 
> the method of qnxmount
> > 
> > affs
> no fuse equivalent but a grub filesystem may be ported to fuse
> > ecryptfs
> no fuse equivalent
> > jffs2
> no fuse equivalent
> > jfs
> no fuse equivalent but a grub filesystem may be ported to fuse
> > 
> > And I think that I can also safely add a few more which while actively 
> > maintained I believe are only used in a retrocomputing context or are 
> > generally uncommon anyway:
> > 
> > befs
> A fuse module seems to be avalaible 
> https://www.haiku-os.org/guides/daily-tasks/access_bfs_with_fuse/
> > bfs
> no fuse equivalent
> > hpfs
> no fuse
> > omfs
> https://github.com/bcopeland/omfs_fuse/
> > qnx4
> Maybe Fuse ro filesystem https://pypi.org/project/qnxmount/
> > reiserfs
> so incomplete work using grub filesystem 
> https://github.com/albertz/reiserfs-fuse
> > spu
> This one is a virtual fs for powerpc should be dropped of the list
> > ufs
> https://github.com/mkatiyar/fuse-ufs2
> > 
> 
> 



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

Re: HFS/HFS+ are insecure

[Bastien Roucariès]

Le vendredi 21 juillet 2023, 08:55:39 UTC Marco d'Itri a écrit :
> efs
https://pypi.org/project/qnxmount/ claim to mount it. Check
> hfs
https://github.com/0x09/hfsfuse
> hfaplus
https://github.com/0x09/hfsfuse
> qnx6
Fuse ro filesystem https://pypi.org/project/qnxmount/ better support then 
kernel one
> sysv
no fuse equivalent may be easier to port from (net)?bsd source to fuse or use 
the method of qnxmount
> 
> affs
no fuse equivalent but a grub filesystem may be ported to fuse
> ecryptfs
no fuse equivalent
> jffs2
no fuse equivalent
> jfs
no fuse equivalent but a grub filesystem may be ported to fuse
> 
> And I think that I can also safely add a few more which while actively 
> maintained I believe are only used in a retrocomputing context or are 
> generally uncommon anyway:
> 
> befs
A fuse module seems to be avalaible 
https://www.haiku-os.org/guides/daily-tasks/access_bfs_with_fuse/
> bfs
no fuse equivalent
> hpfs
no fuse
> omfs
https://github.com/bcopeland/omfs_fuse/
> qnx4
Maybe Fuse ro filesystem https://pypi.org/project/qnxmount/
> reiserfs
so incomplete work using grub filesystem 
https://github.com/albertz/reiserfs-fuse
> spu
This one is a virtual fs for powerpc should be dropped of the list
> ufs
https://github.com/mkatiyar/fuse-ufs2
> 



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

Re: HFS/HFS+ are insecure

[Bastien Roucariès]

Le vendredi 21 juillet 2023, 10:17:13 UTC Marco d'Itri a écrit :
> On Jul 21, Bastien Roucariès  wrote:
> 
> > Ok found it call mountlo outdated 
> > will need a small patch for linux uml, but may be worthwhile
> > Last version seems to be outdated 0.6 and carried by slitaz distribution.
> > May be time to revive it
> It looks like a good long term solution, but as long as there are 
> insecure file systems in the kernel they should be disabled by default 
> so these are really different issues.

No it is not a long term solution. Long term solution will be to push under 
fuse these filesystem. This a (short term)/(medium term band aid) solution.

I agree with you about disabling these modules

linux uml work on i386/amd64/ppc (by memory) so it could help for some 
filesystem particularly hfs

I do not understand why uml is not part of main kernel build maybe it is time 
to get it.

The plan could be:
- build uml along the main kernel (if possible)
- try to get merged old mountlo kernel support
- push to uml only these insecure filesystem
- long term try to push these to pure userspace or drop

What do you think ?

rouca

> 
> I remember noise from the systemd people about mounting removable media 
> using user space drivers, but I do not think that anybody is working on 
> this.
> 
> 



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

Re: HFS/HFS+ are insecure

[Bastien Roucariès]

Le vendredi 21 juillet 2023, 09:49:48 UTC Bastien Roucariès a écrit :
> Le vendredi 21 juillet 2023, 08:20:12 UTC Matthew Garrett a écrit :
> Hi
> > On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote:
> > > Package: src:linux
> > > Severity: normal
> > > 
> > > You are totally correct.
> > > Kernel team, please blacklist HFS/HFS+ for automounting.
> > 
> > Isn't this a userland policy decision? udisks will happily trigger a 
> > module load for hfsplus if udev has identified it, and I don't think 
> > there's a trivial mechanism for the kernel to disable that. I believe 
> > the only way for the kernel to disable automounting would be to disable 
> > the drivers entirely (which we don't want to do), so this probably needs 
> > to be assigned elsewhere rather than being a linux bug.
> > 
> > (Or, alternatively, we could move hfs(+) support to FUSE and provide 
> > extremely tight seccomp policies around them, and then drop kernel 
> > support, but even though this has been talked about a bunch I haven't 
> > seen anyone try to implement it)
> I vaguely remember that someone implement a fuse over uml (user space linux)
> 
> I used it last time to read in user space some crappy filesystem
> 
> I somebody has better memory than me, it could be an idea

Found it! I was mountlo
> 
> Bastien
> 
> > 
> > 
> 
> 

Re: HFS/HFS+ are insecure

[Bastien Roucariès]

Le vendredi 21 juillet 2023, 09:49:48 UTC Bastien Roucariès a écrit :
> Le vendredi 21 juillet 2023, 08:20:12 UTC Matthew Garrett a écrit :
> Hi
> > On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote:
> > > Package: src:linux
> > > Severity: normal
> > > 
> > > You are totally correct.
> > > Kernel team, please blacklist HFS/HFS+ for automounting.
> > 
> > Isn't this a userland policy decision? udisks will happily trigger a 
> > module load for hfsplus if udev has identified it, and I don't think 
> > there's a trivial mechanism for the kernel to disable that. I believe 
> > the only way for the kernel to disable automounting would be to disable 
> > the drivers entirely (which we don't want to do), so this probably needs 
> > to be assigned elsewhere rather than being a linux bug.
> > 
> > (Or, alternatively, we could move hfs(+) support to FUSE and provide 
> > extremely tight seccomp policies around them, and then drop kernel 
> > support, but even though this has been talked about a bunch I haven't 
> > seen anyone try to implement it)
> I vaguely remember that someone implement a fuse over uml (user space linux)
> 
> I used it last time to read in user space some crappy filesystem
> 
> I somebody has better memory than me, it could be an idea
Ok found it call mountlo outdated 

will need a small patch for linux uml, but may be worthwhile

Last version seems to be outdated 0.6 and carried by slitaz distribution.

May be time to revive it

Bastien

> Bastien
> 
> > 
> > 
> 
> 



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

Re: HFS/HFS+ are insecure

[Bastien Roucariès]

Le vendredi 21 juillet 2023, 08:20:12 UTC Matthew Garrett a écrit :
Hi
> On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote:
> > Package: src:linux
> > Severity: normal
> > 
> > You are totally correct.
> > Kernel team, please blacklist HFS/HFS+ for automounting.
> 
> Isn't this a userland policy decision? udisks will happily trigger a 
> module load for hfsplus if udev has identified it, and I don't think 
> there's a trivial mechanism for the kernel to disable that. I believe 
> the only way for the kernel to disable automounting would be to disable 
> the drivers entirely (which we don't want to do), so this probably needs 
> to be assigned elsewhere rather than being a linux bug.
> 
> (Or, alternatively, we could move hfs(+) support to FUSE and provide 
> extremely tight seccomp policies around them, and then drop kernel 
> support, but even though this has been talked about a bunch I haven't 
> seen anyone try to implement it)
I vaguely remember that someone implement a fuse over uml (user space linux)

I used it last time to read in user space some crappy filesystem

I somebody has better memory than me, it could be an idea

Bastien

> 
> 



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

Re: What *is* the amd64 ABI

[Bastien Roucariès]

Le mardi 16 mai 2023, 04:45:51 UTC Michael Hudson-Doyle a écrit :
> On Tue, 16 May 2023, 15:42 Russ Allbery,  wrote:
> 
> > Sam Hartman  writes:
> >
> > > We've all been talking about the x86_64 ABI, and I'm realizing I'm never
> > > read it.
> > > Are we talking about
> > > https://refspecs.linuxbase.org
> > 
> 
> /elf/x86_64-abi-0.99.pdf
> > 
> >
> > That's the one that I was looking at, at least.  Specifically (for the
> > purposes of the current discussion) page 84.  I'm not sure if there's a
> > newer version, since that one is labeled draft.
> >
> 
> I think the current version lives at
> https://gitlab.com/x86-psABIs/x86-64-ABI

ABI are documented on the wiki

https://wiki.debian.org/ArchitectureSpecificsMemo#amd64

Thanks

Bastien
> 
> Cheers,
> mwh
> 
> > Russ Allbery (r...@debian.org)  
> >
> >
> 

Re: icc-profiles_2.2_source.changes REJECTED

[Bastien Roucariès]

Le vendredi 3 mars 2023, 22:35:24 UTC Jonas Smedegaard a écrit :
> Quoting Bastien Roucariès (2023-03-03 22:21:49)
> > Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit :
> > Hi jonas,
> > 
> > I have just checked the source code of lintian. Could you double check your 
> > package and create a simple test case ?
> > 
> > According to:
> > https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/NonFree.pm#L91
> > The test should not raise
> 
> Sorry, I don't understand what you ask me to do.
> 
> In case it was unclear from my previous posts: The rejection messages I
> shared was not from a lintian check done locally by me, but a rejection
> message I received from ftpmaster.
> 
> Locally I did not experience the same messages.  Are you asking me to
> test again that I (again) do not experience the kind of messages that
> ftpmasters for some reason unknown to me trigger?

Yes could you double check ?

If you do not experience the kind of messages with locally installed lintian, 
it means that lintian need to be backported and that ftpmaster should install a 
backport version.

Bastien
> 
>  - Jonas
> 
> 



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

Re: icc-profiles_2.2_source.changes REJECTED

[Bastien Roucariès]

Le lundi 27 février 2023, 12:11:27 UTC Jonas Smedegaard a écrit :
Hi jonas,

I have just checked the source code of lintian. Could you double check your 
package and create a simple test case ?

According to:
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/NonFree.pm#L91
The test should not raise

Bastien
> Quoting Simon McVittie (2023-02-27 13:04:25)
> > On Mon, 27 Feb 2023 at 12:22:34 +0100, Jonas Smedegaard wrote:
> > > I am not convinced, however, that this issue is a bug in lintian:
> > > The testcase you ask for is the actual files in the icc-profiles source
> > > package which already is already correctly identified by lintian.  I.e.
> > > issue is not that some different files get misdetected but instead that
> > > lintian _correctly_ identifies the files in this non-free package and
> > > _correctly_ classifies those as unsuitable in main
> > 
> > That's correct to a point, but it seems wrong for lintian to be emitting a
> > tag that means "this package is unsuitable for main and that's a problem"
> > for a package in non-free. Yes, we know it's unsuitable for main, and
> > the maintainer has acknowledged that by uploading it to non-free... it
> > doesn't seem like there is any benefit to having an unfixable Lintian
> > error as well.
> > 
> > Or if the interpretation of the tag is "you should use the copy of this
> > file from icc-profiles instead of shipping your own copy", then the lintian
> > check should have a special case to silence that tag when the package being
> > checked *is* icc-profiles.
> > 
> > There are similar special cases in other parts of Lintian. For example,
> > it looks for embedded code copies of zlib, but that check has a special
> > case to avoid it being triggered by zlib itself, because obviously zlib
> > should be allowed to ship zlib code; and similarly checks for a bundled
> > font like Deja Vu shouldn't trigger for fonts-dejavu itself.
> 
> Ah, I was unaware that lintian at other places includes exceptions like
> that, an that lintian is expected to do reliable assessments in this
> kind of tests.
> 
> When that's the case, then please, Bastien (or others skilled with
> internals of lintian) please refine the tests for icc-profiles contents
> to exclude icc-profiles package itself.
> 
> (I'll file a bugreport against lintian if I notice no actions from this)
> 
> Kind regards,
> 
>  - Jonas
> 
> 



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

Re: icc-profiles_2.2_source.changes REJECTED

[Bastien Roucariès]

Le vendredi 24 février 2023, 06:13:48 UTC Shengjing Zhu a écrit :
> Hi,
> 
> On Fri, Feb 24, 2023 at 7:38 AM Jonas Smedegaard  wrote:
> >
> > What to do when a package is blocked from getting updated due to it
> > being itself?
> >
> > I have tried replying to FTPmasters as invited in the rejection message,
> > but have been met with silence.
> >
> > I have tried filing bug#1030961 but have so far seen no response on that
> > either.
> >
> > Will it make sense to reassing that bugreport to the technical
> > committee?  Or to the release team?  Or should I request removal of the
> > package, because security bugfixes (however unlikely for a package
> > containing purely static data files) is impossible?
> >
> >
> >  - Jonas
> >
> > Quoting Debian FTP Masters (2023-02-09 04:19:39)
> > >
> > > icc-profiles source: lintian output: 
> > > 'license-problem-md5sum-non-free-file ECI-RGB.V1.0.icc usual name is 
> > > ECI-RGB.V1.0.icc. Does not allow modification See also 
> > > https://packages.debian.org/sid/icc-profiles.', automatically rejected 
> > > package.
Seems like a bug on lintian

Feel free to prod me with a small testcase or a patch will try to do something

Bastien
> [snip]
> > > icc-profiles source: lintian output: 
> > > 'source-only-upload-to-non-free-without-autobuild ', automatically 
> > > rejected package.
> > > icc-profiles source: If you have a good reason, you may override this 
> > > lintian tag.
> 
> It's auto rejected. So I think it can be technically solved.
> For license-problem-md5sum-non-free-file, it's obviously a false
> positive from lintian. It should not emit such if the source is the
> non-free section. It should be reported as a bug for the lintian
> package. And you can submit patches as well, backport to the version
> that ftp-master server uses.
> For source-only-upload-to-non-free-without-autobuild, it's really a
> bug in your upload. You should fix it.
> 
> 



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

Re: Improvement of sensible-utils

[Bastien Roucariès]

Le vendredi 11 août 2017, 16:37:49 UTC Bastien ROUCARIES a écrit :
Hi,

I have implemented on salsa the sensible-x-terminal, but I need --wait flags in 
order to wait...

Moreover sensible-utils will now support EDITOR as shell snippet like 
EDITOR='emacsclients -n -c -a ""'

Bastien
> Hi,
> 
> I have done some work for sensible-utils but I am a little stuck due
> to lack of documentation/policy.
> 
> I want first to create desktop file for
> sensible-editor/sensible-pager/sensible-browser in order to open from
> firefox text file (fixing #780742).
> 
> The main problem is to exec this in a terminal or not depending of the
> context.
> 
> I propose first to solve #594942 and to implement sensible-x-terminal
> first. This program will
> exec $XTERMINAL if set, then if configured $SENSIBLE_XTERMINAL and
> lastly choose the terminal according to desktop running (maybe using
> xdg-open /proc/self/1 < sensible-x-terminal
> 
> Then nano for instance will provide sensible-editor-nano that will use
> library provided by sensible-utils in order to run nano under a
> terminal if run under X.
> 
> What do you think ?
> 
> Bastien



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

Re: Current NEW review process saps developer motivation

[Bastien Roucariès]

Le vendredi 26 août 2022, 10:58:28 UTC Simon McVittie a écrit :
> On Fri, 26 Aug 2022 at 09:09:25 +0200, Jonas Smedegaard wrote:
> > The way I see it, the process is clear: provide *source* to build from.
> > 
> > If there is "source" built from another source, then that other source
> > is the true source.
> 
> I hope you agree that we are doing this in order to get some desirable
> properties of building from source, rather than because the rules are
> the rules and we follow them without any critical thinking?
> I feel strongly that if our policies are not meeting their goals of
> advancing Free Software and providing benefit to our users, then we
> should reconsider whether they are the right policies.
> 
> I don't think building from the least-derived form is always the right
> thing to do. For instance, take rust-glib-sys, a package of Rust bindings
> for the GLib library, which is one of the libraries whose handling
> prompted this thread. It contains a description of the GLib library's
> API/ABI, basically the Rust equivalent of a C header file. It could
> have been written by hand, but that would be tedious and error-prone,
> so instead its upstream maintainers chose to machine-generate the API/ABI
> description from GLib. The thing that would be closest to "true source"
> would presumably be to redo that machine-generation process, from first
> principles, at build-time

In this case the js team has solved the problem.

We use grouped source package, we have the same problem between javascript 
package and typescript. Javascript is the main source and typescript is often 
generated.

See here
https://wiki.debian.org/Javascript/GroupSourcesTutorial

In your case, you should group your rust source with the glib source and so no 
bundle anymore.

You need only a little bit coordination with the glib maintenair and accept 
funny version for glib like 1.0+~1.2

Bastien



> 
> However, if we did that by using the version of GLib in the archive,
> then the API of the Rust bindings would not be entirely determined
> by the content of the rust-glib-sys package as tracked by its version
> number, which seems really bad for library stability: you could take
> the same version number, build it twice in different environments, and
> get two different APIs! rust-glib-sys could have a minimum supported
> GLib version, but then would unpredictably have or not have additional
> APIs beyond the ones present in that version, depending on the version
> of GLib that happened to be installed at build-time.
> 
> If the generation process is not always 100% backwards-compatible, which
> I suspect it is not, then that just makes it worse: now you can't even
> rely on a rebuilt version of rust-glib-sys being compatible with the
> version from before it was rebuilt! If the API description is curated by
> the upstream maintainers, then they have an opportunity to detect
> incompatible changes and release them with a suitably changed version
> number, or even as a separate parallel-installable version, so that
> dependent projects can migrate at their own pace; but that can't happen
> if the API description is generated at build time.
> 
> Or, the other way to generate rust-glib-sys from "true source" would be
> to bundle a complete copy of GLib source code in it, and generate the
> API description from that (which, as an implementation detail of the way
> it was done, requires compiling GLib and then introspecting the binary,
> and cannot be done while cross-compiling). This is not great from either
> a technical or social point of view. From a technical point of view,
> rust-glib-sys' build system would have to be taught to compile GLib,
> which uses a totally different build system (Meson rather then Cargo)
> and is quite a large library, resulting in a much slower and less
> reliable build. From a social point of view, again, GLib is not small,
> and I don't think either the rust-glib-sys maintainer or the ftp team
> would welcome the requirement to review another complete copy of GLib,
> transcribe all its potential copyright holders into debian/copyright
> and check that it has been done, and so on.
> 
> Generating the API description in a way that does not arbitrarily vary
> based on installed software might also require bundling and building a
> complete copy of GObject-Introspection, which, again, is not small.
> 
> All of this is for a functional interface description, analogous to a C
> header file without comments. In other contexts elsewhere in the project,
> we rely on the functional parts of an interface description as not being
> strongly protected by copyright (after all, the whole GNU system started
> as a compatible implementation of the interfaces provided by 1980s Unix,
> and we have code in Debian that is a compatible reimplementation of
> Windows interfaces), and we strongly limit the modifications that we
> are prepared to make to interface descriptions (because Free Software
> is important to us, we

Re: Automatic trimming of changelogs in binary packages

[Bastien Roucariès]

Le jeudi 18 août 2022, 19:18:35 UTC Gioele Barabucci a écrit :
> Hello,
> 
> in 2020 there was a brief discussion on debian-devel@ about trimming
> changelogs [1,2].
> 
> Now there is a working implementation of said functionality in
> `dh_installchangelogs` [3].
Could you stress on the mapage that some license ask to document the change 
done by downstream in binary distribution and that in this case this tool 
should be disable

bastien
> 
> This implementation, combined with the evolution of the apt/dpkg
> ecosystem that happened in the meantime, provides now all the benefits
> of changelog trimming (less wasted space and bandwidth worldwide,
> reduced processing time) without the downsides discussed at the time.
> 
> ## In detail
> 
> * `dh_installchangelogs` is modified install in binary packages the
> trimmed changelogs, i.e. changelogs that contain only entries more
> recent than the release date of oldstable.
> 
> * The trimming is done automatically in compat >= 14.
> 
> * The `--no-trim` option allows package maintainers that want to ship
> the whole changelog a way to do so.
> 
> * The full changelogs are preserved in the source packages and thus
> available via `apt changelog` and similar mechanisms.
> 
> * The trimming process happens at build time and requires no
> modification to the changelogs stored in the VCS repos, nor changes to
> the packaging.
> 
> ## Data on file size reduction
> 
> On a sample of ~13.000 packages, the median reduction in size of
> gzip-9'ed changelogs is 56% (mean 50%).
> 
> Ancient packages or heavily developed packages gain a lot from trimming
> the changelogs. Some examples (gzipped → trimmed+gzipped):
> 
> * debian-keyring: 664k  → 47k (-92%)
> * dpkg (essential): 223k → 22k (-90%)
> * apt (essential): 156k → 14k (-90%)
> * systemd: 110k → 23k (-78%)
> * gcc-12: 189k → 18k (-90%)
> * python3.9: 48k → 4k (-90%)
> * e2fsprogs: 68k → 7k (-89%)
> 
> ## Consensus
> 
> Does anybody have objective objections against activating automatic
> changelog trimming in binary packages?
> 
> Regards,
> 
> [1] https://lists.debian.org/debian-devel/2020/03/msg00299.html
> [2] https://bugs.debian.org/954313
> [3] https://salsa.debian.org/debian/debhelper/-/merge_requests/80
> 
> --
> Gioele Barabucci



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

Re: A mail relay server for Debian Members is live

[Bastien Roucariès]

Le lundi 15 août 2022, 14:19:57 UTC David Bremner a écrit :
> Bastien Roucariès  writes:
> > Le samedi 16 juillet 2022, 21:49:31 UTC Pierre-Elliott Bécue a écrit :
> > Thanks for this hard work, however it seems that some mail client consider
> > these mail as invalid, whereas gmail and other verifier service consider
> > ok...
> > 
> > Any idea for debugging?
> > 
> > Bastien
> 
> Hi Bastien;
> 
> I'm not involved with the service (even as a user), but I am interested
> in mail clients. Can you be more specific about what is failing and on
> what client? 

kmail is the client with dkim plugin enable

Message-ID: <87h73gyaiw@janja.pimeys.fr> by , Pierre-Elliott Bécue 
 of this thread fail (invalid dkim signature) , where as
Message-ID:  is marked as dkim valid...

Bastien
> > A sample message is typically needed to debug these things.
> I'm not sure there is any sensible way to report issues (RT? BTS?) but
> if someone knows, that would be useful to mention.
> 
> d

Bug#1017366: RFH: imagemagick -- image manipulation programs -- binaries

[Bastien Roucariès]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-devel@lists.debian.org
Control: affects -1 src:imagemagick

I request assistance with maintaining the imagemagick package.

The package description is:
 ImageMagick is a software suite to create, edit, and compose bitmap images.
 It can read, convert and write images in a variety of formats (over 100)
 including DPX, EXR, GIF, JPEG, JPEG-2000, PDF, PhotoCD, PNG, Postscript,
 SVG, and TIFF. Use ImageMagick to translate, flip, mirror, rotate, scale,
 shear and transform images, adjust image colors, apply various special
 effects, or draw text, lines, polygons, ellipses and Bézier curves.
 All manipulations can be achieved through shell commands as well as through
 an X11 graphical interface (display).


I need help in order to get newest 6 version in shape and myabe help to package
version 7. It is a hard to maintain package with a huge popcon.

I will also need help in order to configure by debconf if user want to disable
or not treatment of pdf/ps file for security reasons.

Help is welcome

Bastien

Re: A mail relay server for Debian Members is live

[Bastien Roucariès]

Le samedi 16 juillet 2022, 21:49:31 UTC Pierre-Elliott Bécue a écrit :
> Dear developers,
> 
> In the past months, it's been clear that sending mails from an
> @debian.org address to some mail providers, including GMail, has become
> harder and harder. While user DKIM feature (documented on [0]) can help,
> we thought providing a relay server for our users to send their Debian
> mail was a more long-term solution.
> 
> This service is now operational behind mail-submit.debian.org (AKA
> stravinsky.debian.org). Documentation about how to use this service can
> be accessed via [1]. The page behind [0] will be updated on the next
> release we make of userdir-ldap-cgi.
> 
> Mails sent via this server will be DKIM-signed if the from is a
> debian.org, debconf.org or ftp-master.debian.org address. If any
> additional domain should be considered, feel free to ask.
> 
> This server requires an active Debian Account, and that one sets their
> mailPassword up (again, see [1]) to be able to use the service. I've
> tried to provide some useful tips on the doc.
> 
> If you have any question or issue, please don't hesitate to reach out.
Thanks for this hard work, however it seems that some mail client consider 
these mail as invalid, whereas gmail and other verifier service consider ok...

Any idea for debugging?

Bastien
> 
> Cheers!



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

Re: Wine MinGW system libraries

[Bastien Roucariès]

Le mardi 7 septembre 2021, 00:44:31 UTC Paul Wise a écrit :
> On Mon, Sep 6, 2021 at 9:54 PM Zebediah Figura wrote:
> > The basic problem is that applications can and often do ship with PE
> > builds of cross-platform libraries. These libraries can be ahead of
> > Wine's system libraries, behind them, or even built with custom patches.
> > Accordingly we really don't want to load "our" freetype in place of
> > "their" freetype, or "theirs" in place of "ours". But because of the way
> > the Win32 loader works, you can generally only have one DLL of a given
> > name loaded in a process, and further attempts to dlopen() [as it were]
> > "libfreetype-6.dll" will return the handle to the already loaded
> > library, potentially breaking either Wine or the application.
> 
> I don't know the details here, but my immediate thought when reading
> this is that you need some kind of namespace. I then found that linker
> namespaces are a thing, perhaps they would provide the solution for
> you. It sounds like the OpenGL shim loader solution listed on the
> glibc wiki might work for your use-case. Or perhaps the LD_AUDIT
> feature would also work.
> 
> https://www.sourceware.org/glibc/wiki/LinkerNamespaces
I agree with pabs, implementing name space is a good solution
and will allow to be distrib friendly.

Moreover it will be best if marking a library as wine system one could be done 
post build. We will prefer to not modify upstream (like libpng) source. 

It is easier for us to apply small patch to upstream, or better in your case 
to add a post link linker script or even some compiler flag that will add some 
notes section to dll in order to mark it as use namespace system, or so on.

The problem on windows side is well known as dll hell

Renaming of the lib could be done post install. Moreover a crazy idea why not 
renaming system dll instead of libpng-2.0.0.dll as libpng-2.0.0.sll (note the 
version is manadaroty) Therefore we could use  upstream source. Then add a 
small linker script that will rewrite the depends of  libpng-2.0.0.sll  to 
.sll file (aka binary sed s/.dll/.sll/g).

then add a small wraper (shim) like said pab that load the .sll library, the 
best pratice will be a command tool that take the name of the sll and create 
magically the dll

Therefore from distrib point of side we only changes the way we build the 
package, it could be automated, it is scalable and it does not need to patch 
package by package. Only to add some linker script magic

Bastien

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

[Bastien Roucariès]

Le jeudi 2 septembre 2021, 22:38:35 UTC Phil Morrell a écrit :
> Over this last year there seems to have been a noticeable divergence of
> maintainer opinion, on what has become known as vendoring, from a strict
> reading of [policy 4.13]. I think it's notable that the heading is
> [Embedded] copies and was [Convenience] copies since its inception,
> thankfully I found a request to expand this section using [vendoring].
> 
> [policy 4.13]:
> https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copie
> s [Embedded]: https://bugs.debian.org/955036
> [Convenience]: https://bugs.debian.org/392362
> [vendoring]: https://bugs.debian.org/907051
> 
> It is my reading of the situation that not only has this practice become
> more prevalent across multiple ecosystems since 2008, but that it can be
> a good thing when upstreams use it to better modularise their code. As a
> consequence, and in particular for large upstream projects, it is not a
> good use of maintainer time to package every single vendored library as
> a separate source package. See e.g. [kubernetes], [python BoF @25mins],
> [android-platform-tools], and even [uscan] grouping used by nodejs.
> 
> [kubernetes]: https://bugs.debian.org/971515#172
> [python BoF @25mins]:
> https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/debc
> onf21-97-python-team-bof.webm [android-platform-tools]:
> https://salsa.debian.org/android-tools-team/admin/-/issues/40 [uscan]:
> https://manpages.debian.org/uscan#grouped_package

For uscan you misread, the goal of the uscan grouped package is to avoid 
embeded copy. It decouple the concept of upstream package from debian package 
by grouping it, but (see for instance node-resolve unstable package), but 
decreasing the number of embeded copy in the distrib.
- src:node-resolve embded a few related npm package:
   * node-resolve
  * node-types-resolve (the typescript API for this package but that is 
another packages upstream. It is crazy but welcome to nodejs/npm world)
  * is-core-module really small depends upstream of this package
  * path-parse  really small depends upstream of this package

The node-resolve arch:all debian package provides node-type-resolve 
(=version), node-is-core-module (=version) and so on. So apt-get install node-
types-resolve works for user as expected. Moreover other package could depends 
on node-types-resolve (>> version) thus using the normal depends mechanism of 
debian.

Moreover (it is for now contructed by manual rules but me and mabye yadd are 
planning to automate this rules), node-resolve create a /usr/share/doc/node-
types-resolve directory with copyright and changelog.Debian.gz linked back to 
/usr/share/doc/node-resolve/copyright and /usr/share/doc/node-resolve/
changelog.Debian.gz BUT with documentation of node-types-resolve in order to 
allow switching easilly to non grouped package if needed (package being non 
leaf packages or bigger to pass ftpmaster constraint), and in order to let 
your user thinks node-types-resolve is a normal package, with its own 
documentation.

Thus with my pkg-javascript team hat, I use the group feature of uscan, in 
order to deacrease embeded copy in javascript packages and to workarround npm 
one line one package culture.

It is not perfect but it is I believe a good engineering trade of.

The only problem is I am not english native speaker, and thus I have not 
documented why and how we use this feature. Patch to policy are welcome

Moreover I believe that trackers should display the versionned provides and 
https://packages.debian.org/unstable/node-resolve sould also document 
versionned provides and https://packages.debian.org/unstable/node-types-resolve 
should redirect to d https://packages.debian.org/unstable/node-resolve
in order to avoid to confuse our users.

Bastien


> d https://packages.debian.org/unstable/node-types-resolve
> Is there any objection to the following summary?
> 
> 1. If the reused code is small and intended to be embedded into a
>package, then this MUST be documented in the [security-tracker].
> 2. If the included project has already been packaged, then the Debian
>version SHOULD be used instead.
> 3. If modifications have been made, then those changes SHOULD be
>forwarded and/or the package ported to the official version.
> 4. When 2 or 3 are too onerous to maintain, the package MAY use the
>convenience copy but MUST document why in README.source and SHOULD be
>included in the [security-tracker].
> 5. Where only a small number of unrelated projects are bundled, they
>SHOULD be uploaded as separate source packages.
> 6. If the upstream authors are largely the same, then vendored
>sub-projects MAY simply be built together as the same source.
> 7. A large number of vendored dependencies used only together for a
>single Debian package MAY be grouped into a single source upload.
> 8. If 6 or 7 are used initially but a new package has some overlap, then
>th

Re: Ideas for a dh-privacy-helper

[Bastien Roucariès]

Le jeudi 2 septembre 2021, 16:11:48 UTC Jonas Smedegaard a écrit :
> Quoting Bastien Roucariès (2021-09-02 17:53:18)
> 
> > A few year ago I have created the privacy-breach lintian checks in
> > order to detect trackers in our doc
> > 
> > I think we are losing the battle here.
> > 
> > I believe that we need better tools than sed in order to fix this kind
> > of problem.
> > 
> > I have some idea like:
> > - read the html tree
> > - convert the html tree dom representation to xml serialization (so called
> > 
> >   XHTML5 or polyglot)
> > 
> > - apply to this xhtml5 xslt2 rules for fixing the privacy breach
> > 
> > The problem are the tools to use...
> > 
> > I will like to use javascript for this kind of transformation but
> > nodejs does not compile on armel, and for saxon-ce I need gwt that is
> > not in debian...
> > 
> > I could use saxon2,but it will need java.
> 
> Perl is famous for its text juggling features, and sloppy parsing of
> html can be done e.g. with HTML::HTML5::Parser (i.e. Debian package
> libhtml-html5-parser-perl).
> 
> Also, debhelper itself is written in perl, so is likely easier to
> integrate plugins written in perl as well.  If perl is an option at all,
> obviously...

Perl is an option I implemented the privacy breach test in perl. The problem 
is I prefer to drop a debian/package.privacy.xslt file in the package instead 
of asking maintainer to code the removal of privacy problems...

Generic one could be coded in perl, but for the end side I need something like 
xslt2

> I am sure Python/Ruby/PHP/Haskell/Scheme/Rust/etc. folks will argue that
> their pet language is the right for the task as well: I think it will
> help the conversation if you clarify what you are open to and what are
> constraints for you.
> 
> E.g. do you mean that it *must* be JavaScript when you mention that?  Or
> are you perhaps asking if someone else wants to take over the challenge
> from you, so it does not matter how it is done?

No it must no be javascript, but using V8 or something like browser internal 
in order to fail to get a dom tree in case of broken html file, like a browser 
do. But may be I am overconcious

Bastien
> 
> 
>  - Jonas



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

Ideas for a dh-privacy-helper

[Bastien Roucariès]

Hi,

A few year ago I have created the privacy-breach lintian checks in order to 
detect trackers in our doc

I think we are losing the battle here.

I believe that we need better tools than sed in order to fix this kind of 
problem.

I have some idea like:
- read the html tree
- convert the html tree dom representation to xml serialization (so called 
XHTML5 or polyglot)
- apply to this xhtml5 xslt2 rules for fixing the privacy breach

The problem are the tools to use...

I will like to use javascript for this kind of transformation but nodejs does 
not compile on armel, and for saxon-ce I need gwt that is not in debian...

I could use saxon2,but it will need java.

Any ideas is welcomed

Bastien

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

Bug#993312: ITP: journal-abbreviations -- jabref journal abbreviations

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: Bastien Roucariès 
X-Debbugs-Cc: debian-devel@lists.debian.org
Control: affects -1 kbibtex

* Package name: jabref-journal-abbreviations
  Version : git
  Upstream Author : jabref authors
* URL : https://github.com/JabRef/abbrv.jabref.org/
* License : CC0
  Programming Lang: Text
  Description : jabref journal abbreviations

A repository of abbreviations for references, e.g., for conferences, journals,
institutes, etc.


used by kbibtex and jabref

Bastien

Bug#992503: [RFC] [meta][WiP] URL specification with IPv6 zone identifiers

[Bastien Roucariès]

Package: general
Severity: minor
Tags: upstream ipv6
Forwarded: https://github.com/whatwg/url/issues/392

Dear all,

They are some push to change the RFC in order to support browsing to IPV6
address with zone identifier.

It will help some of us to get configuration of industrial appliance.

Link Local addresses (fe80::/10) are used for addressing devices in your local
subnet. They can be automatically generated and using the IPv6 multicast
address ff02::1, all hosts on the local subnet can easily be located.

However browsers like Chrome or Firefox do not support entering link local
addresses inside a URL, which prevents accessing devices locally with a
browser, for instance for configuring them.

Link local addresses need zone identifiers to specify which network device to
use as an outgoing interface. This is because you have link local addresses on
every interface and your network stack does not know on its own, which
interface to use. So typically a link local address is something on the line of
fe80::fae4:e3ff:fee2:37a4%eth0, where eth0 is the zone identifier.

However, I do not know if debian is ready for this for next release so, open a
bug in order to track issue. I suppose we will need also a user tag

Rational and workarround for the time being here
https://ungleich.ch/u/blog/ipv6-link-local-support-in-browsers/

Last draft here
https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-02.html

Bastien

Re: Arch triplet for uefi applications

[Bastien Roucariès]

Le mercredi 11 août 2021, 09:16:10 UTC Simon McVittie a écrit :
> On Tue, 10 Aug 2021 at 15:19:10 -0700, Josh Triplett wrote:
> > Bastien Roucariès wrote:
> > > I suppose that [EFI] will be  x86_64-efi-none (or maybe
> > > x86_64-windows-efi  )  and i686-uefi-none ?
> 
> It's certainly not x86_64-windows-efi. The EFI environment isn't Windows
> (even though it borrows some conventions like FAT, backslashes in paths
> and the PE executable format from Windows).
> 
> > UEFI is effectively an "operating system", insofar as it provides a
> > runtime environment with some baseline properties and a set of system
> > calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> > since there is an OS of sorts.
> > 
> > For that reason, Rust uses the target names "aarch64-unknown-uefi",
> > "i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> > right names for these targets in other toolchains, as well.
> 
> These names used in Rust seem correct to me. The UEFI environment behaves
> like a miniature operating system, which runs instead of GNU/Linux during
> the first stage of boot, so replacing the linux-gnu part of the tuple with
> uefi makes sense.
> 
> Note that there are two forms for writing a GNU tuple: with or without
> the vendor. The full tuple consists of CPU-VENDOR-OS, where OS sometimes
> consists of KERNEL-USERSPACE, or KERNEL-ABI, or KERNEL-USERSPACEABI where
> both disambiguators are needed.
> 
> Developers who are used to (GNU/)Linux are likely to think the
> KERNEL-USERSPACE form is most common, but actually that one is the
> exception, and the more usual form has traditionally just had a single
> token for OSs where the kernel and user-space are tightly coupled,
> 
> such as solaris2, netbsd or freebsd:
>  |CPU|vendor |kernel |userspace|ABI
>  |
>  |   |   |   | (libc)  |
> 
> -|---|---|---|-|
> i386-pc-solaris2 |i386   |PC |Solaris 2|
> x86_64-pc-freebsd|x86_64 |PC |FreeBSD  |
> arm-unknown-netbsd-eabi  |arm|unknown|NetBSD   |EABI
> x86_64-unknown-uefi  |x86_64 |unknown| UEFI|
> x86_64-pc-linux-gnu  |x86_64 |PC |Linux  |GNU  |
> x86_64-pc-linux-musl |x86_64 |PC |Linux  |musl libc|
> x86_64-pc-linux-gnux32   |x86_64 |PC |Linux  |GNU  |x32
> aarch64-unknown-linux-gnu|aarch64|unknown|Linux  |GNU  |
> arm-unknown-linux-gnu|arm|unknown|Linux  |GNU  |OABI
> arm-unknown-linux-gnueabi|arm|unknown|Linux  |GNU  |EABI
> x86_64-pc-kfreebsd-gnu   |x86_64 |PC |FreeBSD|GNU  |
> 
> In Debian multiarch tuples and GNU-style cross-compilation tool
> prefixes, the tuple is written in a shorter form without the vendor as
> CPU-OS (where, again, the OS might be KERNEL-USERSPACE or KERNEL-ABI or
> KERNEL-USERSPACEABI), because the vendor is not usually significant when
> determining whether two binaries share an ABI and can interoperate:
> 
> i386-solaris2
> x86_64-freebsd
> arm-netbsd-eabi
> x86_64-uefi
> x86_64-linux-gnu
> x86_64-linux-musl
> x86_64-linux-gnux32
> aarch64-linux-gnu
> arm-linux-gnu
> arm-linux-gnueabi
> x86_64-kfreebsd-gnu
> 
> (For instance we have x86_64-linux-gnu-gcc and /usr/lib/x86_64-linux-gnu.)
> 
> I prefer to call these strings tuples rather than triplets, because
> calling them triplets can be misleading. The "target triplet" in Autoconf
> specifically refers to the CPU-VENDOR-OS arrangment - remember that GNU
> started by building Free Software tools to run on top of other (often
> proprietary) operating systems, where the ABI was externally imposed by
> the OS vendor, so initially it wouldn't have made sense to talk about the
> kernel and user-space separately. The Linux, kFreeBSD and Hurd kernels
> and the possibility of running a complete GNU operating system only came
> later. So "triplet" refers to the three parts of a full tuple with the
> vendor, broken up like this:
> 
> <--1--><--2-->  <--3-->
> i386-  pc-  solaris2
> x86_64-pc-  linux-gnu
> 
> "Triplet" does not refer to the three parts of an abbreviated
> GNU/Linux-style tuple written without the vendor, even though this decade
> that's the one we see most often:
> 
> # NOT THIS
> x86_64-l

Re: Arch triplet for uefi applications

[Bastien Roucariès]

Le vendredi 13 août 2021, 00:29:02 UTC Guillem Jover a écrit :
> On Tue, 2021-08-10 at 12:34:18 +0000, Bastien Roucariès wrote:
> > I am going to compile shell.efi from source.
> > 
> > I whish to install to something stable, but I need an arch triplet
> > in order to put in a multiarch (like) location.
> 
> Multiarch-based pathnames should only be used by multiarch-conforming
> packages for matching and existing dpkg architectures, otherwise we'll
> end up with a mess of conflicting paths if we ever add such real
> architecture.

Why ? If we build now a arch-all package and when the arch is up we could 
Break to the arch:all package. Normally it should work (or maybe I miss 
something)
> 
> Where <https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches>
> comes to mind.

Yes it is the same except that uefi is a full fledged arch with a sort of OS.  
But it will be nice to use the same thing

I volontuer to implement this stuff, it will allow to build for instance 
firmware to arm easilly. Do you have some pointer of how to implement ?

> In addition the main reason we had to add the multiarch tuples was
> pretty much to workaround the problem with i386 using varying CPUs in
> the GNU system name (i486, i586, i686), so using anything but i386
> there would be adding insult to injury. :)

Yes and no. In this case, clang use i686 as triplet and API is specified to be 
i686 only.
 
> > I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi  )
> >  and i686-uefi-none ? Note that grub use x86_64-efi
> 
> The vendor always gets ignored in the dpkg context.
> 
> Although is there really a need for a cross-compiler here, or is
> something like -ffreestanding enough?

It is more the freestanding but just a little bit more. I plan to create a 
spec file to gcc for helping and adding slowly stuff like hardenning library 
(for improving security of this beast) 


> > I suppose we should register these triplet somewhere, and I suppose it is
> > config-patc...@gnu.org ?
> 
> https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_ar
> chitectures.3F
Ok will do, step by step.

> 
> Thanks,
> Guillem



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

Re: Arch triplet for uefi applications

[Bastien Roucariès]

Le jeudi 12 août 2021, 10:16:45 UTC Bastien Roucariès a écrit :
> Le jeudi 12 août 2021, 09:52:53 UTC Bastien Roucariès a écrit :
> > Le mercredi 11 août 2021, 14:00:37 UTC Steve McIntyre a écrit :
> > > On Tue, Aug 10, 2021 at 03:19:10PM -0700, Josh Triplett wrote:
> > > >Bastien Roucariès wrote:
> > > >> I am going to compile shell.efi from source.
> > > >> 
> > > >> I whish to install to something stable, but I need an arch triplet in
> > > >> order to put in a multiarch (like) location.
> > > >> 
> > > >> I suppose that it will be  x86_64-efi-none (or maybe
> > > >> x86_64-windows-efi
> > > >> )  and i686-uefi-none ?
> > > 
> > > As Simon says, *definitely* not *windows* here please! :-)
> > > 
> > > >I don't think GRUB's x86_64-efi is an architecture triplet, just a
> > > >GRUB-specific target.
> > > >
> > > >UEFI is effectively an "operating system", insofar as it provides a
> > > >runtime environment with some baseline properties and a set of system
> > > >calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> > > >since there is an OS of sorts.
> > > >
> > > >For that reason, Rust uses the target names "aarch64-unknown-uefi",
> > > >"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> > > >right names for these targets in other toolchains, as well.
> > > 
> > > Nod, agreed. I think that makes sense.
> > 
> > Ok thanks
> > 
> > For the triplet this will be :
> > -  i686-unknown-uefi
> > - x86_64-unknown-uefi
> > Where should I push this triplet ?
> > 
> > Ant therefore we get the multiarch tupple:
> > - i386-uefi
> > - amd64-uefi
> > If I am right ?
> > I have added to https://wiki.debian.org/Multiarch/Tuples but I suppuse I
> > should open a bug somewhere (dpkg ?)
> 
> I have changed the arch name, it will be:
> uefi-i686
> uefi-amd64
> with multiarch tupple i686-uefi, x86_64-uefi
> 
> I think it is better in line with current kfreebsd pratice...
Changed a new once after implementing debian arch-name to uefi-i386 will allow 
to use uefi-$(DEBARCH) in makefile
> 
> Bastien
> 
> > Bastien
> > 
> > Bastien



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

Re: Arch triplet for uefi applications

[Bastien Roucariès]

Le jeudi 12 août 2021, 09:52:53 UTC Bastien Roucariès a écrit :
> Le mercredi 11 août 2021, 14:00:37 UTC Steve McIntyre a écrit :
> > On Tue, Aug 10, 2021 at 03:19:10PM -0700, Josh Triplett wrote:
> > >Bastien Roucariès wrote:
> > >> I am going to compile shell.efi from source.
> > >> 
> > >> I whish to install to something stable, but I need an arch triplet in
> > >> order to put in a multiarch (like) location.
> > >> 
> > >> I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi
> > >> )  and i686-uefi-none ?
> > 
> > As Simon says, *definitely* not *windows* here please! :-)
> > 
> > >I don't think GRUB's x86_64-efi is an architecture triplet, just a
> > >GRUB-specific target.
> > >
> > >UEFI is effectively an "operating system", insofar as it provides a
> > >runtime environment with some baseline properties and a set of system
> > >calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> > >since there is an OS of sorts.
> > >
> > >For that reason, Rust uses the target names "aarch64-unknown-uefi",
> > >"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> > >right names for these targets in other toolchains, as well.
> > 
> > Nod, agreed. I think that makes sense.
> 
> Ok thanks
> 
> For the triplet this will be :
> -  i686-unknown-uefi
> - x86_64-unknown-uefi
> Where should I push this triplet ?
> 
> Ant therefore we get the multiarch tupple:
> - i386-uefi
> - amd64-uefi
> If I am right ?
> I have added to https://wiki.debian.org/Multiarch/Tuples but I suppuse I
> should open a bug somewhere (dpkg ?)
I have changed the arch name, it will be:
uefi-i686
uefi-amd64
with multiarch tupple i686-uefi, x86_64-uefi

I think it is better in line with current kfreebsd pratice...

Bastien

> 
> Bastien
> 
> Bastien



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

Re: Arch triplet for uefi applications

[Bastien Roucariès]

Le mercredi 11 août 2021, 14:00:37 UTC Steve McIntyre a écrit :
> On Tue, Aug 10, 2021 at 03:19:10PM -0700, Josh Triplett wrote:
> >Bastien Roucariès wrote:
> >> I am going to compile shell.efi from source.
> >> 
> >> I whish to install to something stable, but I need an arch triplet in
> >> order to put in a multiarch (like) location.
> >> 
> >> I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi 
> >> )  and i686-uefi-none ?
> 
> As Simon says, *definitely* not *windows* here please! :-)
> 
> >I don't think GRUB's x86_64-efi is an architecture triplet, just a
> >GRUB-specific target.
> >
> >UEFI is effectively an "operating system", insofar as it provides a
> >runtime environment with some baseline properties and a set of system
> >calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> >since there is an OS of sorts.
> >
> >For that reason, Rust uses the target names "aarch64-unknown-uefi",
> >"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> >right names for these targets in other toolchains, as well.
> 
> Nod, agreed. I think that makes sense.
Ok thanks

For the triplet this will be :
-  i686-unknown-uefi
- x86_64-unknown-uefi
Where should I push this triplet ?

Ant therefore we get the multiarch tupple:
- i386-uefi
- amd64-uefi
If I am right ?
I have added to https://wiki.debian.org/Multiarch/Tuples but I suppuse I 
should open a bug somewhere (dpkg ?)

Bastien

Bastien


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

Arch triplet for uefi applications

[Bastien Roucariès]

Hi,

I am going to compile shell.efi from source.

I whish to install to something stable, but I need an arch triplet in order to 
put in a multiarch (like) location.

I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi  )  and 
i686-uefi-none ? Note that grub use x86_64-efi

I suppose we should register these triplet somewhere, and I suppose it is 
config-patc...@gnu.org ?

Bastien

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

Bug#992024: ITP: airsane -- SANE WebScan frontend that supports Apple's AirScan protocol

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: Bastien Roucariès 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: airsane
  Version : 0.3.2
  Upstream Author : Simul Piscator
* URL : https://github.com/SimulPiscator/AirSane
* License : GPL3
  Programming Lang: C++
  Description :  SANE WebScan frontend that supports Apple's AirScan
protocol

 SANE WebScan frontend that supports Apple's AirScan protocol. Scanners are
detected automatically, and published through mDNS. Acquired images may be
transferred in JPEG, PNG, and PDF/raster format.

AirSane's intended purpose is to be used with AirScan/eSCL clients such as
Apple's Image Capture, but a simple web interface is provided as well.

Images are encoded on-the-fly during acquisition, keeping memory/storage
demands low. Thus, AirSane will run fine on a Raspberry Pi or similar device.

Bastien

Bug#940140: ITP: node-es-to-primitive -- Pure javascript implementation of ToPrimitive algorithm

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: Bastien Roucariès 

  Package name: node-es-to-primitive
  Version : 1.2.0
  Upstream Author : Jodan Harband
  URL : https://github.com/ljharb/es-to-primitive/
  License : expat
  Programming Lang: javascript
  Description : Pure javascript implementation of ToPrimitive algorithm

 This package provides a ponyfill for ToPrimitive algorithm, thus
 converting of JavaScript object to a primitive value. In JavaScript
 a primitive is data that is not an object and has no method. There
 are seven primitive data type: string, number, bigint, boolean, null,
 undefined and symbol.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#939772: ITP: node-es-abstract -- ECMAScript spec abstract operations

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: Bastien Roucariès 

  Package name: node-es-abstract
  Version : 1.14.2
  Upstream Author : Jordan Harband (ljharb)
  URL : https://github.com/ljharb/es-abstract
  License : expat
  Programming Lang: javascript
  Description : ECMAScript spec abstract operations.

In order to facilitate their use in multiple parts of this ECMAScript 
specification
(javascript) some algorithms, called abstract operations, are named and written 
in
parameterized functional form so that they may be referenced by name
from within other algorithms. 
.
Abstract operations are typically referenced using a functional application 
style such as OperationName(arg1, arg2). 
Some abstract operations are treated as polymorphically dispatched methods of 
class-like specification abstractions.
.
This module implement this abstract operation as functions.

This module is useful for mocha a javascript tester useful for debci

javascript team

Bug#939771: ITP: node-es-abstract -- ECMAScript spec abstract operations.

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: Bastien Roucariès 

  Package name: node-es-abstract
  Version : 1.14.2
  Upstream Author : Jordan Harband (ljharb)
  URL : https://github.com/ljharb/es-abstract
  License : expat
  Programming Lang: javascript
  Description : ECMAScript spec abstract operations.

In order to facilitate their use in multiple parts of this ECMAScript 
specification
(javascript) some algorithms, called abstract operations, are named and written 
in
parameterized functional form so that they may be referenced by name
from within other algorithms. 
.
Abstract operations are typically referenced using a functional application 
style such as OperationName(arg1, arg2). 
Some abstract operations are treated as polymorphically dispatched methods of 
class-like specification abstractions.
.
This module implement this abstract operation as functions.

This module is useful for mocha a javascript tester useful for debci

javascript team

New lintian warnings helping to detect FTBFS and license violation

[Bastien ROUCARIÈS]

Hi,

Newest lintian will detect a few new problems in our package.

It will first detect minified javascript/css embedded in html file (source 
only). It it possible to avoid this warning by creating a symlink
 to source or adding source under debian/missing-source/$nameoffile.fragment 
(better naming welcome).

It will also detect html file that include script with a copyright statement. 
These scripts were likely copy-pasted and likely needs to be rebuilt from the 
original source.  
Moreover they may be also outdated and may need need to be updated from a 
security point of view. [1] They are a few false positive that will fixed ASAP.

Last but not least, lintian will detect browserify/webpack source both in html  
included script and js file [2]. These file should be rebuilt from source
(I am now packaging browserify to main. Technically they are also some problem 
with browserified file that need to be rebuilt each time a depends change).

Bastien

[1] 
https://lintian.debian.org/tags/embedded-script-includes-copyright-statement.html
[2] https://lintian.debian.org/tags/source-contains-browserified-javascript.html


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

[good new]Type 1 font hinting is now free software

[Bastien ROUCARIÈS]

Hi,

I have achieved after 6 years to get adobe relicense type 1 code.

Since 1985 type fonts hinting was not free, now it is free software [1].

The license choosen by adobe is unfortunalty apache 2 and thus not compatible 
with GPL2 only.

They are about 7146 fonts that need to be audited and add correct copyright to 
debian/copyright.

I plan to close #694308 and  ask upstream to fix #665334.

We will need to do a ful rebuilt of fontforge fonts in order to add the new 
code to actual fonts.

Lintian warning will be fixed.

Thank 

[1] https://github.com/adobe-type-tools/afdko/issues/172

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

Bug#873360: ITP: libtie-hash-indexed-perl -- Ordered hashes for Perl

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Bastien_Roucari=C3=A8s?= 

* Package name: libtie-hash-indexed-perl
  Version : 0.05
  Upstream Author : Marcus Holland-Moritz 
* URL : https://metacpan.org/release/Tie-Hash-Indexed
* License : Same as perl
  Programming Lang: perl and C (XS)
  Description : Ordered hashes for Perl

This module implements an ordered hash, meaning that it associates keys
 with values like a Perl hash, but keeps the keys in a consistent order.
 .
 Tie::Hash::Indexed is very similar to Tie::IxHash. However, it is written
 completely in XS and usually about twice as fast as Tie::IxHash. It's quite a
 lot faster when it comes to clearing or deleting entries from large hashes.
 .
 However compared to Tie::IxHash, only the plain tying mechanism is supported.


Plan to pacakge for improving lintian. Under pkg-perl team umbrella

Bug#864689: ITP: node-read-only-stream -- wrap a readable/writable stream to be read-only

[Bastien ROUCARIÈS]

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

* Package name: node-read-only-stream
  Version : 2.0.0
  Upstream Author : James Halliday  (http://substack.net)
* URL : https://github.com/substack/read-only-stream
* License : Expat
  Programming Lang: JavaScript
  Description : wrap a nodejs readable/writable stream to be read-only

This module allow one to use a readable/writable stream internally but to 
expose just the readable part of that internal stream. 
.
 A stream is an abstract interface for working with streaming data in Node.js. 
There are many stream objects provided by Node.js. For instance, a request to 
an HTTP server and process.stdout are both stream instances. 
 Node.js is an event-based server-side JavaScript engine.


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

Bug#798212: ITP: node-indent-string -- Nodejs package indenting every line of string

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: "Bastien Roucariès" 

* Package name: node-indent-string
  Version : 2.1.0
  Upstream Author : Sindre Sorhus
* URL : https://github.com/sindresorhus/indent-string
* License : MIT
  Programming Lang: js
  Description : Nodejs package indenting every line of string

Needed for grunt

Bug#797837: ITP: node-hashish -- maniuplate hash data structures in Node.js

[Bastien Roucariès]

Package: wnpp
Severity: wishlist
Owner: "Bastien Roucariès" 

* Package name: node-hashish
  Version : 0.4.0
  Upstream Author : James Halliday 
* URL : https://github.com/substack/node-hashish/
* License : X11
  Programming Lang: js
  Description : maniuplate hash data structures in Node.js

 Hashish is a Node.js library for manipulating hash data structures. It is
 distilled from the finest that ruby, perl, and haskell have to offer by way of
 hash/map interfaces.

 Needed for packaging browserify needed to package a reverse dep of grunt.

Re: UPG and the default umask

[Bastien ROUCARIÈS]

"Roger Leigh"  a écrit :

>On 20/05/2010 18:30, Russ Allbery wrote:
>> Roger Leigh  writes:
>>
>>> If all current Debian systems support a 32-bit UID and GID range, then
>>> it would be great if we could amend Policy to move the reserved ranges
>>> to the end of the 32-bit range rather than being at the end of the
>>> 16-bit range.  This would give a vast contiguous user range (4294931294
>>> UIDs using the scheme below)
>>
>> You can't move the static reserved space: it contains statically assigned
>> UIDs.  :)  That's the whole point of it.  We could change where we're
>> assigning future static UIDs and GIDs from, but I'm not sure it's worth
>> the effort given that there's always going to have to be a legacy reserved
>> space for the ones that were already assigned.
>
>Do we have any actual users of this space?  I didn't see anything in 
>Policy.  Is there a central database listing the assignments?  If so, 
>where may it be found?
>
>In the absence of any existing static assignments, I don't see any
>issue with moving the range.  If there are assignments, could these
>not be moved for new installs?
>
>>> Additionally, user nobody would then be in the middle of the user
>>> range; it could be shifted back to the end of the 32-bit range.
>>
>> I don't think it's a good idea to let people assign 65535 to a regular
>> user.  That's been hardcoded as nobody in a vast number of UNIX systems
>> for decades.  Reusing that UID for other purposes in any sort of shared
>> infrastructure is almost certain to cause problems.
>
>65534 is the UID for nobody.  Anything using the UID for nobody should 
>be getting it through the libc functions as for any other user; does any 
>code actually hardcode 65534?  IMO that's a bug if so.  Given that 
>nobody can't create files except for in /tmp and other world-writable 
>locations, there shouldn't be any issues with changing the UID/GID since 
>nothing in the filesystem should be owned by them.  A quick check on my 
>system shows just two locations:
>
>drwxrwxrwt 2 nobody nogroup 4096 Jan 27  2009 /var/spool/cups-pdf/ANONYMOUS
>drwxr-se-x root nogroup 63488 May  2 01:04 /usr/lib/kde4/libexec/kdesud
>
>The first is totally pointless (bug filed), it could just be root:root 
>and be even more safe.  The latter looks OK but should we really be 
>having a file owned by nogroup in the filesystem at all on general 
>principle?
>
>Regarding 65535: Does any software actually hardcode the number 65535? 
>Given that its only use is as an error return (-1) for uid_t and this is 
>now a uint32_t any code hardcoding this value is already broken.
>
>The main justification I would have for this change is that keeping the 
>old 16-bit-constrained assignments fragments the 32-bit range space 
>unnecessarily.  For checks such as being discussed, having a contiguous 
>user range makes things much simpler for both us and admins.  I accept 
>that we can't change things for existing systems where these are already 
>being used, but it sucks to be stuck with a 16-bit legacy for evermore 
>even for new installs.


Does it will break reading file from uid16 filesystem?

Regards

Bastien
>
>Regards,
>Roger
>
>
>-- 
>To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>Archive: http://lists.debian.org/4bf58e18.3030...@codelibre.net
>