Bug#660432: ITP: python-dxfwrite -- A Python library to create DXF R12 drawings

[Andrea Palazzi]

Package: wnpp
Severity: wishlist
Owner: Andrea Palazzi 

* Package name: python-dxfwrite
  Version : 1.1.0
  Upstream Author : mozman 
* URL : http://packages.python.org/dxfwrite/
* License : GPL
  Programming Lang: Python
  Description : A Python library to create DXF R12 drawings

This is a Python library to create DXF R12 drawings.



-- 
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/20120219081444.5198.84614.report...@marcopolo.lan

Bug#660433: ITP: libre-jigsaw -- A jigsaw puzzle game

[Jonathan Hulka]

Package: wnpp
Severity: wishlist
Owner: Jonathan Hulka 


* Package name: libre-jigsaw
  Version : 2012.02.18
  Upstream Author : Jonathan Hulka 
* URL : http://speedduck.net/games/jigsaw
* License : (GPL)
  Programming Lang: (Java)
  Description : A jigsaw puzzle game

Libre Jigsaw is a jigsaw puzzle game. It features square or hex shaped tiles, 
multiple layers (play areas) for sorting pieces, the ability to save and load 
games, and more.



-- 
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/20120219081619.2821.63038.reportbug@test.localhost

Bug#660435: ITP: libre-jigsaw-pics -- Libre Jigsaw pictures

[Jonathan Hulka]

Package: wnpp
Severity: wishlist
Owner: Jonathan Hulka 


* Package name: libre-jigsaw-pics
  Version : 2012.02.14
  Upstream Author : JS Nature Photos 
* URL : http://photos.jstechs.com/
* License : CC BY-SA 3.0
  Programming Lang: 
  Description : Libre Jigsaw pictures

Photos for the libre-jigsaw package.



-- 
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/20120219082656.9767.85647.reportbug@test.localhost

Re: [Pkg-oss4-maintainers] Help (voodoo, really) needed [Re: failed i386 build of iceweasel 11.0~b1-2]

[Josselin Mouette]

Le samedi 18 février 2012 à 22:57 -0600, Romain Beauxis a écrit : 
> More seriously there are people who care about their sound drivers in
> more specific ways than the average user who "just wants his shit to
> work" (sic). There are also people using OSes that do not have ALSA
> and, interestingly, we happen to support some of those.

This is why I’m advocating for the removal of OSS *in Linux*. Not
necessarily in kFreeBSD.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Bug#660449: general: The pc freeze suddenly

[Vittore Luccio]

Package: general
Severity: important

SOmetimes the pc suddenly freeze and is impossible to use. The only way to stop
the pc is to press down the start button.



-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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/20120219101742.2512.90306.report...@aleph.bet

Bug#660449: general: The pc freeze suddenly

[Josselin Mouette]

Le dimanche 19 février 2012 à 11:17 +0100, Vittore Luccio a écrit : 
> Package: general
> Severity: important
> 
> SOmetimes the pc suddenly freeze and is impossible to use. The only way to 
> stop
> the pc is to press down the start button.

{o,o}  O RLY?
|)__)
-"-"-



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

Bug#660449: general: The pc freeze suddenly

[Holger Levsen]

severity 660449 normal
tags 660449 + moreinfo
thanks

Hi Vittore,

On Sonntag, 19. Februar 2012, Vittore Luccio wrote:
> SOmetimes the pc suddenly freeze and is impossible to use. The only way to
> stop the pc is to press down the start button.

I'm afraid you will have to give us more information about what you are doing, 
when your PC freezes, else it's impossible to debug your problem. Logfiles 
might also help...


cheers,
Holger

P.S.: Joss, I dont think it's helpful or appropriate to just make fun at users 
submitting bugs. (Even if (you think) the bug is rather useless - if so, why 
reply at all?) I also think you're intelligent enough to make better jokes.



-- 
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/201202191228.42620.hol...@layer-acht.org

Processed: Re: Bug#660449: general: The pc freeze suddenly

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 660449 normal
Bug #660449 [general] general: The pc freeze suddenly
Severity set to 'normal' from 'important'

> tags 660449 + moreinfo
Bug #660449 [general] general: The pc freeze suddenly
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
660449: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660449
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.13296509292677.transcr...@bugs.debian.org

Bug#660449: marked as done (general: The pc freeze suddenly)

[Debian Bug Tracking System]

Your message dated Sun, 19 Feb 2012 13:28:28 +0200
with message-id <20120219112828.GD11930@sid.nuvreauspam>
and subject line Re: Bug#660449: general: The pc freeze suddenly
has caused the Debian Bug report #660449,
regarding general: The pc freeze suddenly
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
660449: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660449
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: important

SOmetimes the pc suddenly freeze and is impossible to use. The only way to stop
the pc is to press down the start button.



-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


--- End Message ---
--- Begin Message ---
On Du, 19 feb 12, 11:17:42, Vittore Luccio wrote:
> Package: general
> Severity: important
> 
> SOmetimes the pc suddenly freeze and is impossible to use. The only way to 
> stop
> the pc is to press down the start button.

Hello Vittore,

You message has no information that could help track this issue and 
reassign to the correct package, so I'm closing this bug.

Please contact http://lists.debian.org/debian-user (or 
http://lists.debian.org/debian-italian instead) and provide more 
information. At a minimum this should be:

- Debian version
- hardware
- if you are doing something special that leads to the freezes

The output of following commands would be helpful for people trying to 
assist you:

cat /etc/debian_version
uname -a
cat /proc/cpuinfo
free
lscpi -nn

Hope this helps,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature
--- End Message ---

Re: Teams in changelog trailers

[Jonas Smedegaard]

On 12-02-19 at 09:59am, Charles Plessy wrote:
> Le Sat, Feb 18, 2012 at 05:51:57PM +0100, Stefano Zacchiroli a écrit :
> > 
> > It'd be nice if debbugs could understand "[ Debian Developer ]" 
> > lines and give credit to the appropriate individuals when closing 
> > bugs mentioned in changelogs. But I understand that's not entirely 
> > trivial to do, and I don't consider that to be enough of a reason to 
> > keep around hard to attribute changelog entries.
> 
> Hi Stefano,
> 
> If there is ambiguity about credit, perhaps the BTS boilerplate could 
> be amended to include a disclaimer that not all of it shall come to 
> the uploader.
> 
> Recenlty, I have uploaded new packages with changelogs like the 
> following.
> 
>   r-cran-proto (0.3-9.2-1) unstable; urgency=low
>   
>  * Team upload.
>   
>  [ Carlos Borroto ]
>  * Initial release (Closes: #657994)
>   
>    -- Charles Plessy   Wed, 01 Feb 2012 13:47:24 +0900
> 
> At first I worried that it would deprive Carlos from the credit of 
> preparing the package.  But in the end, I think that such a changelog 
> clearly presents the responsibilities, credit aside.  I am responsible 
> for having uploaded the package, and Carlos is responsible for making 
> this packaging happen.
> 
> If the changelogs were about credit, what would be missing there would 
> be the contribution of the team to the packaging work of Carlos, and 
> that would bring us back putting the team's name in the changelog 
> signature, which is not as informative as having a human name.

I also use the style listing the contributor in square brackets and 
myself at the final line, when releasing a package (fully or mostly) on 
behalf of others - whether or not done in a team.

I understand that adding that "Team upload" statement silences lintian 
when my name is not listed as maintainer or uploader, but is that not 
all?  I fail to see other benefit than that, and I fail to understand 
what other style is sensible than the above.

In other words, can someone please help post a concrete example of a 
different changelog style than above, involving "Team upload" statement 
so that I understand what is really discussed here?


Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Teams in changelog trailers

[Simon McVittie]

On 19/02/12 11:40, Jonas Smedegaard wrote:
> In other words, can someone please help post a concrete example of a 
> different changelog style than above, involving "Team upload" statement 
> so that I understand what is really discussed here?

Preconditions: minetest is maintained by the Games Team; I am a member
of the Games Team; I am not an Uploader for minetest. Suppose I want to
fix a bug in minetest, without taking future responsibility for the
package in general.

Good:

minetest (0.23-5) unstable; urgency=low

  * Team upload.
  * Fix crash when badgers consume mushrooms (Closes: #424242)

 -- Simon McVittie   Sun, 19 Feb 2012 11:49:02 +

Bad:

minetest (0.23-5) unstable; urgency=low

  [ Simon McVittie ]
  * Fix crash when badgers consume mushrooms (Closes: #424242)

 -- Debian Games Team   Sun, 19
Feb 2012 11:49:02 +

I think this is the thing under discussion.

Regards,
S


-- 
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/4f40e2eb.2050...@debian.org

Re: Teams in changelog trailers

[Jonas Smedegaard]

On 12-02-19 at 11:54am, Simon McVittie wrote:
> On 19/02/12 11:40, Jonas Smedegaard wrote:
> > In other words, can someone please help post a concrete example of a 
> > different changelog style than above, involving "Team upload" 
> > statement so that I understand what is really discussed here?
> 
> Preconditions: minetest is maintained by the Games Team; I am a member 
> of the Games Team; I am not an Uploader for minetest. Suppose I want 
> to fix a bug in minetest, without taking future responsibility for the 
> package in general.
> 
> Good:
> 
> minetest (0.23-5) unstable; urgency=low
> 
>   * Team upload.
>   * Fix crash when badgers consume mushrooms (Closes: #424242)
> 
>  -- Simon McVittie   Sun, 19 Feb 2012 11:49:02 +
> 
> Bad:
> 
> minetest (0.23-5) unstable; urgency=low
> 
>   [ Simon McVittie ]
>   * Fix crash when badgers consume mushrooms (Closes: #424242)
> 
>  -- Debian Games Team   Sun, 19
> Feb 2012 11:49:02 +
> 
> I think this is the thing under discussion.

Thanks for the clarification.

Yes, I fully agree that we should get rid of such abomination!

In my opinion that final line should always match the uploader, which is 
either a single individual or (for binNMU) a script.

Yes, In my opinion that goes for sponsoring too: The sponsor should add 
herself/himself in the changelog to clearly advertise to the World whom 
within the Debian web of trust proof-read and uploaded the packaging.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Teams in changelog trailers

[David Bremner]

On Sun, 19 Feb 2012 13:15:19 +0100, Jonas Smedegaard  wrote:
> 
> Yes, In my opinion that goes for sponsoring too: The sponsor should add 
> herself/himself in the changelog to clearly advertise to the World whom 
> within the Debian web of trust proof-read and uploaded the packaging.
> 

Hi Jonas;

I understand the motivation, I think, of making sponsor responsibility
more clear. But I think in general it is more important that the sponsor
upload (or choose not to) a pristine package from the sponsoree.  This
avoids situations where the sponsoree somehow feels sabotaged by changes
after they last saw the package, and it also matches my understanding of
what the responsibility of sponsoring is: to act as a gatekeeper, but
not to promise any further maintenance of the package (other than
orphaning of the sponsoree goes MIA).  We have both sponsoring and
co-maintenance; there is no rule that says co-maintainers have have to
be DD/DMs. 

One suggestion that came up on IRC was to have the PTS track the
"who-uploads" information to make it more convenient for non-developers
(or just lazy developers ;) ) to access, and more visible.

David




-- 
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/87mx8f0z7u.fsf@zancas.localnet

Bug#660449: general: The pc freeze suddenly

[Vittore Luccio]

Thanks to you. Here's some other information:

cat /etc/debian_version
6.0.4

uname - a
Linux aleph 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012 x86_64
GNU/Linux

free
 total   used   free sharedbuffers cached
Mem:   2055376 8319561223420  0  18692 379728
-/+ buffers/cache: 4335361621840
Swap:  4009976  04009976


lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset
Memory Controller Hub [8086:2a40] (rev 07)
00:01.0 PCI bridge [0604]: Intel Corporation Mobile 4 Series Chipset PCI
Express Graphics Port [8086:2a41] (rev 07)
00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #4 [8086:2937] (rev 03)
00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #5 [8086:2938] (rev 03)
00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #6 [8086:2939] (rev 03)
00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2
EHCI Controller #2 [8086:293c] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD
Audio Controller [8086:293e] (rev 03)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 1 [8086:2940] (rev 03)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 2 [8086:2942] (rev 03)
00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 3 [8086:2944] (rev 03)
00:1c.4 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 5 [8086:2948] (rev 03)
00:1c.5 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 6 [8086:294a] (rev 03)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #1 [8086:2934] (rev 03)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #2 [8086:2935] (rev 03)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #3 [8086:2936] (rev 03)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2
EHCI Controller #1 [8086:293a] (rev 03)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge
[8086:2448] (rev 93)
00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M LPC Interface Controller
[8086:2919] (rev 03)
00:1f.2 SATA controller [0106]: Intel Corporation ICH9M/M-E SATA AHCI
Controller [8086:2929] (rev 03)
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Device
[1002:95c2]
03:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 5100 AGN
[Shiloh] Network Connection [8086:4237]
86:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8072
PCI-E Gigabit Ethernet Controller [11ab:436c]




2012/2/19 Holger Levsen 

> severity 660449 normal
> tags 660449 + moreinfo
> thanks
>
> Hi Vittore,
>
> On Sonntag, 19. Februar 2012, Vittore Luccio wrote:
> > SOmetimes the pc suddenly freeze and is impossible to use. The only way
> to
> > stop the pc is to press down the start button.
>
> I'm afraid you will have to give us more information about what you are
> doing,
> when your PC freezes, else it's impossible to debug your problem. Logfiles
> might also help...
>
>
> cheers,
>Holger
>
> P.S.: Joss, I dont think it's helpful or appropriate to just make fun at
> users
> submitting bugs. (Even if (you think) the bug is rather useless - if so,
> why
> reply at all?) I also think you're intelligent enough to make better jokes.
>
>
>


-- 


__
In an open world, who needs Windows or Gates?
Vittore 3481201018

Re: Teams in changelog trailers

[Jonas Smedegaard]

On 12-02-19 at 08:44am, David Bremner wrote:
> On Sun, 19 Feb 2012 13:15:19 +0100, Jonas Smedegaard  
> wrote:
> > 
> > Yes, In my opinion that goes for sponsoring too: The sponsor should 
> > add herself/himself in the changelog to clearly advertise to the 
> > World whom within the Debian web of trust proof-read and uploaded 
> > the packaging.
> > 
> 
> Hi Jonas;
> 
> I understand the motivation, I think, of making sponsor responsibility 
> more clear. But I think in general it is more important that the 
> sponsor upload (or choose not to) a pristine package from the 
> sponsoree.  This avoids situations where the sponsoree somehow feels 
> sabotaged by changes after they last saw the package,

Obviously sponsors should not sabotage works of sponsorees.  Which 
leaves the _feeling_ of sabotage.

I disagree that avoiding sponsorees _feeling_ sabotaged is more 
important than documenting who in Debian changed something in Debian.


> and it also matches my understanding of what the responsibility of 
> sponsoring is: to act as a gatekeeper, but not to promise any further 
> maintenance of the package (other than orphaning of the sponsoree goes 
> MIA).

The very act as gatekeeper is the responsibility I want more explicit.

(yes, I dislike the sponsoring system in general due to that lack of 
responsibility inside Debian for the _maintainance_ of packages, but 
that is a different issue: here I raise a concern only about visibility 
of responsibility inside Debian in _releasing_ a package).

The key part is "inside Debian": We trust each other, but cannot trust 
sponsorees (that's the whole reason for them needing a sponsor!), so 
they need someone among us to take the responsibility on their behalf.  
I want that responsibility clearly stated.


> We have both sponsoring and co-maintenance; there is no rule that says 
> co-maintainers have have to be DD/DMs.

Since only DD/DMs can upload co-maintained packages, same rule applies 
there.

Or did I miss your point?


> One suggestion that came up on IRC was to have the PTS track the 
> "who-uploads" information to make it more convenient for 
> non-developers (or just lazy developers ;) ) to access, and more 
> visible.

That argument has come up before.  It is nice that our online machinery 
can infer such information.  I still find it much better to simply 
require that the changelog entry reflects in its final line the Debian 
entity responsible for the packaging release.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Bug#660449: general: The pc freeze suddenly

[Fernando Lemos]

Hello Vittore,

On Sun, Feb 19, 2012 at 12:01 PM, Vittore Luccio  wrote:
> Thanks to you. Here's some other information:
[...]

What you're reporting is waaay too general. Please contact the
debian-user mailing list [1] or some other localized mailing list for
Debian users, and ask for advice on how to narrow it down and
troubleshoot it. It might be anything, hardware problems, driver
problems, or actual bugs on other higher level components.

Reporting a bug without narrowing it down first is pretty much useless.

Also, please take care not to mail cont...@bugs.debian.org unless you
know what you're doing, as it can have unintended consequences.

[1] http://lists.debian.org/debian-user/

Regards,



-- 
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/CANVYNa9Sr37d4TuvdtvVi7vSijkyXtzwfUHh1N=7m90xcot...@mail.gmail.com

Re: Teams in changelog trailers

[Simon Chopin]

On Sun, Feb 19, 2012 at 03:21:10PM +0100, Jonas Smedegaard wrote:
[snip]
> That argument has come up before.  It is nice that our online machinery 
> can infer such information.  I still find it much better to simply 
> require that the changelog entry reflects in its final line the Debian 
> entity responsible for the packaging release.
It seems to me that the changelog is not the place for that information.
Its purpose is to document the changes made to the packaging, which is
totally orthogonal to whether it has been uploaded and by whom.

From a user POV, what matters is to know who made the changes. The chain
of trust that lead to the changes being accepted into the archive are
only useful for internal purposes, AFAICT, and thus should not be into
the package.

I think of this piece of info as something similar to the Ack-By: tags
in Git and such : it would not make sense to store it in the code
itself. And here, the whole debian/ directory is the code.

Regards,

Simon


signature.asc
Description: Digital signature

Re: Teams in changelog trailers

[Jonas Smedegaard]

On 12-02-19 at 04:03pm, Simon Chopin wrote:
> On Sun, Feb 19, 2012 at 03:21:10PM +0100, Jonas Smedegaard wrote:
> [snip]
> > That argument has come up before.  It is nice that our online 
> > machinery can infer such information.  I still find it much better 
> > to simply require that the changelog entry reflects in its final 
> > line the Debian entity responsible for the packaging release.
> It seems to me that the changelog is not the place for that 
> information. Its purpose is to document the changes made to the 
> packaging, which is totally orthogonal to whether it has been uploaded 
> and by whom.
> 
> From a user POV, what matters is to know who made the changes. The 
> chain of trust that lead to the changes being accepted into the 
> archive are only useful for internal purposes, AFAICT, and thus should 
> not be into the package.
> 
> I think of this piece of info as something similar to the Ack-By: tags 
> in Git and such : it would not make sense to store it in the code 
> itself. And here, the whole debian/ directory is the code.

...which brings us back to the topic of this thread:

Why then write "Team upload" in a changelog entry, if that space in 
solely for documenting _changes_ and who made them, not who _finalized_ 
them (i.e. was responsible for their appearing into Debian)?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Teams in changelog trailers

[Stefano Rivera]

Hi Simon (2012.02.19_17:03:17_+0200)
> It seems to me that the changelog is not the place for that information.
> Its purpose is to document the changes made to the packaging, which is
> totally orthogonal to whether it has been uploaded and by whom.

Uploading is a fairly important change in the packaging, and it's useful
to know who made the decision to upload. In the case of sponsored
uploads, that is the contributor that requested the upload, not
necessarily the person who made all the changes.

> The chain of trust that lead to the changes being accepted into the
> archive are only useful for internal purposes, AFAICT, and thus should
> not be into the package.

That's the GPG signature. It's not part of the changelog.

I often end up with:

 [Maintainer]
 * foo

 [Contributor]
 * Team Upload
 * bar

 -- Contributor <...> ...

which works well for me.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127


-- 
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/20120219151408.go14...@bach.rivera.co.za

Bug#660449: general: The pc freeze suddenly

[Ben Hutchings]

On Sun, 2012-02-19 at 11:17 +0100, Vittore Luccio wrote:
> Package: general
> Severity: important
> 
> SOmetimes the pc suddenly freeze and is impossible to use. The only way to 
> stop
> the pc is to press down the start button.

Use netconsole
 or
serial console
 to capture
the kernel log on other system.  This should provide some information
about what went wrong.

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug


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

Re: Teams in changelog trailers

[Jonas Smedegaard]

On 12-02-19 at 11:31am, David Bremner wrote:
> On Sun, 19 Feb 2012 15:21:10 +0100, Jonas Smedegaard  
> wrote:
> > On 12-02-19 at 08:44am, David Bremner wrote:
> > > We have both sponsoring and co-maintenance; there is no rule that 
> > > says co-maintainers have have to be DD/DMs.
> > 
> > Since only DD/DMs can upload co-maintained packages, same rule 
> > applies there.
> > 
> > Or did I miss your point?
> 
> My point is/was that what you suggest sounds more like co-maintenance 
> to me.

Ah (yes, I missed that point before!)


> So, people who dislike the current sponsoring system (i.e. leaving the 
> sponsoree as the uploader in changelog) can co-maintain instead.
> 
> Maybe we are proposing the same set of actions, and just giving it 
> different names (your "improved sponsoring" is my "co-maintenance").
> 
> Obviously you are free to do what you like when you sponsor.  A 
> different, and more contentious point, is what the project should 
> prefer. Given the state of near-collapse (by ratio of requests to 
> active sponsors) of the sponsoring system, I would hesitate to impose 
> too many requirements the process. As we both know, one person's 
> innocuous requirement (e.g. let's all use dh7) is another persons 
> reason to walk away from an activity.

As I tried to point out in a different post, my point here is *not* to 
make sponsoring into co-maintainance (even if I personally encourage 
that for anyone concreltey approaching me asking for sponsorship).

There is different styles of develpment, and there is the effect on 
Debian as a whole.

Yes, it can be argued that CDBS is hurtful for Debian as a whole, but I 
find that a weaker point than the one of the Debian member responsible 
for an upload not being explicitly available t our users - only 
implicitly possible to dig out of our logs somewhere and present 
centralized at e.g. packages.qa.debian.org.


NB! Please do not cc me discretely - I am subscribed to this list (and 
besides our [code of conduct] tells not to do so).


Regards,

 - Jonas


[code of conduct]: http://www.debian.org/MailingLists/#codeofconduct

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Teams in changelog trailers

[David Bremner]

On Sun, 19 Feb 2012 15:21:10 +0100, Jonas Smedegaard  wrote:
> On 12-02-19 at 08:44am, David Bremner wrote:
> > We have both sponsoring and co-maintenance; there is no rule that says 
> > co-maintainers have have to be DD/DMs.
> 
> Since only DD/DMs can upload co-maintained packages, same rule applies 
> there.
> 
> Or did I miss your point?

My point is/was that what you suggest sounds more like co-maintenance to
me. So, people who dislike the current sponsoring system (i.e. leaving
the sponsoree as the uploader in changelog) can co-maintain instead.

Maybe we are proposing the same set of actions, and just giving it
different names (your "improved sponsoring" is my "co-maintenance").

Obviously you are free to do what you like when you sponsor.  A
different, and more contentious point, is what the project should
prefer. Given the state of near-collapse (by ratio of requests to active
sponsors) of the sponsoring system, I would hesitate to impose too many
requirements the process. As we both know, one person's innocuous
requirement (e.g. let's all use dh7) is another persons reason to walk
away from an activity.

d


-- 
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/87obsu262b.fsf@zancas.localnet

Bug#660558: general: hostname changed to unknownXXXXXX after upgrading packages

[Iker Salmón]

Package: general
Severity: normal

Dear Maintainer,

Sorry i can't identify the package involved in this issue but it happened in a 
wheezy instalation and also in testing/sid instalation as well
Ater some packages upgrading the hostname changed as i described in the subject 
of this bug report.

these are the packages involved in the last upgrade, i think this happen in 
this upgrade, let me know if i can provide more info.

Thanks

[INSTALA, DEPENDENCIAS] libx264-120
[ACTUALIZA] aspell-es 1.11-3 -> 1.11-4
[ACTUALIZA] bluetooth 4.96-3 -> 4.98-2
[ACTUALIZA] bluez 4.96-3 -> 4.98-2
[ACTUALIZA] bluez-alsa 4.96-3 -> 4.98-2
[ACTUALIZA] bluez-cups 4.96-3 -> 4.98-2
[ACTUALIZA] bluez-gstreamer 4.96-3 -> 4.98-2
[ACTUALIZA] colord 0.1.15-3 -> 0.1.16-2
[ACTUALIZA] cups-driver-gutenprint 5.2.7-4 -> 5.2.7-5
[ACTUALIZA] file 5.09-2 -> 5.10-1
[ACTUALIZA] gir1.2-glib-2.0 1.31.1-1 -> 1.31.10-1
[ACTUALIZA] iso-codes 3.32-1 -> 3.32.2-1
[ACTUALIZA] ispanish 1.11-3 -> 1.11-4
[ACTUALIZA] libbluetooth3 4.96-3 -> 4.98-2
[ACTUALIZA] libcolord1 0.1.15-3 -> 0.1.16-2
[ACTUALIZA] libdirac-decoder0 1.0.2-4 -> 1.0.2-6
[ACTUALIZA] libdirac-encoder0 1.0.2-4 -> 1.0.2-6
[ACTUALIZA] libgail18 2.24.8-3 -> 2.24.9-2
[ACTUALIZA] libgdk-pixbuf2.0-0 2.24.0-2 -> 2.24.1-1
[ACTUALIZA] libgdk-pixbuf2.0-common 2.24.0-2 -> 2.24.1-1
[ACTUALIZA] libgirepository-1.0-1 1.31.1-1 -> 1.31.10-1
[ACTUALIZA] libgnutls28 3.0.12-1 -> 3.0.12-2
[ACTUALIZA] libgpg-error0 1.10-2 -> 1.10-3
[ACTUALIZA] libgtk2.0-0 2.24.8-3 -> 2.24.9-2
[ACTUALIZA] libgtk2.0-bin 2.24.8-3 -> 2.24.9-2
[ACTUALIZA] libgtk2.0-common 2.24.8-3 -> 2.24.9-2
[ACTUALIZA] libgutenprint2 5.2.7-4 -> 5.2.7-5
[ACTUALIZA] libmagic1 5.09-2 -> 5.10-1
[ACTUALIZA] libpng12-0 1.2.46-4 -> 1.2.46-5
[ACTUALIZA] libslang2 2.2.4-5 -> 2.2.4-6
[ACTUALIZA] libslp1 1.2.1-7.8 -> 1.2.1-9
[ACTUALIZA] libsmbclient 2:3.6.1-3 -> 2:3.6.3-1
[ACTUALIZA] libtalloc2 2.0.7-3 -> 2.0.7+git20120207-1
[ACTUALIZA] libvlc5 1.1.13-1 -> 1.1.13-1+b1
[ACTUALIZA] libvlccore4 1.1.13-1 -> 1.1.13-1+b1
[ACTUALIZA] libwbclient0 2:3.6.1-3 -> 2:3.6.3-1
[ACTUALIZA] libwebp2 0.1.3-2 -> 0.1.3-2.1
[ACTUALIZA] libxcb-dri2-0 1.8-1 -> 1.8-2
[ACTUALIZA] libxcb-randr0 1.8-1 -> 1.8-2
[ACTUALIZA] libxcb-render0 1.8-1 -> 1.8-2
[ACTUALIZA] libxcb-shape0 1.8-1 -> 1.8-2
[ACTUALIZA] libxcb-shm0 1.8-1 -> 1.8-2
[ACTUALIZA] libxcb-xv0 1.8-1 -> 1.8-2
[ACTUALIZA] libxcb1 1.8-1 -> 1.8-2
[ACTUALIZA] myspell-es 1.11-3 -> 1.11-4
[ACTUALIZA] printer-driver-gutenprint 5.2.7-4 -> 5.2.7-5
[ACTUALIZA] python-fpconst 0.7.2-4 -> 0.7.2-5
[ACTUALIZA] python-gi 3.0.3-3 -> 3.1.0-2
[ACTUALIZA] python-gobject 3.0.3-3 -> 3.1.0-2
[ACTUALIZA] python-wicd 1.7.0+ds1-9 -> 1.7.1-1
[ACTUALIZA] samba-common 2:3.6.1-3 -> 2:3.6.3-1
[ACTUALIZA] samba-common-bin 2:3.6.1-3 -> 2:3.6.3-1
[ACTUALIZA] smbclient 2:3.6.1-3 -> 2:3.6.3-1
[ACTUALIZA] vlc 1.1.13-1 -> 1.1.13-1+b1
[ACTUALIZA] vlc-nox 1.1.13-1 -> 1.1.13-1+b1
[ACTUALIZA] vlc-plugin-notify 1.1.13-1 -> 1.1.13-1+b1
[ACTUALIZA] vlc-plugin-pulse 1.1.13-1 -> 1.1.13-1+b1
[ACTUALIZA] wicd-daemon 1.7.0+ds1-9 -> 1.7.1-1
[ACTUALIZA] xkb-data 2.5-1 -> 2.5.1-1



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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/20120219205811.6190.44143.reportbug@debian

Description-less Packages indices

[Joe Dalton]

Martin Eberhard Schauer  writes:

> The changes have ill side-effects:
>  - DDTP/DDTSS is partially broken (1). The Database has $(nr_of_packages)
>new entrys since 01-22 containing just the short description.
>  - These (untranslated) one-liners is what one gets visiting (2), e.g. (3).
>  - There are no new Translation-xx files (4).
>  - In (5) there is the link why it was done: (6). IMHO one part of the
> reasoning is
>not really convincing.
>
>... and also enables non-English-speaking users (and eventually
>multi-arch enabled APT) to save on download size, as they no longer
>need to download a language that is of no use to them or is already
>there.

But I need to download binary-amd64/Packages, binary-i386/Packages,
binary-armel/Packages, binary-mipsel/Packages. That is 4 times nearly
identical sets of long descriptions. Now I only need to download the
english "translation" once.


I'm not in a position, to estimate this effect, but the change has a severe 
impact
on the translation effort at least for Danish and I guess that the above 
situation
has lasted for some time (downloading several long descriptions).

It must be possible to undone this change, until a solution for the translation 

robot has been prepared.

bye
Joe
Danish



--
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/1329687486.8181.yahoomail...@web28405.mail.ukl.yahoo.com

Processed: reassign 660558 to wicd-daemon

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # most likely related to DHCP and #609851
> reassign 660558 wicd-daemon
Bug #660558 [general] general: hostname changed to unknownXX after 
upgrading packages
Bug reassigned from package 'general' to 'wicd-daemon'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
660558: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660558
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.132968855715005.transcr...@bugs.debian.org

Re: Processed: reassign 660558 to wicd-daemon

[David Paleino]

reassign 660558 general
thanks

On Sun, 19 Feb 2012 21:57:12 +, Debian Bug Tracking System wrote:

> > # most likely related to DHCP and #609851
> > reassign 660558 wicd-daemon
> Bug #660558 [general] general: hostname changed to unknownXX after
> upgrading packages
> Bug reassigned from package 'general' to 'wicd-daemon'.
> > thanks
> Stopping processing here.

This bus is unlikely to be caused by wicd. It is, in fact, been patched to deal
with the bug Ben is referring to.

http://patch-tracker.debian.org/patch/series/view/wicd/1.7.1-1/02-workaround_dhclient_bug.patch

Reassigning back to general.

Kindly,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Processed: Re: Processed: reassign 660558 to wicd-daemon

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 660558 general
Bug #660558 [wicd-daemon] general: hostname changed to unknownXX after 
upgrading packages
Bug reassigned from package 'wicd-daemon' to 'general'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
660558: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660558
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.132968948921878.transcr...@bugs.debian.org

Re: Processed: reassign 660558 to wicd-daemon

[Ben Hutchings]

On Sun, 2012-02-19 at 23:11 +0100, David Paleino wrote:
> reassign 660558 general
> thanks
> 
> On Sun, 19 Feb 2012 21:57:12 +, Debian Bug Tracking System wrote:
> 
> > > # most likely related to DHCP and #609851
> > > reassign 660558 wicd-daemon
> > Bug #660558 [general] general: hostname changed to unknownXX after
> > upgrading packages
> > Bug reassigned from package 'general' to 'wicd-daemon'.
> > > thanks
> > Stopping processing here.
> 
> This bus is unlikely to be caused by wicd. It is, in fact, been patched to 
> deal
> with the bug Ben is referring to.

I know, but this could be a regression caused by the fix.

> http://patch-tracker.debian.org/patch/series/view/wicd/1.7.1-1/02-workaround_dhclient_bug.patch
> 
> Reassigning back to general.

The list of packages upgraded doesn't include anything else likely to
affect the hostname.

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug


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

Bug#660558: hostname changed to unknownXXXXXX after upgrading packages

[Jonathan Nieder]

reassign 660558 upgrade-reports
tags 660558 + wheezy
quit

David Paleino wrote:

> This bus is unlikely to be caused by wicd. It is, in fact, been patched to 
> deal
> with the bug Ben is referring to.
>
> http://patch-tracker.debian.org/patch/series/view/wicd/1.7.1-1/02-workaround_dhclient_bug.patch
>
> Reassigning back to general.

All right, reassigning to upgrade-reports, since this is still not a
general bug affecting a large portion of packages in the archive.  Not
sure which package might be responsible, but hopefully someone else
will know.

Thanks for looking into it.
Jonathan



-- 
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/20120219225218.GA946@burratino

Processed: Re: hostname changed to unknownXXXXXX after upgrading packages

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 660558 upgrade-reports
Bug #660558 [general] general: hostname changed to unknownXX after 
upgrading packages
Bug reassigned from package 'general' to 'upgrade-reports'.
> tags 660558 + wheezy
Bug #660558 [upgrade-reports] general: hostname changed to unknownXX after 
upgrading packages
Added tag(s) wheezy.
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
660558: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660558
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.13296919515348.transcr...@bugs.debian.org

[DEP9] RFC: draft-> candidate

[Serafeim Zanikolas]

[cc'ing the maintainers of openbsd-inetd & xinetd]

Hi,

DEP9 is implemented in the new package reconf-inetd (currently in unstable)
and is ready to be tested. I've opened wishlist bugs #660568 & #660569 for a
couple of "Depends: update-inetd" packages (the legacy tool to be replaced).

DEP0's criterion for the draft->candidate transition is:

consensus exists for /what/ should be done, and /how/ it should be done
(agreement needs to be expressed by all affected parties, not just the
drivers; silence is not agreement, but unanimity is not required, either)

I believe that there is rough consensus for the 'what' (rewrite update-inetd)
but there's not been much reaction on the 'how' that DEP9 proposes (except for
significant input from Marco d'Itri in the early stages of DEP9, and "when
will it be ready?" queries from update-inetd bug report submitters more
recently)

Unless someone screams against DEP9 within the next few weeks, I'll file
wishlist bugs for all ~50 rdepends of update-inetd.

cheers,
sez


-- 
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/20120219233806.GC3604@mobee

Bug#660576: ITP: disktest -- verify disk integrity

[Richard Hartmann]

Package: wnpp
Severity: wishlist
Owner: Richard Hartmann 

* Package name: disktest
  Version : 0.20120220
  Upstream Author : Richard Hartmann 
* URL : https://github.com/RichiH/disktest
* License : GPL
  Programming Lang: POSIX Shell
  Description : verify disk integrity

disktest will test your disks using S.M.A.R.T. and badblocks, saving the
results into files named after your disk's vendor, model, and serial
number.

Basic precautions have been made, i.e. disktest will refuse to operate
on mounted disks. Still, by design, disktest will erase any and all data
on disks you decide to test. You have been warned.



-- 
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/20120219235804.17689.90848.reportbug@rockhopper.hartmann.local

Re: Teams in changelog trailers

[Charles Plessy]

Le Sun, Feb 19, 2012 at 08:44:37AM -0400, David Bremner a écrit :
> 
> what the responsibility of sponsoring is: to act as a gatekeeper, but
> not to promise any further maintenance of the package (other than
> orphaning of the sponsoree goes MIA).

Hi David,

I think that opinions differ on that subject, but mine is that the developer
who uploads has the full responsibility for taking care of the package.  That
includes problems caused or revealed by the upload, but also problems that were
existing before.  If there are worries that this may be too much for a given a
package, then I think that it is a hint that it should be removed instead.

Have a nice day,

-- 
Charles Plessy
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/20120220002932.gb30...@falafel.plessy.net

Re: leaks in our only-signed-software fortress

[Christoph Anton Mitterer]

Hey.

Just by now,... two additional cases of security problems crossed my
mind.
Though not related to our package signing, they originate to some extent
in the same problem as everything that was discussed in this thread
before:
Insufficient "feeling" for security [by maintainers].


1) Silent modification of defaults.
IMHO, it's perfectly well for a maintainer, to modify the default
_configuration_ of and even to "lower" security by that (to the later:
if there is really good reason for it).
The admin installing the package shall be expected to go through the
configuration and understand it. If he doesn't it's his fault not the
maintainers.


But I've already seen several cases, where maintainers choose to
directly modify (patch) the defaults in the program code.
Sometimes this was for good reasons, sometimes I could not follow it (as
in my mind, a simple change of the default config would have been
enough).

Nevertheless, in such a case it is utmost important that these
modifications are documented.
And not just in the quilt patch header.
This should really go into several places:
- any --help output of the program itself must be updated, too.
- manpages/documentation should be added with information (in the
respective sections) that Debian deviates from the upstream default
value (and how).
- There should be one central point, where all those modifications are
_clearly_ (that is not hidden between words of text) documented
(probably README.Debian).



2) Well I really feel bad now, having to point my finger at the Nagios
Maintainers as they really do a good job, but this just shocked me:
Bug #660585.

Well as I describe in the bug, it is practically (at the moment) of no
relevance as SSL in Nagios' NRPE is broken.
The problem here is IMHO rather the attitude behind.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature