Re: Announcing debtags.debian.net

[Andreas Tille]

Hi Enrico,

thanks for the rewrite!

I did not tested everything but I think I dectected a small
inconsistency compared to former behaviour.  On the Blends pages I'm
using links to debtags like:

   http://debtags.alioth.debian.org/edit.html?pkg=gbrowse

which is rewritten to

   http://debtags.debian.net/edit/gbrowse/

which is not found.  You rather need to remove the '/' in the end of
this URL.  I could very easily change the link on the Blends pages to

   http://debtags.debian.net/edit/

if I can trust that this will be the proper URL for the future. 

Otherwise I would like you to adapt the URL rewriting mechanism to
work as before.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/20120107090340.gb4...@an3as.eu

Re: Providing a dummy web server package in Debian (Removing web server dependencies from web apps)

[Stefano Zacchiroli]

On Fri, Jan 06, 2012 at 08:20:23PM +0100, Arno Töll wrote:
> The overall benefit over our virtual package system, possibly in
> addition to equivs seems flexible enough. Why do we tailor incomplete
> special case solutions instead of recommending equivs more popularly?
> 
> I say incomplete, because similar use cases exist for different package
> groups - e.g. think of mail servers and database servers. Do we really
> want dummy packages for each group of alternatives?
> 
> On the other hand, we have a perfect solution which apparently only
> needs some more propaganda if even developer don't know it.

You surely have a point here.

At the same time to use equivs one needs to step out of the package
manager interface, which is the most well known interface to install
Debian packages. And is precisely while you're installing packages that
you get (apparently) stuck on the need of a package called
"apache2-mpm-prefork" or "mysql-server-5.1".

I agree we should advertise equivs more as it is the most flexible
solution. But until it is discoverable from (not to mention integrated
with) package managers, I doubt we can make a dent in the number of
people who will get stuck with this.

All in all, having *some* dummy packages in the archive to fulfill
dependencies in non standard setups would cost us very little and save
quite some time for our power users.  It will also have the extra
benefit that we keep a tighter control on the existence of such dummy
packages and on their naming, instead of having tons of equivs generated
packages on user machines with random versioning scheme.  This aspect
will make easier actions such as removing those packages in future
Debian releases, when we find a better solution.

Copying -webapps, as this discussion should probably continue there.

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: [Long] UEFI support

[Tanguy Ortolo]

Steve Langasek, 2012-01-07 01:08+0100:
>> It is also worth noting that an amd64 PC will probably support x64 UEFI
>> only, so given that there is probably no UEFI-base x86 PCs, there is no
>> point in creating corresponding images.
> 
> Your terminology is a bit muddled here.  If you mean "there will be no
> 32-bit-only systems using UEFI", that's not a safe assumption to make. 
> There are still 32-bit-only systems being produced, and the move from BIOS
> to UEFI will affect them as well.

This is possible indeed, but I am not sure. What kind of systems are
these exactly, before we can draw any conclusion?

-- 
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer
 \_


-- 
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/je95pv$8a8$1...@dough.gmane.org

Re: Removing web server dependencies from web apps

[Bastian Blank]

On Fri, Jan 06, 2012 at 03:19:21PM +0100, Mathieu Parent wrote:
> Because ruby has an embedded web server (webrick), so it doesn't
> require one (but it is better for performance and more).

PHP also got one recently.

Bastian

-- 
Change is the essential process of all existence.
-- Spock, "Let That Be Your Last Battlefield", stardate 5730.2


-- 
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/20120107113424.gb6...@wavehammer.waldi.eu.org

Bug#654964: ITP: shelxle -- graphical user interface for SHELXL

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Debichem Team 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: shelxle
  Version : 1.0.513
  Upstream Author : Christian B. Huebschle 
* URL : http://ewald.ac.chemie.uni-goettingen.de/shelx/
* License : LGPL-2.0+
  Programming Lang: C++
  Description : graphical user interface for SHELXL

ShelXle combines an editor with syntax highlighting for the
SHELXL-associated .ins (input) and .res (output) files with an interactive
graphical display for visualization of a three-dimensional structure including
the electron density (Fo) and difference density (Fo-Fc) maps.


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

iEYEARECAAYFAk8IMCoACgkQm0bx+wiPa4zs8wCfZIzhRKuxDTMQIIUx03l08scG
928AoMDOoD6nZNfGwLw6JKjc+oMuQgCH
=xftp
-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/20120107114448.6751.56323.reportbug@localhost

Re: Bug#654896: ITP: xul-ext-debianbuttons -- Buttons for querying Debian-related pages with Iceweasel/Firefox

[Adam Borowski]

On Fri, Jan 06, 2012 at 05:32:20PM +0100, Tanguy Ortolo wrote:
> * Package name: xul-ext-debianbuttons
> * URL : https://addons.mozilla.org/firefox/addon/debian-buttons/
>   Description : Buttons for querying Debian-related pages with 
> Iceweasel/Firefox
> 
> Debian buttons is an extension that provides three new buttons for quick
> access to information about Debian package or bug report on the web
> using text from the X11 clipboard.

What's exactly the point of this extension?

It appears to do exactly nothing a simple keyword can't do.
Even in bare Firefox, you make a bookmark with URL http://bugs.debian.org/%s
and keyword "bts", then typing "bts 654896" or "bts bash" gets you there.
And keywords don't take up screen space a series of buttons does.

-- 
1KB // Yo momma uses IPv4!


-- 
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/20120107120228.ga2...@angband.pl

Re: Bug#654896: ITP: xul-ext-debianbuttons -- Buttons for querying Debian-related pages with Iceweasel/Firefox

[Neil Williams]

On Sat, 7 Jan 2012 13:02:28 +0100
Adam Borowski  wrote:

> On Fri, Jan 06, 2012 at 05:32:20PM +0100, Tanguy Ortolo wrote:
> > * Package name: xul-ext-debianbuttons
> > * URL : https://addons.mozilla.org/firefox/addon/debian-buttons/
> >   Description : Buttons for querying Debian-related pages with 
> > Iceweasel/Firefox
> > 
> > Debian buttons is an extension that provides three new buttons for quick
> > access to information about Debian package or bug report on the web
> > using text from the X11 clipboard.
> 
> What's exactly the point of this extension?
> 
> It appears to do exactly nothing a simple keyword can't do.
> Even in bare Firefox, you make a bookmark with URL http://bugs.debian.org/%s
> and keyword "bts", then typing "bts 654896" or "bts bash" gets you there.
> And keywords don't take up screen space a series of buttons does.

Actually, I use epiphany precisely because it does this and
iceweasel does not. Epiphany can provide a toolbar with multiple buttons
with a text entry box next to each one because that means I can put a
number into the box via the middle mouse button and go straight to the
page, no messing with the address bar or having to clear previous stuff
or getting mixed in with the usually unhelpful search help which usually
covers the bit of the screen I want to see... and the button itself
still works as a plain bookmark button. Just what I need.

Browsing experiences and browsing requirements vary enormously. Don't
assume that you would use any package in the way that others would want
to use it.

The three buttons I always end up adding to any epiphany install are
PTS, BTS and Wiki. I find them particularly useful during a release
freeze to get a quick handle on packages with RC bugs. If iceweasel had
the same functionality, it would be better if it was adaptable to a
wide range of other queries but I'd still use it. I also end up adding
ones for ticket numbers and changeset numbers at work and a variety of
others. I don't care if this functionality is available via the address
bar, that's too awkward and requires actions prior to entering the
query data. Just a simple text entry box, ready and waiting is much
better.

Personally, I'd welcome a fix from the epiphany maintainers to
add a Debian toolbar with these buttons already assigned but I'm not
sure if it's sufficiently popular to warrant a wishlist bug.

-- 


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



pgpEcg18eIBik.pgp
Description: PGP signature

Re: Removing web server dependencies from web apps

[Tzafrir Cohen]

On Sat, Jan 07, 2012 at 12:34:24PM +0100, Bastian Blank wrote:
> On Fri, Jan 06, 2012 at 03:19:21PM +0100, Mathieu Parent wrote:
> > Because ruby has an embedded web server (webrick), so it doesn't
> > require one (but it is better for performance and more).
> 
> PHP also got one recently.

Right. But for redmine and trac (the other example mentioned) using the
built-in server is a common and well-supported configuration. Does the
package of, say, wordpress, explain how to use that built-in web server?

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend


-- 
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/20120107131735.gb8...@pear.tzafrir.org.il

Bug#654970: ITP: drwright -- Known as typing break in GNOME 2

[Savvas Radevic]

Package: wnpp
Severity: wishlist
Owner: Savvas Radevic 


* Package name: drwright
  Version : 3.2.3
  Upstream Author : Richard Hult 
* URL : http://git.gnome.org/browse/drwright
* License : GPL-2.0+
  Programming Lang: C, Python (I think)
  Description : Known as typing break in GNOME 2

 Typing monitor to force typing breaks. It's a GNOME 3 tool that forces you to 
 take regular breaks to prevent RSI (Repetitive Strain Injury).
 .
 It can be found in GNOME control center as "typing break".



-- 
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/20120107133950.GA19602@savvas-desktop

Re: Bug#654896: ITP: xul-ext-debianbuttons -- Buttons for querying Debian-related pages with Iceweasel/Firefox

[Tanguy Ortolo]

Adam Borowski, 2012-01-07 13:02+0100:
> It appears to do exactly nothing a simple keyword can't do.

That is correct, but it does not mean it is not useful.

Assuming you put a bug number into the clipboard, for instance by
double-clicking it on some IRC channel, let us compare:
* in both case, you go to your browser;
* with a keyword:
  - you search for the appropriate search plugin, install it and program
the keywork (only the first time),
  - you type ^L to go to the address bar,
  - you type “bts ”,
  - you move your mouse to the address bar and middle-click,
  - you type ↵;
* with a button:
  - you search for the appropriate extension, install it and place the
buttons (only the first time),
  - you move your mouse to it and left-click.

You might prefer the first way, but not everybody does, so these buttons
may still be useful for some people. Actually, they will for at least
one person, myself. :-)

By the way, the BTS button seems to have one nice feature: it works even
for texts such as “#4212”, whereas with a keywork it may be necessary to
remove the hash sign first.

-- 
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer
 \_


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

Re: Bug#654896: ITP: xul-ext-debianbuttons -- Buttons for querying Debian-related pages with Iceweasel/Firefox

[Adam Borowski]

On Sat, Jan 07, 2012 at 02:03:56PM +, Tanguy Ortolo wrote:
> Adam Borowski, 2012-01-07 13:02+0100:
> > It appears to do exactly nothing a simple keyword can't do.
> 
> That is correct, but it does not mean it is not useful.
> 
> Assuming you put a bug number into the clipboard, for instance by
> double-clicking it on some IRC channel, let us compare:
> * in both case, you go to your browser;
> * with a keyword:
>   - you search for the appropriate search plugin, install it and program
> the keywork (only the first time),

There's no "search plugin" needed.

In fact, keywords make the whole search bar redundant, it's kept only for
marketing purposes (as Mozilla gets most of its income from Google) and for
beginner users.  It's faster to type "g foo bar baz" (since you're already
typing) or "wp MAFIAA" instead of having to both select a search plugin and
type in (or paste) the query.

And if you prefer to use several mouse clicks instead of several keyclicks,
defining a search does the same thing as this extension without taking up
extra interface space.

> * with a button:
>   - you search for the appropriate extension, install it and place the
> buttons (only the first time),
>   - you move your mouse to it and left-click.

This works only if the query never comes from any other source than the
clipboard.  A bug number tends to be pasted, package names not really.  And
often you want to prepend "src:", something that can't be done easily in the
clipboard.

> You might prefer the first way, but not everybody does, so these buttons
> may still be useful for some people. Actually, they will for at least
> one person, myself. :-)

Hey, I'm not someone to protest having more features -- doing that leaves
you with such abominations as Gnome3.  I'm just pointing out a away that
(to me) appears more convenient and greatly more generic, while requiring no
extra package.

-- 
1KB // Yo momma uses IPv4!


-- 
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/20120107142122.ga4...@angband.pl

Re: Bug#654896: ITP: xul-ext-debianbuttons -- Buttons for querying Debian-related pages with Iceweasel/Firefox

[Paul Wise]

On Sat, Jan 7, 2012 at 8:22 PM, Neil Williams wrote:

> Actually, I use epiphany precisely because it does this and
> iceweasel does not. Epiphany can provide a toolbar with multiple buttons
> with a text entry box next to each one because that means I can put a
> number into the box via the middle mouse button and go straight to the
> page, no messing with the address bar or having to clear previous stuff
> or getting mixed in with the usually unhelpful search help which usually
> covers the bit of the screen I want to see... and the button itself
> still works as a plain bookmark button. Just what I need.

When I switched from galeon I also wanted galeon style smart bookmarks
and had to reimplement them as a hard-coded extension:

http://bonedaddy.net/pabs3/log/2011/11/04/migrate-from-galeon-to-iceweasel-firefox/

I would love it if I could replicate my galeon smart bookmarks
experience in iceweasel but I couldn't find any extensions to do that.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6EZDKPnweMNpriL4NywHigMbg=p1kj89muq8qd9cui...@mail.gmail.com

Re: Removing web server dependencies from web apps

[Tollef Fog Heen]

]] Daniel Baumann 

> it's not policy incompliant if e.g. php5 would install
> /etc/apache2/sites-enabled/whatever containing a virtualhost definition.
> the reason why nobody would do that, is, that it's just wrong and
> unreasonable to do such a thing (where e.g. aliases and directory
> directives are a reasonable thing to do for a web application).

Having, say, mediawiki, ask using debconf if you would like a vhost set
up with the host name wiki.$domain would be completely sane, IMO.  If
you don't want it, just tell the config script no.

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

Re: bits from the DPL for December 2011

[Lior Kaplan]

On Sat, Jan 7, 2012 at 6:17 PM, Stefano Zacchiroli wrote:

> Auditor work ramping up
> ---
>
> We've almost always been struggling for transparency in Debian budgets.
> The money dealings we do at SPI are quite visible, but other assets, as
> well as money hosted at other trusted organizations, are too scattered
> and not always as accessible as they should. ... which is close to
> unacceptable for a project soliciting donations.  Historically, we've
> always had trouble finding people capable and willing to work on
> non-technical stuff, and accounting / auditing work is a perfect example
> of that.
>

I'll be happy to help if needed. I'm already doing accounting the Israeli
free software association.

Kaplan

p.s.
I'm not a professional accountant, just willing to help (:

Re: Removing web server dependencies from web apps

[Russ Allbery]

Tollef Fog Heen  writes:
> ]] Daniel Baumann 

>> it's not policy incompliant if e.g. php5 would install
>> /etc/apache2/sites-enabled/whatever containing a virtualhost
>> definition.  the reason why nobody would do that, is, that it's just
>> wrong and unreasonable to do such a thing (where e.g. aliases and
>> directory directives are a reasonable thing to do for a web
>> application).

> Having, say, mediawiki, ask using debconf if you would like a vhost set
> up with the host name wiki.$domain would be completely sane, IMO.  If
> you don't want it, just tell the config script no.

Agreed, provided that the default action is no.

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

Re: Removing web server dependencies from web apps

[Jonas Smedegaard]

On 12-01-07 at 09:15am, Russ Allbery wrote:
> Tollef Fog Heen  writes:
> > ]] Daniel Baumann 
> 
> >> it's not policy incompliant if e.g. php5 would install 
> >> /etc/apache2/sites-enabled/whatever containing a virtualhost 
> >> definition.  the reason why nobody would do that, is, that it's 
> >> just wrong and unreasonable to do such a thing (where e.g. aliases 
> >> and directory directives are a reasonable thing to do for a web 
> >> application).
> 
> > Having, say, mediawiki, ask using debconf if you would like a vhost 
> > set up with the host name wiki.$domain would be completely sane, 
> > IMO.  If you don't want it, just tell the config script no.
> 
> Agreed, provided that the default action is no.

I too feel that no webapp package should add vhosts by default.

But does it violate Policy?

The package jwchat currently enable a vhost by default, I believe.


 - 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: Removing web server dependencies from web apps

[Russ Allbery]

Jonas Smedegaard  writes:
> On 12-01-07 at 09:15am, Russ Allbery wrote:
>> Tollef Fog Heen  writes:
>>> ]] Daniel Baumann 
>> 
 it's not policy incompliant if e.g. php5 would install 
 /etc/apache2/sites-enabled/whatever containing a virtualhost 
 definition.  the reason why nobody would do that, is, that it's 
 just wrong and unreasonable to do such a thing (where e.g. aliases 
 and directory directives are a reasonable thing to do for a web 
 application).

>>> Having, say, mediawiki, ask using debconf if you would like a vhost 
>>> set up with the host name wiki.$domain would be completely sane, 
>>> IMO.  If you don't want it, just tell the config script no.

>> Agreed, provided that the default action is no.

> I too feel that no webapp package should add vhosts by default.

> But does it violate Policy?

> The package jwchat currently enable a vhost by default, I believe.

I'm not sure that it really violates Policy, mostly because we don't have
any Policy guidance about web applications at all right now.  But I think
it's fairly obvious that it's not a sane thing to do to camp on a piece of
URL space without any consultation with the local administrator.  Even
more so than file system space under /srv, the URL namespace served by a
web server is frequently under tight control and needs to be carefully
managed according to rules and conventions that the package has no way of
knowing.

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

Re: Bug#654896: ITP: xul-ext-debianbuttons -- Buttons for querying Debian-related pages with Iceweasel/Firefox

[Andreas Tille]

On Sat, Jan 07, 2012 at 10:45:38PM +0800, Paul Wise wrote:
> When I switched from galeon I also wanted galeon style smart bookmarks
> and had to reimplement them as a hard-coded extension:
> 
> http://bonedaddy.net/pabs3/log/2011/11/04/migrate-from-galeon-to-iceweasel-firefox/
> 
> I would love it if I could replicate my galeon smart bookmarks
> experience in iceweasel but I couldn't find any extensions to do that.

It would be soo cool to get the Galeon experience in Iceweasel.
After heaving read the link above I can only say that I wish you look.
Always if I want to copy-n-paste a bug number into my browser I remember
those good old days where galeon was available.  If this ITP would help
out here in this way I would really like to try this soonish (and people
like Adam can probably easily ignore it).

Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
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/20120107175546.gd14...@an3as.eu

Re: Removing web server dependencies from web apps

[Jonas Smedegaard]

On 12-01-07 at 09:42am, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> > On 12-01-07 at 09:15am, Russ Allbery wrote:
> >> Tollef Fog Heen  writes:
> >>> ]] Daniel Baumann
> >> 
>  it's not policy incompliant if e.g. php5 would install 
>  /etc/apache2/sites-enabled/whatever containing a virtualhost 
>  definition.  the reason why nobody would do that, is, that it's 
>  just wrong and unreasonable to do such a thing (where e.g. 
>  aliases and directory directives are a reasonable thing to do for 
>  a web application).
> 
> >>> Having, say, mediawiki, ask using debconf if you would like a 
> >>> vhost set up with the host name wiki.$domain would be completely 
> >>> sane, IMO.  If you don't want it, just tell the config script no.
> 
> >> Agreed, provided that the default action is no.
> 
> > I too feel that no webapp package should add vhosts by default.
> 
> > But does it violate Policy?
> 
> > The package jwchat currently enable a vhost by default, I believe.
> 
> I'm not sure that it really violates Policy, mostly because we don't 
> have any Policy guidance about web applications at all right now.  But 
> I think it's fairly obvious that it's not a sane thing to do to camp 
> on a piece of URL space without any consultation with the local 
> administrator.  Even more so than file system space under /srv, the 
> URL namespace served by a web server is frequently under tight control 
> and needs to be carefully managed according to rules and conventions 
> that the package has no way of knowing.

Well, in the case of jwchat it is not so clear cut: the user _is_ asked 
for a hostname for the vhost, and offered to opt-out by writing "none", 
but default is not none.


 - 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: Source package without a binary

[Joachim Breitner]

Hi Guillem,

Am Samstag, den 07.01.2012, 02:40 +0100 schrieb Guillem Jover:
> That's what I did for the last posixtestsuite 1.5.2-4 upload, and
> while the “dummy” binary package might seem a bit worthless, it has
> some advantages; it keeps the maintainer build log, something the buildd
> network does not currently do, and it makes the test results, which in
> a way could be considered different to build logs, available in an
> easily installable form. The other advantage of not providing a
> foo-source binary package is that the natural way of building binary
> packages is from source packages not binary ones.

strange that it did not occur to me to look for precedence cases of a
source package shipping “only” a testsuite; thanks for pointing me to
it. I now followed that lead and packaged ghc-testsuite as a source that
generates one binary containing the test results.

Greetings,
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

zram Usage as Default in Debian (?)

[Rainer Dorsch]

Hello,

I recently setup zram (for compressed swap space in RAM) on an older low RAM  
machine. I was quite happy with the result and started now to do the same 
setup also on my other machines. I am wondering if anybody is investigating, 
if debian should do that by default when installing a new machine or even 
better also when machines get upgraded.

Here is what I did:

(see http://crunchbanglinux.org/forums/post/150355/#p150355 for more details)

/etc/modules: add zram

add (num_devices=)
rd@blackbox:~$ cat /etc/modprobe.d/zram.conf
options zram num_devices=2
rd@blackbox:~$ 

/etc/init.d/zram
#!/bin/bash
### BEGIN INIT INFO
# Provides: zram
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Increased Performance In Linux With zRam (Virtual Swap 
Compressed in RAM)
# Description: Adapted from systemd scripts at 
https://github.com/mystilleef/FedoraZram
### END INIT INFO

start() {
# get the number of CPUs
num_cpus=$(grep -c processor /proc/cpuinfo)
# if something goes wrong, assume we have 1
[ "$num_cpus" != 0 ] || num_cpus=1

# set decremented number of CPUs
decr_num_cpus=$((num_cpus - 1))

# get the amount of memory in the machine
mem_total_kb=$(grep MemTotal /proc/meminfo | grep -E --only-matching 
'[[:digit:]]+')
mem_total=$((mem_total_kb * 1024))

# load dependency modules
modprobe zram num_devices=$num_cpus

# initialize the devices
for i in $(seq 0 $decr_num_cpus); do
echo $((mem_total / num_cpus)) > /sys/block/zram$i/disksize
done

# Creating swap filesystems
for i in $(seq 0 $decr_num_cpus); do
mkswap /dev/zram$i
done

# Switch the swaps on
for i in $(seq 0 $decr_num_cpus); do
swapon -p 100 /dev/zram$i
done
}

stop() {
# get the number of CPUs
num_cpus=$(grep -c processor /proc/cpuinfo)

# set decremented number of CPUs
decr_num_cpus=$((num_cpus - 1))

# Switching off swap
for i in $(seq 0 $decr_num_cpus); do
if [ "$(grep /dev/zram$i /proc/swaps)" != "" ]; then
swapoff /dev/zram$i
sleep 1
fi
done

sleep 1
rmmod zram
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
sleep 3
start
;;
*)
echo "Usage: $0 {start|stop|restart}"
RETVAL=1
esac
exit $RETVAL


END##

# update-rc.d zram defaults

Thanks,
Rainer
-- 
Rainer Dorsch
http://bokomoko.de/


-- 
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/201201071848.38748...@bokomoko.de

Re: Removing web server dependencies from web apps

[Russ Allbery]

Jonas Smedegaard  writes:
> On 12-01-07 at 09:42am, Russ Allbery wrote:

>> I'm not sure that it really violates Policy, mostly because we don't
>> have any Policy guidance about web applications at all right now.  But
>> I think it's fairly obvious that it's not a sane thing to do to camp on
>> a piece of URL space without any consultation with the local
>> administrator.  Even more so than file system space under /srv, the URL
>> namespace served by a web server is frequently under tight control and
>> needs to be carefully managed according to rules and conventions that
>> the package has no way of knowing.

> Well, in the case of jwchat it is not so clear cut: the user _is_ asked 
> for a hostname for the vhost, and offered to opt-out by writing "none", 
> but default is not none.

The reason why the default is important is because the default is what's
taken if people have set their debconf prompting level to high or
critical (since I assume that this prompt is not critical, and probably
not high, and I think that would be priority inflation).

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

Re: Removing web server dependencies from web apps

[Jonas Smedegaard]

On 12-01-07 at 11:33am, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> > On 12-01-07 at 09:42am, Russ Allbery wrote:
> 
> >> I'm not sure that it really violates Policy, mostly because we 
> >> don't have any Policy guidance about web applications at all right 
> >> now.  But I think it's fairly obvious that it's not a sane thing to 
> >> do to camp on a piece of URL space without any consultation with 
> >> the local administrator.  Even more so than file system space under 
> >> /srv, the URL namespace served by a web server is frequently under 
> >> tight control and needs to be carefully managed according to rules 
> >> and conventions that the package has no way of knowing.
> 
> > Well, in the case of jwchat it is not so clear cut: the user _is_ 
> > asked for a hostname for the vhost, and offered to opt-out by 
> > writing "none", but default is not none.
> 
> The reason why the default is important is because the default is 
> what's taken if people have set their debconf prompting level to high 
> or critical (since I assume that this prompt is not critical, and 
> probably not high, and I think that would be priority inflation).

Yes, I am aware of that (but thanks anyway).

I am not package maintainer of jwchat, but a concerned user of it. :-)


 - 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#655010: ITP: missing-manpages -- manual pages for software missing them

[brian m. carlson]

Package: wnpp
Severity: wishlist
Owner: "brian m. carlson" 

* Package name: missing-manpages
  Version : 1
  Upstream Author : brian m. carlson 
* URL : https://github.com/bk2204/missing-manpages
* License : GPL-2/Apache-2.0/CC-BY-SA-3.0 tri-license
  Programming Lang: man
  Description : manual pages for software missing them

missing-manpages provides free manual pages for software that does not
have them.

Note that this is the name of the source package.  Currently only manual
pages for GCC are available, but it's possible manpages for other
packages will be included at some point in the future.  This is being
packaged separately from gcc because its maintainer is not interested in
including manpages in the gcc-4.6 package.  The exact name for the
binary package containing the gcc manpages is yet to be determined
pending feedback from debian-gcc (CC'd).

The description for the binary package is as follows:

documentation for the GNU Compiler Collection

This package contains manual pages for the GNU Compiler Collection.  The
upstream manual pages cannot be included in main for license reasons, so
these (incomplete) manual pages have been written from scratch to
replace them.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: zram Usage as Default in Debian (?)

[Paul Wise]

On Sun, Jan 8, 2012 at 1:48 AM, Rainer Dorsch wrote:

> I recently setup zram (for compressed swap space in RAM) on an older low RAM
> machine. I was quite happy with the result and started now to do the same
> setup also on my other machines. I am wondering if anybody is investigating,
> if debian should do that by default when installing a new machine or even

Please ask on the Debian installer team mailing list about that:

http://lists.debian.org/debian-boot/

> better also when machines get upgraded.

I think a change like that should be up to the sysadmin.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6GM6Vc-1XQ=6cdfegme6t4iwlk5khy7fpyqyv3u3n-...@mail.gmail.com

Re: zram Usage as Default in Debian (?)

[Chow Loong Jin]

On 08/01/2012 01:48, Rainer Dorsch wrote:
> Hello,
> 
> I recently setup zram (for compressed swap space in RAM) on an older low RAM  
> machine. I was quite happy with the result and started now to do the same 
> setup also on my other machines. I am wondering if anybody is investigating, 
> if debian should do that by default when installing a new machine or even 
> better also when machines get upgraded.
> [...]

In my experience from using a zram + on-disk swap setup, performance is only
good until the zram swap gets filled up. Then performance goes to hell because
you'll be functioning primarily on your on-disk swap while your zram swap just
acts as deadweight sitting around taking up memory. What I usually did at that
point was to swapoff the zram swap to force everything into the on-disk swap,
rmmod, and re-create the zram swap again to get free zram swap space.

I don't think it's a good idea to make this default.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature