Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #225263 > unrolled thread

About /var/log/dpgk.log

Back to article view | Back to linux.debian.user

Contents

  About /var/log/dpgk.log Rodolfo Medina <rodolfo.medina@gmail.com> - 2020-07-25 21:50 +0200
    Re: About /var/log/dpgk.log <tomas@tuxteam.de> - 2020-07-25 22:10 +0200
      Re: About /var/log/dpgk.log The Wanderer <wanderer@fastmail.fm> - 2020-07-25 22:30 +0200
        Re: About /var/log/dpgk.log <tomas@tuxteam.de> - 2020-07-25 23:00 +0200
        Re: About /var/log/dpgk.log Sven Joachim <svenjoac@gmx.de> - 2020-07-25 23:00 +0200
          Re: About /var/log/dpgk.log <tomas@tuxteam.de> - 2020-07-25 23:40 +0200
            Re: About /var/log/dpgk.log Rodolfo Medina <rodolfo.medina@gmail.com> - 2020-07-27 14:20 +0200
              Re: About /var/log/dpgk.log Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-27 14:30 +0200
              Re: About /var/log/dpgk.log The Wanderer <wanderer@fastmail.fm> - 2020-07-27 14:40 +0200
                Re: About /var/log/dpgk.log Rodolfo Medina <rodolfo.medina@gmail.com> - 2020-07-27 15:00 +0200
                  Re: About /var/log/dpgk.log The Wanderer <wanderer@fastmail.fm> - 2020-07-27 15:10 +0200
                    Re: About /var/log/dpgk.log Rodolfo Medina <rodolfo.medina@gmail.com> - 2020-07-27 16:00 +0200
                      Re: About /var/log/dpgk.log The Wanderer <wanderer@fastmail.fm> - 2020-07-27 16:10 +0200
                        Re: About /var/log/dpgk.log Rodolfo Medina <rodolfo.medina@gmail.com> - 2020-07-27 16:30 +0200
                          Re: About /var/log/dpgk.log The Wanderer <wanderer@fastmail.fm> - 2020-07-27 16:40 +0200
                            Re: About /var/log/dpgk.log The Wanderer <wanderer@fastmail.fm> - 2020-07-27 17:50 +0200
                              Re: About /var/log/dpgk.log Rodolfo Medina <rodolfo.medina@gmail.com> - 2020-07-28 01:10 +0200
                                Re: About /var/log/dpgk.log The Wanderer <wanderer@fastmail.fm> - 2020-07-28 01:20 +0200
                                  Re: About /var/log/dpgk.log Rodolfo Medina <rodolfo.medina@gmail.com> - 2020-07-28 13:30 +0200
                          Re: About /var/log/dpgk.log David Wright <deblis@lionunicorn.co.uk> - 2020-07-27 17:40 +0200
                            Re: About /var/log/dpgk.log Rodolfo Medina <rodolfo.medina@gmail.com> - 2020-07-27 21:10 +0200
                              Re: About /var/log/dpgk.log Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-27 21:20 +0200
                                Re: About /var/log/dpgk.log Rodolfo Medina <rodolfo.medina@gmail.com> - 2020-07-27 21:50 +0200
                                  Re: About /var/log/dpgk.log Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-27 21:50 +0200
                                    Re: About /var/log/dpgk.log Rodolfo Medina <rodolfo.medina@gmail.com> - 2020-07-27 22:20 +0200

Page 1 of 2  [1] 2  Next page →

#225263 — About /var/log/dpgk.log

Hi all...

Please what do those occurrences of `<none>' mean in /var/log/dpgk.log just on
the right next to some (and some not) of packages names?

thanks for any help

cheers

rodolfo

[toc] | [next] | [standalone]

#225264

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jul 25, 2020 at 07:47:01PM +0000, Rodolfo Medina wrote:
> Hi all...
> 
> Please what do those occurrences of `<none>' mean in /var/log/dpgk.log just on
> the right next to some (and some not) of packages names?

You mean like this:

  2019-10-18 17:09:25 install gcc-8-base:amd64 <none> 8.3.0-6

I don't know for sure, But grepping around in my logs shows a version
number in that place, when there's no '<none>'. So my hunch would be
that it is the prior installed version (when there was one) or <none>
when there was --uh-- none.

But perhaps someone more in the know chimes in.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#225267

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-25 at 16:02, tomas@tuxteam.de wrote:

> On Sat, Jul 25, 2020 at 07:47:01PM +0000, Rodolfo Medina wrote:
>
>> Hi all...
>> 
>> Please what do those occurrences of `<none>' mean in /var/log/dpgk.log just on
>> the right next to some (and some not) of packages names?
> 
> You mean like this:
> 
>   2019-10-18 17:09:25 install gcc-8-base:amd64 <none> 8.3.0-6
> 
> I don't know for sure, But grepping around in my logs shows a version
> number in that place, when there's no '<none>'. So my hunch would be
> that it is the prior installed version (when there was one) or <none>
> when there was --uh-- none.

On mine, I also note that the lines with <none> in column 5 have
'install' in column 3, whereas the ones with a version number in column
5 in that column have 'upgrade' in column 3. This seems to back up that
interpretation.

My guess would be that this is done just to keep the number of columns
per line equal between the install and upgrade cases, most likely
because it makes translating this into a table by columns easier.

I haven't checked the source, and offhand don't know of any obvious
non-source documentation to check, however.

-- 
   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

[toc] | [prev] | [next] | [standalone]

#225269

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jul 25, 2020 at 04:25:50PM -0400, The Wanderer wrote:
> On 2020-07-25 at 16:02, tomas@tuxteam.de wrote:
> 
> > On Sat, Jul 25, 2020 at 07:47:01PM +0000, Rodolfo Medina wrote:
> >
> >> Hi all...
> >> 
> >> Please what do those occurrences of `<none>' mean in /var/log/dpgk.log just on
> >> the right next to some (and some not) of packages names?
> > 
> > You mean like this:
> > 
> >   2019-10-18 17:09:25 install gcc-8-base:amd64 <none> 8.3.0-6
> > 
> > I don't know for sure, But grepping around in my logs shows a version
> > number in that place, when there's no '<none>'. So my hunch would be
> > that it is the prior installed version (when there was one) or <none>
> > when there was --uh-- none.
> 
> On mine, I also note that the lines with <none> in column 5 have
> 'install' in column 3, whereas the ones with a version number in column
> 5 in that column have 'upgrade' in column 3. This seems to back up that
> interpretation.

Oh, I forgot to say that I filtered "install" lines. So there are
"install" lines with a version number -- this seems to be the
action (install can also replace a version).

But yes, our takes seem to coincide otherwise.

> My guess would be that this is done just to keep the number of columns
> per line equal between the install and upgrade cases, most likely
> because it makes translating this into a table by columns easier.

That makes sense, yes.

> I haven't checked the source, and offhand don't know of any obvious
> non-source documentation to check, however.

We are a lazy pack, ain't we ;-P

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#225270

On 2020-07-25 16:25 -0400, The Wanderer wrote:

> On 2020-07-25 at 16:02, tomas@tuxteam.de wrote:
>
>> On Sat, Jul 25, 2020 at 07:47:01PM +0000, Rodolfo Medina wrote:
>>
>>> Hi all...
>>>
>>> Please what do those occurrences of `<none>' mean in /var/log/dpgk.log just on
>>> the right next to some (and some not) of packages names?
>>
>> You mean like this:
>>
>>   2019-10-18 17:09:25 install gcc-8-base:amd64 <none> 8.3.0-6
>>
>> I don't know for sure, But grepping around in my logs shows a version
>> number in that place, when there's no '<none>'. So my hunch would be
>> that it is the prior installed version (when there was one) or <none>
>> when there was --uh-- none.
>
> On mine, I also note that the lines with <none> in column 5 have
> 'install' in column 3, whereas the ones with a version number in column
> 5 in that column have 'upgrade' in column 3. This seems to back up that
> interpretation.
>
> My guess would be that this is done just to keep the number of columns
> per line equal between the install and upgrade cases, most likely
> because it makes translating this into a table by columns easier.
>
> I haven't checked the source, and offhand don't know of any obvious
> non-source documentation to check, however.

It's mentioned in the dpkg manpage, search for the --log option there.

Cheers,
       Sven

[toc] | [prev] | [next] | [standalone]

#225273

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jul 25, 2020 at 10:54:56PM +0200, Sven Joachim wrote:

[...]

> It's mentioned in the dpkg manpage, search for the --log option there.

:-)

Thanks, that puts it to rest.

As always, if everything else fails, read the instructions.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#225321

<tomas@tuxteam.de> writes:

> On Sat, Jul 25, 2020 at 10:54:56PM +0200, Sven Joachim wrote:
>
> [...]
>
>> It's mentioned in the dpkg manpage, search for the --log option there.
>
> :-)
>
> Thanks, that puts it to rest.
>
> As always, if everything else fails, read the instructions.


Thanks to you all.  Then, e.g.,

 2020-07-23 08:02:37 install liblilv-0-0:i386 <none> 0.24.2~dfsg0-2

means that liblilv-0-0 has been installed or not on 2020-07-23?  From dpkg
manpage, --log option, as I understand, the field with `<none>' should
correspond to the installed version, so `<none>' seems to state that it is not
installed at all...?  If so, what does the `install' action do there...?

thanks again,

rodolfo

[toc] | [prev] | [next] | [standalone]

#225322

On Mon, Jul 27, 2020 at 12:15:37PM +0000, Rodolfo Medina wrote:
> Thanks to you all.  Then, e.g.,
> 
>  2020-07-23 08:02:37 install liblilv-0-0:i386 <none> 0.24.2~dfsg0-2
> 
> means that liblilv-0-0 has been installed or not on 2020-07-23?  From dpkg
> manpage, --log option, as I understand, the field with `<none>' should
> correspond to the installed version, so `<none>' seems to state that it is not
> installed at all...?  If so, what does the `install' action do there...?

<none> is the *previously* installed version.

[toc] | [prev] | [next] | [standalone]

#225323

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-27 at 08:15, Rodolfo Medina wrote:

> <tomas@tuxteam.de> writes:
> 
>> On Sat, Jul 25, 2020 at 10:54:56PM +0200, Sven Joachim wrote:
>> 
>> [...]
>> 
>>> It's mentioned in the dpkg manpage, search for the --log option
>>> there.
>> 
>> :-)
>> 
>> Thanks, that puts it to rest.
>> 
>> As always, if everything else fails, read the instructions.
> 
> Thanks to you all.  Then, e.g.,
> 
> 2020-07-23 08:02:37 install liblilv-0-0:i386 <none> 0.24.2~dfsg0-2
> 
> means that liblilv-0-0 has been installed or not on 2020-07-23?  From
> dpkg manpage, --log option, as I understand, the field with `<none>'
> should correspond to the installed version, so `<none>' seems to
> state that it is not installed at all...?  If so, what does the
> `install' action do there...?

That log message means that at 08:02:37 on July 23rd, 2020, the computer
went from not having any i386-architecture version of liblv-0-0
installed at all to having version 0.24.2~dfsg0-2 installed.

The "<none>" is the version which was installed *before* dpkg took
action. The field after that is the version which was installed *after*
dpkg took action. (Or maybe "was to be"; I don't know what gets logged
in the case where the install fails, et cetera.)

-- 
   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

[toc] | [prev] | [next] | [standalone]

#225327

The Wanderer <wanderer@fastmail.fm> writes:

> On 2020-07-27 at 08:15, Rodolfo Medina wrote:
>
>> <tomas@tuxteam.de> writes:
>> 
>>> On Sat, Jul 25, 2020 at 10:54:56PM +0200, Sven Joachim wrote:
>>> 
>>> [...]
>>> 
>>>> It's mentioned in the dpkg manpage, search for the --log option
>>>> there.
>>> 
>>> :-)
>>> 
>>> Thanks, that puts it to rest.
>>> 
>>> As always, if everything else fails, read the instructions.
>> 
>> Thanks to you all.  Then, e.g.,
>> 
>> 2020-07-23 08:02:37 install liblilv-0-0:i386 <none> 0.24.2~dfsg0-2
>> 
>> means that liblilv-0-0 has been installed or not on 2020-07-23?  From
>> dpkg manpage, --log option, as I understand, the field with `<none>'
>> should correspond to the installed version, so `<none>' seems to
>> state that it is not installed at all...?  If so, what does the
>> `install' action do there...?
>
> That log message means that at 08:02:37 on July 23rd, 2020, the computer
> went from not having any i386-architecture version of liblv-0-0
> installed at all to having version 0.24.2~dfsg0-2 installed.
>
> The "<none>" is the version which was installed *before* dpkg took
> action. The field after that is the version which was installed *after*
> dpkg took action. (Or maybe "was to be"; I don't know what gets logged
> in the case where the install fails, et cetera.)


Clear now, thanks...

Now, when I try to remove liblilv-0-0, Debian warns me that audacity depends on
it:

# aptitude purge liblilv-0-0
The following packages will be REMOVED:  
  liblilv-0-0{p} 
0 packages upgraded, 0 newly installed, 1 to remove and 192 not upgraded.
Need to get 0 B of archives. After unpacking 132 kB will be freed.
The following packages have unmet dependencies:
 audacity : Depends: liblilv-0-0 (>= 0.16.0~dfsg0) but it is not going to be
 installed


But audacity is installed on my Debian box since months...  How can it depend
on a package installed a few days ago...?

rodolfo

[toc] | [prev] | [next] | [standalone]

#225329

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-27 at 08:53, Rodolfo Medina wrote:

> The Wanderer <wanderer@fastmail.fm> writes:
> 
>> On 2020-07-27 at 08:15, Rodolfo Medina wrote:

>>> Thanks to you all.  Then, e.g.,
>>> 
>>> 2020-07-23 08:02:37 install liblilv-0-0:i386 <none> 0.24.2~dfsg0-2
>>> 
>>> means that liblilv-0-0 has been installed or not on 2020-07-23?  From
>>> dpkg manpage, --log option, as I understand, the field with `<none>'
>>> should correspond to the installed version, so `<none>' seems to
>>> state that it is not installed at all...?  If so, what does the
>>> `install' action do there...?
>>
>> That log message means that at 08:02:37 on July 23rd, 2020, the computer
>> went from not having any i386-architecture version of liblilv-0-0
>> installed at all to having version 0.24.2~dfsg0-2 installed.
>>
>> The "<none>" is the version which was installed *before* dpkg took
>> action. The field after that is the version which was installed *after*
>> dpkg took action. (Or maybe "was to be"; I don't know what gets logged
>> in the case where the install fails, et cetera.)
> 
> Clear now, thanks...
> 
> Now, when I try to remove liblilv-0-0, Debian warns me that audacity depends on
> it:
> 
> # aptitude purge liblilv-0-0
> The following packages will be REMOVED:  
>   liblilv-0-0{p} 
> 0 packages upgraded, 0 newly installed, 1 to remove and 192 not upgraded.
> Need to get 0 B of archives. After unpacking 132 kB will be freed.
> The following packages have unmet dependencies:
>  audacity : Depends: liblilv-0-0 (>= 0.16.0~dfsg0) but it is not going to be
>  installed
> 
> 
> But audacity is installed on my Debian box since months...  How can it depend
> on a package installed a few days ago...?

My guess would be that this is about architecture differences.

What the install line from above indicates was installed on the 23rd is
the i386 version of liblilv-0-0. I suspect that the amd64 version was
already installed. The amd64 version of audacity depends on the amd64
version of this library, and the i386 version of audacity almost
certainly depends on the i386 version of this library.

Try

# aptitude purge liblilv-0-0:i386

and see what that gives you.

-- 
   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

[toc] | [prev] | [next] | [standalone]

#225339

The Wanderer <wanderer@fastmail.fm> writes:

> On 2020-07-27 at 08:53, Rodolfo Medina wrote:
>
>> The Wanderer <wanderer@fastmail.fm> writes:
>> 
>>> On 2020-07-27 at 08:15, Rodolfo Medina wrote:
>
>>>
>>> That log message means that at 08:02:37 on July 23rd, 2020, the computer
>>> went from not having any i386-architecture version of liblilv-0-0
>>> installed at all to having version 0.24.2~dfsg0-2 installed.
>>>
>>> The "<none>" is the version which was installed *before* dpkg took
>>> action. The field after that is the version which was installed *after*
>>> dpkg took action. (Or maybe "was to be"; I don't know what gets logged
>>> in the case where the install fails, et cetera.)
>> 
>> Clear now, thanks...
>> 
>> Now, when I try to remove liblilv-0-0, Debian warns me that audacity depends
>> on it:
>> 
>> # aptitude purge liblilv-0-0
>> The following packages will be REMOVED:  
>>   liblilv-0-0{p} 
>> 0 packages upgraded, 0 newly installed, 1 to remove and 192 not upgraded.
>> Need to get 0 B of archives. After unpacking 132 kB will be freed.
>> The following packages have unmet dependencies:
>>  audacity : Depends: liblilv-0-0 (>= 0.16.0~dfsg0) but it is not going to be
>>  installed
>> 
>> 
>> But audacity is installed on my Debian box since months...  How can it
>> depend on a package installed a few days ago...?
>
> My guess would be that this is about architecture differences.
>
> What the install line from above indicates was installed on the 23rd is
> the i386 version of liblilv-0-0. I suspect that the amd64 version was
> already installed. The amd64 version of audacity depends on the amd64
> version of this library, and the i386 version of audacity almost
> certainly depends on the i386 version of this library.
>
> Try
>
> # aptitude purge liblilv-0-0:i386
>
> and see what that gives you.


Your guess seems to be true:

# aptitude purge liblilv-0-0:i386
The following packages will be REMOVED:  
  liblilv-0-0:i386{p} libserd-0-0:i386{u} libsord-0-0:i386{u} 
  libsratom-0-0:i386{u} 
0 packages upgraded, 0 newly installed, 4 to remove and 192 not upgraded.
Need to get 0 B of archives. After unpacking 394 kB will be freed.
Do you want to continue? [Y/n/?]

, so it's also important that appendix `:i386'.  Now, I want to remove all tha
packages I installed on last july 23th.  To do so, I do:

 $ grep "2015-12-19.*.install " /var/log/dpkg.log | awk '{ print $4 }' | cut  -d: -f1 | tr '\n' ' '

How can I modify the above command so to include - when it is present - also
that important suffix?

thanks

rodolfo

[toc] | [prev] | [next] | [standalone]

#225340

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-27 at 09:56, Rodolfo Medina wrote:

> The Wanderer <wanderer@fastmail.fm> writes:
> 
>> On 2020-07-27 at 08:53, Rodolfo Medina wrote:

>>> But audacity is installed on my Debian box since months...  How can it
>>> depend on a package installed a few days ago...?
>>
>> My guess would be that this is about architecture differences.
>>
>> What the install line from above indicates was installed on the 23rd is
>> the i386 version of liblilv-0-0. I suspect that the amd64 version was
>> already installed. The amd64 version of audacity depends on the amd64
>> version of this library, and the i386 version of audacity almost
>> certainly depends on the i386 version of this library.
>>
>> Try
>>
>> # aptitude purge liblilv-0-0:i386
>>
>> and see what that gives you.
> 
> Your guess seems to be true:
> 
> # aptitude purge liblilv-0-0:i386
> The following packages will be REMOVED:  
>   liblilv-0-0:i386{p} libserd-0-0:i386{u} libsord-0-0:i386{u} 
>   libsratom-0-0:i386{u} 
> 0 packages upgraded, 0 newly installed, 4 to remove and 192 not upgraded.
> Need to get 0 B of archives. After unpacking 394 kB will be freed.
> Do you want to continue? [Y/n/?]
> 
> , so it's also important that appendix `:i386'.  Now, I want to remove all tha
> packages I installed on last july 23th.  To do so, I do:
> 
>  $ grep "2015-12-19.*.install " /var/log/dpkg.log | awk '{ print $4 }' | cut  -d: -f1 | tr '\n' ' '
> 
> How can I modify the above command so to include - when it is present - also
> that important suffix?

Drop the '| cut -d: -f1' part. That explicitly gets rid of the suffix.
As far as I can tell from trivial testing, the resulting package list is
in the correct syntax to be passed to apt-get or aptitude for removal.

-- 
   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

[toc] | [prev] | [next] | [standalone]

#225343

The Wanderer <wanderer@fastmail.fm> writes:

> On 2020-07-27 at 09:56, Rodolfo Medina wrote:
>
>> The Wanderer <wanderer@fastmail.fm> writes:
>> 
>>> On 2020-07-27 at 08:53, Rodolfo Medina wrote:
>
>>>> But audacity is installed on my Debian box since months...  How can it
>>>> depend on a package installed a few days ago...?
>>>
>>> My guess would be that this is about architecture differences.
>>>
>>> What the install line from above indicates was installed on the 23rd is
>>> the i386 version of liblilv-0-0. I suspect that the amd64 version was
>>> already installed. The amd64 version of audacity depends on the amd64
>>> version of this library, and the i386 version of audacity almost
>>> certainly depends on the i386 version of this library.
>>>
>>> Try
>>>
>>> # aptitude purge liblilv-0-0:i386
>>>
>>> and see what that gives you.
>> 
>> Your guess seems to be true:
>> 
>> # aptitude purge liblilv-0-0:i386
>> The following packages will be REMOVED:  
>>   liblilv-0-0:i386{p} libserd-0-0:i386{u} libsord-0-0:i386{u} 
>>   libsratom-0-0:i386{u} 
>> 0 packages upgraded, 0 newly installed, 4 to remove and 192 not upgraded.
>> Need to get 0 B of archives. After unpacking 394 kB will be freed.
>> Do you want to continue? [Y/n/?]
>> 
>> , so it's also important that appendix `:i386'.  Now, I want to remove all
>> tha packages I installed on last july 23th.  To do so, I do:
>> 
>>  $ grep "2015-12-19.*.install " /var/log/dpkg.log | awk '{ print $4 }' | cut  -d: -f1 | tr '\n' ' '
>> 
>> How can I modify the above command so to include - when it is present - also
>> that important suffix?
>
> Drop the '| cut -d: -f1' part. That explicitly gets rid of the suffix.
> As far as I can tell from trivial testing, the resulting package list is
> in the correct syntax to be passed to apt-get or aptitude for removal.


Unfortunately,

 root@lenovo:~# aptitude purge "2020-07-23.*.install " /var/log/dpkg.log | awk '{ print $4 }' | tr '\n' ' '
Unable to apply some actions, aborting
   information...  information...  package root@lenovo:~# 

Strange, because:

$ grep "2020-07-23.*.install " /var/log/dpkg.log | awk '{ print $4 }' | tr '\n' ' '
xml-core:all docutils-common:all docutils-doc:all libimagequant0:amd64 libjs-sphinxdoc:all python-alabaster:all python-asn1crypto:all python-babel-localedata:all python-tz:all python-babel:all python-certifi:all python-cffi-backend:amd64 python-enum34:all python-ipaddress:all python-cryptography:amd64 python-roman:all python-docutils:all python-idna:all python-imagesize:all python-markupsafe:amd64 python-jinja2:all python-olefile:all python-openssl:all python-pyparsing:all python-packaging:all python-pil:amd64 python-pygments:all python-urllib3:all python-requests:all python-typing:all sphinx-common:all python-sphinx:all nasm:amd64 yasm:amd64 cmake-data:all libcurl4:amd64 librhash0:amd64 libuv1:amd64 cmake:amd64 libchromaprint-tools:amd64 libchromaprint-dev:amd64 frei0r-plugins-dev:amd64 libunistring-dev:amd64 libunbound8:amd64 libgnutls-dane0:amd64 libopts25:amd64 gnutls-bin:amd64 libgmpxx4ldbl:amd64 libgmp-dev:amd64 libgnutlsxx28:amd64 libidn2-dev:amd64 libp11-kit-dev:amd64 libtasn1-6-dev:amd64 nettle-dev:amd64 libgnutls28-dev:amd64 libtasn1-doc:all libdpkg-perl:all libfile-fcntllock-perl:amd64 pkg-config:amd64 ladspa-sdk:amd64 aom-tools:amd64 libaom-dev:amd64 libserd-0-0:i386 libsord-0-0:i386 libsratom-0-0:i386 liblilv-0-0:i386 libserd-dev:amd64 libsord-dev:amd64 lv2-dev:amd64 libsratom-dev:amd64 liblilv-dev:amd64 libraw1394-dev:amd64 libiec61883-dev:amd64 libraw1394-tools:amd64 libraw1394-11:i386 libiec61883-0:i386 libraw1394-dev:i386

Maybe all those `:all'...?  Then get cut off only them?

rodolfo

[toc] | [prev] | [next] | [standalone]

#225344

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-27 at 10:25, Rodolfo Medina wrote:

> The Wanderer <wanderer@fastmail.fm> writes:
> 
>> On 2020-07-27 at 09:56, Rodolfo Medina wrote:

>>> Now, I want to remove all
>>> tha packages I installed on last july 23th.  To do so, I do:
>>> 
>>>  $ grep "2015-12-19.*.install " /var/log/dpkg.log | awk '{ print $4 }' | cut  -d: -f1 | tr '\n' ' '
>>> 
>>> How can I modify the above command so to include - when it is present - also
>>> that important suffix?
>>
>> Drop the '| cut -d: -f1' part. That explicitly gets rid of the suffix.
>> As far as I can tell from trivial testing, the resulting package list is
>> in the correct syntax to be passed to apt-get or aptitude for removal.
> 
> Unfortunately,
> 
>  root@lenovo:~# aptitude purge "2020-07-23.*.install " /var/log/dpkg.log | awk '{ print $4 }' | tr '\n' ' '
> Unable to apply some actions, aborting
>    information...  information...  package root@lenovo:~# 

You have your syntax wrong. This attempts to run the following commands,
in order, passing the output of each one as input to the next one:

aptitude purge "2020-07-23.*.install " /var/log/dpkg.log
awk '{ print $4 }'
tr '\n' ' '

> Strange, because:
> 
> $ grep "2020-07-23.*.install " /var/log/dpkg.log | awk '{ print $4 }' | tr '\n' ' '
> xml-core:all docutils-common:all docutils-doc:all libimagequant0:amd64 libjs-sphinxdoc:all python-alabaster:all python-asn1crypto:all python-babel-localedata:all python-tz:all python-babel:all python-certifi:all python-cffi-backend:amd64 python-enum34:all python-ipaddress:all python-cryptography:amd64 python-roman:all python-docutils:all python-idna:all python-imagesize:all python-markupsafe:amd64 python-jinja2:all python-olefile:all python-openssl:all python-pyparsing:all python-packaging:all python-pil:amd64 python-pygments:all python-urllib3:all python-requests:all python-typing:all sphinx-common:all python-sphinx:all nasm:amd64 yasm:amd64 cmake-data:all libcurl4:amd64 librhash0:amd64 libuv1:amd64 cmake:amd64 libchromaprint-tools:amd64 libchromaprint-dev:amd64 frei0r-plugins-dev:amd64 libunistring-dev:amd64 libunbound8:amd64 libgnutls-dane0:amd64 libopts25:amd64 gnutls-bin:amd64 libgmpxx4ldbl:amd64 libgmp-dev:amd64 libgnutlsxx28:amd64 libidn2-dev:amd64 libp11-kit-dev:amd64 libtas
n1-6-dev:amd64 nettle-dev:amd64 libgnutls28-dev:amd64 libtasn1-doc:all libdpkg-perl:all libfile-fcntllock-perl:amd64 pkg-config:amd64 ladspa-sdk:amd64 aom-tools:amd64 libaom-dev:amd64 libserd-0-0:i386 libsord-0-0:i386 libsratom-0-0:i386 liblilv-0-0:i386 libserd-dev:amd64 libsord-dev:amd64 lv2-dev:amd64 libsratom-dev:amd64 liblilv-dev:amd64 libraw1394-dev:amd64 libiec61883-dev:amd64 libraw1394-tools:amd64 libraw1394-11:i386 libiec61883-0:i386 libraw1394-dev:i386
> 
> Maybe all those `:all'...?  Then get cut off only them?

What you want to do instead is to run this exact latter command, and
pass the output of that into the 'aptitude purge' command.

To do that, you use a subshell. This can be done in either of two ways:
with backticks (that is, `, from the key to the left of the '1' key), or
with $() syntax. The former is easier to type, but the latter is more
versatile, because it can be nested.

Try:

$ aptitude purge $(grep "2020-07-23.*.install " /var/log/dpkg.log | awk
'{ print $4 }' | tr '\n' ' ')

and see what you get.


As I understand matters, running 'command' in a subshell results in the
stdout of that command being dropped into the place in the original
command line where the subshell was located. For example, the command

$ aptitude purge $(echo packagename)

results in running the actual command

$ aptitude purge packagename

Note that if the output of the subshell command includes spaces, or
other special characters, you need to handle shell quoting and the
result can get very messy. I don't have a good handle on the more
advanced examples of it myself, but there are reference guides out there
for the basic principles, although I don't keep track of them.

-- 
   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

[toc] | [prev] | [next] | [standalone]

#225356

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-27 at 10:37, The Wanderer wrote:

> What you want to do instead is to run this exact latter command, and
> pass the output of that into the 'aptitude purge' command.

> Try:
> 
> $ aptitude purge $(grep "2020-07-23.*.install " /var/log/dpkg.log | awk
> '{ print $4 }' | tr '\n' ' ')
> 
> and see what you get.

Turns out that the 'tr' part can be dropped as well; the subshell
redirection is smart enough for the newlines to be processed correctly.
All you need to do with the output from grep is reduce it to only column 4.

I habitually do that via e.g. "cut -d ' ' -f 4" instead of "awk {print
$4}", but the result should be the same, and awk is more versatile.

-- 
   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

[toc] | [prev] | [next] | [standalone]

#225399

The Wanderer <wanderer@fastmail.fm> writes:

> On 2020-07-27 at 10:37, The Wanderer wrote:
>
>> What you want to do instead is to run this exact latter command, and
>> pass the output of that into the 'aptitude purge' command.
>
>> Try:
>> 
>> $ aptitude purge $(grep "2020-07-23.*.install " /var/log/dpkg.log | awk
>> '{ print $4 }' | tr '\n' ' ')
>> 
>> and see what you get.
>
> Turns out that the 'tr' part can be dropped as well; the subshell
> redirection is smart enough for the newlines to be processed correctly.


All right, but with the `tr' part then it's easier to copy and paste the output
and pass it as argument to `# aptitude purge'...

thanks

rodolfo

[toc] | [prev] | [next] | [standalone]

#225400

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-27 at 19:02, Rodolfo Medina wrote:

> The Wanderer <wanderer@fastmail.fm> writes:
> 
>> On 2020-07-27 at 10:37, The Wanderer wrote:
>>
>>> What you want to do instead is to run this exact latter command, and
>>> pass the output of that into the 'aptitude purge' command.
>>
>>> Try:
>>> 
>>> $ aptitude purge $(grep "2020-07-23.*.install " /var/log/dpkg.log | awk
>>> '{ print $4 }' | tr '\n' ' ')
>>> 
>>> and see what you get.
>>
>> Turns out that the 'tr' part can be dropped as well; the subshell
>> redirection is smart enough for the newlines to be processed correctly.
> 
> All right, but with the `tr' part then it's easier to copy and paste the output
> and pass it as argument to `# aptitude purge'...

Quite true, and that's what I thought at first you were doing, until you
gave the command line with incorrect syntax that I responded to earlier.

The advantage of using a subshell is that you don't need to
copy-and-paste the output, because it gets put into the right place
automatically. As long as there's no special shell quoting that has to
be handled, everything Just Works.

-- 
   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

[toc] | [prev] | [next] | [standalone]

#225415

The Wanderer <wanderer@fastmail.fm> writes:

> On 2020-07-27 at 19:02, Rodolfo Medina wrote:
>
>> The Wanderer <wanderer@fastmail.fm> writes:
>> 
>>> On 2020-07-27 at 10:37, The Wanderer wrote:
>>>
>>>> What you want to do instead is to run this exact latter command, and
>>>> pass the output of that into the 'aptitude purge' command.
>>>
>>>> Try:
>>>> 
>>>> $ aptitude purge $(grep "2020-07-23.*.install " /var/log/dpkg.log | awk
>>>> '{ print $4 }' | tr '\n' ' ')
>>>> 
>>>> and see what you get.
>>>
>>> Turns out that the 'tr' part can be dropped as well; the subshell
>>> redirection is smart enough for the newlines to be processed correctly.
>> 
>> All right, but with the `tr' part then it's easier to copy and paste the
>> output
>> and pass it as argument to `# aptitude purge'...
>
> Quite true, and that's what I thought at first you were doing, until you
> gave the command line with incorrect syntax that I responded to earlier.


Yes, it was a moment of confusion of mine...

thanks,

rodolfo

[toc] | [prev] | [next] | [standalone]

#225354

On Mon 27 Jul 2020 at 14:25:29 (+0000), Rodolfo Medina wrote:
> The Wanderer <wanderer@fastmail.fm> writes:
> > On 2020-07-27 at 09:56, Rodolfo Medina wrote:
> >> The Wanderer <wanderer@fastmail.fm> writes:
> >>> On 2020-07-27 at 08:53, Rodolfo Medina wrote:
> >
> >>>> But audacity is installed on my Debian box since months...  How can it
> >>>> depend on a package installed a few days ago...?
> >>>
> >>> My guess would be that this is about architecture differences.
> >>>
> >>> What the install line from above indicates was installed on the 23rd is
> >>> the i386 version of liblilv-0-0. I suspect that the amd64 version was
> >>> already installed. The amd64 version of audacity depends on the amd64
> >>> version of this library, and the i386 version of audacity almost
> >>> certainly depends on the i386 version of this library.
> >>>
> >>> Try
> >>>
> >>> # aptitude purge liblilv-0-0:i386
> >>>
> >>> and see what that gives you.
> >> 
> >> Your guess seems to be true:
> >> 
> >> # aptitude purge liblilv-0-0:i386
> >> The following packages will be REMOVED:  
> >>   liblilv-0-0:i386{p} libserd-0-0:i386{u} libsord-0-0:i386{u} 
> >>   libsratom-0-0:i386{u} 
> >> 0 packages upgraded, 0 newly installed, 4 to remove and 192 not upgraded.
> >> Need to get 0 B of archives. After unpacking 394 kB will be freed.
> >> Do you want to continue? [Y/n/?]
> >> 
> >> , so it's also important that appendix `:i386'.  Now, I want to remove all
> >> tha packages I installed on last july 23th.  To do so, I do:
> >> 
> >>  $ grep "2015-12-19.*.install " /var/log/dpkg.log | awk '{ print $4 }' | cut  -d: -f1 | tr '\n' ' '
> >> 
> >> How can I modify the above command so to include - when it is present - also
> >> that important suffix?
> >
> > Drop the '| cut -d: -f1' part. That explicitly gets rid of the suffix.
> > As far as I can tell from trivial testing, the resulting package list is
> > in the correct syntax to be passed to apt-get or aptitude for removal.
> 
> 
> Unfortunately,
> 
>  root@lenovo:~# aptitude purge "2020-07-23.*.install " /var/log/dpkg.log | awk '{ print $4 }' | tr '\n' ' '
> Unable to apply some actions, aborting
>    information...  information...  package root@lenovo:~# 
> 
> Strange, because:
> 
> $ grep "2020-07-23.*.install " /var/log/dpkg.log | awk '{ print $4 }' | tr '\n' ' '
> xml-core:all docutils-common:all docutils-doc:all libimagequant0:amd64 libjs-sphinxdoc:all python-alabaster:all python-asn1crypto:all python-babel-localedata:all python-tz:all python-babel:all python-certifi:all python-cffi-backend:amd64 python-enum34:all python-ipaddress:all python-cryptography:amd64 python-roman:all python-docutils:all python-idna:all python-imagesize:all python-markupsafe:amd64 python-jinja2:all python-olefile:all python-openssl:all python-pyparsing:all python-packaging:all python-pil:amd64 python-pygments:all python-urllib3:all python-requests:all python-typing:all sphinx-common:all python-sphinx:all nasm:amd64 yasm:amd64 cmake-data:all libcurl4:amd64 librhash0:amd64 libuv1:amd64 cmake:amd64 libchromaprint-tools:amd64 libchromaprint-dev:amd64 frei0r-plugins-dev:amd64 libunistring-dev:amd64 libunbound8:amd64 libgnutls-dane0:amd64 libopts25:amd64 gnutls-bin:amd64 libgmpxx4ldbl:amd64 libgmp-dev:amd64 libgnutlsxx28:amd64 libidn2-dev:amd64 libp11-kit-dev:amd64 libtasn1-6-dev:amd64 nettle-dev:amd64 libgnutls28-dev:amd64 libtasn1-doc:all libdpkg-perl:all libfile-fcntllock-perl:amd64 pkg-config:amd64 ladspa-sdk:amd64 aom-tools:amd64 libaom-dev:amd64 libserd-0-0:i386 libsord-0-0:i386 libsratom-0-0:i386 liblilv-0-0:i386 libserd-dev:amd64 libsord-dev:amd64 lv2-dev:amd64 libsratom-dev:amd64 liblilv-dev:amd64 libraw1394-dev:amd64 libiec61883-dev:amd64 libraw1394-tools:amd64 libraw1394-11:i386 libiec61883-0:i386 libraw1394-dev:i386
> 
> Maybe all those `:all'...?  Then get cut off only them?

I don't know why you'd want to learn bash scripting at
root's command line, but if you insist, please add -s
after the word aptitude.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web