Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Leo Antunes]

Hi Reinhard,

absolutely no worries at all! Huge thanks on all your work and sorry for not 
being more responsive. I can only manage some "debian time" in between "real 
life" blocks, so a lot falls through the cracks :(

Cheers
Leo

--- Original Message ---
On Wednesday, July 19th, 2023 at 12:35, Reinhard Tartler  
wrote:

> Hi Leo,
>
> I hope you are well. Now that all dependencies to build this package are in 
> place, I've taken the liberty of uploading the package to debian/experimental 
> and pushed my sources to 
> https://salsa.debian.org/go-team/packages/golang-github-sigstore-sigstore
>
> I really don't want this to be seen as an ITP takeover, since we've been 
> talking on this ITP for a while, I hope that's okay. Please take a look at 
> this repo and at 
> https://ftp-master.debian.org/new/golang-github-sigstore-sigstore_1.4.0-1.html
>  and let me know what you think.
>
> Best,
> -rt
> --
>
> regards,
> Reinhard

Bug#1038117: util-linux: resume building of static libs

[Leo Antunes]

Hi,

On Thu, 15 Jun 2023 17:38:27 +0200 Chris Hofstaedtler 
wrote:
> For Debian we just do the Debian thing: do not ship static libraries
> except for very narrow within-Debian-use-cases.

Don't wanna come off too abrasive here, but:
$ apt-file search -lx '^/usr/lib/.*\.a$' | sort | uniq | wc -l
6849

That doesn't look very narrow 😅
Also, policy explicitly mentions it as "usually provided"[0], which -
granted - doesn't mean you *have* to do it, but does kinda endorse it.

Just because we (via policy) forbid linking statically within debian,
it shouldn't mean we have to unnecessarily alienate out users (in this
case myself 🙈) when they want to do it on their systems.

> I think if you do custom stuff for minimal containers etc, its best
> if you bring your own libraries and do not rely on development
> packages intended -for- Debian packages.

Not sure I understand the reasoning: a library is a tool, in the
broadest sense. Our users rely on debian providing a usable gcc to
build stuff, just as they rely on us providing libs for them to link
against, dynamically or otherwise. AFAICT there's nothing particularly
debian-specific about this?

But don't get me wrong: if there's a technical reason I'm overlooking,
then the points above are irrelevant, of course.

--
Leo

[0]
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#static-libraries

Bug#1038118: lcms2: please build static libs

[Leo Antunes]

Source: lcms2
Version: 2.14-2
Severity: normal

Dear Maintainers,

It would be great if we could start including the .a files in the -dev
packages. This would allow building static binaries against the library
(e.g. for minimal container cases)

Thanks!
Leo Antunes

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1038117: util-linux: resume building of static libs

[Leo Antunes]

Source: util-linux
Version: 2.38.1-5+b1
Severity: normal

Dear Maintainers,

During the bump to dh13 a couple of years back the static libs were
removed from all *-dev packages[0].
This change has the unfortunate side-effect of making it impossible to
actually use the libraries in static builds (e.g. when building for
minimal container scenarios).

It would be great if we could either re-introduce them or at least add
a comment explaining the reasoning behind the removal (to avoid future
me bumping into this again ;))


Thanks!

[0] 
https://salsa.debian.org/debian/util-linux/-/commit/1e827a6811e2b22aacdd4b91b11aca9f103e5d12


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Leo Antunes]

Sorry for the late reply. My laptop decided it was a good time to break, so 
I'll have even less time to work on this in the next few days/weeks :/

--- Original Message ---
On Sunday, March 26th, 2023 at 22:07, Reinhard Tartler  
wrote:

> Sounds good.
> 
> I'm happy to take on the easier dependencies, such as pkg/browser or 
> jellydator/ttlcache.


That would be a huge help already!


> But the dependency on boulder is giving me a massive headache. It is really 
> unfortunate that they chose to use such a heavy dependency for a rather 
> simple task (goodkey). What are your thoughts on resolving this?


I didn't dive deep into the code, but I suspect we can patch away the boulder 
dep. I'll gladly give it a try as soon as I have a workable laptop again (but 
feel free to jump in if you find the time!)


Regards,
Leo Antunes

Bug#1030857: transmission 4.0.1-1

[Leo Antunes]

hi,

--- Original Message ---
On Friday, March 17th, 2023 at 21:51, Barak A. Pearlmutter 
 wrote:

> I would say that marking lots of 100% downloaded torrent as 0%, and
> refusing to re-verify them, would count as a severity: important bug,
> and hence allow 4.0.2 to get into the release. The release team wants
> a high-quality release just as much as we do, and transmission is a
> leaf package and therefore they might be a bit more lenient.

Testing still has 3.00, so I'm afraid bugs in 4.0.1 are probably not an 
argument for migration.
But who knows, maybe 🤷
 
> Anyway, I've just prepared a 4.0.2-1 release candidate,
> https://salsa.debian.org/bap/transmission branch "master" with
> "upstream" and "pristine-tar" branches updated as well, and new tag
> "upstream/4.0.2". I've tested it, and it solves the "fully downloaded
> torrent sticks as 0% and refuses to verify" problem, and seems
> otherwise functional.

4.0.2 is already uploaded ;)
https://tracker.debian.org/news/1427244/accepted-transmission-402-1-source-into-unstable/


Regards,
Leo

Bug#1030857: transmission 4.0.1-1

[Leo Antunes]

I'm on it.
But AFAIUI, the only chance of getting it through the freeze would be some 
autopkgtests[0] :/

Regards,

[0] https://release.debian.org/testing/freeze_policy.html#hard


--- Original Message ---
On Thursday, March 16th, 2023 at 15:28, Sandro Tosi  wrote:
> 
> upstream released 4.0.2:
> https://github.com/transmission/transmission/releases/tag/4.0.2

Bug#1030857: verification issue

[Leo Antunes]

Hi,

--- Original Message ---
On Thursday, March 2nd, 2023 at 01:39, Barak A. Pearlmutter 
 wrote:
> Okay, I cherry-picked upstream commits 487cc27e1..d21a3b622, the
> endpoint being the current upstream/main, and built, and installed,
> and it seems to solve this problem. The "no bencoded data to parse"
> messages are gone. And things verify upon request, with most of them
> succeeding.

Since we missed the freeze anyway, I'd suggest we give upstream a couple more 
days for a release including the fixes?

> A few failed to verify even though they are absolutely
> downloaded; these are all single file torrents, instead of a directory
> containing files. So that's a clue as to the bug, I suppose.

What does "fail to verify" mean? Does it invalidate the whole download? Or are 
they stuck in some state?
My test upgrade triggered verifications for all existing torrents, but once 
verifications were done, all seemed good.


Cheers
Leo Antunes

Bug#1030857: Testing

[Leo Antunes]

Hi,

On Fri, 24 Feb 2023 21:28:18 + "Barak A. Pearlmutter" wrote:
> The upgraded daemon invalidates all downloaded data and wants to
> verify them, which is a local operation, but is still taking forever.
> I think that's supposed to be a feature not a bug.

Yeah, that makes sense.

> If someone were to test the clients that would be great!

Unless morph vetoes it, I'd merge your 3 salsa MRs [0][1][2] and if no obvious 
problems pop up during testing I'd just upload it. WDYT?


Cheers
Leo Antunes


[0] https://salsa.debian.org/debian/transmission/-/merge_requests/11
[1] https://salsa.debian.org/debian/transmission/-/merge_requests/12
[2] https://salsa.debian.org/debian/transmission/-/merge_requests/13

Bug#1030857: transmission: New 4.0 version is available

[Leo Antunes]

Hi,

Just FYI: I have done some work in the salsa repo[0], but there are still a few 
kinks to iron out before we can ship it. It builds, but my debhelper-foo is a 
bit rusty :)

If anyone wants to jump in and finish it up, I wouldn't complain!

Cheers
Leo

[0] https://salsa.debian.org/debian/transmission

Bug#1030840: fonts-femkeklaver: relicensing of Debian packaging to 0BSD?

[Leo Antunes]

Hi Gioele,

--- Original Message ---
On Wednesday, February 8th, 2023 at 09:06, Gioele Barabucci  
wrote:

> Given the trivial amount of packaging now left (a handful of boilerplate
> code), would you be OK with relicensing it under 0BSD (ISC without
> attribution, pretty much public domain)?
> 
> https://opensource.org/licenses/0BSD
> 
> A yes/no answer is enough. I'll take care of the change if you both agree.

Sure, go ahead.


Cheers
Leo Antunes

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Leo Antunes]

Hi Reinhard,

It seems I underestimated the work and overestimated by free time: we need some 
bumps for deps (e.g. golang-github-azure-azure-sdk-for-go-dev) and maybe some 
patching to get rid of other deps (e.g. github.com/letsencrypt/boulder), if we 
can manage that.
OTOH, I see you already took care of #1030555 and #1030557! That's great! :)

Cheers
Leo


--- Original Message ---
On Thursday, February 2nd, 2023 at 12:33, Reinhard Tartler  
wrote:


> seems https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022937 was accepted. 
> Any update on sigstore packaging?

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Leo Antunes]

Hi Reinhard!

I think this changed a bit in the meantime: now the sigstore project has mostly 
shared lib code, while the individual commands (rekor, fulcio, gitsign, etc) 
are all in separate repos. So I expect this library to not be THAT difficult to 
package (the next one on my list is rekor - see #990249 - which will probably 
require more work).
As soon as #1022937 is done (waiting in NEW since 2 months), I expect sigstore 
to be a quick follow-up.
However, I'd gladly take an extra pair of eyes on the package, so I can ping 
you as soon as I have something that builds.

Thanks,
Leo Antunes
--- Original Message ---
On Thursday, January 19th, 2023 at 09:37, Reinhard Tartler  
wrote:

> Hi Leo,
>
> Thank you so much for your interest in packaging this! -- I've noticed that 
> it is a dependency of containers/image for image signing, and have looked at 
> this package before. Unfortunately, I got intimidated with the sheer number 
> of unpackaged dependencies that it requires. Maybe this has improved since 
> the last time I looked at it? In any case, I've decided to patch the source 
> to disable signing functionality to avoid requiring code from sigstore, which 
> is of course very unfortunate.
>
> Let me know if you could use another set of eyeballs or help with this 
> package. It surely seems intimidating (at least to me).
>
> best,
> -rt
>
> On Wed, Jan 18, 2023 at 3:21 PM Leo Antunes  wrote:
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Leo Antunes 
>>
>> * Package name : golang-github-sigstore-sigstore
>> Version : 1.5.1-1
>> Upstream Author : The Sigstore Authors 
>> * URL : https://github.com/sigstore/sigstore
>> * License : Apache-2.0
>> Programming Lang: Go
>> Description : Common go library shared across sigstore services and clients
>>
>> sigstore/sigstore contains common Sigstore code: that is, code shared
>> by infrastructure (e.g. Fulcio and Rekor) and Go language clients (e.g.
>> Cosign and Gitsign.
>
> --
>
> regards,
> Reinhard

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: golang-github-sigstore-sigstore
  Version : 1.5.1-1
  Upstream Author : The Sigstore Authors 
* URL : https://github.com/sigstore/sigstore
* License : Apache-2.0
  Programming Lang: Go
  Description : Common go library shared across sigstore services and 
clients

 sigstore/sigstore contains common Sigstore code: that is, code shared
 by infrastructure (e.g. Fulcio and Rekor) and Go language clients (e.g.
 Cosign and Gitsign.

Bug#990249: Giving it a try

[Leo Antunes]

Hi,

I'll give this a try for #1019518.
I'll start with the library to solve the dep, but try to get the binary while 
I'm at it.
Can't make any promises on the time frame :/

--
Leo

Bug#1024430: ITP: golang-github-coreos-go-oidc -- A Go OpenID Connect client.

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: golang-github-coreos-go-oidc-v3
  Version : 3.4.0-1
  Upstream Author : CoreOS
* URL : https://github.com/coreos/go-oidc
* License : Apache-2.0
  Programming Lang: Go
  Description : Go libraries for implementing OIDC clients and servers

 This package provides a comprehensive collection of golang libraries
 for other projects to implement OpenID Connect (OIDC) server and
 client components.

Bug#1023288: ITP: golang-github-certifi-gocertifi -- curated collection of Root Certificates

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: golang-github-certifi-gocertifi
  Version : 2021.04.29-1
  Upstream Author : Certifi
* URL : https://github.com/certifi/gocertifi
* License : MPL-2.0
  Programming Lang: Go
  Description : curated collection of Root Certificates
 This Go package contains a CA bundle that you can reference in your Go
 code. This is useful for systems that do not have CA bundles that Golang
 can find itself, or where a uniform set of CAs is valuable.
 .
 This is the same CA bundle that ships with the Python Requests
 (https://github.com/kennethreitz/requests) library, and is a Golang
 specific port of certifi (https://github.com/kennethreitz/certifi). The
 CA bundle is derived from Mozilla's canonical set.

Bug#1023287: ITP: golang-github-github-smimesign -- An S/MIME signing utility for use with Git

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: golang-github-github-smimesign
  Version : 0.2.0-1
  Upstream Author : GitHub
* URL : https://github.com/github/smimesign
* License : Expat
  Programming Lang: Go
  Description : An S/MIME signing utility for use with Git

 Smimesign is an S/MIME signing utility that is compatible with Git.
 This allows developers to sign their Git commits and tags using
 X.509 certificates issued by public certificate authorities or their
 organization's internal certificate authority.

Bug#1019518: ITP: gitsign -- keyless git signing using sigstore

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: gitsign
  Version : 0.3.0
  Upstream Author : The Sigstore Authors 
* URL : https://sigstore.dev
* License : Apache 2.0
  Programming Lang: go
  Description : keyless git signing using sigstore

Tool for keyless signing of git commits based on sigstore.

Bug#1008881: RFP: lapce -- Lightning-fast and Powerful Code Editor

[Leo Antunes]

Package: wnpp
Severity: wishlist

* Package name: lapce
  Version : v0.0.12
  Upstream Author : Dongdong Zhou 
* URL : https://lapce.dev
* License : ASL-2.0
  Programming Lang: Rust
  Description : Lightning-fast and Powerful Code Editor

GUI based code editor. Extensible via WASI plugins.

Bug#989207: RFP: cuelang -- language and tooling for defining, generating, and validating data in multiple formats

[Leo Antunes]

Package: wnpp
Severity: wishlist

* Package name: cuelang
  Version : v0.4.0
  Upstream Author : Marcel van Lohuizen 
* URL : https://cuelang.org
* License : Apache-2.0
  Programming Lang: Go/Cue
  Description : language and tooling for defining, generating, and 
validating data in multiple formats

 CUE is an open source data constraint language which aims to simplify tasks 
involving defining and using data.
 .
 It is a superset of JSON, allowing users familiar with JSON to get started 
quickly.

Bug#973724: RFS: hcloud-python/1.10.0-1 -- official client library for Hetzner Cloud

[Leo Antunes]

Package: sponsorship-requests
Severity: wishlist

Dear Maintainers,

I am looking for a sponsor for my package "hcloud-python":

* Package name: hcloud-python
  Version : 1.10.0-1
  Upstream Author : Hetzner Cloud GmbH
* URL : https://github.com/hetznercloud/hcloud-python
* License : MIT
  Section : python

It builds those binary packages:

  python3-hcloud - official client library for Hetzner Cloud

For more info: https://mentors.debian.net/package/hcloud-python


Alternatively, download it with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/h/hcloud-python/hcloud-python_1.10.0-1.dsc


Cheers,
Leo Antunes



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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

Bug#972444: ffmpeg: please build with libvo-amrwbenc0 support

[Leo Antunes]

Package: ffmpeg
Version: 7:4.3.1-4
Severity: wishlist

Dear Maintainer,

It would be great if ffmpeg could be built with --enable-libvo-amrwbenc
for AMR-WB encoding support[0].
AFAICT the needed libvo-amrwbenc-dev is already available in Debian.


Cheers,
Leo

[0] https://www.ffmpeg.org/ffmpeg-codecs.html#libvo_002damrwbenc


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 ffmpeg depends on:
ii  libavcodec587:4.3.1-4
ii  libavdevice58   7:4.3.1-4
ii  libavfilter77:4.3.1-4
ii  libavformat58   7:4.3.1-4
ii  libavresample4  7:4.3.1-4
ii  libavutil56 7:4.3.1-4
ii  libc6   2.31-4
ii  libpostproc55   7:4.3.1-4
ii  libsdl2-2.0-0   2.0.12+dfsg1-4
ii  libswresample3  7:4.3.1-4
ii  libswscale5 7:4.3.1-4

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

Bug#972439: RFP: tailscale -- wireguard overlay network manager (client)

[Leo Antunes]

Package: wnpp
Severity: wishlist

* Package name: tailscale
  Version : v1.0.3
  Upstream Author : Tailscale Inc. 
* URL : https://github.com/tailscale/tailscale
* License : BSD
  Programming Lang: Go
  Description : wireguard overlay network manager (client)

Client for the Tailscale™ wireguard overlay network service.
.
Tailscale provides a centralized service for managing wireguard
connection across a fleet of machines.

Bug#963574: RFS: hcloud-python/1.8.0-1 [ITP] -- official client library for Hetzner Cloud

[Leo Antunes]

On Thu, 27 Aug 2020 16:28:32 +0200 Tobias Frost  wrote:
> thanks for the package, I've just uploaded it to the NEW queue…

\o/  thanks!

> One remark: Do you think it would be sensible to also package the 
> documentation?

Good idea. Hadn't thought about it. I'll check it out.

> Another one: It seems that the CI configuration on salsa is broken; please 
> check
> if the right yaml file is selected (I've forked the project to check it and on
> my site it looks ok: https://salsa.debian.org/tobi/hcloud-python/-/pipelines)

Ah, good catch! Thanks.


Cheers,
Leo

Bug#963611: RFS: golang-github-stevenroose-gonfig/0.1.5-1 [ITP] -- Go package for program configuration (library)

[Leo Antunes]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "golang-github-stevenroose-gonfig"

 * Package name: golang-github-stevenroose-gonfig
   Version : 0.1.5-1
   Upstream Author : Steven Roose 
 * URL : https://github.com/stevenroose/gonfig
 * License : MIT
 * Vcs : 
https://salsa.debian.org/go-team/packages/golang-github-stevenroose-gonfig
   Section : devel

It builds those binary packages:

  golang-github-stevenroose-gonfig-dev - Go package for program configuration 
(library)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/golang-github-stevenroose-gonfig

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-stevenroose-gonfig/golang-github-stevenroose-gonfig_0.1.5-1.dsc

Changes since the last upload:

   * Initial release (Closes: #963576)

Regards,

--
  Leo Antunes

Bug#963610: RFS: golang-github-mdlayher-netlink/1.1.0-1 [ITP] -- Package netlink provides low-level access to Linux netlink sockets. (library)

[Leo Antunes]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "golang-github-mdlayher-netlink"

 * Package name: golang-github-mdlayher-netlink
   Version : 1.1.0-1
   Upstream Author : Matt Layher 
 * URL : https://github.com/mdlayher/netlink
 * License : Expat
 * Vcs : 
https://salsa.debian.org/go-team/packages/golang-github-mdlayher-netlink
   Section : devel

It builds those binary packages:

  golang-github-mdlayher-netlink-dev - Package netlink provides low-level 
access to Linux netlink sockets. (library)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/golang-github-mdlayher-netlink

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-mdlayher-netlink/golang-github-mdlayher-netlink_1.1.0-1.dsc

Changes since the last upload:

   * Initial release (Closes: #963592)

Regards,
--
Leo Antunes

Bug#963608: ITP: golang-github-mdlayher-genetlink -- Package genetlink implements generic netlink interactions and data types.

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 
Control: block 963577 by -1

* Package name: golang-github-mdlayher-genetlink
  Version : 1.0.0-1
  Upstream Author : Matt Layher
* URL : https://github.com/mdlayher/genetlink
* License : Expat
  Programming Lang: Go
  Description : Package genetlink implements generic netlink interactions 
and data types.

 Package genetlink implements generic netlink interactions and data
 types.

Bug#963594: ITP: golang-github-jsimonetti-rtnetlink -- Package rtnetlink provides low-level access to the Linux rtnetlink API. MIT Licensed.

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 
Control: block 963592 by -1

* Package name: golang-github-jsimonetti-rtnetlink
  Version : 0.0~git20200505.3ee32e7-1
  Upstream Author : Jeroen Simonetti
* URL : https://github.com/jsimonetti/rtnetlink
* License : Expat
  Programming Lang: Go
  Description : Package rtnetlink provides low-level access to the Linux 
rtnetlink API.

 Package rtnetlink allows the kernel's routing tables to be read and
 altered. Network routes, IP addresses, Link parameters, Neighbor setups,
 Queueing disciplines, Traffic classes and Packet classifiers may all be
 controlled. It is based on netlink messages.
 .
 A convenient, high-level API wrapper is available using package rtnl
 (https://godoc.org/github.com/jsimonetti/rtnetlink/rtnl).
 .
 The base rtnetlink library explicitly only exposes a limited low-level
 API to rtnetlink. It is not the intention (nor wish) to create an
 iproute2 replacement.

Bug#963592: ITP: golang-github-mdlayher-netlink -- Package netlink provides low-level access to Linux netlink sockets. MIT Licensed.

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 
Control: block 963577 by -1

* Package name: golang-github-mdlayher-netlink
  Version : 1.1.0-1
  Upstream Author : Matt Layher
* URL : https://github.com/mdlayher/netlink
* License : Expat
  Programming Lang: Go
  Description : Package netlink provides low-level access to Linux netlink 
sockets.

 Package netlink provides low-level access to Linux netlink sockets.

Bug#963577: ITP: golang-zx2c4-wireguard-wgctrl -- Package wgctrl enables control of WireGuard interfaces on multiple platforms.

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 
Control: block 963575 by -1

* Package name: golang-zx2c4-wireguard-wgctrl
  Version : 0.0~git20200609.bd2cb78-1
  Upstream Author : WireGuard
* URL : https://github.com/WireGuard/wgctrl-go
* License : Expat
  Programming Lang: Go
  Description : Package wgctrl enables control of WireGuard interfaces on 
multiple platforms.

 Package wgctrl enables control of WireGuard devices on multiple platforms.
 .
 wgctrl can control multiple types of WireGuard devices, including:
 - Linux kernel module devices, via generic netlink
 - userspace devices (e.g. wireguard-go), via the userspace
   configuration protocol
 .
 This package implements WireGuard configuration protocol operations,
 enabling the configuration of existing WireGuard devices. Operations such
 as creating WireGuard devices, or applying IP addresses to those devices,
 are out of scope for this package.

Bug#963576: ITP: golang-github-stevenroose-gonfig -- Go package for program configuration

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: golang-github-stevenroose-gonfig
  Version : 0.1.5-1
  Upstream Author : Steven Roose
* URL : https://github.com/stevenroose/gonfig
* License : Expat
  Programming Lang: Go
  Description : Go package for program configuration

 gonfig is a configuration library designed using the following
 principles:
 - The configuration variables are fully specified and loaded into a
   struct variable.
 - You only need one statement to load the configuration fully.
 - Configuration variables can be retrieved from various sources, in
   this order of increasing priority:
   - default values from the struct definition
   - the value already in the object when passed into Load()
   - config file in either YAML, TOML, JSON or a custom decoder
   - environment variables
   - command line flags

 Furthermore, it has the following features:
 - supported types for interpreting:
   - native Go types: all int, uint, string, bool
   - types that implement TextUnmarshaler from the "encoding" package
   - byte slices ([]byte) are interpreted as base64
   - slices of the above mentioned types
   - map[string]interface{}
 - the location of the config file can be passed through command line
   flags or environment variables
 - printing help message (and hiding individual flags)

This package is needed for #963575

Bug#963575: ITP: wesher -- wireguard overlay mesh network manager

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: wesher
  Version : 0.2.6-1
  Upstream Author : Leo Antunes
* URL : https://github.com/costela/wesher
* License : GPL-3.0
  Programming Lang: Go
  Description : wireguard overlay mesh network manager
 wesher creates and manages an encrypted mesh overlay network across a
 group of nodes, using wireguard.
 .
 Its main use-case is adding low-maintenance security to public-cloud
 networks or connecting different cloud providers.
 .
 WARNING: since mesh membership is controlled by a mesh-wide pre-shared
 key, this effectively downgrades some of the security benefits from
 wireguard. See security considerations in README for more details.

Bug#963574: RFS: hcloud-python/1.8.0-1 [ITP] -- official client library for Hetzner Cloud

[Leo Antunes]

Package: sponsorship-requests
Severity: wishlist

Dear Maintainers,

I am looking for a sponsor for my package "hcloud-python":

* Package name: hcloud-python
  Version : 1.8.0-1
  Upstream Author : Hetzner Cloud GmbH
* URL : https://github.com/hetznercloud/hcloud-python
* License : MIT
  Section : python

It builds those binary packages:

  python3-hcloud - official client library for Hetzner Cloud

For more info: https://mentors.debian.net/package/hcloud-python


Alternatively, download it with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/h/hcloud-python/hcloud-python_1.8.0-1.dsc


Cheers,
Leo Antunes

Bug#961920: RM: pidgin-encryption -- ROM; abandoned upstream

[Leo Antunes]

Package: ftp.debian.org
Severity: normal

Hi ftp-master,

As mentioned in the RFA bug[0], this package is long abandoned, has
better alternatives and low popcon score.

Cheers
Leo Antunes

[0] https://bugs.debian.org/899195

Bug#955750: python3-pgspecial: please update to new upstream release

[Leo Antunes]

Package: python3-pgspecial
Version: 1.9.0-2
Severity: wishlist

Dear Maintainers,

It would be really cool if you could find the time to update pgspecial
to the latest upstream release. In particular I'm interested in
resolving this issue:
https://github.com/dbcli/pgcli/issues/1130

Thanks for all the work!

Cheers,
Leo

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pgspecial depends on:
ii  python3   3.8.2-2
ii  python3-click 7.0-3
ii  python3-psycopg2  2.8.4-2
ii  python3-sqlparse  0.2.4-3

python3-pgspecial recommends no packages.

python3-pgspecial suggests no packages.

-- no debconf information

Bug#934177: ansible: add suggests for python3-hcloud

[Leo Antunes]

Package: ansible
Version: 2.8.3+dfsg-1
Severity: wishlist
Control: block -1 by 933820

Dear Maintainers,

Once #933820 gets closed, it would be nice if ansible had a suggests (or
maybe even recommends?) on python3-hcloud. It enables ansible to make
use of the hcloud_* modules, available since 2.8.

Cheers,
Leo "costela" Antunes

Bug#933861: RFS: hcloud-python/1.4.0-1 [ITP] -- official client library for Hetzner Cloud

[Leo Antunes]

Package: sponsorship-requests
Severity: wishlist

Dear Maintainers,

I am looking for a sponsor for my package "hcloud-python":

* Package name: hcloud-python
  Version : 1.4.0-1
  Upstream Author : Hetzner Cloud GmbH
* URL : https://github.com/hetznercloud/hcloud-python
* License : MIT
  Section : python

It builds those binary packages:

  python3-hcloud - official client library for Hetzner Cloud

For more info: https://mentors.debian.net/package/hcloud-python


Alternatively, download it with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/h/hcloud-python/hcloud-python_3.1-4.dsc



Cheers,
Leo Antunes

Bug#933820: ITP: hcloud-python -- official client library for Hetzner Cloud

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: hcloud-python
  Version : 1.4.0
  Upstream Author : Hetzner Cloud GmbH
* URL : https://github.com/hetznercloud/hcloud-python
* License : MIT
  Programming Lang: Python
  Description : official client library for Hetzner Cloud

 python-hcloud is a Python library for acessing the API for the Hetzner
 Cloud service.

--

Ideally this would be maintained inside the Python Modules Team.

Bug#932288: ansible: new upstream release 2.8.*

[Leo Antunes]

Package: ansible
Version: 2.7.8+dfsg-1
Severity: wishlist

Dear Maintainers,

As you are probably already aware, 2.8.0 was released 2 months ago.
Now that buster is out the dor, I assume someone is at least already thinking
about uploading it. So this bug is more like a reminder to myself... :)


Cheers and thanks for all the work!
Leo "costela" Antunes


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ansible depends on:
ii  python33.7.3-1
ii  python3-crypto 2.6.1-9+b1
ii  python3-cryptography   2.6.1-3
ii  python3-httplib2   0.11.3-2
ii  python3-jinja2 2.10-2
ii  python3-netaddr0.7.19-1
ii  python3-paramiko   2.4.2-0.1
ii  python3-pkg-resources  41.0.1-1
ii  python3-yaml   3.13-2

Versions of packages ansible recommends:
ii  python3-jmespath   0.9.4-1
ii  python3-kerberos   1.1.14-2
ii  python3-libcloud   2.4.0-1
ii  python3-selinux2.8-1+b1
ii  python3-winrm  0.3.0-2
ii  python3-xmltodict  0.11.0-2

Versions of packages ansible suggests:
pn  cowsay   
ii  sshpass  1.06-1

-- no debconf information

Bug#932239: libcloud: new upstream version available: 2.5.0

[Leo Antunes]

Source: libcloud
Severity: wishlist

Dear Maintainers,

A new upstream has been released: 2.5.0
It would be great if someone would find the time to upload it! :)


Cheers
Leo

Bug#923500: snapd: non-classic snap not confined

[Leo Antunes]

Package: snapd
Version: 2.37.3-1
Severity: important

Dear Maintainer,


I just started experimenting with snaps and noticed my (pretty vanilla)
installation is silently not confining snaps. E.g.:

$ snap install hello-world
2019-03-01T00:20:19+01:00 INFO Waiting for restart...
hello-world 6.3 from Canonical✓ installed
$ snap run --shell hello-world
$ ls /
bin boot ...


Since the hello-world snap has no interfaces, I'd expect it to deny
access to / (like in snap's tutorial), but this is not the case.

Neither installation nor running the command (or its shell) give off any
indication something might be wrong

I'm an AppArmor newbie, but the generated profile (attached) seems a bit
too permissive. That is generated and loaded by snap itself, right?

Here's some further debug info. I imagine the lack of "strict" is the
problem, but it's not obvious to me why snap cannot enable it.
--
$ snap debug confinement
partial

$ snap debug sandbox-features
apparmor: kernel:caps kernel:domain kernel:file kernel:mount 
kernel:namespaces kernel:network_v8 kernel:policy kernel:ptrace kernel:query 
kernel:rlimit kernel:signal parser:unsafe policy:downgraded 
support-level:partial
confinement-options:  classic devmode
dbus: mediated-bus-access
kmod: mediated-modprobe
mount:freezer-cgroup-v1 layouts mount-namespace 
per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles 
stale-base-invalidation
seccomp:  bpf-argument-filtering kernel:allow kernel:errno 
kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap
udev: device-cgroup-v1 tagging



Setting severity to important because I'd argue this is a security
breach: the expectation of confinement is silently not met, potentialy
leading to information leakage.

Cheers,
Leo

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages snapd depends on:
ii  adduser  3.118
ii  apparmor 2.13.2-9
ii  ca-certificates  20190110
ii  gnupg2.2.12-1
ii  libapparmor1 2.13.2-9
ii  libc62.28-7
ii  libcap2  1:2.25-2
ii  libseccomp2  2.3.3-4
ii  libudev1 241-1
ii  openssh-client   1:7.9p1-7
ii  squashfs-tools   1:4.3-11
ii  systemd  241-1
ii  udev 241-1

Versions of packages snapd recommends:
ii  gnupg  2.2.12-1

Versions of packages snapd suggests:
ii  zenity  3.30.0-2

-- no debconf information

#include 

# This is a snap name without the instance key
@{SNAP_NAME}="hello-world"
# This is a snap name with instance key
@{SNAP_INSTANCE_NAME}="hello-world"
@{SNAP_REVISION}="27"
@{PROFILE_DBUS}="snap_2ehello_2dworld_2ehello_2dworld"
@{INSTALL_DIR}="/{,var/lib/snapd/}snap"

profile "snap.hello-world.hello-world" (attach_disconnected,mediate_deleted) {
  # set file rules so that exec() inherits our profile unless there is
  # already a profile for it (eg, snap-confine)
  / rwkl,
  /** rwlkm,
  /** pix,

  capability,
  change_profile unsafe /**,
  dbus,
  network,
  mount,
  remount,
  umount,
  pivot_root,
  ptrace,
  signal,
  unix,


}

Bug#907501: ITP: golang-docker-go-docker -- official go SDK for docker

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: golang-docker-go-docker
  Version : 1.0.0
  Upstream Author : Docker Inc.
* URL : https://docker.io/go-docker
* License : TBD (https://github.com/docker/go-docker/issues/10)
  Programming Lang: go
  Description : official go SDK for docker

This is the official SDK for interacting with the docker deamon in go.

- end description -

This package is needed to build at least one other ITP: #907356
Maintainment would be in the pkg-go team.


Cheers

Bug#907356: ITP: docker-etchosts -- Manage hosts file entries for docker containers

[Leo Antunes]

Package: wnpp
Severity: wishlist
Owner: Leo Antunes 

* Package name: docker-etchosts
  Version : 0.1.0
  Upstream Author : Leo Antunes 
* URL : https://github.com/costela/docker-etchosts
* License : GPLv3
  Programming Lang: Go
  Description : Manage hosts file entries for docker containers

Deamon to automatically manage /etc/hosts entries for running local containers.
It listens for events from the docker daemon and creates or removes entries
accordingly.

- end description -

I'd like to maintain this as a part of the golang packaging team, and
will probably need a sponsor since my old key has been removed from the
keyring and I never got around to re-adding a new one :/


Cheers

Bug#899195: RFA: pidgin-encryption -- pidgin plugin that provides transparent encryption

[Leo Antunes]

Package: wnpp
Severity: normal

I request an adopter for the pidgin-encryption package. Package seems
abandoned upstream (last release 2010), has more well maintained
alternatives (pidgin-otr) and has a low pop-con score (currently ~600).

If no takers show up, I'll probably request removal in the not so
distant future.

The package description is:
 Provides transparent encryption to all protocols supported by Pidgin.
 Can be activated on a per user basis or even automatically detected.
 Uses a private/public key system based on Mozilla's NSS.

Bug#889986: nomad: new upstream version: 0.7.1

[Leo Antunes]

Package: nomad
Version: 0.4.0+dfsg-1
Severity: wishlist

Dear Maintainers,

Just a friendly poke: maybe someone in the pkg-go team has some time to
update nomad? Or are there any dependency issues? In this case this
could be documented here for other people like me ;)


Cheers,
Leo

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nomad depends on:
ii  init-system-helpers  1.51
ii  libc62.26-6
pn  pipexec  
ii  procps   2:3.3.12-3

nomad recommends no packages.

nomad suggests no packages.

Bug#885207: rocksdb: add *-tools package

[Leo Antunes]

Source: rocksdb
Version: 5.8.7-1
Severity: wishlist

Dear Maintainer,

It would be useful to have the tools[0] built in a separate package
(especially ldb). AFAICT they're not available anywhere. Did I miss
something?

Cheers

[0] https://github.com/facebook/rocksdb/tree/master/tools

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#879271: RFP: puppet-development-kit -- toolkit for developing puppet modules

[Leo Antunes]

Package: wnpp
Severity: wishlist

* Package name: puppet-development-kit
  Version : 1.2.0
  Upstream Author : Puppet, Inc. 
* URL : https://github.com/puppetlabs/pdk
* License : Apache-2
  Programming Lang: ruby
  Description : toolkit for developing puppet modules

The Puppet Development Kit (PDK) includes key Puppet code development
and testing tools, so you can install one package with all the tools
you need to create and validate new modules.

PDK includes testing tools, a complete module skeleton, and command
line tools to help you create, validate, and run tests on Puppet
modules. PDK also includes all dependencies needed for its use.

---

RFP NOTE: some of the included tools are already packaged and could
probably be pulled in as dependencies.

Bug#872474: debocker: version-parsing chokes on valid versions

[Leo Antunes]

Package: debocker
Version: 0.2.1
Severity: normal

Dear Maintainer,

The current version-parsing code (Package.version()) is too strict and
chokes on valid versions, like ubntu packages (e.g. 1.0-0ubuntu1), or
NMUs (1.0-1.1) or the format sometimes used for RCs (1.0-0~rc1).

Maybe you could use python3-debian's "changelog" module to take over a
bit of the work? This would probably make debocker a bit more
future-proof ;)

Cheers

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debocker depends on:
ii  python33.5.3-3
ii  python3-click  6.7-1

Versions of packages debocker recommends:
ii  docker.io  1.13.1~ds1-2

debocker suggests no packages.

-- no debconf information

Bug#856524: RFA: libpst - library for reading Microsoft Outlook PST files

[Leo Antunes]

Package: wnpp
Severity: normal

I haven't used this package in years and have unfortunately (and
regretably) let it fall out of shape for lack of time. It would be
great if someone with more time could step up and adopt it.

The releases are very seldom and there's only one reverse-dep of note:
evolution-plugins.

Cheers,
Leo

Bug#856421: RFA: gnokii -- fc4f45003af70b9edaaa93fd24a289b6

[Leo Antunes]

Package: wnpp
Severity: normal

For lack of time for proper maintenance, I request an adopter for the gnokii 
package.

The package description is:
 Gnokii is a suite of programs that allows communication with mobile
 phones.
 It currently supports many Nokia mobile phones, all AT capable ones as
 well as
 many Symbian based.
 For a list of compatible phones, please visit:
 http://wiki.gnokii.org
 .
 interface::graphical, interface::x11, role::program,
 scope::application, uitoolkit::gtk, use::transmission, x11::application


Cheers,
Leo

Bug#844218: RFS: knockd/0.7-1 [RC]

[Leo Antunes]

Package: sponsorship-requests
Severity: important

Dear mentors,

anyone care to sponsor a fellow DD whose key has been removed from the
keyring in the 1024bit purge? :)

* Package name: knockd
  Version : 0.7-1
  Upstream Author : Judd Vinet 
* URL : http://www.zeroflux.org/projects/knock
* License : GPLv2
  Section : net

It builds those binary packages:

  knockd - small port-knock daemon

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/knockd


Alternatively, one can download the package with dget using this
command:

  dget -x https://mentors.debian.net/debian/pool/main/k/knockd/knockd_0.7-1.dsc


Changes since the last upload:

  * [b2567e28] New upstream version 0.7 (closes: #761853)
- adds timeout to pcap_open_live (closes: #816388, #308078)
  * [48f78ca5] bump policy to 3.9.8 (no changes)
  * [0b63eacb] update homepage url
  * [86381cd5] migrate to dh short notation
  * [4a38db8d] drop patches/include_limits_h: fixed upstream
  * [42ec7481] drop patches/manpage_cmd_timeout: fixed upstream
  * [733d82a7] switch to source/format 3.0 (quilt)
  * [bfc99c1f] add systemd support (closes: #729663)
  * [197eb24d] init: add dependency on $remote_fs
  * [848daeab] add hardening flags
  * [5c686b87] remove knock client docs from installation
  * [805dec71] debian/control: add VCS URL
  * [14a9bb3f] add watch file


Cheers
Leo "costela" Antunes

Bug#842294: RM: python-soaplib -- ROM; dead upstream; no rev-deps; low pop-con

[Leo Antunes]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

python-soaplib has been dead for several years upstream, after a series
of API-breaking versions (0.8, 1.0 and the unreleased 2.0). It has no
reverse dependencies and has a very low pop-con. There are no drop-in
replacements, but there are functional replacements (python-suds,
python-spyne) which are still actively developed.


Cheers,
Leo

Bug#832387: syncthing: please include .desktop files

[Leo Antunes]

Package: syncthing
Version: 0.14.0+dfsg1-1
Severity: wishlist

Dear Maintainer,

It would be a nice touch to be able to find syncthing in the
applications menu of desktop environments. Especially in order to set up
automatic startup on login without too many hacks.

One slightly kludgy possibility would be to include two .desktop files:
syncthing.desktop:
[Desktop Entry]
Name=Syncthing
GenericName=Syncthing
Comment=
Exec=/usr/bin/syncthing
Terminal=false
Type=Application
X-Gnome-Autostart=true

syncthing-ui.desktop:
[Desktop Entry]
Encoding=UTF-8
Name=Syncthing UI
Type=Link
URL=http://localhost:8384
Icon=www


But maybe it's possible to merge them into one and start both the
backend and the browser simultaneously? (since syncthing will refuse to
start if another instance is running anyway)

Thanks for considering!

Cheers,
Leo 'costela' Antunes


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages syncthing depends on:
ii  libc6  2.23-2

syncthing recommends no packages.

syncthing suggests no packages.

-- no debconf information

Bug#809355: letsencrypt: should delegate dir management (e.g. /etc/letsencrypt) to dpkg

[Leo Antunes]

Package: letsencrypt
Version: 0.1.1-3
Severity: normal

Dear Maintainer,

letsencrypt creates /etc/letsencrypt and /var/log/letsencrypt when first
run, instead of having dpkg manage them. This means purging the package
won't get rid of these folders.


Cheers

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages letsencrypt depends on:
ii  dialog  1.2-20150920-1
ii  python-letsencrypt  0.1.1-3
pn  python:any  

letsencrypt recommends no packages.

Versions of packages letsencrypt suggests:
pn  python-letsencrypt-apache  
pn  python-letsencrypt-doc 

-- no debconf information

Bug#804917: RFA: ttf-femkeklaver -- 9b249fbb0a8db0070af7dd3ed852ed00

[Leo Antunes]

Package: wnpp
Severity: normal

Hi,

Gioele Barabucci got in touch with me about the fonts team adopting this
package, so this bug is basically just my blessing for them taking it
over! :)

Cheers,
Leo

Bug#790234: ansible: ipaddr filter needs python-netaddr

[Leo Antunes]

Package: ansible
Version: 1.9.1+dfsg-1
Severity: normal
Tags: experimental

Dear Maintainer,

Using the ipaddr filter for template variables (new in 1.9) requires the
python-netaddr package.

Cheers
Leo Antunes

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ansible depends on:
ii  python2.7.9-1
ii  python-crypto 2.6.1-5+b2
ii  python-httplib2   0.9+dfsg-2
ii  python-jinja2 2.7.3-1
ii  python-paramiko   1.15.1-1
ii  python-pkg-resources  17.0-1
ii  python-yaml   3.11-2
pn  python:any

Versions of packages ansible recommends:
ii  python-selinux  2.3-2

Versions of packages ansible suggests:
pn  ansible-doc  
pn  sshpass  

-- no debconf information


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

Bug#780049: coinor-libcbc-dev: missing dependency on coinor-libcgl-dev

[Leo Antunes]

Package: coinor-libcbc-dev
Version: 2.8.12-1
Severity: normal

Dear Maintainer,

There seems to be a missing dependency on libcgl, at least regarding
pkg-config:

$ pkg-config --cflags cbc
Package cgl was not found in the pkg-config search path.
Perhaps you should add the directory containing `cgl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'cgl', required by 'cbc', not found


Cheers,
Leo Antunes

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages coinor-libcbc-dev depends on:
ii  coinor-libcbc3  2.8.12-1

coinor-libcbc-dev recommends no packages.

coinor-libcbc-dev suggests no packages.

-- no debconf information


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

Bug#766645: homebank: new upstream version 4.6.3

[Leo Antunes]

Package: homebank
Version: 4.6.1-1
Severity: wishlist

Dear Maintainer,

If there are no show-stopper bugs I'm not aware of, it would probably
be nice to have 4.6.3 in jessie, since it fixes a few annoying bugs[0].

Cheers

[0] http://homebank.free.fr/ChangeLog

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages homebank depends on:
ii  homebank-data4.6.1-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-12
ii  libcairo21.14.0-2
ii  libfontconfig1   2.11.0-6.1
ii  libfreetype6 2.5.2-2
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.42.0-2
it  libgtk2.0-0  2.24.25-1
ii  libofx6  1:0.9.10-1
ii  libpango-1.0-0   1.36.8-2
ii  libpangocairo-1.0-0  1.36.8-2
ii  libpangoft2-1.0-01.36.8-2

Versions of packages homebank recommends:
ii  librsvg2-common  2.40.5-1

homebank suggests no packages.

-- no debconf information


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

Bug#762346: RFP: pypy3 -- fast alternative implementation of Python3 - PyPy interpreter

[Leo Antunes]

Package: wnpp
Severity: wishlist

* Package name: pypy3
  Version : 2.3.1
  Upstream Author : Armin Rigo 
* URL : http://www.pypy.org
* License : MIT
  Programming Lang: Python
  Description : fast alternative implementation of Python3 - PyPy 
interpreter

 PyPy3 is a fast, compliant alternative implementation of the Python3
 language (3.2). It has several advantages and distinct features:
  * Speed: thanks to its Just-in-Time compiler (on x86), Python programs
often run faster on PyPy.
  * Memory usage: large, memory-hungry Python programs might end up
taking less space than they do in CPython.
  * Compatibility: PyPy is highly compatible with existing Python code.
It supports ctypes and can run popular Python libraries like twisted
and django.
  * Stackless: PyPy supports stackless mode on x86, providing
micro-threads for massive concurrency.


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

Bug#761115: [Pkg-salt-team] Bug#761115: salt: new upstream version 2014.7

[Leo Antunes]

Hi,


On Thu, 2014-09-11 at 09:28 +1000, Joe Healy wrote:


> 2014.7 is still only in release candidate stage. A new release
> candidate is expected shortly.

Oh, I see. Do you know why there's already a tag for "v2014.7"? That's
what led me to believe it was already stable.


> Additionally, I'm not rushing to upload 2014.7 yet - it took 2014.1
> about 9 or 10 point releases to stabilize.

What do you mean with "stabilize"? Did the point releases introduce such
big changes or fix real show-stopper bugs? Otherwise it would IMHO still
be interesting to have 2014.7 in debian (but that's of course not my
call).


> Separately, a new release for 2014.1 (2014.1.11) is almost ready for
> release. I'll be uploading it as soon as I can.

Cool! Thanks for the work and the heads-up!


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

Bug#761115: salt: new upstream version 2014.7

[Leo Antunes]

Source: salt
Version: 2014.1.10+ds-2
Severity: wishlist

Dear Maintainers,

Is there still time to upload the new upstream version before the freeze?

2014.7 has 40 new modules and 33 new states (judging by the diffs), so it
might be interesting to have it in jessie.


Cheers


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

Bug#757829: RFP: docker-registry -- Registry server for docker.io repositories

[Leo Antunes]

Package: wnpp
Severity: wishlist

* Package name: docker-registry
  Version : 0.7.3
  Upstream Author : Docker, Inc.
* URL : https://github.com/docker/docker-registry
* License : ASL
  Programming Lang: python
  Description : Registry server for docker.io repositories

Server for keeping a private registry of docker.io repositories. It
supports pushing and pulling of registries as well as searching.
Registries can be stored on the local filesystem or on the cloud (S3
support is built-in, others supported as extensions)
It currently does not support authentication. For this, an HTTP-proxy
implementing basic auth can be used.


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

Bug#757827: python3-rsa: should depend on python3-pyasn1

[Leo Antunes]

Source: python3-rsa
Version: 3.1.4-1
Severity: important

Dear Maintainers,

The current version of python3-rsa in sid does not depend on
python3-pyasn1 and is therefore unusable unless you install it manually.

Cheers

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#751817: python-pip: change shebang to use /usr/bin/env?

[Leo Antunes]

Source: python-pip
Version: 1.5.6-2
Severity: normal

Dear Maintainers,

Would it be otherwise ok to use "/usr/bin/env python3" in the shebang of
/usr/bin/pip3 ?
This way pip would also work directly from within an "activated" virtual
environment created with --system-site-packages (i.e.: one that doesn't
install it's own pip).
Currently I have to call

$ /path/to/venv/bin/python /usr/bin/pip3 (...)

in order for it to actually notice it's being called from inside a virtual
environment.

Python-policy says it is "strongly preferred" to use the direct path to
python in the shebang, but there's no rationale provided for this preference.
Is this maybe one of the cases where it would be acceptable?


Cheers

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#749587: RFP: python-grako -- Python parser generator, for grammars given in a variation of EBNF

[Leo Antunes]

Package: wnpp
Severity: wishlist

* Package name: python-grako
  Version : 2.4.2
  Upstream Author : Juancarlo Añez 
* URL : https://bitbucket.org/apalala/grako
* License : BSD
  Programming Lang: Python
  Description : Python parser generator, for grammars given in a variation 
of EBNF

Grako (for grammar compiler) is a tool that takes grammars in a
variation of EBNF as input, and outputs memoizing (Packrat) PEG parsers
in Python.

The generated parsers return an abstract syntax tree (AST) and can make
use of semantic actions provided at parse-time.


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

Bug#726624: gnome-shell: notifications not working

[Leo Antunes]

On 17/03/14 15:58, althaser wrote:
> Could you please still reproduce this issue with newer gnome-shell
> version like 3.8.4-5+b1 ?
> 
> It is working fine here with 3.8.4-5+b1.

Nope, sorry, still not working on a fully up-to-date sid system (with
pretty much the same log message as before).

> try the following:
> 
> notify-send "test"
> 
> and then press winkey+m for instance.

What's winkey+m supposed to do? I remapped my keys and even on a new
user's desktop I can't seem to find its function...


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Bug#734791: RFP: elixir -- functional, meta-programming aware language for the Erlang VM

[Leo Antunes]

Package: wnpp
Severity: wishlist

* Package name: elixir
  Version : 0.12.0
  Upstream Author : José Valim 
* URL : http://http://elixir-lang.org
* License : APL 2.0
  Programming Lang: Erlang
  Description : functional, meta-programming aware language for the Erlang 
VM

 Elixir is a functional, meta-programming aware language built on top of
 the Erlang VM. It is a dynamic language with flexible syntax and macro
 support that leverages Erlang's abilities to build concurrent,
 distributed and fault-tolerant applications with hot code upgrades.
 .
 Elixir also provides first-class support for pattern matching,
 polymorphism via protocols (similar to Clojure's), aliases and
 associative data structures.


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

Bug#727553: binwalk maintenance

[Leo Antunes]

Hi Nico,

On 09/01/14 19:23, Nico Golde wrote:
> are you still interested in maintaining binwalk?
> This hasn't received an update since almost a year in Debian even though 
> updates from upstream are fairly frequent and a lot of features have been 
> added recently.

Yes, unfortunately you're absolutely right.

> I would appreciate if you could either update the package or seek for 
> assistance.

As per my pseudo-VAC email to d-private today, I'm looking for people to
(co|team)-maintain packages, so if you're interested, feel free to take
it over. I would however appreciate if you left me as uploader, since I
do intend to work on debian things as time permits (which will
unfortunately not be often).

Cheers


-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Bug#734503: suggestion: mention "finance" in description

[Leo Antunes]

Package: homebank
Version: 4.5.2-1
Severity: wishlist

Dear Maintainer,

Just a small suggestion: maybe it would be nice to mention "finance" or
"money" or something like that in the package description to make
homebank easier to find with an "apt-cache search", for instance.

Cheers

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages homebank depends on:
ii  homebank-data4.5.2-1
ii  libatk1.0-0  2.10.0-2
ii  libc62.17-96
ii  libcairo21.12.16-2
ii  libfontconfig1   2.11.0-2
ii  libfreetype6 2.4.9-1.1
ii  libgdk-pixbuf2.0-0   2.28.2-1
ii  libglib2.0-0 2.36.4-1
ii  libgtk2.0-0  2.24.21-1
ii  libofx4  1:0.9.4-2.1
ii  libpango-1.0-0   1.32.5-5+b1
ii  libpangocairo-1.0-0  1.32.5-5+b1
ii  libpangoft2-1.0-01.32.5-5+b1

Versions of packages homebank recommends:
ii  librsvg2-common  2.36.4-2

homebank suggests no packages.

-- no debconf information


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

Bug#718624: Daemon segfaults due to missing -g [was: Re: The 'Type' is still set to 'notify']

[Leo Antunes]

Hi,

On 02/12/13 13:27, Andrei POPESCU wrote:
> Reading through the upstream bug log I have a few suggestions in regards 
> to fixing this bug:
>
> 1. Create the user debian-transmission with $HOME /var/lib/transmission
>
> 2. Don't hardcode -g|--config-dir in the start parameters and let the 
> daemon use the default $HOME/.config/transmission which will now 
> translate to /var/lib/transmission/.config/transmission

Sounds obvious and elegant... and I'm not sure why I didn't do it this
way to begin with. It might have had something to do with having a
dot-dir in /var/lib, which IMHO seemed a bit "dirty". Admittedly a very
subjective reason.

I'm a bit worried about migration side-effect, though. Would have to
think this through a bit. But I'm obviously open for more specific
suggestions... especially in the form of patches! ;)

> As a bonus this would also allow getting rid of the 
> /etc/default/transmission file ;)

Yeah, I've also been meaning to do that, particularly because I wanted
to get rid of the whole "ENABLE_DAEMON" thing, since it's a very
sysv-init-specific hack, which isn't even the Right Way™ to do things
anyway.

> 3. In order to prevent torrents being downloaded to /var by default ship 
> a settings.json with
>
> "download-dir": "/home/debian-transmission/",
>
> (or whatever)

Why not use $HOME/downloads for this? (which is the current setting
assuming your suggestion of setting $HOME)
Under the FHS definition, /var/lib seems OK and this way we can keep
things in a single place, with the exception of /etc.


Thanks for the suggestions!

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Bug#730144: transmission-daemon.postinst sets priority too high in /etc/rcXX.d

[Leo Antunes]

Hi

On 21/11/13 18:41, Alexander Kuznetsov wrote:
> the defaults chosen by dh_installinit is inappropriate for 
> transmission-daemon. The .postinst contains
> a line `update-rc.d transmission-daemon defaults', which results in creation
> /etc/rc2.d/S01transmission-daemon
The ordering is done automatically by insserv and transmission-daemon's
init script already requires $remote_fs precisely for that reason.
Unfortunately it seems autofs isn't considered part of $remote_fs.
I wouldn't rule out fixing this on transmission-daemon's side, but it
would require adding an explicit mention of autofs (i.e.: Should-Start:
autofs), which doesn't sound that elegant.
Another option which seems better at first glance would be adding autofs
as an optional service to $remote_fs, i.e. adding the changing the
appropriate line in /etc/insserv.conf to include +autofs.
You can do this manually as a stopgap measure (just remember to call
update-rc.d afterwards).

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Bug#724731: XDG_RUNTIME_DIR has incorrect value

[Leo Antunes]

Hi,

On 14/11/13 13:57, Simon McVittie wrote:
> libpam-systemd derives the XDG_RUNTIME_PATH from the "loginuid", which
> was originally part of the audit framework. The loginuid was originally
> intended to answer questions like "yes, I know this process is root, but
> who is it really?" to provide an audit trail:

Thanks for the explanation. I wasn't aware of the rationale behind loginuid.
The historical intention makes sense, but I don't get why logind should
return XDG_RUNTIME_PATH based on this "really real uid" instead of the
effective uid, since that's what's going to be used for permission
control on the fs level. Am I missing something or do you mean to say
this is a questionable decision?

> (...)
> Even after gdm daemonizes and re-parents to init, its loginuid remains.
> That's sort of the point of loginuid.

Again, makes sense, but doesn't explain why XDG_RUNTIME_PATH must use
loginuid. If loginuid's main reason for existence is auditing, I should
still be able to see that my gdm was started by a su'd user 1000, but I
want it to get /run/user/, since that's the process effective
uid. Or more importantly, it seems really unintuitive (to say the least)
that a request for session creation for an *explicitly given* UID should
create a runtime dir for a different uid.
But again, I may be missing something obvious.

> The same thing breaks many tools when run under su (e.g. see
> ). There's some
> recent discussion on that bug: Ubuntu developers have been hit badly by
> it too.

If I understand you (and mentioned bug log) correctly, I guess this bug
should be reassigned (or at least cloned over) to systemd then?


Cheers


-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Bug#724731: XDG_RUNTIME_DIR has incorrect value

[Leo Antunes]

[cc'ing systemd maintainers for their input]

Hi all,

On a fresh qemu install dist-upgraded to sid (wheezy install;
dist-upgrade and lastly gnome install) I'm consistently getting the
issue described by Gabriel Mainberger, namely that gdm gets the wrong
XDG_RUNTIME_PATH and fails to start. But interestingly it only happens
if I restart gdm. So it actually works on boot, but if I try to restart
it, I get the following dbus calls from libpam-systemd:

-

method call sender=:1.59 -> dest=org.freedesktop.login1 serial=2 
path=/org/freedesktop/login1; interface=org.freedesktop.login1$Manager; 
member=CreateSession
   uint32 117
   uint32 3462
   string "gdm-launch-environment"
   string "x11"
   string "greeter"
   string "seat0"
   uint32 7
   string ""
   string ":0"
   boolean false
   string ""
   string ""
   array [
   ]
   array [
   ]
   boolean false
method return sender=:1.17 -> dest=:1.59 reply_serial=2
   string "2"
   object path "/org/freedesktop/login1/session/_32"
   string "/run/user/1000"
(dbus-monitor too dumb to decipher arg type 'h')
   string ""
   uint32 0
   boolean true

-
Note that we're requesting a login for uid=117 and getting
runtime_path=/run/user/1000.
This is the result when run under "su". The returned path is
"/run/user/0" if run directly by root. This doesn't seem to be impacted
by the /proc/*/loginuid of systemd-logind (even if logind was started by
a su'ed uid 1000, we still get /run/user/ when running "gdm3
start").

At first I wasn't sure where gnome-session was getting the wrong
XDG_RUNTIME_PATH, so I attempted calling "env - /usr/sbin/service gdm3
restart", but this changed nothing.

Incidently, this system is also affected by #728180, so maybe the fact
that I had to kill Xorg (and with it gnome-session) after stopping gdm3
might have something to do with it?

I'm not sure if this is a problem with gdm3, gnome-session or
systemd-logind, and I'm unfortutately stumped as to ways of debugging
this better.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Bug#729489: gdm3.init uses $PIDFILE inconsistently

[Leo Antunes]

Package: gdm3
Version: 3.8.4-4
Severity: minor

Dear Maintainers,

gdm3's init uses the unset variable $PIDFILE in the "status" action,
and hardcodes the pidfile's location in other actions.
The attached minor patch solves this inconsistency by setting PIDFILE
and using it throughout.

Cheers
--- debian.orig/gdm3.init	2013-11-13 14:54:21.919312075 +0100
+++ debian/gdm3.init	2013-11-13 14:56:08.074499707 +0100
@@ -16,6 +16,7 @@
 
 PATH=/sbin:/bin:/usr/sbin:/usr/bin
 DAEMON=/usr/sbin/gdm3
+PIDFILE=/var/run/gdm3.pid
 
 test -x $DAEMON || exit 0
 
@@ -76,7 +77,7 @@
 log_daemon_msg "Starting GNOME Display Manager" "gdm3"
 gen_config
 rm -f /var/lib/gdm/.ICEauthority
-start-stop-daemon --start --quiet --pidfile /var/run/gdm3.pid \
+start-stop-daemon --start --quiet --pidfile $PIDFILE \
 			--background --exec $DAEMON || log_end_msg 1
 log_end_msg 0
 fi
@@ -84,7 +85,7 @@
   stop)
 log_daemon_msg "Stopping GNOME Display Manager" "gdm3"
 set +e
-start-stop-daemon --stop --quiet --pidfile /var/run/gdm3.pid \
+start-stop-daemon --stop --quiet --pidfile $PIDFILE \
 --name gdm3 --retry 5
 set -e
 log_end_msg $?
@@ -93,8 +94,8 @@
 log_daemon_msg "Scheduling reload of GNOME Display Manager configuration" "gdm3"
 set +e
 gen_config
-start-stop-daemon --stop --signal HUP --quiet --pidfile \
-/var/run/gdm3.pid --name gdm3
+start-stop-daemon --stop --signal HUP --quiet --pidfile $PIDFILE \
+--name gdm3
 start-stop-daemon --stop --signal HUP --quiet --name dconf-service \
 --user Debian-gdm --oknodo
 set -e

Bug#726625: gnome-shell: media-keys plugin not working; JS ERROR

[Leo Antunes]

Hi,

[since the package is team-maintained, should I cc you in replies?]

On 17/10/13 14:11, Michael Biebl wrote:
> Not reproducible here.
> Does the problem persist if you reboot your system or if you use a fresh
> user account?

Also happens in a freshly created account. I've attached the
.xsession-errors from this new account, maybe there's more context to it
and I'm not seeing it.
You'll notice I only logged in, opened dconf-editor to make sure the
keybindings where set, tried a "Ctrl-Alt-Del" (seemed like an
appropriate one to test) and nothing happened. The logout was performed
via menu item.

Is there any more debugging info I could send?


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]
Xsession: X session started for test at Thu 17 Oct 14:27:14 CEST 2013
localuser:test being added to access control list
Script for ibus started at run_im.
Script for auto started at run_im.
Script for default started at run_im.
Script for ibus started at run_im.
Script for auto started at run_im.
Script for default started at run_im.

** (gnome-session-check-accelerated:21047): WARNING **: Couldn't register with 
accessibility bus: Did not receive a reply. Possible causes include: the remote 
application did not send a reply, the message bus security policy blocked the 
reply, the reply timeout expired, or the network connection was broken.

** (gnome-session:20973): WARNING **: Couldn't register with accessibility bus: 
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.

** (gnome-settings-daemon:21054): WARNING **: Couldn't register with 
accessibility bus: Did not receive a reply. Possible causes include: the remote 
application did not send a reply, the message bus security policy blocked the 
reply, the reply timeout expired, or the network connection was broken.
W: [pulseaudio] authkey.c: Failed to open cookie file 
'/home/test/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authorization key 
'/home/test/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to open cookie file 
'/home/test/.pulse-cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authorization key 
'/home/test/.pulse-cookie': No such file or directory
GNOME_KEYRING_CONTROL=/run/user/1003/keyring-97Qwee
GNOME_KEYRING_CONTROL=/run/user/1003/keyring-97Qwee
GPG_AGENT_INFO=/run/user/1003/keyring-97Qwee/gpg:0:1
GNOME_KEYRING_CONTROL=/run/user/1003/keyring-97Qwee
GPG_AGENT_INFO=/run/user/1003/keyring-97Qwee/gpg:0:1
SSH_AUTH_SOCK=/run/user/1003/keyring-97Qwee/ssh
GNOME_KEYRING_CONTROL=/run/user/1003/keyring-97Qwee
GPG_AGENT_INFO=/run/user/1003/keyring-97Qwee/gpg:0:1

** (gnome-shell:21158): WARNING **: Couldn't register with accessibility bus: 
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.
  JS LOG: GNOME Shell started at Thu Oct 17 2013 14:27:16 GMT+0200 (CEST)
Creating config directory:'/home/test/.config/tracker'
Tracker-Message: Importing config file to GSettings
Tracker-Message: Importing config file to GSettings

** (smart-notifier:21218): WARNING **: Couldn't register with accessibility 
bus: Did not receive a reply. Possible causes include: the remote application 
did not send a reply, the message bus security policy blocked the reply, the 
reply timeout expired, or the network connection was broken.
JS ERROR: !!!   Exception was: TypeError: arguments[0] is null
JS ERROR: !!! message = '"arguments[0] is null"'
JS ERROR: !!! fileName = 
'"/usr/share/gnome-shell/js/ui/components/autorunManager.js"'
JS ERROR: !!! lineNumber = '131'
JS ERROR: !!! stack = '"(null,[object 
GLib_Error])@/usr/share/gnome-shell/js/ui/components/autorunManager.js:131
([object GObject_Object],[object 
GObject_Object])@/usr/share/gjs-1.0/overrides/Gio.js:87
"'
JS ERROR: !!!   Exception was: Error: Expected type utf8 for Argument 'str' 
but got type 'object' 0x7fad5318a2c0
JS ERROR: !!! message = '"Expected type utf8 for Argument 'str' but got 
type 'object' 0x7fad5318a2c0"'
JS ERROR: !!! fileName = 
'"/usr/share/gnome-shell/js/ui/status/power.js"'
JS ERROR: !!! lineNumber = '157'
JS ERROR: !!! stack = 
'"()@/usr/share/gnome-shell/js/ui/status/power.js:157
wrapper()@/usr/share/gjs-1.0/lang.js:213
()@/usr/share/gnome-shell/js/ui/status/power.js:166
wrapper()@/usr/share/gjs-1.0/lang.js:213
([object GObject_Object],null)@/usr/share/gnome-shell/js/ui/status/power.js:65
([object GObject_Object],[object 
GObject_Object])@/usr/share/gjs-1.0/overrides/Gio.js:203
"'
Window manager warning: Log level 16: invalid cast from `NMRemoteConnection' to 
`NMObject'
Window manager w

Bug#726625: gnome-shell: media-keys plugin not working; JS ERROR

[Leo Antunes]

Package: gnome-shell
Version: 3.8.4-4
Severity: important

Dear Maintainer,

None of the keybindings associated with the media-keys plugin are
working and the plugin itself seems to be crashing with the following
error:


JS ERROR: !!!   Exception was: Error: Expected type utf8 for Argument 
'accelerator' but got type 'object' 0x7f97bc3565d8
JS ERROR: !!! message = '"Expected type utf8 for Argument 'accelerator' 
but got type 'object' 0x7f97bc3565d8"'
JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/ui/shellDBus.js"'
JS ERROR: !!! lineNumber = '184'
JS ERROR: !!! stack = '"([object
Array],4294967295,":1.11")@/usr/share/gnome-shell/js/ui/shellDBus.js:184
wrapper([objectArray],4294967295,":1.11")@/usr/share/gjs-1.0/lang.js:213
([object 
Array],[objectGObject_Object])@/usr/share/gnome-shell/js/ui/shellDBus.js:152
wrapper([object Array],[objectGObject_Object])@/usr/share/gjs-1.0/lang.js:213
_handleMethodCall([object GObject_Boxed],[object 
GObject_Object],"GrabAccelerators",[object GObject_Boxed],[object 
GObject_Object])@/usr/share/gjs-1.0/overrides/Gio.js:315
([object GObject_Object],"GrabAccelerators",[object GObject_Boxed],[object 
GObject_Object])@/usr/share/gjs-1.0/overrides/Gio.js:346
"'


Shortly after this error another one further indicates an issue:
(gnome-settings-daemon:16637): media-keys-plugin-WARNING **: 24: Timeout was 
reached

This may be related to #726624, since both seem to be related to API
issues (wrong argument types), but this is of course a very superficial
interpretation


Cheers

PS.: severity:important because I consider not being able to use many of
my keybindings a "major usability effect" for a desktop environment.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8"  (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.16.1-1
ii  evolution-data-server3.8.5-2
ii  gdm3 3.8.4-2
ii  gir1.2-accountsservice-1.0   0.6.34-2
ii  gir1.2-caribou-1.0   0.4.12-1
ii  gir1.2-clutter-1.0   1.14.4-3
ii  gir1.2-freedesktop   1.36.0-2+b1
ii  gir1.2-gcr-3 3.8.2-4
ii  gir1.2-gkbd-3.0  3.6.0-1
ii  gir1.2-glib-2.0  1.36.0-2+b1
ii  gir1.2-gmenu-3.0 3.8.0-2
ii  gir1.2-gnomebluetooth-1.03.8.1-2
ii  gir1.2-gnomedesktop-3.0  3.8.4-2
ii  gir1.2-gtk-3.0   3.8.5-1
ii  gir1.2-ibus-1.0  1.5.3-7
ii  gir1.2-mutter-3.03.8.4-2
ii  gir1.2-networkmanager-1.00.9.8.0-5
ii  gir1.2-nmgtk-1.0 0.9.8.4-1
ii  gir1.2-pango-1.0 1.32.5-5+b1
ii  gir1.2-polkit-1.00.105-4
ii  gir1.2-soup-2.4  2.42.2-6
ii  gir1.2-telepathyglib-0.120.22.0-1
ii  gir1.2-telepathylogger-0.2   0.8.0-2
ii  gir1.2-upowerglib-1.00.9.22-1
ii  gjs  1.36.1-2
ii  gnome-bluetooth  3.8.1-2
ii  gnome-icon-theme-symbolic3.8.2.2-2
ii  gnome-settings-daemon3.8.5-2
ii  gnome-shell-common   3.8.4-4
ii  gnome-themes-standard3.8.4-1
ii  gsettings-desktop-schemas3.8.2-2
ii  libatk-bridge2.0-0   2.10.0-1
ii  libatk1.0-0  2.10.0-2
ii  libc62.17-93
ii  libcairo-gobject21.12.16-2
ii  libcairo21.12.16-2
ii  libcamel-1.2-43  3.8.5-2
ii  libcanberra-gtk3-0   0.30-2
ii  libcanberra0 0.30-2
ii  libclutter-1.0-0 1.14.4-3
ii  libcogl-pango12  1.14.0-3
ii  libcogl121.14.0-3
ii  libcroco30.6.8-2
ii  libdbus-1-3  1.6.16-1
ii  libdbus-glib-1-2 0.100.2-1
ii  libecal-1.2-15   3.8.5-2
ii  libedataserver-1.2-173.8.5-2
ii  libegl1-mesa [libegl1-x11]   9.1.7-1
ii  libgck-1-0   3.8.2-4
ii  libgcr-base-3-1  

Bug#529372: transmission: Contains and uses embedded code copy: libevent

[Leo Antunes]

tag 529372 confirmed upstream
forwarded 529372 http://trac.transmissionbt.com/ticket/2070
--

Hi all,

Firstly, thanks a lot for the patch Cyril! I feel stupid I hadn't even
noticed that earlier...

Charles Kerr wrote:
> Could you tweak the patch s.t. it decides whether or not to user
> third-party/libevent/ based on whether or not libevent 1.4x headers
> and libs are present on the system already?
FYI: I'm working on this, but I'm currently a bit swamped (as usual) and
it might take some time to get it to a working condition.

Cheers

-- 
*Leo Antunes*



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

Bug#416126: patch doesn't solve problem

[Leo Antunes]

Hi,

David Spreen wrote:
> I just downloaded your source package and rebuilt it for i386. The
> notifications still overlap my gnome-panel (which is at the top of the 
> screen).
>   

Hm... can you confirm I didn't mess something up with the source package
and that the patch really got applied to your package?
It's a fairly simple patch and I can't imagine it should stop working
simply by switching architectures.
Just to be sure I downloaded and tested it again in another machine with
the panel on top, and it worked as expected, avoiding the overlap.

I also took the opportunity to test the Xinerama setup, and it also
worked as expected. Though I still have to test it in a i386 VM...

Cheers



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

Bug#505846: New upstream version 1.40

[Leo Antunes]

Hi

Chris Coulson wrote:
> I've just updated the version in Ubuntu to 1.40. The only think I
> changed was the build-depend on libcurl-dev (which is a virtual pacakge)
> to build-depend on the actual physical packages provided by libcurl-dev,
> as we experienced a build failure for some reason. I'm not sure if you
> want to share this change.
>   

Thanks for the heads-up.
Coincidently I had just uploaded the 1.40 to Debian yesterday. It should
enter the archive shortly.
I haven't implemented the libcurl-dev build-dep change, because I didn't
see any build-problems. It could be a ubuntu-specific thing. Can you
give me some more details?
I did add a build-dep on intltool though, plus some other changes.
Please take a look at the changes in the NEW queue[0] or in the packages
themselves when they enter the archive, if you have the time and want to
import some of those changes into Ubuntu as well.

If you have any other comments on the package, please let me know!

Cheers

[0] http://ftp-master.debian.org/new/transmission_1.40-1.html

-- 
*Leo Antunes*



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

Bug#487355: Bug forwarded upstream

[Leo Antunes]

forwarded 487355 http://trac.transmissionbt.com/ticket/319
tag 487355 upstream

--

Hi,

This had already been requested upstream a while ago and they seem to
have dismissed the idea. I'm requesting it again pointing to this bug.

Cheers

-- 
*Leo Antunes*



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

Bug#474332: fixed in gnokii 0.6.24.dfsg-2

[Leo Antunes]

Mathias Brodala wrote:
> Then please change both xngokii and gnokii-cli to depend on
> 0.6.24.dfsg-2, otherwise they can't be kept while upgrading
> gnokii-common. Or am I misunderstanding something here?
I think you misunderstood it.
xgnokii and gnokii-cli 0.6.24.dfsg-2 already depend on gnokii-common
0.6.24.dfsg-2.
The thing is: you can't upgrade only gnokii-common because it doesn't
depend on anything (and shouldn't, conceptually speaking), rather the
others depend on it.
In the situation you had, you should have upgraded xgnokii or
gnokii-cli, and not gnokii-common, because from apt's perpective, if you
REALLY want to upgrade gnokii-common, then the other packages that
depend on an old version from it really must be removed. The trick is:
you don't REALLY want to upgrade gnokii-common, you want to upgrade gnokii!

But that situation shouldn't have happened because the deps on the
'gnokii' package should have pulled the other new packages and they
didn't. That's the real problem behind this bug.

Cheers

-- 
*Leo Antunes*




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

Bug#439144: closed by [EMAIL PROTECTED] (Wesley J. Landaker) (Bug#439144: fixed in googleearth-package 0.4.0)

[Leo Antunes]

[just to keep it public]

On Wed, 2007-09-19 at 15:09 +, Debian Bug Tracking System wrote:
> >* Despite being very hackish, by popular nagging we now can build 
> > packages
> >  without --force on amd64/ia64 with ia32-libs (closes: #439144) 
> > (again!).
> >* Cleaned up dependencies for allow the above to work a bit more cleanly.

Thanks!
I didn't want to annoy so much, but I really feel this is the best
solution.
Feel free to nag me back if it ever causes too much trouble and also if
you ever need any beta-testing on amd64 CPUs! :-)

Cheers

-- 
Leo Antunes <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Bug#439144: closed by [EMAIL PROTECTED] (Wesley J. Landaker) (Bug#439144: fixed in googleearth-package 0.3.3)

[Leo Antunes]

Hi,

Since you closed the bug with a README entry (basically a WONTFIX), I'll
try to explain once again what I think the problem is. If you think I'm
annoying you with this, please tell me (through this bug report, to keep
it archived for future bug posters like me) what you think is wrong with
my technical assessment of the problem, instead of just adding a
disclaimer surrounding the bug.

My first point is: if you feel so strongly against supporting amd64/ia64
in your package, at least patch your script so that the generated
package (AFTER I've --forced it into submission) has a correct
Architecture field, so the user doesn't need to --force dpkg too. If
your reasoning behind this is "well, but googleearth is a i386-only
binary, so the package has to be too", it's wrong, since ia32-libs is a
package full of i386-only binaries that is natively installable on
amd64/ia64, precisely to enable 32 bits binaries to run natively on
those processors which support both modes of operation.

My second point: even though you're free to feel insecure about
supporting amd64/ia64, there's AFAIK no technical need to do so, and in
fact you're just putting up a barrier for no reason at all. Running a 32
bits binary over ia32-libs should be precisely as running it inside a
pure 32 bit debian instalation on an AMD64, so there's no practical
difference between supporting it on i386 and amd64.
Aside from that, the package ia32-libs was created precisely to enable
us - as a distribution - to ease the lives of our users enabling them to
run 32 bit code on mixed 64/32 bit systems! Even though its history is a
bit "hacky", it's our only working way to do it, and it's used by other
packages in the same situation as GoogleEarth (flashplugin, for
instance) with no problem. So not supporting it is complicating our
users' experience out of fear of, AFAIK, unknown problems.

Please bear in mind that I'm only saying this because you gave no solid
reasoning behind your posture of not supporting amd64/ia64, only a "if
you do this, it's your problem", based on apparently nothing. Again: if
there IS a technical reason for it, please let me know. I'm only
reacting to what I perceive as a miss-informed WONTFIX.

Once again thanks for the script. Asside from our current little
squabble, it's a very nice work.
Cheers


On Wed, 2007-09-19 at 00:09 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the googleearth-package package:

> >* Blurb about i386 restrictions in README.Debian (closes:
> > #439144)

> > 
-- 
Leo Antunes <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Bug#439466: help

[Leo Antunes]

tags 439466 + help unreproducible
quit

I can't reproduce this on my AMD64 and my ASM is very limited, anyone
can give me a hand?

Cheers

-- 
Leo Antunes <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Bug#425428: pidgin-encryption: Looks for id.priv in .gaim subdirectory

[Leo Antunes]

Hi,

I've only seen this bug now, sorry about that...

Do you still have this problem? 
It was most probably generated because the configured 'Keyfile location'
in the pidgin-encryption's options was changed at some point, since it
uses the default libpurple dir for storage, unless configured otherwise.

So this bug probably isn't really a bug, but if you think my assumption
is wrong for some reason, please let me know so I can investigate it
further.

Cheers and thanks for the information
Leo

On Mon, 2007-05-21 at 17:59 +0200, Jean-Luc Coulon (f5ibh) wrote:
> Package: pidgin-encryption
> Version: 3.0-1
> Severity: normal
> 
> Hi,
> 
> pidgin doesnt look for id.priv in .purple but in .gaim directory. So it
> complains it cannot change the permissions (.gaim doent exist on my system)
> 
> If I create the .gaim directory then copy id.priv from .purple in it, I've a
> popup saying:
> Bad permissions on key file: id.priv
> Pidgin-encryption will not save keys to a world it group-accessible file.
> 
> (the same apply to the id file)
> 
> id and id.priv was rw-r--r- with my userid/geoup as the owner. I've not set 
> them up myself.
> 
> Regards
> 
> Jean-Luc
> 
> -- System Information:
> Debian Release: lenny/sid
>   APT prefers unstable
>   APT policy: (900, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.22-rc2-k8-1 (PREEMPT)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages pidgin-encryption depends on:
> ii  libc6 2.5-8  GNU C Library: Shared libraries
> ii  libnspr4-0d   4.6.6-3NetScape Portable Runtime Library
> ii  libnss3-0d3.11.5-3+b1Network Security Service 
> libraries
> ii  pidgin    2.0.0+dfsg.1-4 multi-protocol instant messaging 
> c
> 
> pidgin-encryption recommends no packages.
> 
> -- no debconf information
> 

-- 
Leo Antunes <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Bug#439155: googleearth-package: Automatic run of make-googleearch-package on postinst

[Leo Antunes]

Package: googleearth-package
Version: 0.2.2
Severity: wishlist

Perhaps make-googleearch-package could be run during postinst, if the
user wishes?
>From what I've seen, there's no easy way of finding the version being
downloaded (since the name of the package contains no version token),
so there's no way to automatically determine if an update is necessary,
but anyway a debconf question could be asked, easing the life of users
that don't know what to do after they install googleearth-package.

Cheers and thanks for the script!


-- 
Leo Antunes <[EMAIL PROTECTED]>



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

Bug#439144: googleearth-package: still has problems on non-i386 arches

[Leo Antunes]

Package: googleearth-package
Version: 0.2.2
Severity: normal

Hi,

Actually, I think bug #416457 (archived) isn't quite closed yet.

The generated package still has a hardcoded 'Architecture: i386' field,
where it actually could be 'amd64' or 'ia64', making it necessary to
edit the make-googleearth-package to generate an installable deb on my
AMD64 (one that doesn't need any --force-* arguments to install).

The corect solution IMO (please let me know if I'm missing something
obvious here!), would be to make the googleearth-package package
"Arch:i386,amd64,ia64" (which are the only arches it actually has a
chance of building a running package) and change the hardcoded Arch:i386
field to 'Arch: $(dpkg-architecture -qDEB_BUILD_ARCH)', creating a
package suited for your arch.
I also think the --force check in the make-googleearth-package script is
unnecessary, since changing the Arch field in the package would make
sure the use ran it in the correct arch. If it's an advanced user, who
would know what to do with an out-of-arch package, then he can use
--force-architecture with dpkg, the way it's supposed to be done.

With this change, the package builds, installs and runs flawlessly on my
AMD64 machine, without any --force arguments or editing of files.

Cheers
Leo Antunes <[EMAIL PROTECTED]>


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=pt_BR (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages googleearth-package depends on:
ii  bzip2 1.0.3-7high-quality block-sorting file co
ii  dpkg-dev  1.14.5 package building tools for Debian
ii  fakeroot  1.7.1  Gives a fake root environment
ii  file  4.21-2 Determines file type using "magic"
ii  wget  1.10.2-3   retrieves files from the web

googleearth-package recommends no packages.

-- no debconf information


signature.asc
Description: This is a digitally signed message part

Bug#243262: Debian update on old bugs

[Leo Antunes]

Hi,

You're receiving this because you've opened a bug for Gnokii a long
while back which hasn't got the attention it deserved during all this
time.

I've adopted the Debian packaging duties for Gnokii and I'm checking up
on old bugs to ascertain whether they're still valid or have been solved
in the meantime and left without update.

If you still have the problems, please let me know by replying to the
bug logs. If you don't have the problem, don't know or care anymore, let
it be and I'll close the bug reports in a few weeks.

Cheers, thanks for the help and apologies for the long hiatus and abrupt
contact!
-- 
Leo Antunes <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Bug#403603: Update

[Leo Antunes]

Hi,

This bug completely slipped past me so it's probably already solved, but
if not, you might wanna try using the file /etc/gnokiirc as a starting
point for your next attempt. 
Taking a better look at it, you'll see that the right line should be
something like:
port=/dev/ttyUSB0
(it's the 10th line of the current version's /etc/gnokiirc file)

If this problem persists (and is still a problem to you, since I took so
long to look at it), please let me know.

Cheers and apologies for letting you off the hook regarding this
problem.

-- 
Leo Antunes <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Bug#339817: Status

[Leo Antunes]

Hi,

I've adopted this package and I'm checking on old bugs that might have
been fixed but not closed during the long update-hiatus.

Is this bug still an issue? Otherwise, can the patch be updated to
account for current changes?

Cheers
-- 
Leo Antunes <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Bug#426473: muine-plugin-trayicon: Copyright file missing MIT reference (NotificationArea.cs and friends)

[Leo Antunes]

Package: muine-plugin-trayicon
Version: 0.8.7-1
Severity: serious
Justification: Policy 12.5

muine-plugin-trayicon's copyright file mentions only the GPL and fail to
mention the MIT licence that NotificationArea.cs and friends use.

Cheers


-- System Information:
Debian Release: Sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=pt_BR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash


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

Bug#420723: Build fix patch

[Leo Antunes]

Ha! If I had spent at least a few minutes looking at the problem... :-)

Thanks for the pointer!
Will be uploaded shortly.

Cheers

On 5/16/07, Thomas Perl <[EMAIL PROTECTED]> wrote:


tags 420723 patch
thanks

Changing GNOMELOCALEDIR to PACKAGE_LOCALE_DIR makes things work again.
Trivial patch attached.


Enjoy,
Thomas






--
Leo Antunes
[EMAIL PROTECTED] | [EMAIL PROTECTED]

Bug#420723: tagging help

[Leo Antunes]

tags 420723 help
--

I don't have the extra time/interest right now to delve into this
problem. If someone could help I'd be thankful, otherwise I'll
eventually look at it sometime.

Cheers

-- 
Leo Antunes <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Bug#395309: Status

[Leo Antunes]

Hey there,

What's the status of this bug?
Is it currently being worked on? Could you use some help?

I'm personally interested in packaging this app, so if you're not really
into it, let me know so I can do it.

Cheers

--
Leo Antunes
[EMAIL PROTECTED] | [EMAIL PROTECTED]

Bug#419970: Bug status

[Leo Antunes]

Hey Philipp,

Just wanted to know if you're working on this and/ot the other opened
bugs for transmission. 
I got a little time on my hands now and could use it to close them, but
I don't want to run over anything you might have planned (since the bugs
are all tagged as 'pending').

Let me know if you don't have the time, so I'll work on them.

Cheers

-- 
Leo Antunes <[EMAIL PROTECTED]>



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

Bug#386447: Status update

[Leo Antunes]

Hi

What's the status of this package? Anything currently blocking it from
entering the archive?
If there's anything I can do to help, please let me know.
If you're not interested in packaging this app anymore, change the bug to an
'RFP' and I'll probably take it over.

Cheers
--
Leo Antunes
[EMAIL PROTECTED] | [EMAIL PROTECTED]

Bug#416457: googleearth-package: Architecture issues

[Leo Antunes]

Package: googleearth-package
Version: 0.0.5
Severity: important

The script doesn't check for running arch and downloads the bin file
without any warning. It should tell the user that if he's not in a i386
Arch (or one of the arches with ia32-compat libs) the script won't be
very useful.

Strictly speaking, it's ok for it to be "Arch: all", but you could at
least warn the user that it's probably not going to work.

Regarding this issue there's a small patch attached to make it work
better on AMD64 machines, but there's still the problem of dependency:
it needs ia32-libs and ia32-libs-gtk.

In hindsight, I think it's best to leave this package as "Arch: i386,
amd64", add dependencies like "ia32-libs [amd64], ia32-libs-gtk [amd64]"
and be done with it! :-)

Cheers and thanks for the neat script!
Leo Costela

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=C, LC_CTYPE=pt_BR (charmap=ISO-8859-1)

Versions of packages googleearth-package depends on:
ii  dpkg-dev  1.13.25package building tools for Debian
ii  fakeroot  1.6.5  Gives a fake root environment
ii  wget  1.10.2-2   retrieves files from the web

googleearth-package recommends no packages.

-- no debconf information
--- /usr/bin/make-googleearth-package   2006-12-09 14:25:07.0 -0200
+++ make-googleearth-package.costela2007-03-28 00:29:27.0 -0300
@@ -242,7 +242,7 @@
 Section: non-free/science
 Priority: optional
 Maintainer: $OPT_FULLNAME <${OPT_EMAIL}>
-Architecture: i386
+Architecture: $(dpkg-architecture -qDEB_HOST_ARCH)
 Depends: ttf-dejavu | ttf-bitstream-vera, $depends
 Description: Google Earth, a 3D map/planet viewer
  Package built with googleearth-package.

Bug#402349: Waiting for gtk 2.10

[Leo Antunes]

Hi,

Just to keep the bug log updated, the new version of Camorama is ready,
but it's waiting for gtk 2.10 to enter unstable.


Cheers
-- 
Leo Antunes <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Bug#374088: Status?

[Leo Antunes]

Hi!

On Tue, 2006-11-07 at 13:27 +0100, Free Ekanayaka wrote:
> I really though it  was still in the NEW  queue, but actually I  can't
> see it anymore :(
> 
> So I guess it was probably rejected, but  I did not receive any notice
> of that, or I might have trashed for mistake.
> 
> Is there a way to access the REJECT reports from the ftp-masters?

Unfortunately I don't know of any REJECT archive, but you could check in
the #debian-devel channel on IRC to see if there is such a thing.

The only time I had a rejected package, I received an email explaining
what had happened from an ftp-master.
If you didn't get it and can't find it archived anywhere, I think you
should mail the ftp-masters and ask again about a reason (as soon as
possible, since if there is no archive, they might forget about the
reason themselves! :-) ) 

Thanks for the quick answer!

Cheers

-- 
Leo Antunes <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part