Bug#1050359: RM: gpr -- RoQA; dead upstream; depends on gtk2

[A Mennucc1]

I (the mantainer) am in favor too.
a.

Il 16/09/23 19:18, Till Kamppeter ha scritto:
gpr is not only not upstream-maintained any more and depending oon the 
obsolete GTK2, it is also only used for printing with 
LPD/gnulpr/LPRng, all these being printing systems which are obsolete 
for near 2 decades (replaced by CUPS) and all not maintained upstream 
any more.


So it does not actually make sense any more to keep gpr in Debian. So 
I am in favor of its removal, too.





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054660: debdelta: Improve performance info

[A Mennucc1]

hi

Il 27/10/23 17:34, Stefan Monnier ha scritto:

I'm very happily using `debdelta-upgrade` now that I finally heard about
it (I've been using Debian for 20 years and wishing for something like
DebDelta for a big part of it), so first: thanks!

One think that annoys me is that I find the output unclear.  E.g. I see
[note the output was actually in French, so I translated it by hand, it
probably doesn't match 100% what debdelta would say]:

 Created,time  0.42sec, speed 202kB/sec, avahi-daemon_0.8-12_i386.deb
 [...]
 The delta est too large: libmbim-glib4_1.28.4-2_1.30.0-1_i386.debdelta
 Delta was not created since new package is too small: 
libmbim-proxy_1.28.4-2_1.30.0-1_i386.debdelta
 [...]
 Created,time  1.07sec, speed 239kB/sec, 
libedata-book-1.2-27_3.50.1-1_i386.deb
 [...]
 Downloaded, time  0.11sec, speed  8kB/sec, 
libudisks2-0_2.10.1-1_2.10.1-2_i386.debdelta
 Downloaded, time  0.24sec, speed 13MB/sec, 
libreoffice-calc_4%3a7.5.6-1_4%3a7.5.8~rc1-2_i386.debdelta
 [...]
 Downloaded, time  0.02sec, speed 488kB/sec, libmbim-proxy_1.30.0-1_i386.deb
 Downloaded, time  0.03sec, speed 7658kB/sec, 
libmbim-glib4_1.30.0-1_i386.deb
 [...]
 Created,time 27.30sec, speed 296kB/sec, 
libreoffice-calc_4%3a7.5.8~rc1-2_i386.deb
 [...]
 Statistics of delta-upgrade:
debs result total, size 115MB time 257sec virtual speed 458kB/sec


by default, debdelta-upgrade tries to be smart: for each package that 
has to be upgraded,


1)  if there is  a delta, it will download the delta, apply it, and 
"create" the new deb
2) if there is no delta, it will "download" the new package (this may be 
because, the delta was too big, or the package was too small, or, some 
error)
3) after all available deltas have been applied, it may exit, or 
continue downloading all needed new .deb


This behavior can be tuned with the option --deb-policy option, see man 
page.



Q uestions that I can't answer based on the above output:
- I don't see any other mention of "avahi-daemon" than the "created" line,
   so how was it created?

by downloading the delta and applying it

- Why/how were `libmbim-proxy` and `libmbim-glib4` downloaded (since
   there's a delta missing for them) and from where?

from the standard repository of debs

   There's no subsequent matching "created" line, so IIUC it was
   downloaded in non-delta form, which I'd expect `debdelta-upgrade`
   never does (leaving it to `apt upgrade` instead).

actually, it does

- The "Downloaded" speed varies very widely (w

I have no idea

- I'd appreciate seeing the actual size of the downloaded data on each
   line (maybe instead of the time?).

add some -v options

- In the final statistics, I'd be interested to see a report comparing
   the amount of bytes that passed over the network compared to the
   number of bytes in the resulting `.deb` files (so as to see how much
   we gained in this).


add some -v options

bye

a.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054665: debdelta: Avoid generating the actual `.deb`

[A Mennucc1]

Dear Stefan,

some years ago I did some work in this respect.

debpatch and debdelta-upgrade have an option
 --format unzipped
that will recreate the deb w/o compressing the data part: this is much 
faster.


The point is, I do not know if apt will accept those .debs . Maybe apt 
may have an option to accept debs even when the size is not what is 
expected.


I also experimented with other --format options. One option would write 
all new files in the filesystem, the way that

dpkg --unpack
does, so after that, only configuration would be needed; this work is 
there but uncomplete.


a.

Il 27/10/23 18:09, Stefan Monnier ha scritto:

Subject: debdelta: Avoid generating the actual `.deb`
Package: debdelta
Version: 0.67
Severity: wishlist

Dear Maintainer,

`debdelta-upgrade` is great at reducing the amount of data downloaded,
but on some of my (weaker) machines, generating the `.deb` files takes
a lot of time, and for no good reason: 99% of the time is spent not
applying the xdelta but (re)compressing the result with `xz`.

So, this wishlist item is to change APT such that we can skip the
generation of the `.deb` file and instead keep the old `.deb` together
with the patch(es) in `/var/cache/apt/archives`.
When APT needs to install the (not created) `.deb`, instead of
unpacking+uncompressing the (not created) `.deb`, it would
unpack+uncompress the old `.deb`, and apply the (set of) patch(es).

Since the old `.deb` + patch(es) is usually larger than
a patched+recompressed `.deb`, we could occasionally "repack" the files
in `/var/cache/apt/archives`, but that would be optional and could be
performed opportunistically in the background, a bit like Git's GC.


 Stefan


-- System Information:
Debian Release: trixie/sid
   APT prefers testing
   APT policy: (990, 'testing'), (500, 'stable-security'), (100, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE not se$
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debdelta depends on:
ii  binutils  2.41-6
ii  bzip2 1.0.8-5+b1
ii  libbz2-1.01.0.8-5+b1
ii  libc6 2.37-12
ii  python3   3.11.4-5+b1
ii  python3-requests  2.31.0+dfsg-1
ii  zlib1g1:1.2.13.dfsg-3

Versions of packages debdelta recommends:
ii  bsdiff   4.3-23
ii  gnupg2   2.2.40-1.1
ii  gpg-agent [gnupg-agent]  2.2.40-1.1
ii  lzma 9.22-2.2
ii  python3-apt  2.6.0
ii  python3-debian   0.1.49
ii  xdelta   1.1.3-10.4
ii  xdelta3  3.0.11-dfsg-1.2
ii  xz-utils [lzma]  5.4.4-0.1

Versions of packages debdelta suggests:
pn  debdelta-doc  

-- no debconf information

Bug#1036042: build-depends on libgmock-dev

[A Mennucc1]

Package: libhwy-dev
Version: 1.0.3-3
Severity: normal
Tags: ftbfs

Dear mantainer,

I tried to build the above version from source  (using the git tree
 master 491551e d/changelog: Upload 1.0.3-3 to unstable
) and it failed; it succeded once I installed the package libgmock-dev.

Regards

a.



-- System Information:
Debian Release: 11.7
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-0.deb11.5-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libhwy-dev depends on:
ii  libhwy1 1.0.3-3

libhwy-dev recommends no packages.

libhwy-dev suggests no packages.

-- no debconf information



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001976: ITS: libppd

[A Mennucc1]

Dear Christoph

if you wish to adopt this package, go ahead.

Thanks

a.

Il 06/01/22 15:37, Christoph Biedl ha scritto:

X-Debbugs-CC: mennu...@debian.org, m...@qa.debian.org

[ Re-sending as I forgot about X-Debbugs-CC ]

| Source: libppd
| Version: 2:0.10-7.3
| Severity: important
|
| Greetings,
|
| hereby I declare my intention to salvage the "libppd" package using the
| procedure described in the Developer's Reference (5.12) and the Debian
| Wiki .
|
| Criteria are met as follows:
|
| * The package is in clear need of some love and care: There is an open
|   RC bug: .
| AND
| * An upload is needed to fix this.
| AND
| * At least one to the following applies (non-applicable omitted):
|   * There is no visible activity regarding the package for six months.
|   * A previous NMU was not acknowledged, and a bug justifying another
| NMU is pending for one month.
|   * The last upload was an NMU and there was no maintainer upload within
| one year.
|
| My objective is to have this package in Debian, and in good shape. So
| if you (maintainer) want to resume taking care of it, please do. And in
| case you object or already have other plans, just let me know.
|
| Kind regards,
|
| Christoph





OpenPGP_signature
Description: OpenPGP digital signature

Bug#989053: debdelta: Problems with signatures

[A Mennucc1]

you have to download and install a later version of debdelta, for
example from

https://packages.debian.org/bullseye/debdelta

a.

Il 24/05/21 20:58, Ilari Halminen ha scritto:
> Package: debdelta
> Version: 0.62
> Severity: normal
>
> Dear Maintainer,
>
> I cannot use debdelta at all, because it complains of missing 
> signatures. I do not know if the problems has something to do with my 
> systems special options like still using inittab. I have included a file 
> with all messages so you may see the problem. I do not know not often report 
> any bug, so at least wanted to send that raport just for you.
>
> With best wishes
> Ilari Halminen 
> (from Finland)
>
> -- System Information:
> Debian Release: 10.9
>   APT prefers proposed-updates
>   APT policy: (500, 'proposed-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fi_FI.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
> Versions of packages debdelta depends on:
> ii  binutils2.31.1-16
> ii  bzip2   1.0.6-9.2~deb10u1
> ii  libbz2-1.0  1.0.6-9.2~deb10u1
> ii  libc6   2.28-10
> ii  python  2.7.16-1
> ii  zlib1g  1:1.2.11.dfsg-1
>
> Versions of packages debdelta recommends:
> ii  bsdiff   4.3-21
> ii  gnupg-agent  2.2.12-1+deb10u1
> ii  gnupg2   2.2.12-1+deb10u1
> ii  gpg-agent [gnupg-agent]  2.2.12-1+deb10u1
> ii  lzma 9.22-2.1
> ii  python-apt   1.8.4.3
> ii  python-debian0.1.35
> ii  xdelta   1.1.3-9.2
> ii  xdelta3  3.0.11-dfsg-1+b1
> ii  xz-utils [lzma]  5.2.4-1
>
> Versions of packages debdelta suggests:
> ii  debdelta-doc  0.62
>
> -- no debconf information





signature.asc
Description: OpenPGP digital signature

Bug#979966: debdelta still contains isAlive()s

[A Mennucc1]

dear all,

I just uploaded a 0.66 *before* reading this message

when I checked 0.65+nmu it seemed it was fine in this respect

before creating 0.66, I did
# grep -e isAlive -r .
and I did not see any occurrence
so hopefully it will be OK

a.


Il 18/01/21 18:59, Calum McConnell ha scritto:
> On Mon, 2021-01-18 at 14:41 +0100, Steven De Herdt wrote:
>> reopen 979966
>> thanks
>>
>> This report actually concerns 0.65+nmu1: /usr/bin/debdelta is identical
>> to the one in 0.65.  Something must have gone wrong in the NMU...
>>
>> Thanks for the work on this package!
>> -Steven
> I can confirm that is true.  It's almost certainly something I screwed up,
> and now that A. Mennucc1 is back, the solution will probably be to upload
> a new 0.66 rather than a +nmu2.
>
> I'm not sure quite HOW I managed to mess it up, but I have a feeling it is
> because I wasn't careful enough in keeping track of what changes I made to
> which versions. It's probably the direct result of me using a patch to
> copy over the changelog (instead of, you know, just copy-pasting): but as
> I prepared the NMU in /tmp, I can't say for sure.  Suffice it to say I am
> whacking my head against the wall for not checking one final time whether
> there were any more occurences of isAlive().
>
> A. Mennucc, any chance of doing a full upload sometime soon, to hopefully
> prevent my mistake from entering Bullseye's final release?
>
> Thanks,
> Calum
>
>




signature.asc
Description: OpenPGP digital signature

Bug#979966: debdelta still contains isAlive()s

[A Mennucc1]

dear all,

I just uploaded a 0.66 *before* reading this message

when I checked 0.65+nmu it seemed it was fine in this respect

before creating 0.66, I did
# grep -e isAlive -r .
and I did not see any occurrence
so hopefully it will be OK

a.


Il 18/01/21 18:59, Calum McConnell ha scritto:
> On Mon, 2021-01-18 at 14:41 +0100, Steven De Herdt wrote:
>> reopen 979966
>> thanks
>>
>> This report actually concerns 0.65+nmu1: /usr/bin/debdelta is identical
>> to the one in 0.65.  Something must have gone wrong in the NMU...
>>
>> Thanks for the work on this package!
>> -Steven
> I can confirm that is true.  It's almost certainly something I screwed up,
> and now that A. Mennucc1 is back, the solution will probably be to upload
> a new 0.66 rather than a +nmu2.
>
> I'm not sure quite HOW I managed to mess it up, but I have a feeling it is
> because I wasn't careful enough in keeping track of what changes I made to
> which versions. It's probably the direct result of me using a patch to
> copy over the changelog (instead of, you know, just copy-pasting): but as
> I prepared the NMU in /tmp, I can't say for sure.  Suffice it to say I am
> whacking my head against the wall for not checking one final time whether
> there were any more occurences of isAlive().
>
> A. Mennucc, any chance of doing a full upload sometime soon, to hopefully
> prevent my mistake from entering Bullseye's final release?
>
> Thanks,
> Calum
>
>







signature.asc
Description: OpenPGP digital signature

Bug#962203: NMU

[A Mennucc1]

Il 11/01/21 01:28, Paul Wise ha scritto:
> A Mennucc1, would you be interested in having assistance with the
> codebase and the service?

that's OK for me

What is the best debian-ish way to collaborate?

There are some problems to address (a few urgent): how do we discuss?
mailing list? does `salsa` have a way to open a chat/mailing list for us
to use?


a.



signature.asc
Description: OpenPGP digital signature

Bug#962203: NMU

[A Mennucc1]

Dear all, sorry for being MIA so long; I have added the NMU to the GIT
repository. a.



signature.asc
Description: OpenPGP digital signature

Bug#962203: NMU

[A Mennucc1]

Il 14/12/20 23:23, Calum McConnell ha scritto:
> I have prepared an NMU for this package.  It is currently at
> https://mentors.debian.net/package/debdelta/ .  While I need a sponsor to
> get it into Debian, I am now reaching out to ment...@lists.debian.org to
> see if I can expedite the process.

I am sorry, I have been away from Debian activities for some months... I
will catch up in a week. Thanks so far. a.




signature.asc
Description: OpenPGP digital signature

Bug#741565: 741565

[A Mennucc1]

Dear shirish शिरीष

> Either give a progress bar or a
> percentage bar which tells alongwith the upload kilobyte rate.

The problem is that the server part was never deployed. So the program
was waiting forever for a service that was not there.

In the latest version I disabled sending of error logs to the server.

I I will ever implement the server part , then I will reactivate the
"send the logs" feature in debdelta, and I will add a timeout.

Cheers,

a.

Bug#913696: debdelta: Script accesses internal dpkg database

[A Mennucc1]

Dear Guillem,

I see your point;

but (as the name " dpkg_L_faster" suggests), using the dpkg commands to
obtain meta-information is quite slow; so I will have to think about it

BTW: you write

>  And finally, the contents and its format, will be changing in
> the near future.
May you please point me to some more info regarding this change?

Thanks,

a.

Il 14/11/18 04:13, Guillem Jover ha scritto:
> Source: debdelta
> Source-Version: 0.62
> Severity: important
> User: debian-d...@lists.debian.org
> Usertags: dpkg-db-access-blocker
>
> Hi!
>
> This package contains a script («debdelta»), which directly accesses
> the dpkg internal database, instead of using one of the public interfaces
> provided by dpkg. The code in do_patch_, should be switched to use:
>
>   «dpkg-query --showformat='${Conffiles}\n' --show»
>
> to fetch the list of conffiles. Then _symlink_data_tree should be switched
> to always use dpkg_L, and dpkg_L_faster should be removed. Finally the
> code handling 'old-control-tree' should be switched to use something like:
>
>   «dpkg-query --control-list»
>
>
> This is a problem for several reasons, because even though the layout and
> format of the dpkg database is administrator friendly, and it is expected
> that those might need to mess with it, in case of emergency, this
> “interface” does not extend to other programs besides the dpkg suite of
> tools. The admindir can also be configured differently at dpkg build or
> run-time. And finally, the contents and its format, will be changing in
> the near future.
>
> Thanks,
> Guillem
>




signature.asc
Description: OpenPGP digital signature

Bug#834162: freevo: obsolete

[A Mennucc1]

Il 09/09/2018 14:35, Adrian Bunk ha scritto:
> On Fri, Aug 12, 2016 at 05:50:58PM +0200, A Mennucc wrote:
>> ...
>> 'freevo' is in "dormant state" since Feb 2014 [1] ; there are some
>> patches around to revive it [2] and a github branch that had some
>> activity [3], but in truth there was no activity in some years.
>> ...
>> I gave it a look: fixing 'freevo' is more work than I can dedicate now.
>> Moreover 'kodi' is now in Debian, so fixing 'freevo' probably
>> does not make much sense.
>>
>> So I am opening this 'grave' bug; I am perfectly OK if someone wishes
>> to fix 'freevo' ; but I would rather not see 'freevo' (as it is now) being
>> part of the next major Debian release.
> Would it be OK to remove the freevo packages
> (freevo kaa-base kaa-imlib2 kaa-metadata)
> from unstable now?
>
> The only reverse dependency is tracked in #907663,
> and I can do an NMU for that.
sure

a.



signature.asc
Description: OpenPGP digital signature

Bug#894096: Why is donizetti not currently producing any deltas?

[A Mennucc1]

Dear Carlos,

donizetti is producing deltas as always, but there is a long long queue.

I identified a problem.

Every ten minutes , or 20 deltas, the server in donizetti synced its
internal repository of deltas with  the public web repository 
http://debdeltas.debian.net/ . In the past this would take a few
minutes, For some unknown reasons now it takes 30minutes, sometimes 60.
So the server works roughly 1/4th of capacity.

The server keeps track of newly created deltas, so it could send only
newly created deltas to http://debdeltas.debian.net/ . Unfortunately
this is not currently supported by the debian infrastructure : only a
full sync is allowed.

To alleviate the problem, I changed the repository refresh to
120minutes, or 200 deltas . So the server should run its queue faster.

I also temporarely disabled creating deltas for the 'debian-debug' part
of the archive.

I will keep an eye on it.

a.

Il 26/03/2018 14:22, Carlos Maddela ha scritto:
> Package: debdelta
> Version: 0.60
> Severity: important
>
> Hi,
>
> Since about March 10, 2018, no new deltas have been available.
>
> The current unstable release [0.60] is not able to produce deltas for
> the current format of new debs being uploaded to the archive, although
> it is able to decode deltas produced by the unreleased version in VCS.
> Prior to the above date, deltas were being produced, so I suspect the
> version of debdelta that the donizetti server had was the unreleased
> version in VCS. Is it possible that this somehow got downgraded to the
> current unstable version?
>
> Please release the fixes in VCS. Perhaps this will make deltas available
> again.
>
> Thanks,
>
> Carlos
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages debdelta depends on:
> ii  binutils2.30-8
> ii  bzip2   1.0.6-8.1
> ii  libbz2-1.0  1.0.6-8.1
> ii  libc6   2.27-2
> ii  python  2.7.14-4
> ii  zlib1g  1:1.2.8.dfsg-5
>
> Versions of packages debdelta recommends:
> ii  bsdiff   4.3-20
> ii  gnupg2   2.2.5-1
> ii  gpg-agent [gnupg-agent]  2.2.5-1
> ii  lzma 9.22-2.1
> ii  python-apt   1.6.0~rc2
> ii  python-debian0.1.32
> ii  xdelta   1.1.3-9.2
> ii  xdelta3  3.0.11-dfsg-1+b1
> ii  xz-utils [lzma]  5.2.2-1.3
>
> Versions of packages debdelta suggests:
> ii  debdelta-doc  0.60
>
> -- Configuration Files:
> /etc/debdelta/sources.conf changed [not included]
>
> -- no debconf information
>

Bug#880925: no checks to know if the debdelta mirror is up or down.

[A Mennucc1]

Dear shirish,

Il 05/11/2017 19:48, shirish शिरीष ha scritto:
> First of all thank you for still maintaining and caring about
> debdelta. I did see the last update according to changelog.gz is 12th
> Oct which means you are still maintaining it.
yes
> Delta missing, server failed to create it:
> [...]
> This has been happening over a week now. It seems the server is down.
well actually the server is up. The problem is that in recent deb files,
the component control.tar.gz is now control.tar.xz, and the server was
not prepared for this change. I have just uploaded patches.
> Pinging debdelta.debian.net gets you nowhere.
debdelta.debian.net is the server for web pages (it is very small and at
my home.)
debdeltas.debian.net is the server for serving the deltas, but not the
one that creates them.

the server that creates deltas is donizetti

a.

Bug#816150: debdelta: support debian-debug archive

[A Mennucc1]

hi. Thanks for the hint.

It seems that the server has been generating the diffs all along;the but
the client did not know about it.

Try to add these 4 lines to /etc/debdelta/sources.conf

[debug debian archive]
Origin=Debian
Label=Debian debug
delta_uri=http://debdeltas.debian.net/debian-debug-deltas

a.




signature.asc
Description: OpenPGP digital signature

Bug#823818: debdelta: scale threads on multiple cores

[A Mennucc1]

Il 19/05/2016 14:24, Ritesh Raj Sarraf ha scritto:
> But then reading xz-util's manpage, I don't think they have multithread
> support.

xz 5.2.2 has introduced multithread for compression, but not
decompression, so it still is no help when using debdelta-upgrade

a.





signature.asc
Description: OpenPGP digital signature

Bug#845173: Cannot handle new debs with data component XZ compressed in parallel

[A Mennucc1]

Il 01/01/2017 09:51, A Mennucc1 ha scritto:
>
> Dear Carlos,
>
> thanks a lot,
>
> I have applied the patch from your GIT tree into the server, soon we
> will see if it works fine,
>
it works, but it needs xz-utils 5.2.2 (for creating debpatches)

a.




signature.asc
Description: OpenPGP digital signature

Bug#845173: Cannot handle new debs with data component XZ compressed in parallel

[A Mennucc1]

Il 21/11/2016 04:27, Carlos Maddela ha scritto:
> Ever since dpkg 1.18.14 or 1.18.15 was released there haven't been too
> many usable debdeltas available for download. The reason being that debs
> that have their data component compressed in XZ format are now being
> done so in parallel, which produces a file that debdelta cannot
> reproduce.

Dear Carlos,

thanks a lot,

I have applied the patch from your GIT tree into the server, soon we
will see if it works fine,

Andrea





signature.asc
Description: OpenPGP digital signature

Bug#794039: change notification

[A Mennucc1]

dear all,

hi

 I was bitten by this bug, I could not pair bluetooth device. I tried 
with a different notification system, and the bug disappears. So I was
able to pair bluetooth devices.

Just in case. Bye and thanks,

a.

-- how to change notification-daemon

1) sudo apt-get install notification-daemon

2) sudo apt-get remove mate-notification-daemon

3) killall mate-notification-daemon

4) /usr/lib/notification-daemon/notification-daemon &

5) notify-send   hello

(at the last step, you should see a friendly "hello" message on screen).

--

All the above in Debian Jessie amd64

a.





signature.asc
Description: OpenPGP digital signature

Bug#815870: debdelta: frequent changes in /etc/debdelta/gnupg/random_seed

[A Mennucc1]

Dear Ritesh,

first of all, are you using some automated tools that keeps  /etc under
GIT versioning? If so, which?

In any case.

The directory /etc/debdelta/gnupg/ is the GNUPG home for debdelta
operations. The file
  /etc/debdelta/gnupg/random_seed contains the random seed used by GNUPG
in some operations . See [1] . It is not unexpected that this file may
change. You may wish to add that file to the appropriate .gitignore file.

Bye, a.

[1] https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration.html

Il 25/02/2016 09:18, Ritesh Raj Sarraf ha scritto:
> l disk space will be used.
> Do you want to continue? [Y/n] 
> [master b624316] saving uncommitted changes in /etc prior to apt run
>  Author: Ritesh Raj Sarraf 
>  1 file changed, 0 insertions(+), 0 deletions(-)
>  rewrite debdelta/gnupg/random_seed (100%)




signature.asc
Description: OpenPGP digital signature

Bug#791662: aptitude: debdelta integration

[A Mennucc1]

dear all,

first of all, I am happy to see that debdelta is useful.

There was an attempt to integrate in aptitude in the past, as a
apt-method (there are some traces in the code since).

But keep in mind that debdelta is integrated in 'cupt' that is another
package manager, similar to 'aptitude'.

A.

Il 15/03/2016 00:04, Axel Beckert ha scritto:
> Hi,
>
> Yuri D'Elia wrote:
>> First, some debdelta praise: I've been using debdelta on and off over the 
>> last
>> years depending on the circumstances. Whenever I'm working on a lousy/slow
>> internet connection (quite often, unfortunately), debdelta is effectively my
>> only chance to perform upgrades to massive packages like tetex, libreoffice, 
>> or
>> the like. The bandwidth saving are, in most cases, absolutely enormous
>> (especially when packaging tweaks are being pushed).
> Same here.
>
>> It would be awesome if aptitude itself supported debdelta when installed. 
>> This
>> would mean to run `debdelta-upgrade [selected package list]` as opposed to
>> downloading the packages directly. I couldn't care less about the progress
>> meter in this scenario, and having "something that works" would be better 
>> than
>> just running "debdelta-upgrade" blindly and then continuing with aptitude.
> aptitude uses apt methods to download files. So I think that
> integration should be done as an apt method for easier integration
> with _any_ apt based package manager and to avoid duplicating the
> integration effort.
>
> The documentation for developing such a backend is at
> /usr/share/doc/libapt-pkg-doc/method.html/index.html (in the package
> libapt-pkg-doc).
>
>> I believe *many* users would realize debdelta existed if debdelta was 
>> actually
>> integrated into aptitude and suggested as a dependency. debdelta is suggested
>> by 'libcupt' (and thus, when cupt is installed), but sincerely I have no use
>> for another frontend if I'm already using aptitude.
> JFTR: cupt is _not_ yet another frontend but on the same level as apt.
>
>> It would also be *very* important, irregardless if debdelta is installed 
>> and/or
>> if it will ever be integrated on a lower level, to allow the user to switch
>> between regular/debdelta updates though an option in the configuration:
>> debdelta trades between CPU time and bandwidth, and if you have a decent
>> network connection, debdelta is often slower. A setting is definitely
>> warranted.
> Definitely, yes.
>
>   Regards, Axel




signature.asc
Description: OpenPGP digital signature

Bug#823818: debdelta: scale threads on multiple cores

[A Mennucc1]

Il 09/05/2016 12:40, Ritesh Raj Sarraf ha scritto:
> Package: debdelta
> Version: 0.55
> Severity: wishlist
>
> As it stands now, it looks like debdelta is threaded only to parallelize
> download and patching of deltas. Other than that, it seems to be a
> single thread application.
>
> This really shows up when you have multiple cores waiting, while
> debdelta only utilizes a single core to patch a giant deb package.
>
> It would be nicer to have debdelta (or maybe attack the underneath
> archive library) spawn and utilize all available logical CPUs.
>
yes it would be nice and not really difficult to implement. Altough I am
afraid that debdelta is mostly HD bound, so there may be only marginal
benefits.

a.



signature.asc
Description: OpenPGP digital signature

Bug#736535: Dr Geo II

[A Mennucc1]

hi,

that program you find in drgeo.eu and in Launchpad
is called "Dr Geo II"

I have looked around, and the source is not available.

What you can download from the the above websites is a precompiled
binary.

a.

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)


signature.asc
Description: Digital signature

Bug#791416: .sig, Re: Bug#791416: gpa: add mime info

[A Mennucc1]

I also just noted that gpa can verify signatures, so we add in
gpa.desktop an entry for application/pgp-signature

a.

Il 06/07/2015 20:21, A Mennucc1 ha scritto:
> you may want to add this as well, it seems that having a mimetype then
> requires an argument to 'exec'
>
> a.
>
> Il 06/07/2015 12:19, Andreas Ronnquist ha scritto:
>> tags 791416 + pending
>> thanks
>>
>> Applied in the git repository, so it will be part of the next
>> Debian release of gpa.
>>
>> - thanks for the patch, and for your contribution to Debian!
>>
>> -- Andreas Rönnquist
>> gus...@debian.org




signature.asc
Description: OpenPGP digital signature

Bug#760237: patch

[A Mennucc1]

hi,

I prepared a patch for the above problem ; it is patch n 3 in
http://mennucc1.debian.net/gpa/

Patch 2 adds a dependency on gnupg-agent ... it makes sense since gpa
does not work w/o

Patch 1 is a minor fix for what I proposed in 791416

patch 4 is a changelog, so that I compiled two versions for jessie i386
and jessie amd64 ; I am using them, it seems to work fine

 bye,
a.





signature.asc
Description: OpenPGP digital signature

Bug#791416: gpa: add mime info

[A Mennucc1]

you may want to add this as well, it seems that having a mimetype then
requires an argument to 'exec'

a.

Il 06/07/2015 12:19, Andreas Ronnquist ha scritto:
> tags 791416 + pending
> thanks
>
> Applied in the git repository, so it will be part of the next
> Debian release of gpa.
>
> - thanks for the patch, and for your contribution to Debian!
>
> -- Andreas Rönnquist
> gus...@debian.org

From e42fff7489965ae187971842eada5b885a100be1 Mon Sep 17 00:00:00 2001
From: A Mennucc 
Date: Mon, 6 Jul 2015 14:00:41 +0200
Subject: [PATCH] add %F to 'exec' in gpa.desktop

---
 debian/patches/add_desktop_file_keywords.patch | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/debian/patches/add_desktop_file_keywords.patch b/debian/patches/add_desktop_file_keywords.patch
index 9456a28..0073594 100644
--- a/debian/patches/add_desktop_file_keywords.patch
+++ b/debian/patches/add_desktop_file_keywords.patch
@@ -1,9 +1,15 @@
-Author: Andreas Rönnquist
-Description: Add keywords to the desktop file to silence lintian
+Author: Andreas Rönnquist, A Mennucci
+Description: Add keywords to the desktop file to silence lintian, add MimeTypes
 Forwarded: http://lists.gnupg.org/pipermail/gnupg-users/2014-September/050818.html
 --- a/gpa.desktop
 +++ b/gpa.desktop
-@@ -10,3 +10,5 @@
+@@ -5,8 +5,10 @@
+ GenericName=GNU Privacy Assistant
+ GenericName[sv]=GNU Integritets-hjälpreda
+ GenericName[en_US.ISO8859-1]=GNU Privacy Assistant
+-Exec=gpa
++Exec=gpa %F
+ Icon=gpa
  Terminal=false
  Type=Application
  Categories=GTK;Application;Security;Utility;
-- 
2.1.4



signature.asc
Description: OpenPGP digital signature

Bug#761026: GPGME Error at keytable.c:150 'Unsupported certificate' renders GPA unusable

[A Mennucc1]

Package: gpa
Version: 0.9.7-2
Followup-For: Bug #761026

hi,

I prepared a workaround in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790737#25

a.

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)


signature.asc
Description: Digital signature

Bug#790737: gpg agent workaround

[A Mennucc1]

dear all,

I had some problems using GPA

I did some testing re: this bug

It seems that gpa really needs the gpg agent up and running. W/o agent 
it reports the error:
"THE GPGME library returned and unexpected error at keytable.c:150.
The error was: unknown option"
and is unusable, and it hangs and never exists.

Moreover gpa does not work with the fake agent
"THE GPGME library returned and unexpected error at keytable.c:150.
The error was: unsupported certificate"

I have prepared a workaround . TL;DR jump to section 'Summarizing'



Let me first explain a few technical thingies, so that everybody can
understand the problem and its subtleties

-1-- the gpg agent

To use the gpg-agent , the program gpg needs to know where to find it.
To this end, the location of the agent is saved in the environment
variable GPG_AGENT_INFO

There are two ways to start the agent

-1a--- global  gpg-agent for X11 session

If you add the string   use-agent  to either  ~/.gnupg/gpg.conf or 
~/.gnupg/options, then a global gpg-agent will be started for the whole
X session. This is done by the script file 
/etc/X11/Xsession.d/90gpg-agent  . When starting the agent , the env
variable for this agent is also saved in the file 
~/.gnupg/gpg-agent-info-$(hostname)

(If you add "use-agent" right now, you need to log out and login again)

-1b-- local  gpg-agent for terminal

open a terminal and run the command
# eval $(gpg-agent --daemon)

this will start a gpg-agent, and set the env variable

any further command you issue in this terminal (e.g. gpa) will use this
agent

this is though inconvenient since other terminals will not see this same
agent

-2---  the gnome-keyring

If the gnome-keyring is installed, then it will overwrite the
GPG_AGENT_INFO variable, and propose itself as gpg-agent . Unfortunately
gpa is not compatible.  So let's work around this.

-2a remove gnome-keyring

You may remove the package gnome-keyring  and reboot. Problem is, the
network-manager-applet uses gnome-keyring to store and to ask for WIFI
passwords. If you remove it, next time you will try to connect to a new
WIFI, it will all fail silently.

-2b--- recover global agent

If you are running the global  gpg-agent for X11 session, then you can
recover this mess as follows

open a terminal and run the commands

# source   ~/.gnupg/gpg-agent-info-$(hostname)
# export GPG_AGENT_INFO

this will recover the connection to the global agent

any further command you issue in this terminal (e.g. gpa) will use the
global agent

this though will not let you use 'gpa' from the main application menu,
so I prepared a automatic method, see sec 4

-2c--- use a local agent

just follow instructions at point 1b before.

--4-- Summarizing

This is a workaround that will solve the problem for good.

For normal users, do this:

save the attached file gpa.mine as /tmp/gpa.mine , and

# sudo dpkg-divert --local --rename --add /usr/bin/gpa
# sudo cp /tmp/gpa.mine /usr/bin/gpa
# sudo chown root.root /usr/bin/gpa
# sudo chmod 0755 /usr/bin/gpa


So I suggest to the maintainer to wrap gpa into a shell script,
imitating the above .

After doing the above  then gpa works OK in all situations, and you can
keep gnome-keyring installed

that's all folks

a.

#!/bin/sh

: ${GNUPGHOME=$HOME/.gnupg}

GPGAGENT=/usr/bin/gpg-agent
PID_FILE="$GNUPGHOME/gpg-agent-info-$(hostname)"


warn () {
echo "gpa warning: $1"  1>&2
if test -x /usr/bin/zenity ; then
zenity --warning --text="gpa warning: $1" &
fi
}

if ! test -x $GPGAGENT ; then

warn "gpg-agent not installed, gpa will not work correctly"

else

## It would be nice to warn people, but let's omit this
#if test "${GPG_AGENT_INFO}" = "" && ! grep -qs '^[[:space:]]*use-agent' 
"$GNUPGHOME/gpg.conf" "$GNUPGHOME/options" ; then
#   warn "gpg-agent is not enabled globally, you may want to add 
'use-agent' to $GNUPGHOME/gpg.conf 
# fi


# the  GPG_AGENT_INFO  may point to the dreaded gnome-keyring
case ${GPG_AGENT_INFO} in
# this is the agent set up by gnome-keyring, and is not compatible with gpg
/run/user/*/keyring/gpg*  |  ${XDG_RUNTIME_DIR}/keyring/gpg* )
warn "overriding gnome-keyring fake gpg agent " ; unset 
GPG_AGENT_INFO ;;
esac

# if no env variable, try to recover the global one
if test "${GPG_AGENT_INFO}" = "" && test -f ${PID_FILE} ; then
. "${PID_FILE}"
export GPG_AGENT_INFO
fi

   # check if the above informations are not stale
   if ! $GPGAGENT 1>/dev/null  2>/dev/null; then
   $GPGAGENT --daemon --sh --write-env-file=${PID_FILE}
   . "${PID_FILE}"
   export GPG_AGENT_INFO
   fi
fi


exec /usr/bin/gpa.distrib "$@"


signature.asc
Description: OpenPGP digital signature

Bug#789796: systemd[1]: Looping too fast. Throttling execution a little.

[A Mennucc1]

Il 24/06/2015 21:41, Marco d'Itri ha scritto:
> Can you clarify what you are complaining about exactly?
sure.

Yesterday systemd was filling its own logs with the message "
systemd[1]: Looping too fast. Throttling execution a little" (as you can
see in the attached log sy_po_log.txt.xz ).

BTW to create the attachment I used  "journalctl  > sy_po_log.txt" then 
deleted some private lines, then  compressed and attached it

Moreover I add this fact. I use the  tool  "Mate System Monitor", that
graphs the CPU usage. Yesterday the graph was flat but for a recurring
spike of activity. IMHO the spike of activity was due to systemd crazy
looping, and then noticing it, and then throttling, up t the next crazy
loop.

This seems some sort of bug, or at least a misbehavior.

(In the end I rebooted the notbook, and it all went back to normal — but
on production servers this may be quite annoying)

This kind of problem was already reported in
  
http://lists.freedesktop.org/archives/systemd-devel/2015-February/028541.html
where they say:
> THis is happens if for some reason the event loop entered a busy
> loop. It's simply a protection against eating up all CPU forever. It's
> a symptom of another bug, which is the one to track down.
In the above post they suggest to use 'strace -p 1' ; I did that (for 2
seconds) and attached the result to this bug.

This other post
 
http://lists.freedesktop.org/archives/systemd-devel/2014-December/025867.html
suggests that the problem may occur after heavy swapping. This is
exactly what happened here two days ago: I was trying to compile
'git-annex' but ghc exhausted all the memory. Note though  but the
problem did not start immediately after the swapping; it started when I
put the notebook to sleep, and resumed it next morning.

My hypothesis is that at a certain point some parts of systemd died
because of lack of memory, indeed I could spot this
> giu 23 19:41:40 kytty systemd-journal[30249]: Journal started
> giu 23 19:41:40 kytty systemd-journald[227]: Received SIGTERM from PID 1 
> (systemd).
> giu 23 19:41:40 kytty systemd[1]: systemd-journald.service stop-sigterm timed 
> out. Killing.
> giu 23 19:41:40 kytty systemd[1]: systemd-journald.service: main process 
> exited, code=killed, status=9/KILL
> giu 23 19:41:40 kytty systemd[1]: Unit systemd-journald.service entered 
> failed state.
> giu 23 19:41:40 kytty kernel: ghc invoked oom-killer: gfp_mask=0x201da, 
> order=0, oom_score_adj=0
then after I put the notebook to sleep and resumed it, systemd wanted to
use those killed parts, but could not, and hence this triggered the
weird behavior. You may probably see if I am right or wrong by looking
at the strace. (I lack the competence).

A solution of this bug (if my analysis is correct) may be as follows. If
a part of systemd dies because of lack of memory, then, when the
situation is back to normal, systemd should restart it.

Hope this helps, thx

a.




signature.asc
Description: OpenPGP digital signature

Bug#789710: debdelta: debpatch always says "does not seem to be a debian delta" although debdelta-upgrade works.

[A Mennucc1]

Dear Chakravarti

may you please tell me the name of the package that you wanted to patch,
the name of the patch, and the command that you used?


thx,

a.




signature.asc
Description: OpenPGP digital signature

Bug#786474: Accepted wfrog 0.8.2+svn973-1 (source all) into unstable

[A Mennucc1]

dear all,

may you please reconsider the request 786474 of removal of pygooglechart ?

Please be aware  that the *Google Image Charts* are deprecated but the
*Google Charts* are not.
See https://developers.google.com/chart/image/

The program 'wfrog' that I mantain uses actively this service /Google
Charts/ and would not work w/o (unless a large overhaul of the code ,
that I have no time to perform).

I can confirm indeed that all the web pages generate by 'wfrog' work
well, even if the (supposed) deadline of Apr 2015 is past.

So the service is not dead, it is alive and kicking.

So please do not remove pygooglechart.

If noone wishes to mantain pygooglechart, I volunteer.

It would be (for me) much easier to solve bug 786051 , that is, to
migrate pygooglechart from python-support to dh_python2 ... rather than
rewriting large part of wfrog.

Bye

a.


Il 22/06/2015 15:59, Luca Falavigna ha scritto:
> Mi sono accorto ora che wfrog è l'unico pacchetto che dipende da
> pygooglechart, che è in procinto di essere rimosso da unstable
> (#786474).
> Pensi possa essere possibile rimuovere il supporto di pygooglechart da
> wfrog senza comprometterne le funzionalità?
>




signature.asc
Description: OpenPGP digital signature

Bug#788808: parted: incorrectly reads partition table, or crashes

[A Mennucc1]

  
  
Warning to anyone reading this bug
report!
  
  Il 17/06/2015 20:00, A Mennucc1 ha scritto:


  I used the command
# dd conv=notrunc if=/dev/zero of=a20_Lime_debian_3.4.90_release_3.img
bs=446 count=1
to delete the boot code.


the above command (in bold) was line-wrapped , in email and
in the web presentation! Using only the first line would
  overwrite the ouput file with zeros, and go on forever (up to disk
  space)

Let me rewrite the command, hopefully this time it will display
fine. The correct command is

# dd  bs=446 count=1 conv=notrunc if=/dev/zero of=imagefile.img

(The part bs=446 count=1 ensures that only the first 446
bytes will be zeroed)


In the command you would substitute the imagefile.img with
the correct filename for output.

    a.

  




signature.asc
Description: OpenPGP digital signature

Bug#788808: parted: incorrectly reads partition table, or crashes

[A Mennucc1]

Il 17/06/2015 19:24, A Mennucc1 ha scritto:
> here is the MBR.
for real  ;->


mbr.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#788808: parted: incorrectly reads partition table, or crashes

[A Mennucc1]

You are right.

I used the command
# dd conv=notrunc if=/dev/zero of=a20_Lime_debian_3.4.90_release_3.img
bs=446 count=1
to delete the boot code.

Now the wheezy version of parted reports:
>  No Implementation: Partition 1 isn't aligned to cylinder boundaries. 
This is still unsupported.
while th Jessie version reports

vvv
Model:  (file)
Disk
/home/andrea/mnt/frivolo/media/R2D2/olimex/a20_Lime_debian_3.4.90_release_3.img:
3980MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End SizeType File system  Flags
 1  1049kB  17,8MB  16,8MB  primary  fat16
 2  17,8MB  3980MB  3963MB  primary  ext3
^^^
or in sectors
> Number  Start   End   Size  Type File system  Flags
> 1  2048s   34814s32767sprimary  fat16
> 2  34816s  7774207s  7739392s  primary  ext3

that is exactly what cfdisk reports

THX

a.

ps: anyway I think that 'parted' should check as expressed above. You
may want to change the bug title


Il 15/06/2015 15:31, Phil Susi ha scritto:
>
> It seems that parted has decided that the MBR looks more like a FAT
> boot sector than an MBR.  Please attach the first kb of the image. 




signature.asc
Description: OpenPGP digital signature

Bug#788808: parted: incorrectly reads partition table, or crashes

[A Mennucc1]

here is the MBR.

I also have a proposal. When parted opens a disk, it should both check
if the whole disk is formatted as a VFAT (or other) volume, and check if
there is a partition table of some kind. In case that both checks are
true, it should stop and warn the user that the disk structure is
ambiguous, and ask for instructions.

a.

Il 15/06/2015 15:31, Phil Susi ha scritto:
> On 6/15/2015 5:06 AM, A Mennucc wrote:
>> The partition table of this image file cannot be properly read or
>> modified with parted. Older versions of parted crash on this image
>> file. Newer versions report a the partition table is dangerously
>> different from the real one, so an user that uses parted to change
>> partitions may destroy all the data.
>
> It seems that parted has decided that the MBR looks more like a FAT
> boot sector than an MBR.  Please attach the first kb of the image.




signature.asc
Description: OpenPGP digital signature

Bug#779897: some more info.

[A Mennucc1]

Il 07/03/2015 10:20, shirish शिरीष ha scritto:
> I am still not sure why it says 'Delta is not present' - I wish I
> could get some more precise output/statement -
one possible cause: debdelta will not created deltas for packages that
are too small; but I am not sure that this covers all cases...

a.



signature.asc
Description: OpenPGP digital signature

Bug#773174: unblock: debdelta/0.55 , or discuss on the matter

[A Mennucc1]

Dear Jonathan Wiltshire,

I attach the debdiff (both for changes and for dsc)

thanks a lot

a.

File lists identical (after any substitutions)

Control files of package debdelta: lines which differ (wdiff format)

Installed-Size: [-408-] {+410+}
Version: [-0.50+2-] {+0.50+3+}

Control files of package debdelta-doc: lines which differ (wdiff format)

Version: [-0.50+2-] {+0.50+3+}
diff -Nru debdelta-0.50+2/debian/changelog debdelta-0.50+3/debian/changelog
--- debdelta-0.50+2/debian/changelog	2012-11-07 13:33:08.0 +0100
+++ debdelta-0.50+3/debian/changelog	2014-12-19 14:42:36.0 +0100
@@ -1,3 +1,14 @@
+debdelta (0.50+3) testing-proposed-updates; urgency=medium
+
+  * Ship new GPG key
+  * Bug fix: "owned and unowned files after purge (policy 6.8 + 10.7.3)",
+ (Closes: #617481).
+  * Portuguese translation, thanks to Américo Monteiro  (Closes: #760731).
+  * Add a stanza in etc/sources.conf to find deltas for backports
+  * Thanks to Jonathan Wiltshire for T-P-U assistance
+
+ -- A Mennucc1   Fri, 19 Dec 2014 14:42:17 +0100
+
 debdelta (0.50+2) unstable; urgency=high
 
   * debdelta-upgrade: uses incorrect URL when requesting
diff -Nru debdelta-0.50+2/debian/postinst debdelta-0.50+3/debian/postinst
--- debdelta-0.50+2/debian/postinst	2011-03-31 11:32:26.0 +0200
+++ debdelta-0.50+3/debian/postinst	2014-12-19 14:10:08.0 +0100
@@ -1,19 +1,47 @@
-#!/bin/sh -e
+#!/bin/sh
+
+set  -e
+
+umask 0077
 
 GPG_MASTER_PUB_KEYRING="/usr/share/keyrings/debian-debdelta-archive-keyring.gpg"
 GPG_HOME="/etc/debdelta/gnupg"
 
+sha1it () {
+ (
+cd ${GPG_HOME}
+echo '#if this file is deleted or it does not match, then  ' > sha1_hashes.txt
+echo '# these files will not be removed when purging "debdelta"  ' >> sha1_hashes.txt
+sha1sum pubring.gpg  secring.gpg >> sha1_hashes.txt
+if test -f trustdb.gpg ; then sha1sum trustdb.gpg >> sha1_hashes.txt ; fi
+ )
+}
+
+check1it () {
+ (
+  cd ${GPG_HOME}
+  test -f sha1_hashes.txt && sha1sum -c --quiet sha1_hashes.txt
+ )
+}
+
 case "$1" in
   configure|reconfigure)
 if test ! -r ${GPG_HOME} ; then
+  echo "Debdelta: creating ${GPG_HOME}"
+  mkdir ${GPG_HOME}
+fi
+if test ! -r ${GPG_HOME}/pubring.gpg -a \
+! -r ${GPG_HOME}/secring.gpg   ; then
   echo "Debdelta: creating keyrings in ${GPG_HOME}"
-  mkdir  ${GPG_HOME}
-  chmod 0700  ${GPG_HOME}
-  touch   ${GPG_HOME}/secring.gpg   ${GPG_HOME}/pubring.gpg 
-  chmod 0600  ${GPG_HOME}/secring.gpg  ${GPG_HOME}/pubring.gpg
+  touch ${GPG_HOME}/secring.gpg  ${GPG_HOME}/pubring.gpg
+  sha1it
 else
   echo "Debdelta: updating public keyring in ${GPG_HOME}"
 fi
-gpg --no-tty --batch --no-options --no-auto-check-trustdb --homedir ${GPG_HOME} --import ${GPG_MASTER_PUB_KEYRING} || true 
+
+c=0 ;  if  check1it ; then   c=1 ;  fi
+gpg --no-tty --batch --no-options --no-auto-check-trustdb --homedir ${GPG_HOME} --import ${GPG_MASTER_PUB_KEYRING} || true
+if test $c = 1 ; then sha1it ; fi
+
 ;;
 esac
diff -Nru debdelta-0.50+2/debian/postrm debdelta-0.50+3/debian/postrm
--- debdelta-0.50+2/debian/postrm	2011-03-31 11:32:26.0 +0200
+++ debdelta-0.50+3/debian/postrm	2014-12-19 14:10:08.0 +0100
@@ -3,32 +3,28 @@
 
 GPG_HOME=/etc/debdelta/gnupg
 
+check1it () {
+ (
+  cd ${GPG_HOME}
+  test -f sha1_hashes.txt && sha1sum -c --quiet sha1_hashes.txt
+ )
+}
+
 if [ "$1" = purge ] ; then
   if  [ -r /var/lib/debdelta ] ; then
 rm -r /var/lib/debdelta
   fi
 
-  if test -f "${GPG_HOME}/secring.gpg" ; then 
-if test -s "${GPG_HOME}/secring.gpg" ; then
-  echo debdelta: does not delete nonempty  ${GPG_HOME}/secring.gpg
-else
-  rm ${GPG_HOME}/secring.gpg 
-fi
-  fi
-
-  if test -f "${GPG_HOME}/pubring.gpg" ; then
-  if  echo "4509b7260dc7aee6ec8dac68263bc662  ${GPG_HOME}/pubring.gpg" | md5sum -c --quiet ; then 
-  rm ${GPG_HOME}/pubring.gpg 
-else
-  echo debdelta: does not delete modified  ${GPG_HOME}/pubring.gpg
-fi
+  if check1it ; then
+(
+  cd ${GPG_HOME}
+  rm -f pubring.gpg  secring.gpg  trustdb.gpg
+  if test -f pubring.gpg~ ; then
+  rm -f pubring.gpg~
+  fi
+  rm -f sha1_hashes.txt
+)
+rmdir ${GPG_HOME} || true
   fi
 
-  if test -f "${GPG_HOME}/pubring.gpg~" ; then
-rm ${GPG_HOME}/pubring.gpg~
-  fi
-
-  #unfortunately I could not spot a good way to detect if the
-  # trustdb does contain useful info
-
 fi
diff -Nru debdelta-0.50+2/etc/sources.conf debdelta-0.50+3/etc/sources.conf
--- debdelta-0.50+2/etc/sources.conf	2011-03-31 11:32:26.0 +0200
+++ debdelta-0.50+3/etc

Bug#773174: debdiff

[A Mennucc1]

 i['Basepath'] = base
+yield i
+  if not cache.broken:
+return
+#
 if packages[-3:] == '.gz':
-  F=subprocess.Popen(["zcat",packages],stdout=subprocess.PIPE).stdout
+  import gzip
+  F=gzip.GzipFile(packages)
+  SP=None
 elif packages[-4:] == '.bz2':
-  F=subprocess.Popen(["bzcat",packages],stdout=subprocess.PIPE).stdout
+  import bz2
+  F=bz2.BZ2File(packages)
+  SP=None
+elif packages[-3:] == '.xz':
+  SP=subprocess.Popen(["xzcat",packages], stdout=subprocess.PIPE, 
stdin=open(os.devnull), close_fds=True)
+  F=SP.stdout
 else:
   F=open(packages)
+  SP=None
+#
+if debian_deb822 and use_debian_822: #use faster implementation
+  #P=debian_deb822.Packages(F,fields=fields)
+  for a in 
debian_deb822.Packages.iter_paragraphs(sequence=F,shared_storage=False,fields=fields):
+if DO_CACHE and not cache.exists: cache.write(a)
+a['Basepath'] = base
+yield a
+  if SP:
+F.read()
+SP.wait()
+  return
+#
 of,pack,vers,arch=None,None,None,None
 for l in F:
   l=l.rstrip('\n')
@@ -3381,16 +3565,20 @@
   if VERBOSE > 2 : print '   skip udeb: '
   continue
 a={}
-a['Basepath'] = base
 a['Filename'] = of
 a['Package']  = pack
 a['Architecture'] = arch
 a['Version'] = vers
+if DO_CACHE and not cache.exists: cache.write(a)
+a['Basepath'] = base
 yield a
 of,pack,vers,arch=None,None,None,None
+    if SP:
+  F.read()
+  SP.wait()
 
   def scan_deb_dir(d, debname, label, lazy):
-assert (debname == None or type(debname) == StringType) and type(label) == 
StringType
+assert (debname == None or type(debname) in string_types) and type(label) 
in string_types
 if not os.path.isdir(d):
   print 'Error, skip non dir:',d
   return
@@ -3444,7 +3632,7 @@
   if VERBOSE > 2 and DEBUG : print '   No such delta dir: ',d
   scanned_delta_dirs.add((d,None)) #trick, if aint there no need to retry
   return
-assert debname == None or type(debname) == StringType
+assert debname == None or type(debname) in string_types
 scanned_delta_dirs.add((d,debname))
 for n in os.listdir(d):
   if debname != None and debname != n.split('_')[0]:
@@ -3682,6 +3870,7 @@
 
 oldn = newest
     generated=0
+seen_versions=[]
 while (oldn>0) :
 oldn -= 1
 
@@ -3725,6 +3914,12 @@
   if VERBOSE > 1 : print '  Skip , already exists: ',delta
   continue
 
+if old['Package']  in seen_versions:
+  if VERBOSE > 3 : print 'Skip , already considered: ',delta
+  continue 
+
+seen_versions.append(old['Package'])
+
 if os.path.exists(delta+'-too-big'):
   if VERBOSE > 1 : print '  Skip , tried and too big: ',delta
   continue
@@ -3980,7 +4175,7 @@
   
   original_cwd = os.getcwd()
 
-  import thread, threading, Queue, pickle, urllib2, fcntl, atexit, signal
+  import thread, threading, Queue, urllib2, fcntl, atexit, signal
 
   proxies=urllib2.getproxies()
   if VERBOSE and proxies:
diff -Nru debdelta-0.50+2/debian/changelog debdelta-0.55/debian/changelog
--- debdelta-0.50+2/debian/changelog2012-11-07 13:33:08.0 +0100
+++ debdelta-0.55/debian/changelog  2014-11-30 18:31:13.0 +0100
@@ -1,3 +1,29 @@
+debdelta (0.55) unstable; urgency=medium
+
+  * update git location
+  * add debian backports to sources.conf
+
+ -- A Mennucc1   Sun, 30 Nov 2014 18:30:51 +0100
+
+debdelta (0.54) unstable; urgency=medium
+
+  * [INTL:pt] Portuguese translation, thanks to Américo Monteiro
+  (Closes: #760731).
+  * bump standards version to 3.9.6.0
+  * debian/rules : add build-arch, build-indep
+  * add new keys into keyring
+  * import some code from GIT server branch
+
+ -- A Mennucc1   Sun, 30 Nov 2014 17:00:39 +0100
+
+debdelta (0.53) experimental; urgency=low
+
+  * merge changes uploaded in wheezy, and changelogs as well
+  * Bug fix: "owned and unowned files after purge (policy 6.8 + 10.7.3)",
+thanks to Holger Levsen (Closes: #617481).
+
+ -- A Mennucc1   Sun, 02 Dec 2012 18:52:15 +0100
+
 debdelta (0.50+2) unstable; urgency=high
 
   * debdelta-upgrade: uses incorrect URL when requesting
@@ -8,12 +34,26 @@
 
  -- A Mennucc1   Wed, 07 Nov 2012 13:31:31 +0100
 
+debdelta (0.52) experimental; urgency=low
+
+  * debpatch, debdelta-upgrade : do not get confused by broken symlinks
+  * enable hardening flags
+
+ -- A Mennucc1   Fri, 02 Nov 2012 10:08:46 +0100
+
 debdelta (0.50+1) unstable; urgency=high
 
   * debpatch, debdelta-upgrade : do not get confused by 

Bug#747695: support added

[A Mennucc1]

Dear Guillem Jover,

the support for data.tar, control.tar and control.tar.xz
(and any other possible combination) is available in the GIT code,
you may find it in
  git clone  git://anonscm.debian.org/collab-maint/debdelta.git
in the branch debdeltas_server_2

It was added as commit
 commit 0d386033058e9d45071f2f8207f34d02976e1c0f
 Date:   Mon Mar 3 11:53:11 2014 +0100


Indeed currently it is mostly needed in the server (the
client is quite agnostic in this respect, will do whatever
the server dictates).

a.

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)


signature.asc
Description: Digital signature

Bug#431833: pygame and audio

[A Mennucc1]

hi

pygame 1.8.1 is available in 'experimental'; I tried most games
(including 'singularity' 'fretsonfire' 'funnyboat') with pygame 1.8.1
and the audio always work

note though a VERY important thing: AFAIK pygame handles audio thru
SDL, so you need to install the package for the SDL audio plugin of
your choice, choosing in the list 
  libsdl1.2debian-alsa
  libsdl1.2debian-arts
  libsdl1.2debian-esd
  libsdl1.2debian-nas
  libsdl1.2debian-oss
  libsdl1.2debian-pulseaudio

a.

ps: I plan to upload 1.8.1 in 'unstable' in short time

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#478574: freevo 1.8.3

[A Mennucc1]

hi,

could you try freevo 1.8.3 (that just entered debian/unstable ---
but it should be possible to install the .debs into debian Lenny)

a.

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#394484: pygame 1.8.1 and sound

[A Mennucc1]

hi

pygame 1.8.1 is available in 'experimental'; I tried most games
(including 'singularity' 'fretsonfire' 'funnyboat') with pygame 1.8.1
and the audio always work

note though a VERY important thing: AFAIK pygame handles audio thru
SDL, so you need to install the package for the SDL audio plugin of
your choice, choosing in the list 
  libsdl1.2debian-alsa
  libsdl1.2debian-arts
  libsdl1.2debian-esd
  libsdl1.2debian-nas
  libsdl1.2debian-oss
  libsdl1.2debian-pulseaudio

a.

ps: I plan to upload 1.8.1 in 'unstable' in short time

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#513530: xmltv: new version

[A Mennucc1]

Package: xmltv
Version: 0.5.52-1
Severity: wishlist
Tags: patch

hi,

I packaged a newer version

a.


-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages xmltv depends on:
ii  libxmltv-perl 0.5.52-1   Perl libraries related to the XMLT
ii  xmltv-gui 0.5.52-1   Graphical user interface related t
ii  xmltv-util0.5.52-1   Utilities related to the XMLTV fil

xmltv recommends no packages.

xmltv suggests no packages.

-- no debconf information
Format: 1.0
Source: xmltv
Binary: xmltv, libxmltv-perl, xmltv-util, xmltv-gui
Architecture: all
Version: 0.5.54-1
Maintainer: Chris Butler 
Uploaders: Neil McGovern 
Homepage: http://xmltv.org/
Standards-Version: 3.8.0
Vcs-Svn: http://svn.crustynet.org.uk/repos/xmltv
Build-Depends: debhelper (>= 4.1.75), dpatch
Build-Depends-Indep: perl (>= 5.8.0), perl-modules, libwww-perl (>= 5.65), 
libxml-parser-perl (>= 2.34), libxml-twig-perl (>= 3.28), libxml-writer-perl 
(>= 0.6), libdate-manip-perl (>= 5.42a), libarchive-zip-perl (>= 1.14), 
libcompress-zlib-perl, libhtml-parser-perl (>= 3.34), 
libhtml-tableextract-perl, libhtml-tree-perl (>= 3.17), 
libhttp-cache-transparent-perl (>= 1.0), libio-stringy-perl, libsoap-lite-perl, 
libterm-readkey-perl, libtext-kakasi-perl, perl-tk, libtk-tablematrix-perl, 
libwww-mechanize-perl (>= 1.02), libxml-libxml-perl, libterm-progressbar-perl 
(>= 2.09), liblingua-preferred-perl (>= 0.2.4), libunicode-string-perl, 
liblog-tracemessages-perl, libfile-slurp-perl, libxml-simple-perl, 
libtext-bidi-perl, libxml-libxslt-perl
Checksums-Sha1: 
 ab7024e6b07cf8fec0f643fd7e48ea413ef3cec5 900184 xmltv_0.5.54.orig.tar.gz
 27a3e69a5141c6c7e4ec26a87a576876ca87212d 21432 xmltv_0.5.54-1.diff.gz
Checksums-Sha256: 
 70ea684846adbed31e06c83138364c4ffb3e2356712105493ffbaddaf363cfbd 900184 
xmltv_0.5.54.orig.tar.gz
 737288e47459c393ad9c75b96e4910d916e02d9e152943fdf0a96383b3458202 21432 
xmltv_0.5.54-1.diff.gz
Files: 
 00ce6a806120201e8847300841ae9f15 900184 xmltv_0.5.54.orig.tar.gz
 3b178077e0f4f4de68e85f046d4c 21432 xmltv_0.5.54-1.diff.gz


xmltv_0.5.54-1.diff.gz
Description: Binary data

Bug#472927: 1.8.1

[A Mennucc1]

hi,

do you still have those bugs with 1.8.1 ?

a.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#492488: here it works

[A Mennucc1]

hi,

I wanted to report that I use everyday iceweasel 3.0.3-3 on two amd64
boxes (one at home, one at office), and it works fine for me.

Just wild-guessing...  I have noted that Michele had installed both
the Adobe and the open-source flashplayer plugin  some time ago I
had a problem with the Adobe plugin (crashing with certain web pages
and certain GTK skins, on transparencies, it was fixed in a recent
upload).  At that time I decided to deinstall that plugin, but I found
out it was not so easy, since there are many many copies around.

Michele, please install the latest iceweasel (and -dbg) and try
MOZILLA_DISABLE_PLUGINS=1 iceweasel -safe-mode  

(Note that 'iceweasel -safe-mode' does not disable plugins!)

Also, what about your video card and drivers?

a.

ps: curiosly
 MOZILLA_DISABLE_PLUGINS=1 iceweasel -safe-mode -g
misbehaves: gdb crashes and disappears, and iceweasel goes on alone... 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#481383: new version 'fuzzyocr' 3.5.1+svn135-1

[A Mennucc1]

hi,

I uploaded a new version

the package name is just 'fuzzyocr', it was uploaded to unstable; the
version is 3.5.1+svn135-1 (that means, the latest SVN snapshot)

a.


signature.asc
Description: Digital signature

Bug#457345: new dpkg-source formats in experimental

[A Mennucc1]

What about letting new  formats in experimental to start with?
It would be a nice way to start testing the whole infrastructure
(buildds, PTS, etc etc)

a.


signature.asc
Description: Digital signature

Bug#464207: patch

[A Mennucc1]

hi,

a patch for this bug was posted in the mplayer-dev-eng list
in 11 may

but, after some discussion, AFAIK it was not added into SVN

so I do not know if it is wise to use it

a.

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#490370: nvidia-glx-legacy-71xx: purge fails

[A Mennucc1]

Package: nvidia-glx-legacy-71xx
Severity: normal

hi

I removed nvidia-glx-legacy-71xx to install nvidia-glx-legacy-96xx

then I also decided to purge it away, since it
still leaves around /etc/init.d/nvidia-glx-legacy-71xx
which installs TLS links at boot
(and this is useless, it is already done by ...96xx )

but purging fails, it says

dpkg-divert: mismatch on package
  when removing `diversion of /usr/lib/libGL.so.1 to 
/usr/lib/nvidia/libGL.so.1.xlibmesa by nvidia-glx-legacy-71xx'
  found `diversion of /usr/lib/libGL.so.1 to 
/usr/lib/nvidia/libGL.so.1.xlibmesa by nvidia-glx-legacy-96xx'

and similarly a lot of commands following do fail

a possible workaround would be to remove all diversions on 
package removal, and not on --purge

a.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages nvidia-glx-legacy-71xx depends on:
ii  libc62.7-10  GNU C Library: Shared libraries
ii  libx11-6 2:1.1.4-2   X11 client-side library
ii  libxext6 2:1.0.4-1   X11 miscellaneous extension librar
ii  nvidia-kerne 71.86.01-1+2.6.18.dfsg.1-17 NVIDIA binary kernel module for Li
ii  nvidia-kerne 71.86.01-1  NVIDIA binary kernel module for Li
ii  x11-common   1:7.3+12X Window System (X.Org) infrastruc
ii  xserver-xorg 2:1.4.2-1   Xorg X server - core server

nvidia-glx-legacy-71xx recommends no packages.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#476504: does not build, even with suggested patch , newer patch

[A Mennucc1]

hi

I tried to build the nvidia 169.12-1 module on my amd64 system with
kernel 2.6.25-1 ; I applied the patch found at

http://www.nvnews.net/vbulletin/attachment.php?s=41498f047cfc027419df58a2559e9a7f&attachmentid=30771&d=1205875946

and then tried to compile using 
$ m-a -O -t b-i nvidia

but it failed in a strange way, reporting 
v
  LD [M]  /usr/src/modules/nvidia-kernel/nv/nvidia.o
  Building modules, stage 2.
  MODPOST 1 modules
scripts/mod/modpost: invalid option -- S
make[4]: *** [__modpost] Error 1
^

the above is strange; it is as if the KBUILD system is passing two
options '-c -S' to 'modpost', but these options are no more recognized.

For a quick and dirty fix, I patched
 /lib/modules/2.6.25-1-amd64/build/scripts/Makefie.modpost
as in attachment, and I could then compile the module.

a.

-- 
Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Tonino Carotone)
--- /lib/modules/2.6.25-1-amd64/build/scripts/Makefile.modpost.orig	2008-05-03 14:20:42.0 +0200
+++ /lib/modules/2.6.25-1-amd64/build/scripts/Makefile.modpost	2008-05-04 12:04:39.0 +0200
@@ -70,11 +70,9 @@
  $(if $(KBUILD_EXTMOD),-i,-o) $(kernelsymfile)   \
  $(if $(KBUILD_EXTMOD),-I $(modulesymfile))  \
  $(if $(KBUILD_EXTMOD),-o $(modulesymfile))  \
- $(if $(CONFIG_DEBUG_SECTION_MISMATCH),,-S)  \
  $(if $(CONFIG_MARKERS),-K $(kernelmarkersfile)) \
  $(if $(CONFIG_MARKERS),-M $(markersfile))	 \
- $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w) \
- $(if $(cross_build),-c)
+ $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w)
 
 quiet_cmd_modpost = MODPOST $(words $(filter-out vmlinux FORCE, $^)) modules
   cmd_modpost = $(modpost) -s


signature.asc
Description: Digital signature