Re: Firefox 78.5.0esr

[Andrei POPESCU]

On Du, 13 dec 20, 19:02:17, Klaus Jantzen wrote:
> Hi,
> 
> I have the feeling that Firefox ist deteriorating.
> 
> In 'Preferences' I have set FF to be the default browser. But whenever I
> open FF on a link in an e-mail  FF tells me that it is not set as default
> browser and asks me to make FF the default browser.

No ideea about this.
 
> Having opened a link in an e-mail I can open another link in an e-mail only
> by copying that link, go to FF and  click on 'Paste & Go' in the address
> field.
> 
> Can this behavior be changed or is these features?

This is typically configured in the Desktop Environment.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

The volume of my pc got into issue.

[nalinidash]

I just installed VLC media player from software centre.But after that other 
media players and browsers are not audible means at very low sound.Please help 
how to fix it.I have used the headphones and tried it but same problem. Any 
suggetion to fix it?

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Debian 10 Buster - difficulty setting up mariaDB 10.3.27 users for use with Debian mediawiki 1.31 package

[Keith Christian]

I start out with:
 sudo apt -y install mediawiki
and it installs all packages including mariadb without problems.

Then, when starting to configure mediawiki with the web page, a
database has to be created along with a db user for mediawiki's use:
 http://localhost/mediawiki/mw-config/index.php?page=Welcome

I left Database host as "localhost"
I set Database name as "mediawiki"
Database table prefix is left blank
User account for installation is '"root"
.and so on.

I started Mariadb immediately after installation with:
sudo mysqld_safe --skip-grant-tables --skip-networking &

Next, I logged in with this:
 mysql -u root -p

But as I remembered, (it's been awhile) one cannot create any users in
this mode due to --skip-grant-tables.

E.g. I can create these users when logging in with mysql -u root:
 create user 'root'@'localhost' identified by 'foo123';
 create user 'mediawiki'@'localhost' identified by 'baz123';

but I can't log in with either user after restarting MariaDB with:
 sudo systemctl start mariadb

Seems I must always log in with
mysql -u root -p

There are lots of web pages mentioning this problem but none are
complete enough and my attempts have failed.

SO.Looking for a "bulletproof" document to set up MariaDB users so
I can get on with configuring Mediawiki.

I don't want to login as a 'root'@'localhost' user for routine DB work
and would rather use the 'mediawiki'@localhost' user for that.

Thanks.

Re: ps2pdf: why differences in different instances using unchanged PS source file

[Tom Browder]

On Sun, Dec 13, 2020 at 11:03 The Wanderer  wrote:
> On 2020-12-13 at 11:40, Tom Browder wrote:
> > personalized calendar for my wife. This year I have been cleaning up
> > my old Perl generating code (in preparation for converting it to Raku
> > [https://raku.org]) and noticed I am getting a different pdf output
> > for each run, even when the PS output source file is unchanged!
...
> What observation leads you to notice that the files are different?

When I have both files under git revision control and committed, a
rerun shows no change in the PS but a change in the PDF.

I read the rest of this post and your additional post. Thank you for
your forensic information. As long as I know what has changed, thanks
to you, I am content for the moment.
I have a Raku online friend (in CC above) who is an expert on PDF and
has built voluminous tools with his PDF modules in Raku. I think he
will either know about the problem or possibly know how to fix it
since he deals with the binary output and modifying it after the fact.

Have a very Happy New Year!

Cheers,

- Tom

P.S. I wasn't aware of vbindiff (or maybe I forgot).

Firefox 78.5.0esr

[Klaus Jantzen]

Hi,

I have the feeling that Firefox ist deteriorating.

In 'Preferences' I have set FF to be the default browser. But whenever I 
open FF on a link in an e-mail  FF tells me that it is not set as 
default browser and asks me to make FF the default browser.


Having opened a link in an e-mail I can open another link in an e-mail 
only by copying that link, go to FF and  click on 'Paste & Go' in the 
address field.


Can this behavior be changed or is these features?

--

K.D.J.

Re: ps2pdf: why differences in different instances using unchanged PS source file

[The Wanderer]

On 2020-12-13 at 12:03, The Wanderer wrote:

> ps2pdf appears to be part of ghostscript. Neither its man page nor the
> one for 'gs' (which it references) seem to contain any options for
> setting these timestamps, preventing their creation, or doing similarly
> with that UUID.
> 
> 
> The Debian reproducible-builds project has a page on eliminating this
> type of "multiple runs on the same input don't produce identical output"
> issue more generally[1], which links to a page on doing so with PDFs
> generated by Ghostscript specifically[2].
> 
> I'm not enough of an expert to follow that much further, but at a
> glance, it looks like the solution is to patch Ghostscript; the patch
> doesn't seem to have been accepted upstream, and it's not clear whether
> or not it's (going to be) distributed in the Debian package.
> 
> If you're not OK with handling that on your own end, then you may be out
> of luck with this.
> 
> [1] https://wiki.debian.org/ReproducibleBuilds/Howto
> [2] https://wiki.debian.org/ReproducibleBuilds/PdfGeneratedByGhostscript

On closer examination of that latter link, apparently it's possible to
bypass the timestamps issue by using a command called 'faketime' (from a
package of the same name), to tell the program that the system-clock
time is set to something other than what it actually is.

The UUID is generated based on time, but apparently it's done in a way
that isn't affected by faketime, and that is what needs to be patched.

So you can probably eliminate three of the five differences by just
prepending 'faketime ' to your ps2pdf command. The other two will still
probably need patching of ghostscript to fix, however, and the link to
the patch from the above page seems to be dead.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: ps2pdf: why differences in different instances using unchanged PS source file

[The Wanderer]

On 2020-12-13 at 11:40, Tom Browder wrote:

> I have been using ps2pdf for many years on a PS source file for a
> personalized calendar for my wife. This year I have been cleaning up
> my old Perl generating code (in preparation for converting it to Raku
> [https://raku.org]) and noticed I am getting a different pdf output
> for each run, even when the PS output source file is unchanged!
> 
> I have looked at the detailed options for ps2pdf and don't see
> anything that stands out to me when using the default settings.
> 
> I attempted a comparison of two different pdf outputs by running "od
> -c file.pdf" on the two outputs but cannot identify anything familiar
> to me about the differences.

What observation leads you to notice that the files are different?

> My command that runs the actual process is this:
> 
> $ ps2pdf  -dAutoRotatePages=/None  file.ps  file.pdf
> 
> I am running on Debian Buster with current updates.
> 
> Any suggestions to produce constant output pdf for constant ps input
> are appreciated.

I ran this command on a random .ps file from a package I have installed,
to two output files.

cmp verified that the files were different.


Running vbindiff on the files shows that the and second differences are
in "ModifyDate" anbd "CreateDate" tags; each file appears to contain
multiple timestamps, and since the files were not generated at the same
second, those timestamps are going to be different.

The third difference is a UUID; that's intended to be globally unique,
and I'm guessing they intentionally generate a new one per PDF so that
they can be told apart.

The fourth difference is a CreationDate label, again with a timestamp.

The fifth and final difference, right before the end of the file, is an
unintelligible string of hex digits. My first suspicion is that it's a
hash of the rest of the file, to make validity checking possible.

So it doesn't look like the differences are meaningful, but they do
exist.


ps2pdf appears to be part of ghostscript. Neither its man page nor the
one for 'gs' (which it references) seem to contain any options for
setting these timestamps, preventing their creation, or doing similarly
with that UUID.


The Debian reproducible-builds project has a page on eliminating this
type of "multiple runs on the same input don't produce identical output"
issue more generally[1], which links to a page on doing so with PDFs
generated by Ghostscript specifically[2].

I'm not enough of an expert to follow that much further, but at a
glance, it looks like the solution is to patch Ghostscript; the patch
doesn't seem to have been accepted upstream, and it's not clear whether
or not it's (going to be) distributed in the Debian package.

If you're not OK with handling that on your own end, then you may be out
of luck with this.

[1] https://wiki.debian.org/ReproducibleBuilds/Howto
[2] https://wiki.debian.org/ReproducibleBuilds/PdfGeneratedByGhostscript

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

ps2pdf: why differences in different instances using unchanged PS source file

[Tom Browder]

I have been using ps2pdf for many years on a PS source file for a
personalized calendar for my wife. This year I have been cleaning up
my old Perl generating code (in preparation for converting it to Raku
[https://raku.org]) and noticed I am getting a different pdf output
for each run, even when the PS output source file is unchanged!

I have looked at the detailed options for ps2pdf and don't see
anything that stands out to me when using the default settings.

I attempted a comparison of two different pdf outputs by running "od
-c file.pdf" on the two outputs but cannot identify anything familiar
to me about the differences.

My command that runs the actual process is this:

$ ps2pdf  -dAutoRotatePages=/None  file.ps  file.pdf

I am running on Debian Buster with current updates.

Any suggestions to produce constant output pdf for constant ps input
are appreciated.

Blessings,

-Tom

Re: setting the date for testing

[hdv@gmail]

On 2020-12-13 16:34, Michael Grant wrote:


and now it appears to stick.  So I'm good.  Thanks for your help though!

Michael Grant


Glad to read you have solved it.

Grx HdV

Re: setting the date for testing

[Michael Grant]

> Could it be that you have systemd-timesyncd running?
> 
> BTW, this is what I do to manually/explicitly set the system time (taken
> verbatim from my vimwiki, so don't mind the wording):
> 
> Changing the Current Date:
> 
> # timedatectl set-time 
> 
> Or both at once:
> 
> # timedatectl set-time  
> 
> This commands will fail if an NTP service is enabled. The NTP service can be
> enabled and disabled using a command as follows:
> 
> # timedatectl set-ntp 
> 
> Changes to the status of chrony or ntpd will not be immediately noticed by
> timedatectl. If changes to the configuration or status of these tools are
> made, enter the following command:
> 
> # systemctl restart systemd-timedated.service
> 
> By default, the system is configured to use UTC. To configure your system to
> maintain the clock in the local time, run the timedatectl command with the
> set-local-rtc option as root:
> 
> # timedatectl set-local-rtc 

I tried stopping systemd-timedated and ntp:

# systemctl stop systemd-timedated.service
# systemctl stop ntp

Then:

# timedatectl set-time 2025-12-13 14:01:42

and here's what I see by running date every few seconds:

# date
Sat 13 Dec 14:01:43 GMT 2025
# date
Sat 13 Dec 14:01:44 GMT 2025
# date
Sun 13 Dec 14:01:48 GMT 2020
# date
Sun 13 Dec 14:01:49 GMT 2020

I can't see anything running that would re-set the date.

This is a VM running inside virtualbox.  I just figured it out, it WAS
using the hardware clock.  I shut down the VM and ran this on the
host:

VBoxManage modifyvm MyVM --biossystemtimeoffset 12623040

and now when it booted, I saw this:

$ date
Sun 13 Dec 15:29:47 GMT 2020
$ date
Fri 13 Dec 15:29:59 GMT 2024
$ date
Fri 13 Dec 15:30:00 GMT 2024
$ date
Fri 13 Dec 15:30:01 GMT 2024
$ date
Fri 13 Dec 15:30:01 GMT 2024
$ date
Fri 13 Dec 15:31:49 GMT 2024

and now it appears to stick.  So I'm good.  Thanks for your help though!

Michael Grant


signature.asc
Description: PGP signature

Re: setting the date for testing

[hdv@gmail]

On 2020-12-13 14:36, Michael Grant wrote:

This did not work:

# timedatectl set-ntp true

Failed to set ntp: NTP not supported

# timedatectl set-ntp false

Failed to set ntp: NTP not supported

Other ideas?

I am trying to set the date manually so that I can test the system set 
at future dates.  Setting the system using the date command, it just 
resets itself back to the current date/time after a few seconds.  How 
can I stop this?


Thanks!

Michael Grant

*From: *hdv@gmail 
*Sent: *07 December 2020 07:53
*To: *debian-user@lists.debian.org 
*Subject: *Re: setting the date for testing

On 2020-12-06 21:56, hdv@gmail wrote:

 > # timedatectl set-ntp true

I am sorry for the typo. This should of course have been "false"!

Grx HdV



Could it be that you have systemd-timesyncd running?

BTW, this is what I do to manually/explicitly set the system time (taken 
verbatim from my vimwiki, so don't mind the wording):


Changing the Current Date:

# timedatectl set-time 

Or both at once:

# timedatectl set-time  

This commands will fail if an NTP service is enabled. The NTP service 
can be enabled and disabled using a command as follows:


# timedatectl set-ntp 

Changes to the status of chrony or ntpd will not be immediately noticed 
by timedatectl. If changes to the configuration or status of these tools 
are made, enter the following command:


# systemctl restart systemd-timedated.service

By default, the system is configured to use UTC. To configure your 
system to maintain the clock in the local time, run the timedatectl 
command with the set-local-rtc option as root:


# timedatectl set-local-rtc 

HTH

Grx HdV

RE: setting the date for testing

[Michael Grant]

This did not work:

# timedatectl set-ntp true
Failed to set ntp: NTP not supported
# timedatectl set-ntp false
Failed to set ntp: NTP not supported

Other ideas?

I am trying to set the date manually so that I can test the system set at 
future dates.  Setting the system using the date command, it just resets itself 
back to the current date/time after a few seconds.  How can I stop this?

Thanks!

Michael Grant
From: hdv@gmail
Sent: 07 December 2020 07:53
To: debian-user@lists.debian.org
Subject: Re: setting the date for testing

On 2020-12-06 21:56, hdv@gmail wrote:

 > # timedatectl set-ntp true

I am sorry for the typo. This should of course have been "false"!

Grx HdV

Re: telecharger video

[Kohler Gerard]

merci à tous,

je vais out tester !