Re: a naive question about EOL encoding in Debian

[Andrey Rakhmatullin]

On Sat, Mar 18, 2023 at 08:45:37PM +0100, Patrice Duroux wrote:
> Hi,
> 
> I am facing ^M (\r) character in the .build output file using sbuild
> on my system (Sid).
> For instance:
> 
> $ file timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build
> timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build: ASCII text, with
> very long lines (307), with CRLF, CR, LF line terminators
> 
> It seems to me that there are some tools not using the conventional
> unix EOL (\n only) in formating their output.
Such as?
That file(1) output, as often happens with file(1) output, is not very
useful or trustworthy by itself.

> So I was curious if there are:
> 1. a policy on this (and more generally source file and/or output encoding),
There is a difference between printing something on stdout and actually
writing files. Printing should of course be in the user locale while files
are different, especially non-text ones.

> 2. a way to search using Debian Code Search for possible culprits,
> just to get an idea.
I doubt that.

a naive question about EOL encoding in Debian

[Patrice Duroux]

Hi,

I am facing ^M (\r) character in the .build output file using sbuild
on my system (Sid).
For instance:

$ file timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build
timidity_2.14.0-9_amd64-2023-03-18T18:33:37Z.build: ASCII text, with
very long lines (307), with CRLF, CR, LF line terminators

It seems to me that there are some tools not using the conventional
unix EOL (\n only) in formating their output.
So I was curious if there are:
1. a policy on this (and more generally source file and/or output encoding),
2. a way to search using Debian Code Search for possible culprits,
just to get an idea.
;-)

Many thanks,
Patrice

Re: Adding epoch to kworkflow package to correct a wrong upstream version

[Rodrigo Siqueira]

On 03/12, Tobias Frost wrote:
> On Sat, Mar 11, 2023 at 06:35:39PM -0700, Rodrigo Siqueira wrote:
> > Hi,
> > 
> > While working on a new version of the kworkflow package
> > (https://tracker.debian.org/pkg/kworkflow), we noticed that the current
> > version is 20191112-1.2, and the latest upstream version is 0.6.2.
> > Version 20191112-1.2 was created because the upstream had no official
> > release at that time; for this reason, the 20191112-1.2 was created and
> > named based on a date.
> > 
> > This package did not get any update in a long time, and now the upstream
> > release frequent versions. The latest version is 0.6.2
> > (https://github.com/kworkflow/kworkflow/tags), and I'm trying to release
> > a new version of this package
> > (https://salsa.debian.org/siqueira/kworkflow/-/tree/master/debian). So,
> > to do a clean update, we should add  1:0.6.2-1 as an epoch to fix the
> > problem generated by the first version of this package.
> > 
> > Is that ok?
> 
> I've got recently a very similiar situtation with
> gnome-shell-extension-autohidetopbar, as there it was considered ok to use an
> epoch. [1]

Thanks all for the help with this topic.
 
> 
> [1] https://lists.debian.org/debian-devel/2022/03/msg00424.html
> 
> -- 
> tobi
> 
>  
> > Thanks
> > -- 
> > Rodrigo Siqueira
> > https://siqueira.tech
> 
> 



-- 
Rodrigo Siqueira
https://siqueira.tech


signature.asc
Description: PGP signature

Bug#1033161: ITP: obs-vintage-filter -- plugin for OBS Studio to make sources black and white or sepia

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-devel@lists.debian.org, cg2121 

* Package name: obs-vintage-filter
  Version : 1.0.0
  Upstream Contact: cg2121 
* URL : https://obsproject.com/forum/resources/vintage-filter.818/
* License : GPL-2
  Programming Lang: C
  Description : plugin for OBS Studio to make sources black and white or 
sepia

 This plugin provides a filter that adds the ability for sources to be black
 and white or sepia. This is useful to create vintage effects over photos,
 movies, webcam images, etc.

Re: Dependency for pre-configure script

[Antonio Russo]

On 3/18/23 09:19, Russ Allbery wrote:
> Antonio Russo  writes:
> 
>> Indeed, trying to install a package with a pre-depends on certbot that
>> has a debconf debian/config file does not have certbot installed by the
>> time the debconf script starts.  This is on testing.
> 
> See section 8 of the debconf specification:
> 
> The config-file contains a new element, which I call the
> configmodule. This is a program that will determine the configuration
> before the package is unpacked. This means it is usually run before
> the preinst, and before the package is unpacked!
> 
> This could definitely be clearer (and easier to find), but yes, this is
> expected behavior.
> 
>> My question: is there a way to ensure a package is installed *before*
>> getting debconf input from the user?  Alternatively, is there a way to
>> run debconf questions during a preinst script?
> 
> The tripwire package prompts in preinst, so that worked at some point, but
> it's for an old upgrade so I don't know if it's still working.  I think
> it's more common to prompt in postinst during configure.  I know of
> several packages that do that, although it's not considered ideal if you
> can avoid it.
> 

I was using db_get instead of db_input in the preinst script (doh!).

Everything works fine if you just do the (correct) action in preinst or
(better still) in postinst.  I.e., if you need any dependencies, do not
try to use them in the preconfigure scripts.

Thanks,
Antonio

Re: Dependency for pre-configure script

[Russ Allbery]

Antonio Russo  writes:

> Indeed, trying to install a package with a pre-depends on certbot that
> has a debconf debian/config file does not have certbot installed by the
> time the debconf script starts.  This is on testing.

See section 8 of the debconf specification:

The config-file contains a new element, which I call the
configmodule. This is a program that will determine the configuration
before the package is unpacked. This means it is usually run before
the preinst, and before the package is unpacked!

This could definitely be clearer (and easier to find), but yes, this is
expected behavior.

> My question: is there a way to ensure a package is installed *before*
> getting debconf input from the user?  Alternatively, is there a way to
> run debconf questions during a preinst script?

The tripwire package prompts in preinst, so that worked at some point, but
it's for an old upgrade so I don't know if it's still working.  I think
it's more common to prompt in postinst during configure.  I know of
several packages that do that, although it's not considered ideal if you
can avoid it.

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

Debian Med video conference tomorrow Sunday 2023-03-19 18:00 UTC

[Andreas Tille]

Hi,

this is the call for the next video conference of the Debian Med team
that are an established means to organise the tasks inside our team.

Meetings usually take us only 15-20min depending what we are talking
about and how many people are joining.  The next meeting is tomorrow
   
 https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230319T18

The meeting is on the Debian Social channel

 https://jitsi.debian.social/DebianMedCovid19

These video meetings were started in the Debian Med Biohackathon.
The topic is what contributors have done in the past period and to
coordinate the work until the next meeting.

For those who are interested in hot topics we want to tackle, here
are some items:

  - Task in frozen times ;-)

Newcomers are always welcome.

Lets keep on the great work and see you on Sunday
 
   Andreas.

-- 
http://fam-tille.de

Processed: reassign bug to kernel

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 1033149 linux
Bug #1033149 [general] general: debian 11 fails to hibernate when RAM usage 
above 7GB
Bug reassigned from package 'general' to 'linux'.
Ignoring request to alter found versions of bug #1033149 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1033149 to the same values 
previously set
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
1033149: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033149
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1033152: ITP: obs-3d-effect -- plugin for OBS Studio to add a static 3D effect to sources

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-devel@lists.debian.org, Exeldro 

* Package name: obs-3d-effect
  Version : 0.0.2
  Upstream Contact: Exeldro 
* URL : https://obsproject.com/forum/resources/3d-effect.1692/
* License : GPL-2
  Programming Lang: C
  Description : plugin for OBS Studio to add a static 3D effect to sources

 This plugin provides a filter that creates a static 3D effect over a
 source. In other words is possible to rotate a source around three axis.
 Also is possible to move the source over three axis and scale it over
 two axis.

Re: add make-4.4.1 to experimental

[Santiago Vila]

El 18/3/23 a las 4:00, Ilari Jääskeläinen escribió:

There is a new upstream release available.


We already know. It's already reported (twice) in the BTS:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029106

If you absolutely need to use make 4.4.1, you can try this,
which is what I did:

- Download and uncompress the tarball from ftp.gnu.org.
- Build it with "./configure" and "make".
- Either "make install" as root or just put the make
executable in /usr/local/bin by hand.

Thanks.

Re: add make-4.4.1 to experimental

[Tomas Pospisek]

Hi Ilari

On 18.03.23 04:00, Ilari Jääskeläinen wrote:


There is a new upstream release available.


Please report your issue as a wishlist ticket. To do that do as root:


apt install reportbug

Then do as non-root:

reportbug --severity=wishlist make

Greetings,
*t

add make-4.4.1 to experimental

[Ilari Jääskeläinen]

There is a new upstream release available.
Best regards, Ilari Jääskeläinen.
Lähetetty Windows 10 -laitteesta

Bug#1033149: general: debian 11 fails to hibernate when RAM usage above 7GB

[muhammad]

Package: general
Severity: important
X-Debbugs-Cc: m6619...@gmail.com

Dear Maintainer,

   * What led up to the situation?
  Fails to hibernate when RAM usage is above 7GB, despite having a
  swap of 30GB and total RAM of 16GB.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  Reduce RAM consumption.
   * What was the outcome of this action?
  If RAM usage below 6.5GB it hibenates successfully.
   * What outcome did you expect instead?
  .

Re: Dependency for pre-configure script

[Jonas Smedegaard]

Quoting Antonio Russo (2023-03-18 07:49:00)
> Hello,
> 
> I'm trying to perform a task during debian/package.config which
> requires another package to be installed.  I initially thought
> pre-depends would be strong enough, because [1] describes it by:
> 
> This field is like Depends, except that it also forces dpkg to
> complete installation of the packages named **before even starting
> the installation of the package which declares the pre-dependency,**
> as follows:
> 
> (my emphasis).  However, reading the next paragraphs does not appear to
> indicate any requirements are attempted to be satisfied before debconf/
> pre-configure questions are asked (only preinst, unpack, and configure
> are explicitly mentioned).
> 
> Indeed, trying to install a package with a pre-depends on certbot that
> has a debconf debian/config file does not have certbot installed by
> the time the debconf script starts.  This is on testing.
> 
> My question: is there a way to ensure a package is installed *before*
> getting debconf input from the user?  Alternatively, is there a way to
> run debconf questions during a preinst script?  Just doing
> 
>   db_get package/template
>   db_go
> 
> doesn't seem to work (it does nothing?). Am I doing something wrong? Is
> there a preferred way to do this?
> 
> Best,
> Antonio
> 
> [1] https://www.debian.org/doc/debian-policy/ch-relationships.html

What confuses here is not package installation order, but that debconf
is a cache of answers to questions, and that cache may be (and is, for
normal uses of debconf together with apt) filled ahead of time.

Because debconf is a cache of answers to questions, insisting that
questions should be answered *without* caching is against the core
design of the tool, and you then better not use that tool.  Beware
though, that there is a very good reason for the caching design: It was
invented to allow asking all install questions once, not force the user
to sit next to their computer for the whole duration of a system
installation to wait for each question that might pop up and pause the
install process until answered.  Therefore, since debconf got invented,
it has been added to Debian Policy that you should not ask questions
that cannot be cached (i.e. you really shouldn't bypass debconf).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Dependency for pre-configure script

[Antonio Russo]

Hello,

I'm trying to perform a task during debian/package.config which
requires another package to be installed.  I initially thought
pre-depends would be strong enough, because [1] describes it by:

This field is like Depends, except that it also forces dpkg to
complete installation of the packages named **before even starting
the installation of the package which declares the pre-dependency,**
as follows:

(my emphasis).  However, reading the next paragraphs does not appear to
indicate any requirements are attempted to be satisfied before debconf/
pre-configure questions are asked (only preinst, unpack, and configure
are explicitly mentioned).

Indeed, trying to install a package with a pre-depends on certbot that
has a debconf debian/config file does not have certbot installed by
the time the debconf script starts.  This is on testing.

My question: is there a way to ensure a package is installed *before*
getting debconf input from the user?  Alternatively, is there a way to
run debconf questions during a preinst script?  Just doing

  db_get package/template
  db_go

doesn't seem to work (it does nothing?). Am I doing something wrong? Is
there a preferred way to do this?

Best,
Antonio

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html