Re: What is this gibberish?

[Todd Zullinger]

Samuel Sieb wrote:
> It lets me know that something else was run, just like there's a line saying
> that it's running a scriptlet for package whatever.  As I mentioned, I would
> much prefer that there was some part of that line that said what the unit is
> for, but at least with that line I know that it's happening and I can check
> the logs if necessary.

There is a lot that is run which is not included in the
rpm/dnf output.  Including it all would be far too verbose
to be useful.  Scriptlets are supposed to be silent.

>> All I see in the case of the man-db-cache-update scriptlet
>> is that the typical >/dev/null was missed when it was
>> converted to use systemd-run.  The scriptlet before was:
>> 
>>  MAN_NO_LOCALE_WARNING=1 /usr/bin/mandb -q
>> 
>> That is silent by design.  The MAN_NO_LOCALE_WARNING=1 was
> 
> This being silent ended up being a problem.  mandb took a long time to run
> and there was no explanation on why the dnf transaction appeared to be hung
> for several minutes.  It would have been good if there had been some output
> saying that mandb was being run.  Sure you might be able to switch consoles
> and run "ps" if you know about that, but this would have been easier.

The problem wasn't that it was silent.  It was that it was a
long(ish)-running process that was not suited to run as a
scriptlet.  It's better done via cron or as it is now as a
transient systemd-run service.

Anyway, I think the current output is unintentional.
Whether the man-db packager maintainers agree or not, I
don't know.  I do feel confident that this output is a
departure from how scriptlets have long behaved and it
should be more deliberately and consistently designed if
it's going to be kept.

-- 
Todd
~~
Future, n. That period of time when our affairs prosper, our friends
are true and our happieness is assured.
-- Ambrose Bierce, "The Devil's Dictionary"



signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: how to digitize a sizable CD collection using fedora?

[Samuel Sieb]

On 02/03/2018 09:44 PM, Ed Greshko wrote:

I happen to be the type of person that is more interested in just listening to 
the
music than thinking I may want to do more conversions later.  That is why I 
spent the
time when I did to find what works best for "me".  As a matter of fact, in the 3
years since I transferred my collection from CD to ogg files I've never said to
myself "I wish I had done things differently".  And I've never been tempted to
recreate the original CD.  :-)  Only recently did I replace my CD/DVD drive 
which had
been broken for about 2 years.


Well, see, I started doing conversions from CD to MP3 (probably at 
128Kb) over 20 years ago when hard drives were still measured in MB. :-) 
 Over the years, hard drives have become larger and I've switched to 
ogg and raised the quality level a couple of times.  Now hard drives are 
large enough that I can go right to flac as the maximum quality and if 
there are any new formats or whatever, I can very easily re-encode the 
whole collection at once with no difficulty.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Samuel Sieb]

On 02/03/2018 09:30 PM, Todd Zullinger wrote:

Samuel Sieb wrote:

How is it not useful?  I'm happy to be aware of that part of the
transaction.  It would certainly be more useful if there was some indication
of what specifically it was for.


IMO, it's not useful because it tells the user nothing about
what script is actually running.

What useful information is included in:

   Running as unit: run-re2635381e8fe44a6aad4926eddab6961.service


It lets me know that something else was run, just like there's a line 
saying that it's running a scriptlet for package whatever.  As I 
mentioned, I would much prefer that there was some part of that line 
that said what the unit is for, but at least with that line I know that 
it's happening and I can check the logs if necessary.



All I see in the case of the man-db-cache-update scriptlet
is that the typical >/dev/null was missed when it was
converted to use systemd-run.  The scriptlet before was:

 MAN_NO_LOCALE_WARNING=1 /usr/bin/mandb -q

That is silent by design.  The MAN_NO_LOCALE_WARNING=1 was


This being silent ended up being a problem.  mandb took a long time to 
run and there was no explanation on why the dnf transaction appeared to 
be hung for several minutes.  It would have been good if there had been 
some output saying that mandb was being run.  Sure you might be able to 
switch consoles and run "ps" if you know about that, but this would have 
been easier.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: how to digitize a sizable CD collection using fedora?

[Joe Zeff]

On 02/03/2018 09:44 PM, Ed Greshko wrote:

I happen to be the type of person that is more interested in just listening to 
the
music than thinking I may want to do more conversions later.


Same here, along with bad hearing.  I have an artillery notch in both 
ears, plus tinnitus, caused by spending most of '72 in Tonkin Gulf doing 
shore support with a 5"/54.  I really don't care if the format's lossy 
or not because I'm not going to hear the difference.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: how to digitize a sizable CD collection using fedora?

[Ed Greshko]

On 02/04/18 11:58, Samuel Sieb wrote:
> On 02/03/2018 04:21 PM, Ed Greshko wrote:
>> I've found that folks have a tendency to overvalue lossless formats but in 
>> fact their
>> ears aren't up to the task.
>
> I definitely do notice mp3 artifacts sometimes.  However, the reason I've 
> switched
> to flac is just to have a true archive of the original cd.  It's a straight 
> copy
> without even volume normalization.  I then convert that to a high-quality ogg 
> file
> with normalization.  In the future, if I need a different format, different 
> volume
> adjustment, or even recreate the original cd, I don't have to use the 
> compressed
> version, I can go back to the original copy.
>

Of course everyone's ability to recognize "artifacts" is going to vary 
depending on
their physical condition as well as the equipment which they listen on. 

What someone chooses to do with regards to transferring from CD to HD will 
depend on
how they intend to play, how much space they want to devote, and how much time 
they
expect to devote to doing the work.

I happen to be the type of person that is more interested in just listening to 
the
music than thinking I may want to do more conversions later.  That is why I 
spent the
time when I did to find what works best for "me".  As a matter of fact, in the 3
years since I transferred my collection from CD to ogg files I've never said to
myself "I wish I had done things differently".  And I've never been tempted to
recreate the original CD.  :-)  Only recently did I replace my CD/DVD drive 
which had
been broken for about 2 years.

Most of my listening is done via VLC on one of my Android devices with my Bose
headphones.  Since VLC can play flac, mp3, ogg, as well as wav I've never been
constrained by the format others have sent to me.  Kind of why I've stayed away 
from
Apple products.  I've wanted to share music and videos with a few Apple Fan 
Friends
and grumbled when I had to convert for them.  Got close to wishing I would have 
spent
a few extra $ on a NAS that did real-time conversions.  :-)


-- 
A motto of mine is: When in doubt, try it out



signature.asc
Description: OpenPGP digital signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Todd Zullinger]

Samuel Sieb wrote:
> On 02/03/2018 05:57 PM, Todd Zullinger wrote:
>> The unit tasks are logged, so you can see them with
>> journalctl or in syslog.  (Not that it's at all ideal to
>> have to look around to find what may have caused this
>> less-than-useful output.)
> 
> How is it not useful?  I'm happy to be aware of that part of the
> transaction.  It would certainly be more useful if there was some indication
> of what specifically it was for.

IMO, it's not useful because it tells the user nothing about
what script is actually running.

What useful information is included in:

  Running as unit: run-re2635381e8fe44a6aad4926eddab6961.service

It says that something is running, but no detail about what
it is.  If more scriptlets add similar calls to systemd-run,
then we'll just have more of those lines, none of which
allow a user to do anything without digging into the logs to
see what service was actually run.  And since the
information is already in the logs, sending the least useful
part of it to stdout during the rpm transaction is not of
any real value.

This is similar to enabling or starting a service in %post.
The output from systemctl start (or /sbin/service, from way
back) isn't sent to stdout either.  Scriptlets are not
supposed to be noisy.

>> The man-db-cache-update service checks /etc/sysconfig/man-db
>> and if the variable SERVICE is not 'no' it runs.  So it
>> should be possible to disable this proactive updating of the
>> man-db if desired.
> 
> This mandb run has always been done.  The change now to running it as a
> service is because when it was being run as part of the main process, it was
> taking a very long time sometimes and holding up the rest of the
> transaction.  Now, it's running separately and is not waited for.

Sure, I understand that part.  I still don't think there's
any value to leaving the systemd-run output in the
transaction output.

> Personally, I hope it's not accepted and I expect there are other parts that
> are using or will use this method.

I'm genuinely curious what value you see in having these
"Running as unit: run-*.service" lines in the output.

I can see wanting to know what was happening if one of them
hangs or causes errors, but the way this is currently done,
the only error output we'd see is if the systemd-run call
itself failed.  I care more about error output of any
commands which are run as scriptlets, but the output of the
systemd service is sent to the logs rather than the terminal
already, so I have to look there for output and errors.

All I see in the case of the man-db-cache-update scriptlet
is that the typical >/dev/null was missed when it was
converted to use systemd-run.  The scriptlet before was:

MAN_NO_LOCALE_WARNING=1 /usr/bin/mandb -q

That is silent by design.  The MAN_NO_LOCALE_WARNING=1 was
added explicitly to avoid spurious output from the scriptlet
in 98f1386 ("suppress potential locale warning when
installing with glibc-minimal-langpack - resolves #1314633",
2016-03-14):

https://src.fedoraproject.org/rpms/man-db/c/98f13860c7

-- 
Todd
~~
(When asked whether he liked children) "Ah yes...boiled or fried."
-- W.C. Fields



signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Todd Zullinger]

Tom Horsley wrote:
> On Sun, 4 Feb 2018 10:17:10 +0800
> Ed Greshko wrote:
> 
>> But please be aware that you're subverting the plot by a secret society to 
>> produce
>> copious indecipherable output so users will switch over to GUIs and have 
>> things
>> hidden from view.  :-) :-)  
> 
> And then the secret society can cause great amusement by
> utterly changing the GUI in every release to see how long it
> takes people to figure out the new one just as they
> got used to the old one :-).

Haha.  :)

They'll pry my TUI from my cold, carpal-tunnel-syndrome'd
hands.

I still remember many years ago, before I heard of linux,
someone's reason for preferring computerized text files to a
book with the same data: "I can't grep a dead tree."  So as
long as we can grep the code, the secrets can't be too well
hidden. ;)

-- 
Todd
~~
How much does it cost to entice a dope-smoking UNIX system guru to
Dayton?
-- Brian Boyle, UNIX/WORLD's First Annual Salary Survey



signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Samuel Sieb]

On 02/03/2018 05:57 PM, Todd Zullinger wrote:

The unit tasks are logged, so you can see them with
journalctl or in syslog.  (Not that it's at all ideal to
have to look around to find what may have caused this
less-than-useful output.)


How is it not useful?  I'm happy to be aware of that part of the 
transaction.  It would certainly be more useful if there was some 
indication of what specifically it was for.



The man-db-cache-update service checks /etc/sysconfig/man-db
and if the variable SERVICE is not 'no' it runs.  So it
should be possible to disable this proactive updating of the
man-db if desired.


This mandb run has always been done.  The change now to running it as a 
service is because when it was being run as part of the main process, it 
was taking a very long time sometimes and holding up the rest of the 
transaction.  Now, it's running separately and is not waited for.



I submitted a patch to quiet this output:

 https://src.fedoraproject.org/rpms/man-db/pull-request/5

If that's accepted then we'll eventually stop seeing this
anytime an rpm installs or removes man pages.


Personally, I hope it's not accepted and I expect there are other parts 
that are using or will use this method.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: how to digitize a sizable CD collection using fedora?

[Wolfgang Pfeiffer]

On Sun, 04 Feb 2018 11:38:40 +1030
Tim  wrote:

> Allegedly, on or about 4 February 2018, Ed Greshko sent:
> > I've found that folks have a tendency to overvalue lossless formats
> > but in fact their ears aren't up to the task.  
> 
> That's often true (but I frequently find MP3 encoding is noticeably
> awful).  And the converse is often true, that people rip down to a
> really crappy bitrate, thinking that saving space is more important
> than it is (producing what sounds like compact cassette recordings from
> shortwave radio).

I think it's true, that it's possible to encode to  crappy mp3 quality.

But it's definitely true that with fine tools you can encode to mp3's with
a quality so high that for  me at least it's difficult to find a difference 
to the wav's they were encoded from, even with decent stereo 
equipment. Also true, I'm old, so I might have ruined ears enough
to be unable to hear differences where they actually are. 

Easy test: try this in a dir with  wav's, and the command below will 
(should) code them to mp3's. With the resulting mp3's I'd bet 
anyone will have difficulties to find a remarkable difference 
between the wav's and the mp3's ...

for f in *.wav; do ffmpeg -i "$f" -codec:a libmp3lame -qscale:a 0 
"${f/%wav/mp3}"; done

For a quick check about what ffmpeg is actually doing here:
https://trac.ffmpeg.org/wiki/Encode/MP3

Feeling challenged, anyone? ... ;)

Regards
-- 
Wolfgang Pfeiffer
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: how to digitize a sizable CD collection using fedora?

[Samuel Sieb]

On 02/03/2018 04:21 PM, Ed Greshko wrote:

I've found that folks have a tendency to overvalue lossless formats but in fact 
their
ears aren't up to the task.


I definitely do notice mp3 artifacts sometimes.  However, the reason 
I've switched to flac is just to have a true archive of the original cd. 
 It's a straight copy without even volume normalization.  I then 
convert that to a high-quality ogg file with normalization.  In the 
future, if I need a different format, different volume adjustment, or 
even recreate the original cd, I don't have to use the compressed 
version, I can go back to the original copy.

___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Tom Horsley]

On Sun, 4 Feb 2018 10:17:10 +0800
Ed Greshko wrote:

> But please be aware that you're subverting the plot by a secret society to 
> produce
> copious indecipherable output so users will switch over to GUIs and have 
> things
> hidden from view.  :-) :-)  

And then the secret society can cause great amusement by
utterly changing the GUI in every release to see how long it
takes people to figure out the new one just as they
got used to the old one :-).
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Ed Greshko]

On 02/04/18 09:57, Todd Zullinger wrote:
> Samuel Sieb wrote:
>> On 02/02/2018 04:31 AM, Tom Horsley wrote:
>>> Just did a dnf update, this comes out:
>>>
>>> ...
>>>Running scriptlet: firefox-58.0.1-1.fc27.x86_64 
>>> 18/18
>>>Running scriptlet: firefox-58.0-4.fc27.x86_64   
>>> 18/18
>>> Running as unit: run-r1880116b569f49288e6d0da0c5832367.service
>>> Running as unit: run-r329e01978cfe43258a05456898834edb.service
>>>Verifying: GraphicsMagick-1.3.28-1.fc27.x86_64   
>>> 1/18
>>>Verifying: GraphicsMagick-c++-1.3.28-1.fc27.x86_64   
>>> 2/18
>>> ...
>>>
>>> Running as unit? Huh?
>> rpm is now running some tasks asynchronously using temporary systemd units.
>> I don't know which tasks are being done this way, but I expect at least the
>> mandb update is.  If you were quick enough, you should have been able to get
>> more info by running "systemctl status
>> run-r1880116b569f49288e6d0da0c5832367.service".
> The unit tasks are logged, so you can see them with
> journalctl or in syslog.  
Snip
> Just knowing what it is is enough for me, I
Snip
>  Plus, the
> output we get now is effectively worthless. :)
>
> I submitted a patch to quiet this output:
>
> https://src.fedoraproject.org/rpms/man-db/pull-request/5
>
> If that's accepted then we'll eventually stop seeing this
> anytime an rpm installs or removes man pages.
>
Thanks for doing the research.

But please be aware that you're subverting the plot by a secret society to 
produce
copious indecipherable output so users will switch over to GUIs and have things
hidden from view.  :-) :-)  

 
-- 
A motto of mine is: When in doubt, try it out



signature.asc
Description: OpenPGP digital signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: What is this gibberish?

[Todd Zullinger]

Samuel Sieb wrote:
> On 02/02/2018 04:31 AM, Tom Horsley wrote:
>> Just did a dnf update, this comes out:
>> 
>> ...
>>Running scriptlet: firefox-58.0.1-1.fc27.x86_64 
>> 18/18
>>Running scriptlet: firefox-58.0-4.fc27.x86_64   
>> 18/18
>> Running as unit: run-r1880116b569f49288e6d0da0c5832367.service
>> Running as unit: run-r329e01978cfe43258a05456898834edb.service
>>Verifying: GraphicsMagick-1.3.28-1.fc27.x86_64   
>> 1/18
>>Verifying: GraphicsMagick-c++-1.3.28-1.fc27.x86_64   
>> 2/18
>> ...
>> 
>> Running as unit? Huh?
> 
> rpm is now running some tasks asynchronously using temporary systemd units.
> I don't know which tasks are being done this way, but I expect at least the
> mandb update is.  If you were quick enough, you should have been able to get
> more info by running "systemctl status
> run-r1880116b569f49288e6d0da0c5832367.service".

The unit tasks are logged, so you can see them with
journalctl or in syslog.  (Not that it's at all ideal to
have to look around to find what may have caused this
less-than-useful output.)

As you said, the man-db package includes a transaction
trigger which runs the man-db-cache-update service when any
package in the transaction adds or removes files from
/usr/share/man:

$ rpm -q --filetriggers man-db
transfiletriggerin scriptlet (using /bin/sh) -- /usr/share/man
if [ -x /usr/bin/systemd-run -a -x /usr/bin/systemctl ]; then
/usr/bin/systemd-run /usr/bin/systemctl start man-db-cache-update || :
fi

# update cache
transfiletriggerpostun scriptlet (using /bin/sh) -- /usr/share/man
if [ -x /usr/bin/systemd-run -a -x /usr/bin/systemctl ]; then
/usr/bin/systemd-run /usr/bin/systemctl start man-db-cache-update || :
fi

The man-db-cache-update service checks /etc/sysconfig/man-db
and if the variable SERVICE is not 'no' it runs.  So it
should be possible to disable this proactive updating of the
man-db if desired.

Just knowing what it is is enough for me, I think.  It
worried me the first time I noticed it when updating a
package I built in a COPR, since I knew there were no
systemd scriptlets in that package.

I'm not sure why the man-db trigger scriptlets don't direct
output to /dev/null like most scriptlets.  It seems like
they should.  The systemd service call is logged, so if
there's a problem it should be visible in syslog.  Plus, the
output we get now is effectively worthless. :)

I submitted a patch to quiet this output:

https://src.fedoraproject.org/rpms/man-db/pull-request/5

If that's accepted then we'll eventually stop seeing this
anytime an rpm installs or removes man pages.

-- 
Todd
~~
Man was made at the end of the week's work when God was tired.
-- Mark Twain



signature.asc
Description: PGP signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: how to digitize a sizable CD collection using fedora?

[Tim]

Allegedly, on or about 4 February 2018, Ed Greshko sent:
> I've found that folks have a tendency to overvalue lossless formats
> but in fact their ears aren't up to the task.

That's often true (but I frequently find MP3 encoding is noticeably
awful).  And the converse is often true, that people rip down to a
really crappy bitrate, thinking that saving space is more important
than it is (producing what sounds like compact cassette recordings from
shortwave radio).

But if you rip to a lossless format that you use now (e.g. ogg vorbis),
and later on change players to one that doesn't support that lossless
format (e.g. mp3-only, particularly when it comes to hardware devices),
you have to re-encode from one lossy scheme to another, and that *does*
introduce audible artefacts.

I've faced that situation.  I generally compress to ogg vorbis, because
it does the job well on almost everything I have, and I don't hear
disturbing audio artefacts that I continually hear with MP3 (direct
uncompressed WAV to MP3, I might add, too).  But, from time to time,
find I want to play a file on something that doesn't support it.

Given sufficient storage space, I'd rip to a lossless format, like
flac.  That gives you a good archive of the file.  Then if you want to
export to a hardware device, you have the choice of doing it any way
that you like, without horrible degradation.

Another issue that crops up with various audio formats is an inability
to do gapless playback of albums.  That can depend on the format *and*
the player.

-- 
[tim@localhost ~]$ uname -rsvp
Linux 4.14.14-200.fc26.x86_64 #1 SMP Fri Jan 19 13:27:06 UTC 2018 x86_64

Boilerplate:  All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.

You can't have equality AND special treatment.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: how to digitize a sizable CD collection using fedora?

[Ed Greshko]

On 02/04/18 08:21, Ed Greshko wrote:
> I've found that folks have a tendency to overvalue lossless formats but in 
> fact their
> ears aren't up to the task.


I also should have included that their audio equipment isn't "good" enough to 
make
the difference noticeable.

Kind of like some folks insisting on the highest pixel density for their camera
equipment and then only viewing on a standard monitor in relatively small 
format.

-- 
A motto of mine is: When in doubt, try it out



signature.asc
Description: OpenPGP digital signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: how to digitize a sizable CD collection using fedora?

[Ed Greshko]

On 02/04/18 06:03, Robert P. J. Day wrote:
> On Sat, 3 Feb 2018, Jon LaBadie wrote:
>
>> On Fri, Feb 02, 2018 at 05:29:40PM -0500, Robert P. J. Day wrote:
>>>   one of my new year's resolutions was to digitize several hundred
>>> music CDs in preparation for figuring out what system to use in the
>>> domicile to play them, but regardless of how i decide to eventually
>>> play these CDs, i'm looking for recommendations for how to rip them to
>>> hard drive before i decide how i will end up using them.
>>>
>>>   given the cheapness of hard drives (and that i have a QNAP NAS
>>> anyway), i don't really care about disk usage, so i figured on ripping
>>> all of those CDs using (lossless) FLAC format, and i can decide down
>>> the road whether to convert them to a different format to save on
>>> space.
>>>
>>>   in short, any recommendations on simply ripping all these CDs to
>>> hard drive, while having no idea what i will eventually use to play
>>> them?
>> I only had about 60 CDs to rip, but like you was uncertain about
>> format.
>>
>> I used "abcde" which let me save .wav, .flac, .oog, and .mp3 in 1
>> run.
>   for now, i was thinking of ripping just to .flac since that's
> lossless and i can always decide later what further format to rip to
> in order to save space. does that make sense? i just want to avoid
> having to go back and rip everything all over again.
>

What makes sense to me is to first select a few individual tracks with different
types of music.  For example, if you have classical, pick a few with quiet 
movements
with only strings, those with lots of highs, etc.   Then record and listen to 
all of
those in various formats.  Even better if you have have someone play them for 
you in
different formats to see if you can tell the difference.

I've found that folks have a tendency to overvalue lossless formats but in fact 
their
ears aren't up to the task.


-- 
A motto of mine is: When in doubt, try it out



signature.asc
Description: OpenPGP digital signature
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Riddle me this: grep / regx experts

[R. G. Newbury]

 Subject: Re: Riddle me this: grep / regx experts

Allegedly, on or about 2 February 2018, R. G. Newbury sent:

I am cleaning up some html code, using sed to standardize the
formatting. I was searching for specific instances of code to amend
using grep.


In case you're not aware of it, there's a HTML tidy command that
neatens up HTML.


I am using sed basically for search and replace.
I already use tidy, but it does not deal with my problem which is that 
the text has multiple variations in the *text* formatting in the many 
different files. This screws up the parsing and requires normalization.


Tidy does not touch that. Unfortunately.

Geoff

 R. Geoffrey Newbury
 954 Owenwood Drive
 Mississauga, Ontario, L5H 3J2

  t905-271-9600 newb...@mandamus.org
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Fedora27: Cannot set the default network route

[Terry Barnaby]

On 02/02/18 16:40, Bill Shirley wrote:

You didn't post the command or its output.  How can anyone help you?

What's the output of these two commands?
ip -o -4 addr
ip -o -4 route

Bill

ip -o -4 addr
1: lo    inet 127.0.0.1/8 scope host lo\   valid_lft forever 
preferred_lft forever
2: enp2s0    inet 192.168.202.2/24 brd 192.168.202.255 scope global 
dynamic enp2s0\   valid_lft 1205223sec preferred_lft 1205223sec


ip -o -4 route
default via 192.168.202.1 dev enp2s0 proto static metric 100
192.168.202.0/24 dev enp2s0 proto kernel scope link src 192.168.202.2 
metric 100


These are when the route is up normally after a DHCP.
The system is fine normally, its just that I wanted to manually change 
the default route to test a different router.

I have managed to do this now by hardcoding the route on the next boot.
I think the issue must be NetworkManager doing something more than it 
used to.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: how to digitize a sizable CD collection using fedora?

[Robert P. J. Day]

On Sat, 3 Feb 2018, Jon LaBadie wrote:

> On Fri, Feb 02, 2018 at 05:29:40PM -0500, Robert P. J. Day wrote:
> >
> >   one of my new year's resolutions was to digitize several hundred
> > music CDs in preparation for figuring out what system to use in the
> > domicile to play them, but regardless of how i decide to eventually
> > play these CDs, i'm looking for recommendations for how to rip them to
> > hard drive before i decide how i will end up using them.
> >
> >   given the cheapness of hard drives (and that i have a QNAP NAS
> > anyway), i don't really care about disk usage, so i figured on ripping
> > all of those CDs using (lossless) FLAC format, and i can decide down
> > the road whether to convert them to a different format to save on
> > space.
> >
> >   in short, any recommendations on simply ripping all these CDs to
> > hard drive, while having no idea what i will eventually use to play
> > them?
>
> I only had about 60 CDs to rip, but like you was uncertain about
> format.
>
> I used "abcde" which let me save .wav, .flac, .oog, and .mp3 in 1
> run.

  for now, i was thinking of ripping just to .flac since that's
lossless and i can always decide later what further format to rip to
in order to save space. does that make sense? i just want to avoid
having to go back and rip everything all over again.

rday
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Copying/duplicating files from ServerA to ServerB

[stan]

On Sat, 3 Feb 2018 11:12:27 -0500
bruce  wrote:

> does the rsync handle "hidden" files/dirs??

Yes.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: Copying/duplicating files from ServerA to ServerB

[bruce]

Hi.

Thanks for the replies.

So far, the dup process will consist of
a- generate list of all service/3rd party processes running on the base server
b- generate list of packages installed from the dnf/yum/rpm
 --hopefully "a" and "b" more or less match!
c- generate the required "steps" to implement/regenerate any misc
processes on the target server
to match the base server
d- handle/recheck any/all config files -- fstab/ssh_config/exportfs/etc..
1- generate/fire up the base server
2- replicate the users from the base server to the target server
-this requires same username/home folders/guid to allow the same
perms/privs on the files/dirs as well as process ownership
3- rsync/cp all dirs/folders from base to target
4- regenerate all packages from yum/dnf as required on the target server
5- reinstall any 3rd party apps/processes  -- yum/dnf/pip/easy_install etc..
6- restart processes
7- firewall/dns/netwroking/port issues   -- TBD..

etc/passwd
etc/shadow
etc/group
etc:gshadow


does the rsync handle "hidden" files/dirs??

have I left anything out??

thanks




On Fri, Feb 2, 2018 at 5:01 PM, Rick Stevens  wrote:
> On 02/02/2018 10:09 AM, stan wrote:
>> On Fri, 2 Feb 2018 08:36:25 -0500
>> bruce  wrote:
>>
>>> Looking to completely duplicate/replicate one server to
>>> another.Running Centos/Fed. I've seen a number of different
>>> articles/etc on different ways of doing this.
>>>
>>> Assuming I'm not using chef/puppet/ansible/etc can anyone give
>>> thoughts on best approaches for this. Articles are cool as well.
>>>
>>> Key Items:
>>> -Need to Maintain same users/passwds
>>> -Need to maintain all dirs/files heirarchy
>>> -Need all system/3rd party processes/apps running
>>> -All config/cron files
>>> -All port/db/ssh functions..
>>>
>>> I'm testing the process to do this on cheap cloud vms so I can screw
>>> up as I figure out best approach for this.
>>>
>>> Thoughts/comments?
>>
>> I would use
>> # rsync -C -x -u -a -v -A -X / /[new mount point without a trailing /]
>>
>> You will have to clean up /boot and /etc/fstab so it will boot properly.
>>
>> You can read the rsync docs to see what it is doing.
>
> If you aren't worried about the actual boot environment and /dev items,
> I back up using
>
> rsync -avXA --exclude-from=/etc/skipdirs.rsync / /newmountpoint
>
> "/newmountpoint" is typically where I mount backup media such as
> "/media/3TB-External-Drive"
>
> The file "/etc/skipdirs.rsync" contains:
>
> /proc/*
> /sys/*
> /dev/*
> /media/*
> /var/log/journal/*
> **/.cache/google-chrome/***
> **/.ccache/***
> /BACKUPS/*
> /run/media/*
>
> The first three are sorta mandatory as they're transient and won't
> translate to a new system. The fourth keeps me from looping through
> mounted media (such as the backup media) and the rest just keep from
> backing up logs and crap that the new machine doesn't care about or
> need. This has worked for me for backup purposes and restoring machines
> from fresh OS installs.
>
> If you need LIVE backup or full bare-metal restoration media, there
> are things like Clonezilla, mondorestore, Acronis (commercial) and lots
> of others.
>
> YMMV (your mileage may vary)
> --
> - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com -
> - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 -
> --
> -He who laughs last thinks slowest.  -
> --
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Re: how to digitize a sizable CD collection using fedora?

[Jon LaBadie]

On Fri, Feb 02, 2018 at 05:29:40PM -0500, Robert P. J. Day wrote:
> 
>   one of my new year's resolutions was to digitize several hundred
> music CDs in preparation for figuring out what system to use in the
> domicile to play them, but regardless of how i decide to eventually
> play these CDs, i'm looking for recommendations for how to rip them to
> hard drive before i decide how i will end up using them.
> 
>   given the cheapness of hard drives (and that i have a QNAP NAS
> anyway), i don't really care about disk usage, so i figured on ripping
> all of those CDs using (lossless) FLAC format, and i can decide down
> the road whether to convert them to a different format to save on
> space.
> 
>   in short, any recommendations on simply ripping all these CDs to
> hard drive, while having no idea what i will eventually use to play
> them?

I only had about 60 CDs to rip, but like you was uncertain about format.

I used "abcde" which let me save .wav, .flac, .oog, and .mp3 in 1 run.

jl
-- 
Jon H. LaBadie  jo...@jgcomp.com
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org