Re: Move "ITP" from Wiki into the Dev Ref

[Andrey Rakhmatullin]

On Fri, Mar 29, 2024 at 11:14:27AM +, c.bu...@posteo.jp wrote:
> Dear Andrey,
> 
> thanks for the reply. What is the answer? It was just a link.
Can you please open it? It's a devref section about ITP.


> On 2024-03-29 15:05 Andrey Rakhmatullin  wrote:
> > On Fri, Mar 29, 2024 at 09:34:27AM +, c.bu...@posteo.jp wrote:
> > > Dear Team,
> > > 
> > > My apologize for contacting you this way. I couldn't find an
> > > appropriate mailing list.
> > > 
> > > I would like to point you to an wiki related bug ticket in context
> > > of your Developers Reference.
> > > 
> > ><https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067939>
> > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#new-packages
> > 
> 
> 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Move "ITP" from Wiki into the Dev Ref

[Andrey Rakhmatullin]

On Fri, Mar 29, 2024 at 09:34:27AM +, c.bu...@posteo.jp wrote:
> Dear Team,
> 
> My apologize for contacting you this way. I couldn't find an
> appropriate mailing list.
> 
> I would like to point you to an wiki related bug ticket in context of
> your Developers Reference.
> 
>
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#new-packages

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#872587: Document the Protected field

[Andrey Rakhmatullin]

On Wed, Mar 27, 2024 at 01:29:50PM +0200, Martin-Éric Racine wrote:
> > The documentation from deb-control(5) is:
> >
> > Protected: yes|no
> > This field is usually only needed when the answer is yes.  It denotes
> > a package that is required mostly for proper booting of the system or
> > used for custom system-local meta-packages.  dpkg(1) or any other
> > installation tool will not allow a Protected package to be removed (at
> > least not without using one of the force options).
> >
> > It's probably also worth noting the parenthetical comment in the
> > documentation of Essential:
> >
> > Essential: yes|no
> > This field is usually only needed when the answer is yes.  It denotes
> > a package that is required for the packaging system, for proper
> > operation of the system in general or during boot (although the latter
> > should be converted to Protected field instead).  dpkg(1) or any other
> > installation tool will not allow an Essential package to be removed
> > (at least not without using one of the force options).
> 
> I'm still not sure that I inderstand the difference between those two.
> They seem to accomplish the same thing. Did I miss something?
Per my understanding which may be flawed: 

"Essential: yes" are always installed. Tools and dependencies assume they
are installed.  Bootstrapping tools install them implicitly. Package
management tools refuse to remove them.

"Protected: yes" are nothing like that. Package management tools refuse to
remove them and that's all.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Andrey Rakhmatullin]

On Fri, Mar 22, 2024 at 01:46:48PM +0100, Holger Wansing wrote:
> Anyway, the symlink points to some path inside the package build path, here:
> /srv/debian-policy/debian-policy-4.6.2.1/debian/debian-policy/usr/share/sphinx_rtd_theme_static/css/theme.css
You are looking at relative symlinks not in their final locations, which
isn't useful and also is expected for every relative symlink that is
packaged.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

[Andrey Rakhmatullin]

On Fri, Mar 22, 2024 at 11:29:11AM +0100, Holger Wansing wrote:
> > I cannot reproduce this. I downloaded debian-policy source package and built
> > it in an up-to-date sid chroot. And the built package has this:
> > 
> >   $ dpkg-deb -c debian-policy_4.6.2.1_all.deb | grep theme.css
> >   lrwxrwxrwx root/root 0 2024-02-24 15:39 
> > ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css -> 
> > ../../../../../sphinx_rtd_theme/static/css/theme.css
> 
> But above output shows a filesize of 0B.
> Shouldn't that be something different?
Not for symlinks.

> Has ./usr/share/doc/debian-policy/policy.html/_static/css/theme.css any
> useful content, when you open it?
It's a symlink, it can't have content.
It's target does have content, as shown in the quote below:

> > So, it is a symlink, not an empty file. When resolving the relative path,
> > I get /usr/share/sphinx_rtd_theme/static/css/theme.css, and that file
> > exists in sphinx-rtd-theme-common and is non-empty.

> if you open that theme.css file in the debian/debian-policy build path,
> does it have any content?
:-/

> Maybe it was bad wording, when I wrote 
> "replaces files provided by read-the-doc theme by empty symlinks" in the 
> subject of this bug.
> Probably "symlinks pointing to a not-existing file" is more correct?
To which non-existent files? Are they non-existent only when you don't
have sphinx-rtd-theme-common installed?

> I don't know where's the problem in detail, I only see that in the
> debian-policy binary package that file is empty, and therefore the html
> layout is broken.
It's not empty, it's a symlink that points to a non-existent (on your
system) file.

> BTW: the same counts for all the symlinks under _static/fonts/:
> 
> holgerw@t520:~/debian-policy$ ls -la 
> policy/debian/debian-policy/usr/share/doc/debian-policy/policy.html/_static/fonts/
> total 64
> drwxr-xr-x 2 holgerw holgerw 4096 Mar 22 11:17 .
> drwxr-xr-x 5 holgerw holgerw 4096 Mar 22 11:17 ..
> lrwxrwxrwx 1 holgerw holgerw   68 Mar 22 11:17 fontawesome-webfont.eot -> 
> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.eot
> lrwxrwxrwx 1 holgerw holgerw   68 Mar 22 11:17 fontawesome-webfont.svg -> 
> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.svg
> lrwxrwxrwx 1 holgerw holgerw   68 Mar 22 11:17 fontawesome-webfont.ttf -> 
> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.ttf
> lrwxrwxrwx 1 holgerw holgerw   69 Mar 22 11:17 fontawesome-webfont.woff -> 
> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff
> lrwxrwxrwx 1 holgerw holgerw   70 Mar 22 11:17 fontawesome-webfont.woff2 -> 
> ../../../../../sphinx_rtd_theme/static/fonts/fontawesome-webfont.woff2
> lrwxrwxrwx 1 holgerw holgerw   64 Mar 22 11:17 Lato-BoldItalic.ttf -> 
> ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.ttf
> lrwxrwxrwx 1 holgerw holgerw   66 Mar 22 11:17 Lato-BoldItalic.woff2 -> 
> ../../../../../sphinx_rtd_theme/static/fonts/Lato-BoldItalic.woff2
> lrwxrwxrwx 1 holgerw holgerw   58 Mar 22 11:17 Lato-Bold.ttf -> 
> ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.ttf
> lrwxrwxrwx 1 holgerw holgerw   60 Mar 22 11:17 Lato-Bold.woff2 -> 
> ../../../../../sphinx_rtd_theme/static/fonts/Lato-Bold.woff2
> lrwxrwxrwx 1 holgerw holgerw   60 Mar 22 11:17 Lato-Italic.ttf -> 
> ../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.ttf
> lrwxrwxrwx 1 holgerw holgerw   62 Mar 22 11:17 Lato-Italic.woff2 -> 
> ../../../../../sphinx_rtd_theme/static/fonts/Lato-Italic.woff2
> lrwxrwxrwx 1 holgerw holgerw   61 Mar 22 11:17 Lato-Regular.ttf -> 
> ../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.ttf
> lrwxrwxrwx 1 holgerw holgerw   63 Mar 22 11:17 Lato-Regular.woff2 -> 
> ../../../../../sphinx_rtd_theme/static/fonts/Lato-Regular.woff2
> lrwxrwxrwx 1 holgerw holgerw   66 Mar 22 11:17 RobotoSlab-Bold.woff2 -> 
> ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Bold.woff2
> lrwxrwxrwx 1 holgerw holgerw   69 Mar 22 11:17 RobotoSlab-Regular.woff2 -> 
> ../../../../../sphinx_rtd_theme/static/fonts/RobotoSlab-Regular.woff2
> 
> All those symlinks are pointing to a not-existing target here.
Only because you don't have sphinx-rtd-theme-common installed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1030382: encourage Vcs-Git over other Vcs-* headers

[Andrey Rakhmatullin]

On Fri, Feb 03, 2023 at 05:57:21PM +, Jelmer Vernooij wrote:
> Sorry, to be clear I also meant encouraging the use of Git as a Vcs - rather 
> than just
> of the Vcs-Git header.
The Policy is a wrong place for this (and the part about Vcs-* headers is
indeed a wrong place for this too).