Bug#719050: general: reportbug is not able to file bugs against some packages.

[atar]

Package: general
Severity: normal

reportbug is not able to file bugs against some packages.

for example, if you try to file a bug against the 'wget' package, or against 
the 'reportbug' 
package, reportbug emit the following error messages:

Querying Debian BTS for reports on wget (source)...
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2206, in 
main()
  File "/usr/bin/reportbug", line 1080, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1702, in user_interface
latest_first=self.options.latest_first)
  File "/usr/lib/pymodules/python2.7/reportbug/ui/text_ui.py", line 517, in 
handle_bts_query
source=source, http_proxy=http_proxy, archived=archived)
  File "/usr/lib/pymodules/python2.7/reportbug/debbugs.py", line 1263, in 
get_reports
stats = debianbts.get_status(bugs)
  File "/usr/lib/pymodules/python2.7/debianbts.py", line 170, in get_status
bugs.append(_parse_status(elem))
  File "/usr/lib/pymodules/python2.7/debianbts.py", line 243, in _parse_status
bug.msgid = _uc(tmp['msgid'])
  File "/usr/lib/pymodules/python2.7/SOAPpy/Types.py", line 1283, in __getitem__
return getattr(self, item)
AttributeError: structType instance has no attribute 'msgid'



-- System Information:
Debian Release: 7.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130808060641.9933.18681.reportbug@localhost

Bug#719042: ITP: pywws -- Python software for wireless weather stations

[Tonnerre Lombard]

Package: wnpp
Severity: wishlist
Owner: Tonnerre Lombard 

* Package name: pywws
  Version : 13.06_r1023
  Upstream Author : Jim Easterbrook 
* URL : https://code.google.com/p/pywws/
* License : GPL-2+
  Programming Lang: Python
  Description : Python software for wireless weather stations


A collection of Python scripts to read, store and process data from
popular USB wireless weather stations such as Elecsa AstroTouch 6975,
Watson W-8681, WH-1080PC, WH1080, WH1081, WH3080 etc. I assume any
model that is supplied with the EasyWeather Windows software is
compatible, but cannot guarantee this.

The software has been developed to run in a low power, low memory
environment such as a router. It can be used to create graphs and web
pages showing recent weather readings, typically updated every hour.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130808000302.9355.901.reportbug@localhost

Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Thomas Hood]

Op 7 aug. 2013 10:33 schreef "Wouter Verhelst"  het
volgende:
> Historically, "localhost" has always been "127.0.0.1". It feels wrong to
> change that, simply because "localhost" starts showing up in places it
> was never meant to show up in.

To clarify, no one is proposing that 'localhost' be assigned any (IPv4)
address other than 127.0.0.1 in /etc/hosts.

The question is what IP address the system hostname should be assigned when
the machine has no static external IP address. Currently it is assigned
127.0.1.1 and the proposal is to assign it 127.0.0.1 with 'localhost'
becoming a mere alias. I have already expressed my opinion about that
proposal.
-- 
Thomas

A transition plan for R data in binary format ?

[Charles Plessy]

Le Tue, Aug 06, 2013 at 08:29:14AM +0900, Charles Plessy a écrit :
> 
> While writing this answer, I also read Don's email advocating for Debian to
> take the lead and change the current practice in the R community, that prefers
> to ditribute data as R binary objects in the source packages.  This is
> laudable, but I expect that it will take time, and it needs people who have
> roots in both communities.
> 
> In the current situation, that I describe as "active bitrotting", we do not
> apply the same rules to the packages that enter the archive and the packages
> that are already in, which cause the packages under active development to
> become obsolete each time new dependancies can not enter in Debian.

Dear FTP team and everybody,

how about the following to smoothly solve the problem.

 - We aim at a full resolution within two or three release cycles.  This is
   roughly the time that was needed to solve the problem of binary blobs in the
   Linux kernel.

 - We define precisely what are the criteria for R binary objects to be
   accaptable in Debian, and how to test conformance with these criteria.

 - For the new R packages that do not interact much with the rest of the
   currently distributed packages, we apply these criteria strictly.

 - After reaching consensus between the main stakeholders (FTP team,
   maintainers of R packages in Debian, ...), we contact the main R communities
   (R developers, CRAN, Bioconductor, etc), and ask them to change the way they
   assemble source packages, so that they contain the files used to generate 
the R
   binary objects.

 - In a transitory period, for the packages that are already in Debian as well
   as the packages needed by them to be upgraded to fresh upstream versions, we
   give the priority to keep the packages up to date, while working in parallel 
to
   solve the problem as indicated above.

To avoid confusion, I would like to remind again that for the majority of the R
binary objects, loseless conversion with a plain text format is already
possible, and there is no evidence that a more complex source file is needed to
generate them, which I think is enough to make them Free.  The main problem
seems to be that with the binary format, it is difficult to detect the rare
cases where conversion from the source format requires non-trivial commands
that are not in the R source package.

What do you think about this ?

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130807233230.ga12...@falafel.plessy.net

Re: build warnings treated as failures

[Kurt Roeckx]

On Wed, Aug 07, 2013 at 09:07:48PM +0100, Neil Williams wrote:
> On Wed, 07 Aug 2013 22:01:33 +0530
> Ritesh Raj Sarraf  wrote:
> 
> > Taking this topic forward, I also reached out to upstream folks,
> > asking them to fix these build errors on various architectures.
> > 
> > I already did an upload of -3 and -4 to experimental. And I still see
> > newer build failures popping up.
> > 
> > My question to rest of the folks: How do you guys cope up with foreign
> > architectures, for which you do not have direct access to the box?
> 
> All DD's have SSH access to machines of each architecture supported by Debian.
> 
> http://db.debian.org/machines.cgi
> 
> http://www.debian.org/doc/manuals/developers-reference/pkgs.html#porting
> 
> http://www.debian.org/devel/dmup
> 
> So login and use the chroots to build natively on each architecture.

Non-DD can request an guest account:
http://dsa.debian.org/doc/guest-account/


Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130807203014.ga5...@roeckx.be

Re: build warnings treated as failures

[Neil Williams]

On Wed, 07 Aug 2013 22:01:33 +0530
Ritesh Raj Sarraf  wrote:

> Taking this topic forward, I also reached out to upstream folks,
> asking them to fix these build errors on various architectures.
> 
> I already did an upload of -3 and -4 to experimental. And I still see
> newer build failures popping up.
> 
> My question to rest of the folks: How do you guys cope up with foreign
> architectures, for which you do not have direct access to the box?

All DD's have SSH access to machines of each architecture supported by Debian.

http://db.debian.org/machines.cgi

http://www.debian.org/doc/manuals/developers-reference/pkgs.html#porting

http://www.debian.org/devel/dmup

So login and use the chroots to build natively on each architecture.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Philipp Kern]

On Wed, Aug 07, 2013 at 10:29:01AM -0700, Russ Allbery wrote:
> I think RFC 1912 is interesting here:
> 
>The "localhost" address is a "special" address which always refers to
>the local host.  It should contain the following line:
> 
>localhost.  IN  A   127.0.0.1

RFC 6761 has a bunch of clarifications, especially towards localhost use
for IPv6 as well.

 Users may assume that IPv4 and IPv6 address queries for localhost names
 will always resolve to the respective IP loopback address.

This conviently ignores the question what should be returned if you're
interested in an answer that does not specify either IPv4 or IPv6.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Bug#719012: ITP: fonts-humor-sans -- a font in the style of xkcd

[Ramakrishnan Muthukrishnan]

Package: wnpp
Owner: Ramakrishnan Muthukrishnan 
Severity: wishlist

* Package name: fonts-humor-sans
  Version : 1.0
  Upstream Author : Michael Ciuffo  
* URL or Web page : http://antiyawn.com/uploads/humorsans.html
* License : SIL Open Font License, Version 1.1
  Description : a font in the style of xkcd
  This truetype font has the typeface that looks like the ones in the
  popular online comic, xkcd (http://xkcd.com).


pgpgeJOqOcBWT.pgp
Description: PGP signature

Re: build warnings treated as failures

[Ritesh Raj Sarraf]

Taking this topic forward, I also reached out to upstream folks, asking
them to fix these build errors on various architectures.

I already did an upload of -3 and -4 to experimental. And I still see
newer build failures popping up.

My question to rest of the folks: How do you guys cope up with foreign
architectures, for which you do not have direct access to the box?


On Wednesday 17 July 2013 11:03 PM, Guillem Jover wrote:
> On Wed, 2013-07-17 at 19:15:42 +0200, Samuel Thibault wrote:
>> Ritesh Raj Sarraf, le Wed 17 Jul 2013 22:38:51 +0530, a écrit :
>>> I see a sudden surge of build failures against my latest upload of
>>> packages[1]. From the build logs, it looks like all warnings are treated
>>> as errors now.
>>>
>>> If that is the case, I would like to know how others are dealing with
>>> it? Fixing every build warning
>>
>> See configure.ac in your package:
>>
>> AM_INIT_AUTOMAKE([-Wall -Werror foreign])
> 
> Actually, those are automake options dealing with automake warnings.
> The culprit here is in Makefile.am (AM_CFLAGS).
> 
>> You probably want to remove -Werror and tell upstream that it's not so
>> good an idea.
> 
> True (for both automake and compiler warnings), at least for release
> builds, as new warnings might suddenly appear with new toolchains.
> 
> Thanks,
> Guillem
> 
> 

-- 
Given the large number of mailing lists I follow, I request you to CC me
in replies for quicker response


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5c9ada-cmd@news.researchut.com

Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Russ Allbery]

Wouter Verhelst  writes:
> On 05-08-13 19:08, Thomas Hood wrote:

>> In that case 'hostname.domain' is the canonical name for alias
>> 'localhost'.

> Which is fine. "localhost" is *supposed* to be an alias, it is not a
> canonical name (there are far too many machines called "localhost" for
> it to be a canonical name of any use...)

This may be a matter of style (and possibly even a matter of semantics),
but I consider the "localhost" name to be the canonical name for the
127.0.0.1 IP address, which always refers to the local loopback.  It's a
different type of canonical name, but I still consider that a canonical
name.

IMO, 127.0.0.1 resolving to anything other than localhost, or 127.0.0.1
resolving to any name other than localhost, is simply broken and not
behavior I want on any of my systems.  Obviously, other people's mileage
may vary, and I'm not saying this to try to change anyone's mind about how
they want to run their systems, simply to register a contrary opinion from
a long-time UNIX user.

I think RFC 1912 is interesting here:

   The "localhost" address is a "special" address which always refers to
   the local host.  It should contain the following line:

   localhost.  IN  A   127.0.0.1

   The "127.0" file should contain the line:

   1PTR localhost.

   There has been some extensive discussion about whether or not to
   append the local domain to it.  The conclusion is that "localhost."
   would be the best solution.  The reasons given include:

  "localhost" by itself is used and expected to work in some
  systems.

  Translating 127.0.0.1 into "localhost.dom.ain" can cause some
  software to connect back to the loopback interface when it didn't
  want to because "localhost" is not equal to "localhost.dom.ain".

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9ktif4y@windlord.stanford.edu

Re: Fwd: /etc/hosts and resolving of the local host/domainname - 127.0.0.1 vs. 127.0.1.1

[Wouter Verhelst]

On 05-08-13 19:08, Thomas Hood wrote:
> Wouter Verhelst wrote:
>> The right way, in my opinion, is that /etc/hosts should
>> look like this:
>>
>> 127.0.0.1 localhost
>> 127.0.0.1 hostname.domain hostname
> 
> Strictly speaking there should be no more than one line per
> IP address, so that would be

In practice, however, glibc parses that and it does not cause problems.
Any program directly parsing /etc/hosts is broken.

At any rate, I also said:

>> or, alternatively:
>>
>> 127.0.0.1 hostname.domain hostname localhost
> 
> In that case 'hostname.domain' is the canonical name for alias 'localhost'.

Which is fine. "localhost" is *supposed* to be an alias, it is not a
canonical name (there are far too many machines called "localhost" for
it to be a canonical name of any use...)

I believe a canonical name should always be an FQDN; there are, in fact,
some systems that break when this assumption is not adhered to (MIT
Kerberos and gridengine spring to mind, but I'm sure there are others).

> Before any move is made to conflate the system hostname with
> 'localhost' in this way I'd like to see some proof that this no longer
> causes any malfunction, or if it does cause malfunction (e.g.,
> 'localhost' appearing in log files)

The first entry on any line in /etc/hosts, AIUI, is supposed to be the
canonical name, with other entries being aliases. If "localhost" appears
in log messages, that would be because "localhost" is listed first on
that line. Fixing that is a simple case of "don't do that, then".

> then I'd like to see the
> malfunctioning packages fixed in advance of the transition from
> 127.0.1.1 to 127.0.0.1. And before making this potentially disruptive
> change, I'd like to see evidence that the current practice actually
> causes problems --- problems that can't easily be solved by patching
> individual packages either to make them listen on 127.0.1.1 on the one
> hand or to make them talk to localhost on the other.

It is, in theory, always possible to fix system-wide issues by patching
individual packages, but that isn't necessarily the right thing to do.

Historically, "localhost" has always been "127.0.0.1". It feels wrong to
change that, simply because "localhost" starts showing up in places it
was never meant to show up in. Yes, the change to 127.0.1.1 may have
fixed that particular issue, but it's ugly.

If applications were logging with "localhost" as their name, then either
these applications are buggy (not using the canonical name when they
should), or the order is not defined as clearly as I thought it was.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52025a99.6040...@debian.org

Bug#718981: ITP: ruby-colorator -- String extension for terminal coloring

[Youhei SASAKI]

Package: wnpp
Owner: Youhei SASAKI 
Severity: wishlist

* Package name: ruby-colorator
  Version : 0.1
  Upstream Author : Parker Moore and Brandon Mathis
* URL or Web page : https://github.com/octopress/colorator
* License : MIT
  Description : String extension for terminal coloring
   A Ruby Library colorize your text in the terminal.
   .
   There are a bunch of gems that provide functionality like this, but
   none have as simple an API as this. Just call `"string".color` and your
   text will be colorized.

---
Youhei SASAKI 
  
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3jxem1x.wl%uwab...@gfd-dennou.org

Bug#718980: ITP: python3-lirc -- LIRC support for Python 3.

[Thomas Preston]

Package: wnpp
Severity: wishlist
Owner: Thomas Preston 

* Package name: python3-lirc
  Version : 1.2.0
  Upstream Author : Thomas Preston 
* URL : https://github.com/tompreston/python-lirc
* License : GPL-3+
  Programming Lang: Python
  Description : LIRC support for Python 3.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130807120706.25692.73891.reportbug@lime

Re: SID: Trap divide error 0 in libc

[Holger Levsen]

Hi,

On Dienstag, 6. August 2013, Ondřej Surý wrote:
> 1) You should report a bug using our BTS and not to the developers list.

this has been reported as 718890 against base, which I have reassigned to 
libc6 - not sure if thats right.


cheers,
Holger


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

Re: pcmanfm on mentors

[Andrew Lee]

Dear LXDE folks,

FYI that I arrived in DebCamp yesterday. And the git repo for LXDE
packaging are backed online today.
Please feel free to commit ASAP if you have any uncommitted changes.
I'd upload updated packages soon.

Best regards,

-Andrew


2013/8/7 Andrew Lee 

> Hi,
>
> I am arrived.
>
> Let me get the git repo for lxde packages back online first.
> And then we should have all the updated in git before upload.
>
> Cheers,
>
> -Andrew
>
>
>
> 2013/8/4 Daniel Baumann 
>
>> Andrew is travelinng to debconf now, he'll get back to you in a couple
>> of days.
>>
>
>
>
> --
> -Andrew
>



-- 
-Andrew

Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?

[Steve McIntyre]

David Kalnischkies wrote:
>On Fri, Aug 2, 2013 at 2:52 PM, Paul Wise  wrote:
>> If so, here is the list of software that probably needs updating:
>>
>> dak
>> apt/apt-ftparchive
>> reprepro
>> launchpad
>> dpkg-dev
>> devscripts
>> derivatives census
>
>(c)debootstrap
>
>Also, apt-get is forcing MD5 in --print-uris by default because not doing
>it used to break all kinds of scripts. I think jigdo was one of them,
>no idea if that is really the case and/or if this changed by now.
>(not saying they shouldn't be fixed, just that the list is probably longer)

jigdo and debian-cd both use MD5 for tracking and indexing files -
debian-cd uses them to assist in generating jigdo files and also as a
verification of archive contents as images are built. There should be
no security implications in either case as more/stronger checksums are
used for verifying the complete images. Changing jigdo to use a
different checksum would not be impossible, but very involved and I'm
not really convinced it would be worth it.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1v6yxw-0005ru...@mail.einval.com

Bug#718956: ITP: printrun -- 3D-printing host software

[Nicolas Dandrimont]

Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont 

* Package name: printrun
  Version : 20130711
  Upstream Author : Kliment Yanev
* URL : https://github.com/kliment/Printrun
* License : GPLv3+
  Programming Lang: Python
  Description : 3D-printing host software

 Printrun is a set of G-Code sending applications for 3D-printers.
 .
 It consists of printcore (a dumb G-Code sender), pronsole (a full-fledged
 command-line G-Code sender), pronterface (a G-Code sender with a graphical
 interface), and a collection of related scripts.
 .
 Combined with a slicing program, it allows the user to operate a 3D printer
 such as a RepRap from scratch.

I'd be glad to hear feedback on the long description, as I'm a bit in a
"bubble" (and I'm sure there's room for improvement).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130807074035.ga3...@hilbert.home.olasd.eu

Re: Non-identical files with identical md5sums on Debian systems?

[Fabian Greffrath]

Dear Peter,

Am Mittwoch, den 07.08.2013, 00:03 +0100 schrieb peter green: 
> The bottom line is under practical conditions the only way you
> are going to see two files with the same md5 is if someone went
> out of their way to create them and send them to you.

thank you very much for this insightful analysis, now I feel more
confident :)

Best regards,

- Fabian



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1375858850.24465.17.camel@kff50

Bug#718952: ITP: php-mysqlnd-ms -- MySQL replication and load balancing module for PHP

[Ondřej Surý]

Package: wnpp
Severity: wishlist
Owner: "Ondřej Surý" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: php-mysqlnd-ms
  Version : 1.5.2
  Upstream Author : Ulf Wendel 
* URL : http://pecl.php.net/package/mysqlnd_ms
* License : PHP License
  Programming Lang: C
  Description : MySQL replication and load balancing module for PHP

 The mysqlnd_ms replication and load balancing plugin can be used with
 PHP MySQL extensions (ext/mysql, ext/mysqli, ext/pdo_mysql) if they
 are compiled to use mysqlnd.  The plugin inspects queries and does
 read-write splitting. Read-only queries are sent to MySQL replication
 slave servers while all other queries are redirected to the MySQL
 replication master server.  Very few, if any, application changes are
 required, depending on the usage scenario.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlIB8ewACgkQ9OZqfMIN8nNWhwCgi3eB7mm0+jUpE4nFaU6fpw4l
f3AAnjccAq/dFCorTn1TvcOk7mer/qDk
=Kq+U
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130807070623.15861.68978.report...@howl.nic.cz