Bug#810616: related upstream bug

[SJ Zhu]

https://bugs.kde.org/show_bug.cgi?id=355463

this upstream bug maybe is related and it was fixed.

-- 
Best regards,
Zhu Shengjing

Bug#823891: wget: segmentation fault when terminal width is small

[SJ Zhu]

FYI, it's fixed by upstream
https://savannah.gnu.org/bugs/index.php?47882

Bug#830940: mirrors: more files should be excluded in stage1 sync

[SJ Zhu]

> Please provide a proper error messages.  by-hash should provide proper
> ordering of updates
>

After investigating this problem again, I find all components of debian have
enabled by-hash, for example Contents*.gz files. Then there will be no problem
in this situation.

When I reported this bug, apt-file has upgraded to 3.0 in debian testing, which
downloads Contents*.gz files during apt update. But debian testing has no
by-hash dir for Contents*.gz.

Debian jessie has no by-hash dir but apt-file in jessie will not be
upgraded to 3.0.
So I think the problem is gone in debian.
However not sure for other distributions which also use apt-file and ftpsync.

Thanks,
Shengjing Zhu

Bug#851804: O: bmon -- portable bandwidth monitor and rate estimator

[SJ Zhu]

Hi Dmitry,

I use bmon and like it. I hope I can help.

What skill do I need to maintain it. Currently I'm not a DD/DM, but I
have some basic knowledge about packaging.

Best regards,
Shengjing Zhu

On Thu, 19 Jan 2017 09:08:16 +1100 Dmitry Smirnov  wrote:
> Package: wnpp
> Severity: normal
> 
> "bmon" needs new maintainer...
> 
> -- 
> Regards,
>  Dmitry Smirnov.


signature.asc
Description: PGP signature

Bug#840680: [pkg-gnupg-maint] Bug#840680: dirmngr: Dirmngr not always responding

[SJ Zhu]

> Thanks for this report.  it sounds frustrating!  I hope we can debug it:
> 
> is this "always not responding" or "sometimes not responding"?  I
> haven't observed the same behavior with dirmngr myself, so i'm not sure
> how to best proceed...
> 

I find it is 'sometimes'. To describe it, I use vlc to record a video of
my desktop, see https://www.youtube.com/watch?v=cOLuUKh-_nA
The video describes the problem, but the timestamp is not the same with
the log files I attached.

> this is definitely strange behavior!  have you tried attaching strace to
> the dirmngr process to see what it's doing while it's not answering you?
> or have you tried increasing the logging of dirmngr to see what it's
> doing while it's not responding?
> 
> if the process id of dirmngr is $DIRMNGR_PID, you can use:
> 
> strace -o dirmngr.strace -f -tt -T -p $DIRMNGR_PID
>

I have attach a dirmngr.strace.


> to get an strace dump.
> 
> You can increase the logging by adding these lines to
> ~/.gnupg/dirmngr.conf and then restarting dirmngr:
> 
> log-file /tmp/dirmngr.log
> debug-level advanced
> 

I have attach a dirmngr.log

In the dirmngr.log:
11:36:50 I launch dirmngr by `gpg-connect-agent --dirmngr /bye`
 But this `gpg-connect-agent` is stuch.
11:38:20 I attach strace to dirmngr, and the `gpg-connect-agent`
 returns.
11:39:52 I start second `gpg-connect-agent`, and stuck too
(In strace log, it seems dirmngr already writed to S.dirmngr)
11:40:15 I start third `gpg-connect-agent`, and the second returns.
Then I send `ctrl-c`

It seems no sensitive log, so I publish it to the BTS.

I don't know whether the config file is needed:

dirmngr.conf

keyserver hkp://sks.ustclug.org
hkp-cacert /usr/share/gnupg2/sks-keyservers.netCA.pem
hkp-cacert ~/.gnupg/trusted-certs/DST_Root_CA_X3.pem

log-file /tmp/dirmngr.log
debug-level advanced

gpg-agent.conf

enable-ssh-support

gpg.conf

default-key 7DFBB2F2
2016-10-14 11:36:50 dirmngr[20597] listening on socket 
'/run/user/1000/gnupg/S.dirmngr'
2016-10-14 11:36:50 dirmngr[20598.0] permanently loaded certificates: 0
2016-10-14 11:36:50 dirmngr[20598.0] runtime cached certificates: 0
2016-10-14 11:38:20 dirmngr[20598.1] handler for fd 1 started
2016-10-14 11:38:20 dirmngr[20598.1] DBG: chan_1 -> # Home: /home/zsj/.gnupg
2016-10-14 11:38:20 dirmngr[20598.1] DBG: chan_1 -> # Config: 
/home/zsj/.gnupg/dirmngr.conf
2016-10-14 11:38:20 dirmngr[20598.1] DBG: chan_1 -> OK Dirmngr 2.1.15 at your 
service
2016-10-14 11:38:20 dirmngr[20598.1] connection from process 20595 (1000:1000)
2016-10-14 11:38:20 dirmngr[20598.1] DBG: chan_1 <- [eof]
2016-10-14 11:38:20 dirmngr[20598.1] handler for fd 1 terminated
2016-10-14 11:39:52 dirmngr[20598.1] handler for fd 1 started
2016-10-14 11:39:52 dirmngr[20598.1] DBG: chan_1 -> # Home: /home/zsj/.gnupg
2016-10-14 11:39:52 dirmngr[20598.1] DBG: chan_1 -> # Config: 
/home/zsj/.gnupg/dirmngr.conf
2016-10-14 11:39:52 dirmngr[20598.1] DBG: chan_1 -> OK Dirmngr 2.1.15 at your 
service
2016-10-14 11:39:52 dirmngr[20598.1] connection from process 20745 (1000:1000)
2016-10-14 11:39:52 dirmngr[20598.1] DBG: chan_1 <- [eof]
2016-10-14 11:39:52 dirmngr[20598.1] handler for fd 1 terminated
2016-10-14 11:40:15 dirmngr[20598.2] handler for fd 2 started
2016-10-14 11:40:15 dirmngr[20598.2] DBG: chan_2 -> # Home: /home/zsj/.gnupg
2016-10-14 11:40:15 dirmngr[20598.2] Assuan accept problem: Broken pipe
2016-10-14 11:40:15 dirmngr[20598.2] handler for fd 2 terminated
20600 11:38:20.134818 futex(0x7fa74998d200, 
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL,  
20599 11:38:20.134970 pselect6(1, [], NULL, NULL, {1, 56253895}, {NULL, 8} 

20600 11:38:20.135039 <... futex resumed> ) = -1 EAGAIN (Resource temporarily 
unavailable) <0.89>
20600 11:38:20.135122 mmap(NULL, 134217728, PROT_NONE, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0 
20598 11:38:20.135189 pselect6(5, [0 4], NULL, NULL, {0, 91526580}, {[], 8} 

20600 11:38:20.135265 <... mmap resumed> ) = 0x7fa73e0e2000 <0.92>
20600 11:38:20.135524 munmap(0x7fa73e0e2000, 32628736) = 0 <0.000110>
20600 11:38:20.135737 munmap(0x7fa74400, 34480128) = 0 <0.35>
20600 11:38:20.135833 mprotect(0x7fa74000, 135168, PROT_READ|PROT_WRITE) = 
0 <0.33>
20600 11:38:20.136019 stat("/etc/localtime", {st_mode=S_IFREG|0644, 
st_size=414, ...}) = 0 <0.48>
20600 11:38:20.136247 write(3, "2016-10-14 11:38:20 dirmngr[2059"..., 53) = 53 
<0.42>
20600 11:38:20.136359 write(3, " started\n", 9) = 9 <0.35>
20600 11:38:20.136576 getsockopt(1, SOL_SOCKET, SO_PEERCRED, {pid=20595, 
uid=1000, gid=1000}, [12]) = 0 <0.32>
20600 11:38:20.136702 stat("/etc/localtime", {st_mode=S_IFREG|0644, 
st_size=414, ...}) = 0 <0.39>
20600 11:38:20.136834 write(3, "2016-10-14 11:38:20 dirmngr[2059"..., 42) = 42 
<0.29>
20600 11:38:20.136920 write(3, "chan_1 -> # Home: /home/zsj/.gnu"..., 35) = 35 
<0.29>
20600 11:38:20.137018 futex(0x7fa74998d200, FUTEX_WAKE_PRIVATE, 1) = 0 

Bug#833741: pepperflashplugin-nonfree: Feature request?: Download from Adobe instead of Google.

[SJ Zhu]

With the release of new google-chrome-stable(54.0.2840.59-1), there is
no libpepflashplayer.so in its deb pack.

```
$ dpkg -L google-chrome-stable|grep so
/opt/google/chrome/default_apps/external_extensions.json
/opt/google/chrome/resources.pak
/opt/google/chrome/libwidevinecdm.so
/opt/google/chrome/libwidevinecdmadapter.so
```

Please increase this bug's severity.

On Mon, 8 Aug 2016 16:48:06 + Bart Martens  wrote:
> On Mon, Aug 08, 2016 at 11:11:57PM +1200, James C wrote:
> > Package: pepperflashplugin-nonfree
> > Version: 1.8.1
> > Severity: wishlist
> >
> > Dear Maintainer,
> >
> > Apparently Adobe now has Pepper Flash available for download from their 
> > site.
> > This is just Pepper Flash, not the whole Chrome browser.
> > Also, an update to the 32-bit version seems to be available.
> > See:
> > http://forum.mepiscommunity.org/viewtopic.php?t=40254
>
> Indeed.
>
> >
> > (This was mentioned in the discussion for #831058,
> > but I think it deserves a new bug report.)
>
> I agree, thanks.
>
> >
> > I'm not sure if this counts as a bug, so I've marked it wishlist,
>
> Perfect.
>
> > but if it was possible to switch to downloading from the Adobe site,
> > it would speed up the download, and make the 32-bit version available again.
>
> Yes, I'm considering that.
>
> Regards,
>
> Bart Martens
>
>

Bug#824223: letsencrypt.sh: Provide more automatism for letsencrypt.sh

[SJ Zhu]

How about add a systemd service like certbot?

A modified version from certbot package:

/lib/systemd/system/letsencrypt.sh.service

[Unit]
Description=letsencrypt.sh
Documentation=file:///usr/share/doc/letsencrypt.sh/README.Debian
[Service]
Type=oneshot
ExecStart=/usr/bin/letsencrypt.sh -c
PrivateTmp=true

/lib/systemd/system/letsencrypt.sh.timer

[Unit]
Description=Run letsencrypt.sh twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target


On Fri, 13 May 2016 22:28:30 +0200 Cord Beermann  wrote:
> Package: letsencrypt.sh
> Version: 0.1.0-2
> Severity: wishlist
>
> I continue the discussion from Bug#822493 here:
>
> Please provide a cron based automatism for refreshing certificates.
>
> It would be nice that users only need to provide the hostname(s) they
> want to get a certificate for in /etc/letsencrypt.sh/ and a cronjob
> that runs letsencrypt.sh -c takes care for refreshing it before it expires.
>
> That script would also need hooks to reload daemons that need to know
> about a certificate-change.
>
> Debconf could ask if automatic refresh is activated.
>
> Cord
>
>

Bug#860528: Acknowledgement (nmu: libev_1:4.22-1)

[SJ Zhu]

> I have scheduled the binNMU, but binNMUs cannot close bugs.  Please
> verify that the binNMU works, appears in testing and then close the bug.
>

Hi,
Could you check why it still haven't appeared in sid?

Thanks
Shengjing Zhu

Bug#860958: zfs-linux: please add kernel version after depmod in postinst of zfs-modules

[SJ Zhu]

Package: src:zfs-linux
Version: 0.6.5.9-5
Severity: wishlist

Dear Maintainer,

Although the target override_dh_binary-modules in debian/rules is not
used in official package, could you fix the
debian/zfs-modules-_KVERS_.postinst.in file?
the depmod command should specify the kernel version, since the
generated package is for a specific kernel, not the current running
kernel.
For example, you can use `depmod _KVERS_`.

-- 
Regards,
Shengjing Zhu

Bug#860302: libmbedtls-dev: please provide static lib in dev package

[SJ Zhu]

Yes, I agree there's disadvantage for static linking.
My use case is to send a copy of the program to others for testing, so
the users don't need to bother the version of the library  and focus
on testing the program itself.
When the program is ready for distrubution, it's better to build a
deb/rpm package and link it dynamically.

On Fri, Apr 14, 2017 at 6:38 PM, James Cowgill  wrote:
> Control: severity -1 wishlist
>
> Hi,
>
> On 14/04/17 10:45, Shengjing Zhu wrote:
>> Package: libmbedtls-dev
>> Version: 2.4.2-1
>> Severity: important
>>
>> Dear Maintainer,
>>
>> In debian/rules, you set -DUSE_STATIC_MBEDTLS_LIBRARY=OFF, but static
>> library is useful in development, and .a file should be put in -dev
>> package according to debian policy 8.3
>
> I'll think about it, but I see a lot of disadvantages with statically
> linking a security library with few advantages. Why would static /
> dynamic linking matter during development?
>
> James
>



-- 
Regards,
Shengjing Zhu

Bug#860301: libev-dev: failed to static link libev.a

[SJ Zhu]

I may figure out why rebuild can fix this,
gcc-6 enables -fPIE by default after 6.2.0-7, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835148
This change is taken on 18 Oct 2016, but libev 1:4.22-1 was built on Jan 2016.

But it still confused me why dh didn't build this library with pic/pie.

Best regards,
Shengjing Zhu

Bug#829046: Difficulties in packaging pagure

[SJ Zhu]

On Thu, May 18, 2017 at 11:59:36AM +0800, Boyuan Yang wrote:
> There are some problems: this packaging uses upstream source code directly 
> from from Git repository, not the tarball upstream released on https://
> pagures.io.
> 

Hi,
I import the source by `git archvie` and remove the minified js,
then import it to upstream branch like what sergiodj did.

PS. I think I forget to remove some files which filename is not matched
by "*.min.js"

> The tarballs contain different distributed files than git repo because 
> tarballs 
> are generated by "python setup.py sdist", which would drop some scripts. 
> Among 
> the dropped files there is the "runtest.sh" script, on which this packaging 
> instruction relies.
> 
> There is a known workaround: we could switch the upstream from https://
> pagures.io/pagures to its mirror on GitHub [1]. The tarball provided by 
> GitHub 
> is simply a compression of files checked out from git tag. I'm not sure if 
> that 
> is acceptable.
> 
> [1] https://github.com/pypingou/pagure/
> 
> --
> Boyuan Yang




signature.asc
Description: PGP signature

Bug#829046: Difficulties in packaging pagure

[SJ Zhu]

On Thu, May 18, 2017 at 08:49:58AM +0530, Pirate Praveen wrote:
> > The remain work is to deal with the JS libraries,
> > some are still not in Debian:
> > * jdenticon.js
> > * cal-heatmap
> 
> There is ruby-cal-heatmap, which I can split or package it separately.

I think we need to separate it, since I don't want this python package
to depend on ruby(bring by ruby-cal-heatmap-rails)

> 
> > * jquery.atwho
> 
> Same for ruby-jquery-atwho-rails
> 
> > * emojione
> 
> This is already there
> https://packages.debian.org/unstable/libjs-emojione
> 

I need some time to figure out how the emojione js work,
upstream pin it at version 1.3.1, see here:
https://pagure.io/pagure/pull-request/1475

I will try to setup a working pagure server to see what if we use
newer emojione.

Besides, in pagure/static/emoji dir,

emoji/jquery.textcomplete-1.7.1.js
emoji/emoji_strategy.json
emoji/jquery.textcomplete.js
emoji/emojione.sprites.min.css
emoji/emojione.sprites.png
emoji/emoji_strategy-1.3.1.json
emoji/emojione.sprites.css
emoji/emojione-1.3.1.js
emoji/emojicomplete.js
emoji/jquery.textcomplete.min.js
emoji/emojione.js
emoji/emojione.min.js
emoji/emojione.sprites.min-1.3.1.css
emoji/emojione.sprites-1.3.1.png
emoji/emojione.sprites-1.3.1.css

libjs-emojione only covers emojione{,.min}.js

I think we need to dig more on this, and one new library I missed,

* jquery.textcomplete

Best regards,
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#762252: ITP: afdko -- Adobe Font Development Kit for OpenType

[SJ Zhu]

On Sat, 30 Apr 2016 20:55:56 +1000 Dmitry Smirnov  wrote:
> Just to mention relevant upstream bugs
>
>   * non-free files:
>
> https://github.com/adobe-type-tools/afdko/issues/136


Hi, I see the issue 136 is closed and it says:

These are covered and are compatible with the Apache 2.0 license for
the entire AFDKO.


>
>   * packaging:
>
> https://github.com/adobe-type-tools/afdko/issues/41
>
> ###
>
> Debian package repository:
>
> https://anonscm.debian.org/cgit/pkg-fonts/afdko.git/
>
> --
> Regards,
>  Dmitry Smirnov.
>
> ---
>
> However beautiful the strategy, you should occasionally look at the
> results.
> -- Winston Churchill