Re: Alioth status update, take 3

[Raphael Hertzog]

Hi,

On Mon, 23 May 2011, Roland Mas wrote:
>   We should now be in the phase where we pretend it's done, wait for the
> complaints, and fix the problems as they are reported (or laugh them off
> when they come from the too-common expectation that Alioth can be used
> to run any random stuff by anyone).

1/ We lost all the ACL in the migration. Many teams rely on ACL to grant
commit rights to all DD, they are also used to ensure the entire team
keeps full write access (even when someone with a restrictive umask
pushes new files).

See how the script /srv/git.debian.org/bin/newrepo setup the ACL and
while I was part of the team I have run dozens of time the scripts
/srv/home/rhertzog/bin/add-Debian-acl.sh or
/srv/home/rhertzog/bin/add-group-acl.sh on various SCM directories.

The issue has been brought up on IRC a couple of times but I have yet
to see an answer on this topic.

It would be a major step backwards for collaborative maintenance if ACL
were no longer allowed. And if you plan to allow ACL again, will you
restore the old ACL or shall we request them again one by one?

It might be a good idea to setup a system where you store the ACL in a
textual file so that you can easily restore them without going through
the pain of backing them up explicitly.

By default each SCM directory should have write access for its own group
but any other ACL would be explicitly listed in a file:
/srv/git.debian.org/git/collab-maint g:Debian:rwX
/srv/svn.debian.org/svn/collab-maint g:Debian:rwX

And a simple script could do the restore:
(while read dir right; do
   sudo setfacl -R -m d:$right $dir;
   sudo setfacl -R -m $right $dir;
done) 
| Envelope-to: hert...@vasks.debian.org
| Delivery-date: Tue, 24 May 2011 06:14:49 +
| Received: from Debian-exim by vasks.debian.org with local (Exim 4.72)
| id 1QOktF-00048B-BO
| for hert...@vasks.debian.org; Tue, 24 May 2011 06:14:49 +
| Date: Tue, 24 May 2011 06:14:49 +
| Message-Id: 
| X-Failed-Recipients: debian-dpkg-...@lists.debian.org,
|   dpkg_...@packages.qa.debian.org
| Auto-Submitted: auto-replied
| From: Mail Delivery System 
| To: hert...@vasks.debian.org
| Subject: Mail delivery failed: returning message to sender
| 
| This message was created automatically by mail delivery software.
| 
| A message that you sent could not be delivered to one or more of its
| recipients. This is a permanent error. The following address(es) failed:
| 
|   debian-dpkg-...@lists.debian.org
| Mailing to remote domains not supported
|   dpkg_...@packages.qa.debian.org
| Mailing to remote domains not supported

3/ Others have already pointed it out, but I also agree that breaking
git:// or svn:// URLs for anonymous access is not really a good idea.
I don't know the reason for the change but I would be interested to hear it.

I don't know if git or svn supports SRV records, but if they do it would be
great to setup those so that they automatically use the new host.

In general I think it's a good idea to offload anonymous read-only access
so that we have the best performance for commits and similar stuff but
this should be mostly transparent for the user. Having to remember to switch
to "anonscm" is annoying.


Anyway, thank you all for the continued work on Alioth. I know how painful that
can be at times. ;-)


Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110524070912.ga32...@rivendell.home.ouaza.com

Re: Alioth status update, take 3

[Iain Lane]

Hi,

Thanks for improving Alioth :-).

On Mon, May 23, 2011 at 10:35:00PM +0200, Roland Mas wrote:

 Hi again,

 Status update for the Alioth situation:

[...]

 We should now be in the phase where we pretend it's done, wait for the
complaints, and fix the problems as they are reported (or laugh them off
when they come from the too-common expectation that Alioth can be used
to run any random stuff by anyone).


In addition to what has already been mentioned: doesn't look like ldap 
replication is working, so I can't use my shiny new DD account:


  laney@chicken> ssh laney@wagner
  Permission denied (publickey).


Coupled with the missing ACLs this means I can't push to many 
repositories any more.


And, as others have said, please try not to break existing Vcs-* fields, 
including Vcs-Browser.


Cheers,
Iain


signature.asc
Description: Digital signature

Re: Alioth status update, take 3

[Mathieu Malaterre]

On Tue, May 24, 2011 at 12:03 AM, Stig Sandbeck Mathisen  
wrote:
> Francesco Poli  writes:
>
>> I hope that some appropriate re-directions may be set up real soon now,
>> so that previous URLs can continue to work as before...
>
> If you have a specific example of something that does not work, it can
> be fixed.

What is the new link for URL such as:

https://alioth.debian.org/~malat-guest/

Thanks !
-- 
Mathieu


-- 
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/BANLkTi=ps996je0dcuau7ozcrumksrv...@mail.gmail.com

Re: Alioth status update, take 3

[Bernd Zeimetz]

Hi!

Thanks for your work!

On 05/23/2011 10:35 PM, Roland Mas wrote:
>   We should now be in the phase where we pretend it's done, wait for the
> complaints, and fix the problems as they are reported (or laugh them off
> when they come from the too-common expectation that Alioth can be used
> to run any random stuff by anyone).

What happened to the crontabs? I hope that importing upstream's git and
svn repositories into those used for Debian development is not 'random
stuff'.

Cheers,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
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/4ddb5f82.80...@bzed.de

Re: Alioth status update, take 3

[Martin Alfke]

On 05/24/2011 09:27 AM, Mathieu Malaterre wrote:
> On Tue, May 24, 2011 at 12:03 AM, Stig Sandbeck Mathisen  
> wrote:
>> Francesco Poli  writes:
>>
>>> I hope that some appropriate re-directions may be set up real soon now,
>>> so that previous URLs can continue to work as before...
>>
>> If you have a specific example of something that does not work, it can
>> be fixed.
> 
> What is the new link for URL such as:
> 
> https://alioth.debian.org/~malat-guest/
> 
> Thanks !
This one is working:
https://alioth.debian.org/users/malat-guest/


-- 
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/4ddb6002.3000...@gmail.com

Re: Alioth status update, take 3

[Mathieu Malaterre]

On Tue, May 24, 2011 at 9:36 AM, Martin Alfke  wrote:
>> What is the new link for URL such as:
>>
>> https://alioth.debian.org/~malat-guest/
>>
>> Thanks !
> This one is working:
> https://alioth.debian.org/users/malat-guest/

This does not point to my public_html pages. I hosted my gpg
transition document there.

Thanks
-- 
Mathieu


-- 
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/banlktik_zl9jgvpbpox2jazjfxjtapj...@mail.gmail.com

Re: Alioth status update, take 3

[Joachim Breitner]

Hi,

I was traveling, so maybe I was missing it, but I did not find anything
on d-devel-announce: What is the rationale for the reorganization? Did
the old machine break suddently, or was it just too weak to handle the
load?

Am Montag, den 23.05.2011, 22:35 +0200 schrieb Roland Mas:
> - read/write access to the repositories through SSH happen on
>   vasks.debian.org; the repositories have adresses that look like
>   $scm.debian.org/$scm/$project, for $scm in arch bzr cvs darcs git hg
>   svn;
> 
> - anonymous read-only access to the repositories is available by HTTP
>   from wagner, at URLs that look like
>   http://anonscm.debian.org/$scm/$project for $scm in arch bzr darcs git
>   hg;

Is there a way to keep the old, short addresses? 
http://darcs.debian.org/pkg-haskell/haskell-xhtml
is much nicer than
http://anonscm.debian.org/darcs/pkg-haskell/haskell-xhtml
plus the prospect of re-uploading 200 haskell source package to change
the URL is not inviting.

Or would it at least be possible to configure vasks such that 
http://darcs.debian.org/pkg-haskell/haskell-xhtml
gets redirected correclty to 
http://anonscm.debian.org/darcs/pkg-haskell/haskell-xhtml
and not, as it currently is,
http://anonscm.debian.org/pkg-haskell/haskell-xhtml

The Darcs browser link
http://darcs.debian.org/cgi-bin/darcsweb.cgi?r=pkg-haskell/haskell-xhtml
as used in the control files is forwarded correctly, thanks!

Thanks,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Alioth status update, take 3

[Aron Xu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011年05月24日 15:17, Iain Lane wrote:
> 
> In addition to what has already been mentioned: doesn't look like ldap
> replication is working, so I can't use my shiny new DD account:
> [...]
>

Alioth does not use the official password database, so I don't think
directly connect to it would work. New DDs need to request a new
password for their Alioth account. (See Alioth FAQ[1] Section 1.4 & 1.5)

But this does not work either because the account syncing script might
be broken now. When requesting to reset the password, it gives an error
claiming the account does not exist.


[1]http://wiki.debian.org/Alioth/FAQ
- --
Regards,
Aron Xu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN22blAAoJEEmrPP2rYrC43GcIAK5OuZ7RGOCPQKcc/8nNsUgF
ily4wE1Xy0WYLEh1GnHyYRmqCc70MKQcZ3Tewt3h0Qnpjr43sBKzaoXMBDqGlqGK
yvVRADIQPM50pn5fx/h953ZQ4TzoPsJJWXnJZtQAhF63HDjDX42BAB3QcX5JEl6e
iLwsAZ2PJMPRQtmgM/6c2D6daBEC3XYVAAFxTF557uVMH1TaxwlgZuGJOCwGVwgo
GX8DocpAFd2iAbxFzM2rYHlSKLD358tigI2JvtqAGPLiWay2l9HaOV+nMmcne021
+apyH/HDmTST0GTlXAdInyZKey0zX1awtBMbCRXOv5pSYIvi9/Pn/SJqOy+2ihc=
=ZLrK
-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/4ddb66e6.90...@gmail.com

Re: double checking Debian's 686-pae vs. -486 probe

[Ben Hutchings]

On Tue, 2011-05-24 at 07:59 +0800, jida...@jidanni.org wrote:
> Recently Debian sid split the kernel into these two packages,
> 
> linux-image-2.6.39-1-486_2.6.39-1_i386.deb
> linux-image-2.6.39-1-686-pae_2.6.39-1_i386.deb
> 
> My Thinkpad ended up being told by the installation scripts to use -486.
> 
> But my Thinkpad isn't really very old... how can one double check to see
> if the decision was correct? I can't figure it out even after probing
> the .debs to find just where they probe the choice.

The clue is in the name.  And expanded in the description, in case you
don't know what PAE is.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: double checking Debian's 686-pae vs. -486 probe

[jidanni]

> "BH" == Ben Hutchings  writes:

BH> The clue is in the name.  And expanded in the description, in case you
BH> don't know what PAE is.

$ apt-cache show linux-image-2.6.39-1-686-pae|grep Celeron
 supported by the Intel Pentium Pro/II/III/4/4M/D, Xeon, Celeron, Core and

That's me. Celeron.

Odd how whatever script it was told me I had to use -486.

I looked in the preinst and postinst parts of
/var/cache/apt/archives/linux-image-2.6.39-1-686-pae_2.6.39-1_i386.deb
to try to find what probed my Celeron and said it couldn't use 686-pae
and had to use -486, but it  is onebigblack
mystery so sorry.


-- 
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/87ipt0ze1n@jidanni.org

Re: double checking Debian's 686-pae vs. -486 probe

[Josselin Mouette]

Le mardi 24 mai 2011 à 16:41 +0800, jida...@jidanni.org a écrit : 
> > "BH" == Ben Hutchings  writes:
> 
> BH> The clue is in the name.  And expanded in the description, in case you
> BH> don't know what PAE is.
> 
> $ apt-cache show linux-image-2.6.39-1-686-pae|grep Celeron
>  supported by the Intel Pentium Pro/II/III/4/4M/D, Xeon, Celeron, Core and
> 
> That's me. Celeron.
> 
> Odd how whatever script it was told me I had to use -486.

How about trying a “grep pae /proc/cpuinfo” instead of looking for
approximate CPU descriptions?

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


--
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/1306227621.3872.275.camel@pi0307572

Re: double checking Debian's 686-pae vs. -486 probe

[jidanni]

> "JM" == Josselin Mouette  writes:
JM> How about trying a “grep pae /proc/cpuinfo” instead of looking for
JM> approximate CPU descriptions?
And indeed lshw says
  product: Intel(R) Celeron(R) M processor 1.40GHz
  capabilities: fpu fpu_exception wp vme de pse tsc msr mce cx8 sep 
mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts

I.e., no pae.

So I would add "often" in the Description:

 This kernel requires PAE (Physical Address Extension). This feature is 
**often**
 supported by the Intel Pentium Pro/II/III/4/4M/D, Xeon, Celeron, Core and
 Atom; AMD Geode NX, Athlon (K7), Duron, Opteron, Sempron, Turion or
 Phenom; Transmeta Efficeon; and VIA C7.

or "may be" or "often available" or something like that.
Also the -486 Description should mention the name of the -686-pae package.

Say, for the sake of sharing a single .deb offline, what bad thing might
happen if I run the -486 kernel on my other machines where I could run
the -pae kernel? Namely other single Celerons having the pae capability.


--
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/87ei3ozbon@jidanni.org

Re: double checking Debian's 686-pae vs. -486 probe

[Andrey Rahmatullin]

On Tue, May 24, 2011 at 05:32:08PM +0800, jida...@jidanni.org wrote:
> JM> How about trying a “grep pae /proc/cpuinfo” instead of looking for
> JM> approximate CPU descriptions?
> And indeed lshw says
>   product: Intel(R) Celeron(R) M processor 1.40GHz
>   capabilities: fpu fpu_exception wp vme de pse tsc msr mce cx8 sep 
> mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts
> 
> I.e., no pae.
> 
> So I would add "often" in the Description:
Or specifically mention early Centrino CPUs not having PAE support.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: double checking Debian's 686-pae vs. -486 probe

[jidanni]

> "AR" == Andrey Rahmatullin  writes:
AR> Or specifically mention early Centrino CPUs not having PAE support.
Celeron™ too! So just say "may" or "might" like the pros do.


--
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/871uzoz6we@jidanni.org

Re: bug reporting workflow is outdated

[Ian Jackson]

Patrick Strasser writes ("Re: bug reporting workflow is outdated"):
> What is the advantage of having a mail-only BTS reporting mechanism?

The advantage is that no-one can make _other_ user interfaces to bug
submission that we don't want.  (Or at least, they are deterred from
doing so.)

I agree that using http as a transport for reportbug would be fine, in
itself.   But if you read this thread you can see numerous suggestions
that "if we had an http interface we could also do X Y Z".

Apparently, if we don't want X Y Z done then we must resist an http
interface for bug submission even if it makes it hard for reportbug to
work correctly, because it's the thin end of a wedge.  

The fat end is a web form for users to submit bugs.

Ian.


-- 
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/19931.38864.379579.84...@chiark.greenend.org.uk

Bug#627776: ITP: jack-stdio -- JACK audio-port for the UNIX command line

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: jack-stdio
  Version : 1.3+20110408.git709becb
  Upstream Author : Robin Gareus 
* URL : http://rg42.org/oss/jackstdio/start
* License : GPL
  Programming Lang: C
  Description : JACK audio-port for the UNIX command line

 jack-stdout is a small tool that writes JACK audio-sample data to buffered
 standard output. jack-stdin reads raw audio data from standard-input and
 writes it to a JACK audio port.
 .
 By default jack-stdout writes 16 bit signed integer raw audio data (much
 like mpg123 -s at JACK's samplerate, but it can output signed/unsigned
 8/16/24/32 bit integer and 32bit floating-point data, both big/little
 endian.



-- 
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/20110524125745.2716.6336.reportbug@alessio-laptop

Re: [ltp] Re: double checking Debian's 686-pae vs. -486 probe

[Yves-Alexis Perez]

On mar., 2011-05-24 at 09:58 -0300, Stefan Monnier wrote:
> > Say, for the sake of sharing a single .deb offline, what bad thing might
> > happen if I run the -486 kernel on my other machines where I could run
> > the -pae kernel?
> 
> Nothing serious, unless they have a lot of RAM (in which case the kernel
> may not be able to make use of all of it).

And you lose NX too.

Regards,
-- 
Yves-Alexis


-- 
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/1306243091.25324.16.camel@oban

Re: double checking Debian's 686-pae vs. -486 probe

[Adam Borowski]

On Tue, May 24, 2011 at 07:15:29PM +0800, jida...@jidanni.org wrote:
> > "AR" == Andrey Rahmatullin  writes:
> AR> Or specifically mention early Centrino CPUs not having PAE support.
> Celeron™ too! So just say "may" or "might" like the pros do.

Early Celerons do have pae:
(a Pentium 2 class one):
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov 
pse36 mmx fxsr

the one mentioned earlier was a Celeron M.  But in general, Celeron is an
insanely overused brand, it carries no information other than "a crippled
version of a CPU from Intel" as it can come from about any other brand they
make.

I think it might be far easier to list CPUs that do not have pae or might
not have it rather than the other way around.

It appears that at least as Intel is concerned, the only processors >=686
without pae are certain models of Pentium M (and thus relevant Celerons as
well).  Not sure about AMD and the rest.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20110524143454.ga26...@angband.pl

Re: [ltp] Re: double checking Debian's 686-pae vs. -486 probe

[Stefan Monnier]

>> > Say, for the sake of sharing a single .deb offline, what bad thing might
>> > happen if I run the -486 kernel on my other machines where I could run
>> > the -pae kernel?
>> Nothing serious, unless they have a lot of RAM (in which case the kernel
>> may not be able to make use of all of it).
> And you lose NX too.

I wouldn't lose any sleep over it.


Stefan


-- 
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/jwvmxicfauw.fsf-monnier+gmane.linux.hardware.think...@gnu.org

Re: double checking Debian's 686-pae vs. -486 probe

[Samuel Thibault]

Adam Borowski, le Tue 24 May 2011 16:34:55 +0200, a écrit :
> But in general, Celeron is an
> insanely overused brand, it carries no information other than "a crippled
> version of a CPU from Intel" as it can come from about any other brand they
> make.

Indeed.  The name could probably be simply dropped from the list.

Samuel


-- 
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/20110524144824.gg4...@const.bordeaux.inria.fr

Re: bug reporting workflow is outdated

[Patrick Strasser]

schrieb Ian Jackson am 2011-05-24 13:34:
> Patrick Strasser writes ("Re: bug reporting workflow is outdated"):
>> What is the advantage of having a mail-only BTS reporting mechanism?
> 
> The advantage is that no-one can make _other_ user interfaces to bug
> submission that we don't want.  (Or at least, they are deterred from
> doing so.)

Is it about control?
What prevents someone to make an additional tool to report bugs?
In the scope of packages this could for sure managed by some agreement
which tools are supported and recommend or even accepted in Debian.
In a global scope, one can now make a web tool that generates mails to
reportbug.d.o., you can do nothing about it. You could ad some mechanism
to limit bug submissions from such tools on the Debian side.
In the end the situation with some additional transport would not change
at all in this respect.

> I agree that using http as a transport for reportbug would be fine, in
> itself.   But if you read this thread you can see numerous suggestions
> that "if we had an http interface we could also do X Y Z".

Of course that suggestions would be made, and a lot of them would be not
so bad. What's the problem with good ideas?

> Apparently, if we don't want X Y Z done then we must resist an http
> interface for bug submission

I do not see that argument. There is no rule that says that implementing
a requested feature implies a obligation to implement every other
requested feature.

> even if it makes it hard for reportbug to
> work correctly, because it's the thin end of a wedge.

I try hard to read that not as
"We can't make reportbug more usefull, because that means we would end
in implementing a lot of clever things. Lets stay with an limited system
to save the trouble."

One of the greatest features of Debian is its openness for user
contribution. Reportbug should not present a intentional barrier in user
contribution.

> The fat end is a web form for users to submit bugs.

Would that be so bad?

Pros and cons for reportbug HTTP transport:
- You would not get all the meta-info you get with reportbug, like
installed package versions. That is only the case for third-party
reporting tools, not reportbug HTTP transport.
+ You would not rely on email transport alone.
+ Symmetry to the bug database web frontend.
+ HTTP transport is connection orientated, the reporter gets immediately
feedback about his/her submission.
+ No rather complex MTA setup necessary, only proxy setup possibly needed.

Regards

Patrick
-- 
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser 
Student of Telemati_cs_, Techn. University Graz, Austria


-- 
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/irgheu$d1a$1...@dough.gmane.org

Re: bug reporting workflow is outdated

[Sune Vuorela]

On 2011-05-24, Patrick Strasser  wrote:
> Pros and cons for reportbug HTTP transport:

Heh. your pro's is all about the user.
the con is all about the developer.

/Sune
 - who has helped many users with their issues just by the data provided
   by reportbug.


-- 
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/slrnitnjur.p7v.nos...@sshway.ssh.pusling.com

Re: bug reporting workflow is outdated

[Josselin Mouette]

Le mardi 24 mai 2011 à 17:05 +0200, Patrick Strasser a écrit : 
> > The fat end is a web form for users to submit bugs.
> 
> Would that be so bad?

We would get more bug reports.

We already receive more bug reports than we can handle. We need less bug
reports, but more useful ones.

Ergo, putting an entry barrier to reporting bugs is not that silly.

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


--
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/1306252234.3872.325.camel@pi0307572

Packaging cups with cdbs

[Laszlo Papp]

Hi,

I have tried to use the debian/rules that you can see below. My
concern is that I would like to make a test package (for maemo, but
actually should also work for debian) in case of using upstart for
init functionalities.
The problem is that if I try to use a debian/cups.upstart file for
that purpose, it seems to be hard coded. It installs the upstart job
into the /etc/init/ and I cannot customize that path, for instance to
/etc/init/apps/ as I would like to have it. I tried to set the
"--onlyscripts" option in order to hope that it does not generate any
init script/job inside the package and I could just make a workaround
by using postinst.

Other option is to change the whole packaging to "dh" usage. However
if I could just bypass the systemv init script and/or hard coded
upstart job installation, it would be easier for me because I am not a
packager. =)

I am not sure what I am doing wrong, so any help is welcome and thank
you in advance! :)

Best Regards,
Laszlo Papp



#!/usr/bin/make -f
export DH_VERBOSE=1

export LIBTOOL=

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk

PACKAGE_TARGETS :=  $(foreach pkg,$(DEB_ALL_PACKAGES),binary/$(pkg))
$(PACKAGE_TARGETS)::
[ ! -f debian/$(notdir $@).aegis ] || aegis-deb-add -control
debian/$(notdir $@)/DEBIAN/control .. debian/$(notdir $@).aegis=_aegis

DEB_DH_INSTALLINIT_ARGS := --onlyscripts
DEB_MAKE_INSTALL_TARGET := install BUILDROOT=$(DEB_DESTDIR)


Best Regards,
Laszlo Papp


-- 
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/banlktin_re4ne9snzonmubr1-v1smou...@mail.gmail.com

Re: bug reporting workflow is outdated

[Patrick Strasser]

schrieb Josselin Mouette am 2011-05-24 17:50:
> Le mardi 24 mai 2011 à 17:05 +0200, Patrick Strasser a écrit : 
>>> The fat end is a web form for users to submit bugs.
>>
>> Would that be so bad?
> 
> We would get more bug reports.
> 
> We already receive more bug reports than we can handle. We need less bug
> reports, but more useful ones.
> 
> Ergo, putting an entry barrier to reporting bugs is not that silly.

Developing software for a living based on a bug tracking system I know
that dilemma. Too much bugs is not very comfortable. Bug reports are
always of too low quality, I've seen a lot of them.

On the other side if bugs exists I'd want to fix them rather soon than
later. The problems do not go away when you do not look at them.

If it is about quality it needs action to educate users or help them
writing better bug reports. A good bug reporting system helps the
reporter giving information and the developer working with the reports
and solve the problems.

When it comes to the content, you can divide reports in at least feature
request and problems (to avoid the term bug). I consider feature request
or wishlist items not as burden, as long as I can sort them out to get a
clean view at the problems. I personally like feature requests as they
can give you insight in the users perspective of software, and often
enough a new idea.

Having a big number of open bugs is uncomfortable for sure, but I would
not worry about it if most problems are cared for and a lot of feature
requests are in the queue. Would be interesting to see the numbers for
Debian, but I could not find a statistical breakdown of bug severities
in Debian except for RC bugs. Perhaps someone has the numbers...

Artificially throttling bug reports annoys users and makes Debian a
worse OS. If it is hard to report bugs you will only get the reports of
advanced users and only solve problems they can not get around - simple
problems for basic users will persist and bug that users that do not
have the skill to help themselves.
Debian claims to be an universal operating system, for advanced users as
well as for users not skilled in computer technology. Raising a bug
reporting barrier discriminates non-advanced users, which is really a
bad thing - for the users and the makers of Debian.

That said, I know that bugs won't solve themselves. I'd like to help to
reduce the bug count, for example at the reportbug package.

Regards

Patrick
-- 
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser 
Student of Telemati_cs_, Techn. University Graz, Austria


-- 
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/4ddbda82.6000...@tugraz.at

Re: double checking Debian's 686-pae vs. -486 probe

[Ben Hutchings]

On Tue, 2011-05-24 at 17:05 +0600, Andrey Rahmatullin wrote:
> On Tue, May 24, 2011 at 05:32:08PM +0800, jida...@jidanni.org wrote:
> > JM> How about trying a “grep pae /proc/cpuinfo” instead of looking for
> > JM> approximate CPU descriptions?
> > And indeed lshw says
> >   product: Intel(R) Celeron(R) M processor 1.40GHz
> >   capabilities: fpu fpu_exception wp vme de pse tsc msr mce cx8 sep 
> > mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts
> > 
> > I.e., no pae.
> > 
> > So I would add "often" in the Description:
> Or specifically mention early Centrino CPUs not having PAE support.

The Centrino brand refers to a combination of Pentium M, Intel chipset
and approved WLAN adapter which all have good power-saving facilities.
It doesn't refer to a processor.

You are correct that most Pentium M processors do not have PAE (or do
not advertise it in CPU feature flags).  I didn't know some of the
Pentium Ms were also called 'Celeron'; I'll see if I can rephrase the
description accordingly.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: bug reporting workflow is outdated

[Patrick Strasser]

schrieb Sune Vuorela am 2011-05-24 17:33:
> On 2011-05-24, Patrick Strasser  wrote:
>> Pros and cons for reportbug HTTP transport:
> 
> Heh. your pro's is all about the user.
> the con is all about the developer.

1) reportbug is about to enable users to help developers solve problems.
2) To quote myselv:
> That is only the case for third-party
> reporting tools, not reportbug HTTP transport.

Patrick
-- 
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser 
Student of Telemati_cs_, Techn. University Graz, Austria


-- 
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/irgluo$d29$2...@dough.gmane.org

Re: double checking Debian's 686-pae vs. -486 probe

[Goswin von Brederlow]

jida...@jidanni.org writes:

> Say, for the sake of sharing a single .deb offline, what bad thing might
> happen if I run the -486 kernel on my other machines where I could run
> the -pae kernel? Namely other single Celerons having the pae capability.

Nothing happens. You just won't be able to use pae capabilities. Which
means you are limited to ~3.5GiB physical memory.

MfG
Goswin


-- 
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/87vcx0dpwi.fsf@frosties.localnet

Re: double checking Debian's 686-pae vs. -486 probe

[Andrey Rahmatullin]

On Tue, May 24, 2011 at 08:58:43AM -0700, Ben Hutchings wrote:
> > > JM> How about trying a “grep pae /proc/cpuinfo” instead of looking for
> > > JM> approximate CPU descriptions?
> > > And indeed lshw says
> > >   product: Intel(R) Celeron(R) M processor 1.40GHz
> > >   capabilities: fpu fpu_exception wp vme de pse tsc msr mce cx8 
> > > sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts
> > > 
> > > I.e., no pae.
> > > So I would add "often" in the Description:
> > Or specifically mention early Centrino CPUs not having PAE support.
> The Centrino brand refers to a combination of Pentium M, Intel chipset
> and approved WLAN adapter which all have good power-saving facilities.
> It doesn't refer to a processor.
I know, Centrino is just easier to remember than 'Pentium M'.

> You are correct that most Pentium M processors do not have PAE (or do
> not advertise it in CPU feature flags).  I didn't know some of the
> Pentium Ms were also called 'Celeron'; I'll see if I can rephrase the
> description accordingly.
Wikipedia doesn't have it either, But Intel site has:
http://ark.intel.com/ProductCollection.aspx?codeName=1788 (Banias)
http://ark.intel.com/ProductCollection.aspx?codeName=2643 (Dothan; some of
them support PAE, but apparently no Celeron ones)

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Packaging cups with cdbs

[Jonas Smedegaard]

Hi Laszlo,

On 11-05-24 at 07:08pm, Laszlo Papp wrote:
> I have tried to use the debian/rules that you can see below. My 
> concern is that I would like to make a test package (for maemo, but 
> actually should also work for debian) in case of using upstart for 
> init functionalities.
> The problem is that if I try to use a debian/cups.upstart file for
> that purpose, it seems to be hard coded. It installs the upstart job
> into the /etc/init/ and I cannot customize that path, for instance to
> /etc/init/apps/ as I would like to have it. I tried to set the
> "--onlyscripts" option in order to hope that it does not generate any
> init script/job inside the package and I could just make a workaround
> by using postinst.
> 
> Other option is to change the whole packaging to "dh" usage. However
> if I could just bypass the systemv init script and/or hard coded
> upstart job installation, it would be easier for me because I am not a
> packager. =)


Not quite sure what is the central issue of yours here.


CDBS is *not* a tool for beginners to do packaging blind-folded!

I believe (and hope) same is true for short-form dh.


CDBS use (long-form) debhelper tools.  If you experience a sensible 
use-case impossible or awkward to express using CDBS, then please do 
contact us at the [CDBS mailinglist] or file a bugreport against it.

[CDBS mailinglist]: 
http://lists.alioth.debian.org/mailman/listinfo/build-common-hackers


If you know what you are doing but believe there is an issue more 
enerally with how Debian (and debhelper and CDBS) deals with upstart, 
then please isolate the problematic long-form debhelper command instead 
of convoluting in some more specific packaging style.

If you need help packaging in general, then perhaps debian-users or 
debian-mentors are more appropriate than this list.


Kind 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: bug reporting workflow is outdated

[Raphael Hertzog]

On Tue, 24 May 2011, Patrick Strasser wrote:
> Having a big number of open bugs is uncomfortable for sure, but I would
> not worry about it if most problems are cared for and a lot of feature
> requests are in the queue. Would be interesting to see the numbers for
> Debian, but I could not find a statistical breakdown of bug severities
> in Debian except for RC bugs. Perhaps someone has the numbers...

http://qa.debian.org/data/bts/graphs/all.png

So wishlist and minor represent 40% of the open bugs on the BTS.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110524164807.gb27...@rivendell.home.ouaza.com

Re: bug reporting workflow is outdated

[Russ Allbery]

Patrick Strasser  writes:

> Developing software for a living based on a bug tracking system I know
> that dilemma. Too much bugs is not very comfortable. Bug reports are
> always of too low quality, I've seen a lot of them.

Actually, they're not always of too low quality.  Debian bugs tend to be
of considerably higher quality than I see in other projects (like Ubuntu,
for example, where the bug quality is remarkably worse).  And, like Ian, I
think some of that may have to do with Debian's bug reporting system,
although doubtless some of it has to do with the profile of the user
population of the projects.

> On the other side if bugs exists I'd want to fix them rather soon than
> later. The problems do not go away when you do not look at them.

Making it easier to submit bad bug reports means that package maintainers
have to spend more time triaging bad bug reports or ignoring bad bug
reports, which means they have less time to fix good bug reports.  Adding
more bad bug reports will actually make software in Debian worse.  It's
also demoralizing, by taking time way from something that's fun and
productive (dealing with good reports) and draining it into something
that's annoying and tedious (ignoring or triaging bad bug reports).

> If it is about quality it needs action to educate users or help them
> writing better bug reports.

Which also no one has time to do.  But it turns out that not putting up a
public web form to submit bugs is a fairly good proxy for user education.
It doesn't *fix* the problem, but it does weed out a lot of users who
don't know how to file good bug reports (and some users who do, which is
indeed a drawback).

> Having a big number of open bugs is uncomfortable for sure, but I would
> not worry about it if most problems are cared for and a lot of feature
> requests are in the queue.

This is not the case now with the bug reports we already have.  It could
not possibly be the case with even more poor-quality bug reports.

> Artificially throttling bug reports annoys users and makes Debian a
> worse OS.

I agree that it ignores users, but I'm fairly sure that at the moment it's
(minorly) contributing to making Debian a better OS.

> If it is hard to report bugs you will only get the reports of advanced
> users and only solve problems they can not get around - simple problems
> for basic users will persist and bug that users that do not have the
> skill to help themselves.

This isn't my experience.  Debian users seem to be fairly good about
reporting simple problems readily.  I make a point to try to always report
anything that I notice, personally, since I know how to write a good bug
report and can make it useful.  My impression is that lots of others who
work on Debian do the same thing.

The barrier that you're going to face in arguing that Debian should have a
more typical web method of submitting bugs is that Ubuntu, which is a very
similar project with essentially the same targets for bug reporting and
almost entirely the same bugs, did this and the result was a disaster.  So
you have to show how Debian could do this and not end up like Ubuntu.

-- 
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/87oc2sqbqm@windlord.stanford.edu

Re: bug reporting workflow is outdated

[Samuel Thibault]

Raphael Hertzog, le Tue 24 May 2011 18:48:07 +0200, a écrit :
> On Tue, 24 May 2011, Patrick Strasser wrote:
> > Having a big number of open bugs is uncomfortable for sure, but I would
> > not worry about it if most problems are cared for

Even in a lot of teams, problems are not cared for due to missing
workforce.

Samuel


-- 
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/20110524165445.gw4...@const.bordeaux.inria.fr

Re: bug reporting workflow is outdated

[Don Armstrong]

On Tue, 24 May 2011, Patrick Strasser wrote:
> Having a big number of open bugs is uncomfortable for sure,

There are currently 72588 un-done bugs reported by 17692 different
addresses which are maintained by at most 2484 maintainers. (Probably
significantly less.)

> but I would not worry about it if most problems are cared for and a
> lot of feature requests are in the queue. Would be interesting to
> see the numbers for Debian, but I could not find a statistical
> breakdown of bug severities in Debian except for RC bugs. Perhaps
> someone has the numbers...

busoni 16:40:12 /srv/bugs.debian.org/spool$ grep wishlist index.db|wc -l
23924
busoni 16:40:24 /srv/bugs.debian.org/spool$ grep minor index.db|wc -l
8555
busoni 16:40:29 /srv/bugs.debian.org/spool$ grep normal index.db|wc -l
33425
busoni 16:40:32 /srv/bugs.debian.org/spool$ grep important index.db|wc -l
11329
busoni 16:40:37 /srv/bugs.debian.org/spool$ grep serious index.db|wc -l
2473
busoni 16:40:42 /srv/bugs.debian.org/spool$ grep critical index.db|wc -l
80
busoni 16:40:47 /srv/bugs.debian.org/spool$ grep grave index.db|wc -l
554

This all should be more easily available, but see #362457 for one of
the requests regarding it.

> Artificially throttling bug reports annoys users and makes Debian a
> worse OS. If it is hard to report bugs you will only get the reports
> of advanced users and only solve problems they can not get around -
> simple problems for basic users will persist and bug that users that
> do not have the skill to help themselves.

Advanced users report basic bugs too. [And often, they include patches
for them.]

My primary goal is keeping the quality of bug reports high (ideally
increasing their quality) while increasing the ability of individual
developers to handle and deal with bug reports. While making it easier
to report bugs is great, doing that at the expense of quality is not
something that I'm personally willing to do.

If someone has specific feature requests of the BTS, they can be made
by filing wishlist bugs against bugs.debian.org or debbugs after
checking to make sure that the existing request doesn't already exist.
[If it does, feel free to add comments to the existing bug.]


Don Armstrong

-- 
No matter how many instances of white swans we may have observed, this
does not justify the conclusion that all swans are white.
 -- Sir Karl Popper _Logic of Scientific Discovery_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20110524165433.gt30...@rzlab.ucr.edu

Re: double checking Debian's 686-pae vs. -486 probe

[Ben Hutchings]

On Tue, 2011-05-24 at 18:28 +0200, Goswin von Brederlow wrote:
> jida...@jidanni.org writes:
> 
> > Say, for the sake of sharing a single .deb offline, what bad thing might
> > happen if I run the -486 kernel on my other machines where I could run
> > the -pae kernel? Namely other single Celerons having the pae capability.
> 
> Nothing happens. You just won't be able to use pae capabilities. Which
> means you are limited to ~3.5GiB physical memory.

Also no SMP.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: bug reporting workflow is outdated

[Drake Wilson]

Quoth Ian Jackson , on 2011-05-24 12:34:40 
+0100:
> Apparently, if we don't want X Y Z done then we must resist an http
> interface for bug submission even if it makes it hard for reportbug to
> work correctly, because it's the thin end of a wedge.  
> 
> The fat end is a web form for users to submit bugs.

Just to link this to a Place of Community Patterns: you and some of
the others seem to be describing a PricklyHedge.

http://meatballwiki.org/wiki/PricklyHedge

> Ian.

   ---> Drake Wilson


-- 
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/20110524170935.GA15144@stingray.internal

Re: Packaging cups with cdbs

[Steve Langasek]

Hi Laszlo,

On Tue, May 24, 2011 at 07:08:22PM +0300, Laszlo Papp wrote:
> I have tried to use the debian/rules that you can see below. My
> concern is that I would like to make a test package (for maemo, but
> actually should also work for debian) in case of using upstart for
> init functionalities.
> The problem is that if I try to use a debian/cups.upstart file for
> that purpose, it seems to be hard coded. It installs the upstart job
> into the /etc/init/ and I cannot customize that path, for instance to
> /etc/init/apps/ as I would like to have it. I tried to set the
> "--onlyscripts" option in order to hope that it does not generate any
> init script/job inside the package and I could just make a workaround
> by using postinst.

It installs it to /etc/init because this is the upstream path for upstart
jobs.  There is no dh_installinit implementation that knows about this
maemo-specific /etc/init/apps/ path.

You could patch dh_installinit to do this in a maemo context, or you could
pass DEB_DH_INSTALLINIT_ARGS=--name=nonexistent to force dh_installinit to
only look for debian/cups.nonexistent.upstart.

> Other option is to change the whole packaging to "dh" usage. However
> if I could just bypass the systemv init script and/or hard coded
> upstart job installation, it would be easier for me because I am not a
> packager. =)

With dh the solution is certainly more easily discoverable and less
convoluted; you can override dh_installinit with a simple rule:

override_dh_installinit:
$stuff_to_manually_install_to_etc_init_apps


-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Alioth status update, take 3

[Julien Valroff]

Le lundi 23 mai 2011 à 22:35:00 (+0200 CEST), Roland Mas a écrit :
>   We should now be in the phase where we pretend it's done, wait for the
> complaints, and fix the problems as they are reported (or laugh them off
> when they come from the too-common expectation that Alioth can be used
> to run any random stuff by anyone).

It seems DDs haven't (yet?) been added to the collab-maint group, am I
right?

Cheers,
Julien

-- 
  .''`.   Julien Valroff ~  ~ 
 : :'  :  Debian Developer & Free software contributor
 `. `'`   http://www.kirya.net/
   `- 4096R/ E1D8 5796 8214 4687 E416  948C 859F EF67 258E 26B1


signature.asc
Description: Digital signature

Re: Packaging cups with cdbs

[Laszlo Papp]

Hi Steve,

On Tue, May 24, 2011 at 8:11 PM, Steve Langasek  wrote:
> Hi Laszlo,
>
> On Tue, May 24, 2011 at 07:08:22PM +0300, Laszlo Papp wrote:
>> I have tried to use the debian/rules that you can see below. My
>> concern is that I would like to make a test package (for maemo, but
>> actually should also work for debian) in case of using upstart for
>> init functionalities.
>> The problem is that if I try to use a debian/cups.upstart file for
>> that purpose, it seems to be hard coded. It installs the upstart job
>> into the /etc/init/ and I cannot customize that path, for instance to
>> /etc/init/apps/ as I would like to have it. I tried to set the
>> "--onlyscripts" option in order to hope that it does not generate any
>> init script/job inside the package and I could just make a workaround
>> by using postinst.
>
> It installs it to /etc/init because this is the upstream path for upstart
> jobs.  There is no dh_installinit implementation that knows about this
> maemo-specific /etc/init/apps/ path.

It is actually not maemo specific feature, it is more like a general
customization. (which seems to be missing from the dh_installinit
implementation right now).

>From the man page of that:
   -o, --onlyscripts
   Only modify postinst/postrm/prerm scripts, do not actually
install any init script, default files, or upstart job.  May be useful
if the init script or upstart job is shipped and/or installed by
upstream in a
   way that doesn't make it easy to let dh_installinit find it.

   If no upstart job file is installed in the target directory
when dh_installinit --onlyscripts is called, this program will assume
that an init script is being installed and not provide the
compatibility symlinks
   or upstart dependencies.

I thought it should eliminate the installation and I could do it
"manually" from the postinst script.

> You could patch dh_installinit to do this in a maemo context, or you could
> pass DEB_DH_INSTALLINIT_ARGS=--name=nonexistent to force dh_installinit to
> only look for debian/cups.nonexistent.upstart.

I have also tried this option, but I still get the /etc/init.d/cups
file somehow. :o I am not sure what I am doing wrong.
I hoped either this option you mentioned, or the "-o" should help to
not install anything, not /etc/init.d/cups either. It might well be, I
have just made some dumb mistake and it should work however. Anyway,
it would be nice if the installation path could be customizable in
case of the cdbs usage.

If nothing works, I think it is time to start thinking of the
debhelper usage, but I do still hope I did something wrong or I missed
something.

Thank you for your answer !

Best Regards,
Laszlo Papp


--
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/BANLkTinF=QDhE_vUSLOhZLoaR=m=vt1...@mail.gmail.com

Getting good bug reports

[Patrick Strasser]

schrieb Russ Allbery on 2011-05-24 18:55:
> Patrick Strasser  writes:

First, I want to emphasize that I do not at all advocate for a web
reporting form. IMO most contributors to this thread do so.

I regard the overall process of reporting bugs in Debian very sensible,
no need to change in general.

I see three issues mixed up here:
1) Web bug reporting facility, ala Ubuntu Launchpad
2) Helping reports writing high quality bug reports
3) Improving reportbug to mitigate bug report drafts that end up in /tmp

> Debian bugs tend to be
> of considerably higher quality than I see in other projects (like Ubuntu,
> for example, where the bug quality is remarkably worse).  And, like Ian, I
> think some of that may have to do with Debian's bug reporting system,

That's about point 1). Again, I do not think that a web-based bug submit
front end would help to improve the situation.

>> If it is about quality it needs action to educate users or help them
>> writing better bug reports.
> 
> Which also no one has time to do.  But it turns out that not putting up a
> public web form to submit bugs is a fairly good proxy for user education.
> It doesn't *fix* the problem, but it does weed out a lot of users who
> don't know how to file good bug reports (and some users who do, which is
> indeed a drawback).

Point 2). I do not think about going out and teaching people to report
bugs. I rather think of some helping questions and information for bug
reporting newbies. I usually recommend people to read Eric S. Raymond's
"How To Ask Questions The Smart Way". reportbug tries hard to collect
good information, I think it could improve in helping reports writing
good bug reports.

>> If it is hard to report bugs you will only get the reports of advanced
>> users and only solve problems they can not get around
> 
> This isn't my experience.  Debian users seem to be fairly good about
> reporting simple problems readily.

Point 3). Still it's too hard for a real novice which would like to help
to get a bug report not at all out. The starting suggestion for this
thread was to add an HTTP based transport path to get around the MTA
thing. In the mid 90ies I was starting with a dial up connection, which
was expensive, and I was glad that I could queue my outgoing mail and
have them shipped together. I needed a working MTA in my box. Nowadays
for me there's no point in having a non-local MTA, I have DSL and alway
access to my ISPs mail transport system, which means I have direct
access to BTS.

I just second the proposal to have a backup to the mail transport in
form of a HTTP or some other direct connection transport. Nothing more.
Mail is fine, having a backup is even better.

Regards

Patrick

[1] http://www.catb.org/~esr/faqs/smart-questions.html
-- 
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser 
Student of Telemati_cs_, Techn. University Graz, Austria


-- 
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/irh0mf$tq4$2...@dough.gmane.org

Bug#627829: ITP: haskell-qt -- Qt bindings for the Haskell language

[Filip Brcic]

Package: wnpp
Severity: wishlist
Owner: Filip Brcic 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: haskell-qt
  Version : 1.1.4.1
  Upstream Author : David Harley 
* URL : http://qthaskell.berlios.de/
* License : BSD
  Programming Lang: Haskell, C++
  Description : Qt bindings for the Haskell language

qtHaskell is a set of Haskell bindings for the Qt Widget Library from
Nokia. Haskell programmers can now access the Qt "Signals and Slots"
interface logic, design interfaces using Qt Designer and write
scripted applications using the Qt ECMA/Javascript engine.

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

iQIcBAEBAgAGBQJN3AvbAAoJEPH9x+slN8N5UtoQAJA40L8VaMddRyWRDyl4FVY6
Re0/80L6piHrNsN9iunnb6/dp2jQ86sn4CRvrciaoS1VrsPaxSvW25o3e1GL2H4N
dsfVW5JhgeLSpeY4wOyXqwotOLjtJyuPf+J5XNmirE9E3sRKCyruAXhbYHwkrYba
wxUwTO0IchppzDVcmxYpXQu0j3LiW4IXOWblrqsEmxPGAT/MpU8dP5g6EnwUsVID
h7Rogp94NmfgJ416ApZ5Q9rvR0rTcoDSckM3ZzAqFng+ME/jwW+3RzXzXdEM9wga
HhQwDdYbVo8PlvePjbTA3hfcddpE4bD3/SMFYs6xDm6GHg/nukSo1Wv/9D2uGbtS
QNMHcw6blsquLcOQRq+0B4uhaG+8JwHvNp4qj917rTwbWoXE3lYRcf7tLts/D3EH
wCPER6XTcAwI7O7QlX8ls4d2rc+kQkkiZHy5nXpDYvQbsdQbz8ZBM4VXcsDsqwnl
eYMHxKOXzVR32MgAyXlCTbiqs1QqEtZikznj40RfLW/DYEEp248a2gx3JG9gERSL
83VjsCf/oBhnwn4Zgi1+23hvYUw/Lq9IjvpL1dfUikMtE5OLWyewETyGw3Dj9hK5
bm+HnIzrTHeD8q6mzMW+o8alTnQK8bmTVHOMoZ5cSXkDfVW5PBzAeVRuQmC1PxWj
GQhE8PZpfHZhxQ5kzMwb
=a5A3
-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/20110524194951.25778.93805.reportbug@perun

Re: Alioth status update, take 3

[Tollef Fog Heen]

]] Russ Allbery 

| windlord:~/tmp> debcheckout libpam-krb5
| declared git repository at git://git.debian.org/git/pkg-k5-afs/pam-krb5.git
| git clone git://git.debian.org/git/pkg-k5-afs/pam-krb5.git libpam-krb5 ...
| Cloning into libpam-krb5...
| git.debian.org[0: 217.196.43.140]: errno=Connection refused
| fatal: unable to connect a socket (Connection refused)
| checkout failed (the command above returned a non-zero exit code)

Yeah, this is a bit bad.  It seems neither git nor svn supports SRV
records so I've set up proxying of svn and git for now.  (That «for now»
means I'll likely turn it off once we have a stable release that
supports SRV records.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/87boyrrfvp@qurzaw.varnish-software.com

Re: new scripts and patches for devscripts

[Benjamin Drung]

Am Samstag, den 21.05.2011, 21:41 +0200 schrieb Tshepang Lekhonkhobe:
> On Thu, 2011-03-10 at 00:26 +0100, Benjamin Drung wrote:
> > Am Mittwoch, den 09.03.2011, 12:26 -0500 schrieb James Vega:
> > > On Tue, Mar 8, 2011 at 7:12 PM, Benjamin Drung  wrote:
> > > > Am Mittwoch, den 09.03.2011, 00:05 + schrieb Roger Leigh:
> > > >> On Tue, Mar 08, 2011 at 11:01:12PM +0100, Benjamin Drung wrote:
> > > >> > Should these script moved from ubuntu-dev-tools into devscripts?
> > > >> >
> > > >> > Most of the script are written in Python. Rewriting them to get them
> > > >> > included in devscripts is too much work without benefit. devscripts
> > > >> > would depend on python then.
> > > >>
> > > >> Most of the scripts are short.  Rewriting would be fairly simple, and
> > > >> may be beneficial in removing the Ubuntu-specific bits.
> > > >
> > > > What speaks against having these script in python? Is python too heavy
> > > > for a _development_ machine?
> > > 
> > > It's not just about a package dependency.  It's more about restricting
> > > the knowledge base required for those maintaining the package.
> > > 
> > > Considering that scripts are contributed to devscripts and the support
> > > burden is then commonly left on the shoulders of those maintaining
> > > devscripts instead of the original script author, it's in our interest
> > > to maintain a consistent set of languages that we are willing to
> > > support.  This is currently Perl and shell.
> > > 
> > > So yes, IMO, accepting scripts written in Python (or any other language)
> > > is too heavy.  Not for a "_development_ machine", but for a maintenance
> > > team.  If people choose to ignore our requirement and develop scripts in
> > > other languages, then they can deal with the consequences.
> > 
> > Stefano Rivera (stefanor) and I offer to maintain the Python scripts in
> > devscripts. Is it enough to have at two DDs to support Python?
> 
> Has this issue been resolved? Has this question been answered by
> devscripts maintainers?

We managed to alleviate the concerns / weaken the resistance. The two
Python scripts suspicious-source and wrap-and-sort landed in the
devscripts git master branch and will be included in the upcoming
upload.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

MERAIH REJEKI LEWAT INFAQ DAN SEDEKAH DENGAN IKHLAS DAN JUJUR

[Eva Syariefs]

--
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/RIZKY1058f67aa650140e7913cdb04abb6d337@rizky1

Re: Alioth status update, take 3

[Francesco Poli]

On Tue, 24 May 2011 00:03:13 +0200 Stig Sandbeck Mathisen wrote:

> Francesco Poli  writes:
> 
> > I hope that some appropriate re-directions may be set up real soon now,
> > so that previous URLs can continue to work as before...
> 
> If you have a specific example of something that does not work, it can
> be fixed.

Sure:

  $ grep '^Package\|^Vcs' debian/control 
  Vcs-Git: git://git.debian.org/git/apt-listbugs/apt-listbugs.git
  Vcs-Browser: http://git.debian.org/?p=apt-listbugs/apt-listbugs.git
  Package: apt-listbugs
  $ cd ~/tmp/TEST/
  $ git clone git://git.debian.org/git/apt-listbugs/apt-listbugs.git
  Cloning into apt-listbugs...
  git.debian.org[0: 217.196.43.140]: errno=Connection refused
  fatal: unable to connect a socket (Connection refused)

The Vcs-Git URL has not worked as before for a while.
Now it seems to work again: thanks for fixing this up!   :-)

The Vcs-Browser URL
http://git.debian.org/?p=apt-listbugs/apt-listbugs.git
seems to redirect to
http://anonscm.debian.org/gitweb/?p=apt-listbugs/apt-listbugs.git
when opened in a web browser.
However the gitweb interface seems to have lost its fancy style sheet
that used to be consistent with the Debian web site
http://www.debian.org/

I haven't yet tried to push to the following remote:
ssh://git.debian.org/git/apt-listbugs/apt-listbugs.git
which was what I used to push to.
I am a bit uneasy in trying to push: would I break anything, if the URL
were wrong?
Can you confirm that this URL should work as before?
With which host key?
The one for vasks.debian.org, which was previously announced in
http://lists.debian.org/debian-devel-announce/2011/05/msg7.html
?



-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpz8AC7aL300.pgp
Description: PGP signature

Re: double checking Debian's 686-pae vs. -486 probe

[jidanni]

Ah,
http://en.wikipedia.org/wiki/NX_bit
http://en.wikipedia.org/wiki/Physical_Address_Extension
http://en.wikipedia.org/wiki/Symmetric_multiprocessing
you know I am learning more and more from you fellows every day.

I have some specific recommendations: forget about listing individual
brands, just say "available in many newer CPUs, check your /proc/cpuinfo" .

> Nothing happens. You just won't be able to use pae capabilities. Which
> means you are limited to ~3.5GiB physical memory.
BH> Also no SMP.
> Nor NX.
Excellent to know. Do mention that on the Description.
Knowing that I can now switch my sneakernet to a pure -486
implementation, as I won't be missing a thing.
3.5GiBs of physical memory? They're not as cheap as gum sticks,
you know. Speaking of which,
http://www.youtube.com/user/jidanni2#p/c/6E40919035151385/10/hB2b3Ce5op0


-- 
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/8739k3ve3m@jidanni.org

Re: Getting good bug reports

[Brian May]

On 25 May 2011 05:25, Patrick Strasser  wrote:

> Point 3). Still it's too hard for a real novice which would like to help
> to get a bug report not at all out. The starting suggestion for this
> thread was to add an HTTP based transport path to get around the MTA
> thing. In the mid 90ies I was starting with a dial up connection, which
> was expensive, and I was glad that I could queue my outgoing mail and
> have them shipped together. I needed a working MTA in my box. Nowadays
> for me there's no point in having a non-local MTA, I have DSL and alway
> access to my ISPs mail transport system, which means I have direct
> access to BTS.
>
> I just second the proposal to have a backup to the mail transport in
> form of a HTTP or some other direct connection transport. Nothing more.
> Mail is fine, having a backup is even better.
>
>
Personally I have many Debian desktops and servers under my control. Some of
them on private networks without public FQDN. Some of them laptops, which
never plugged into the same network, and as such need a different SMTP setup
everytime. Some don't even have Internet access.

It is impossible for me to recall which ones have working MTAs, working
reportbug SMTP configurations, etc. reportbug needs to be run from the
system that encountered the problem or it will generate bad debugging
information. When I encounter a bug somewhere, if I get side tracked trying
to test my MTA setup on a system that never sends emails under normal
conditions, I will run out of time to fill a quality bug report. Or maybe
the bug is with the MTA I am trying to configure.

It has happened that I have submitted quality bug reports, only to find they
go down a black hole, never to be seen again. The fact the BTS takes a while
to respond doesn't help. Sure, maybe this was due to an invalid From address
or something, would rather focus on submitting a good quality bug report
rather then debug my MTA setup for a computer that normally never sends
email however.

As a result, I often end up sending bug reports by hand, using my email
client.

Also a good quality web interface gives immediate feedback that (a) the
command has been processed, (b) validates the command immediately and (c)
outputs the results of the command. None of this resubmitting email after
email after email (with considerable delay between each email waiting
response) to cont...@bugs.debian.org trying to get a simple reassign command
to do the right thing.

Sure, maybe if you are a heavy user of the BTS, these issues won't apply; as
a light/occasional user however I find I am spending more time trying to use
the BTS then being able to file/manipulate bugs in the BTS.
-- 
Brian May 

Vēdera prese. Nostiprini. Esi sexy! ok?

[Cepuks Imants]

Pārliecinošs sporta uzturs no labākajiem Amerikas ražotājiem! 

Tas ir sporta uzturs drošiem sasniegumiem. Turklāt par ļoti labām cenām! 

meklē to visu tajā vietā:  http://www.tavisasniegumi.info




-- 
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/201105250053.p4p0r0rz073...@nts.novoch.ru

Bug#627876: ITP: liblilv-1 -- Lightweight LV2 Host library

[Jeremy Salwen]

Package: wnpp
Severity: wishlist
Owner: Jeremy Salwen 


* Package name: liblilv-1
  Version : 0.4.0
  Upstream Author : David Robillard 
* URL : http://drobilla.net/software/lilv/
* License : ISC License
  Programming Lang: C
  Description : Lightweight LV2 Host library

Lilv is a library to make the use of LV2 plugins as simple as possible 
for applications. Lilv is the successor to SLV2, rewritten to be 
significantly faster and have minimal dependencies.



-- 
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/20110525063340.31829.87106.reportbug@localhost.localdomain