Re: On init in Debian

[Tollef Fog Heen]

]] Stéphane Glondu 

> Le 30/03/2012 08:18, Tollef Fog Heen a écrit :
> > I doubt you'll get upstreams to write metainit files.  I think we'll
> > have upstreams providing systemd files and so I think metainit will
> > basically be #15 in http://xkcd.com/927/.
> 
> Actually, it's more systemd that looks like #15.

systemd isn't inventing a new file format in order to unite all the
existing ones.  metainit is.

-- 
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/8762dm377y@qurzaw.varnish-software.com

Re: On init in Debian

[Vincent Bernat]

OoO En ce  milieu de nuit étoilée du vendredi 30  mars 2012, vers 03:54,
Carlos Alberto Lopez Perez  disait :

>> FWIW, I have a proposal for a GSoC task this year to write a
>> systemd-to-initscript converter,
>> http://wiki.debian.org/SummerOfCode2012/Projects#SysV-init_file_creator_from_systemd_service_files
>> 
>> The systemd service files are covered by the «interface guarantee»,
>> meaning they won't change incompatibly in a future release of systemd,
>> so I think having that as the base format would be fairly reasonable,
>> though probably just a subset so it's portable to other kernels and init
>> systems.

> And instead of this... why not simply improving metainit to support also
> systemd files?

> http://wiki.debian.org/MetaInit

> We already have this metainit thing that auto-generates both sysvinit
> and upstart files based on an easy common format.

> http://darcs.nomeata.de/metainit/examples/

Documentation is  rather absent. Currently (from Parse.pm),  it seems to
only  support   and  use  "Short-Description",   "Description",  "Exec",
"Prestart-Hook",  "Poststop-hook"  and  "No-Auto"  directive.   It  also
supports "Required-Start".  It seems  that simple things, like "reload",
cannot be achieved.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

panic("bad_user_access_length executed (not cool, dude)");
2.0.38 /usr/src/linux/kernel/panic.c


pgpTkil0976f7.pgp
Description: PGP signature

Re: On init in Debian

[Russ Allbery]

Stéphane Glondu  writes:
> Le 30/03/2012 08:18, Tollef Fog Heen a écrit :

>> I doubt you'll get upstreams to write metainit files.  I think we'll
>> have upstreams providing systemd files and so I think metainit will
>> basically be #15 in http://xkcd.com/927/.

> Actually, it's more systemd that looks like #15.

I don't think the analogy really works on either count, although it's
somewhat closer for MetaInit.  But it definitely doesn't make sense for
systemd.  systemd's goal wasn't to become a standard that supported things
people were already doing.  Rather, both it and upstart were aiming to
incorporate into the init system brand-new functionality that wasn't
currently supported at all, things like real process monitoring beyond
init's meager capabilities, safe process kills without using PID files,
and of course event-driven boot.  They're effectively two different
strategies and projects aimed at solving the same set of technical
problems.

The difference between this and standards is that standards as commented
on by XKCD are mostly looking to collect existing solutions to problems
that are currently solved in mutually-incompatible ways into a uniform
framework.  They usually aren't intentionally breaking new ground.

The maintenance of systemd is actually quite the opposite of a standard.
It's focused on being clean, supportable, and fully integrated with Linux
capabilities, *not* to solving everyone's use case, even to the detriment
of being universal.

A standard in the init script space would look more like what the LSB says
about init scripts: a conservative standardization of well-known and
pre-existing ideas and technology that have been indepedently solved
already by multiple different systems in ways that aren't interoperable.

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

Re: On init in Debian

[Salvo Tomaselli]

> Well, wicd has its own bugs, such as preventing a laptop from
> suspending.
are you talking about a bug from 2008 that has been fixed for ages?
https://bugs.launchpad.net/wicd/+bug/306210
-- 
Salvo Tomaselli


-- 
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/201203300839.39267.tipos...@tiscali.it

Re: On init in Debian

[Stéphane Glondu]

Le 30/03/2012 08:18, Tollef Fog Heen a écrit :
> I doubt you'll get upstreams to write metainit files.  I think we'll
> have upstreams providing systemd files and so I think metainit will
> basically be #15 in http://xkcd.com/927/.

Actually, it's more systemd that looks like #15.


Cheers,

-- 
Stéphane


--
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/4f7553a0.9060...@debian.org

Bug#666263: ITP: log4shib -- log4j-style configurable logging library for C++

[Russ Allbery]

Package: wnpp
Severity: wishlist
Owner: Russ Allbery 

This ITP probably needs some additional discussion. log4shib is a fork
of log4cpp (as described in the long description below) that is the
recommended logging library for the Shibboleth web authentication project.
Shibboleth is already packaged for Debian (xmltooling, opensaml2, and
shibboleth-sp2 source packages) and is currently built against log4cpp.
However, log4shib is actively maintained (log4cpp appears to be dormant)
and has bug fixes and thread safety fixes not present in the current
log4cpp.

I'm hesitant to introduce this sort of code duplication in the archive,
but I think this will result in a more robust and higher quality set of
Shibboleth packages.  The Shibboleth maintainers also maintain log4shib
actively, and while there hasn't been a new release of it since 2009 (the
last log4cpp release was in 2007), that's only because no new bugs for the
functionality that Shibboleth uses have cropped up.

Shibboleth upstream has submitted the fixes and changes to the log4cpp
tracker and some have been applied in their CVS and some changed in
other ways (that the Shibboleth upstream didn't have time to evaluate),
but no actual release has happened since that work.  (One of the issues
that Shibboleth upstream had, not directly relevant to Debian, was lack
of testing on Solaris and support on Windows.)

I'd be very interested to hear comments on this, particularly if, for
instance, the security team is concerned.  The package would be
introduced for the use of Shibboleth; I don't know of any other clients
of the library.

Regular ITP details follow:

* Package name: log4shib
  Version : 1.0.4
  Upstream Author : Scott Cantor
* URL : 
https://wiki.shibboleth.net/confluence/display/OpenSAML/log4shib
* License : LGPL 2.1
  Programming Lang: C++
  Description : log4j-style configurable logging library for C++

log4shib provides a library of C++ classes for flexible logging to
files, syslog, and other destinations.  It is modeled after the log4j
Java library, staying as close to that API as is reasonable.

log4shib is a fork of the log4cpp library with additional fixes and
modifications to improve its thread safety and robustness.  It is
primarily intended for use by the Shibboleth web authentication
system.



-- 
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/20120330061741.12291.9162.report...@windlord.stanford.edu

Re: On init in Debian

[Tollef Fog Heen]

]] Carlos Alberto Lopez Perez 

> On 20/03/12 07:14, Tollef Fog Heen wrote:
> > FWIW, I have a proposal for a GSoC task this year to write a
> > systemd-to-initscript converter,
> > http://wiki.debian.org/SummerOfCode2012/Projects#SysV-init_file_creator_from_systemd_service_files
> > 
> > The systemd service files are covered by the «interface guarantee»,
> > meaning they won't change incompatibly in a future release of systemd,
> > so I think having that as the base format would be fairly reasonable,
> > though probably just a subset so it's portable to other kernels and init
> > systems.
> 
> And instead of this... why not simply improving metainit to support also
> systemd files?

I doubt you'll get upstreams to write metainit files.  I think we'll
have upstreams providing systemd files and so I think metainit will
basically be #15 in http://xkcd.com/927/.

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

Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Raphael Hertzog]

On Thu, 29 Mar 2012, Wookey wrote:
> > But you should not rely on this because calling debian/rules directly
> > must be supported.
> 
> Hmm, but if a package cannot use the variables set by
> dpkg-buildpackage and must set them itself, what is the point of
> dpkg-buildpackage setting them? To save the package exporting the
> variables?

I see two main reasons (but I did not write the original code, so I don't
know the initial motivation):

1/ this allows debian/rules to use "?=" assignation resulting in no-op
   when the variables are set. This avoids multiple dpkg-architecture
   invocations since dpkg-buildpackage only calls it once.

2/ it is required for cross-compilation since the fact that DEB_HOST_ARCH
   is set to a value that is not equal to DEB_BUILD_ARCH is the canonical
   fact that defines cross-compilation of the debian package

> Well, perhaps I shouldn't (and indeed I'd like us to get to a point
> where we don't), but currently, in practice, non-native builds need
> other things setting in the environment anyway so even using
> dpkg-buildpackage isn't necessarily sufficient, whereas for a native
> build it always is. 

OK but this should ideally be integrated in common layers such as
CDBS and debhelper.

> Now if everyone is happy that debian/rules remains the canonical
> interface even for cross-builds and that they should work without
> dpkg-buildpackage help then I should start testing on that basis. I
> have not done that to date. 

Honestly I have never seen anyone doing cross-builds and calling
debian/rules manually. So while I believe that cross-build should
not make different assumptions from native builds (i.e. we want to
converge), I would also not bother testing this explicitly.

"dpkg-buildpackage -a" is what people are using (and should be using).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
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/20120330060656.gk12...@rivendell.home.ouaza.com

[OT] NM vs. wicd (was: Re: On init in Debian)

[Chris Knadle]

On Thursday, March 29, 2012 04:09:57, Vincent Lefevre wrote:
> On 2012-03-29 02:43:33 +0200, Carlos Alberto Lopez Perez wrote:
> > $ sudo apt-get remove network-manager*
> > $ sudo apt-get install wicd wicd-curses wicd-gtk
> > 
> > ^ wicd-kde ?
> > 
> > $ wicd-curses
> > 
> > And enjoy your network without the NM mess :)
> 
> Well, wicd has its own bugs, such as preventing a laptop from
> suspending.

Hmm.  That sucks.  I'd like to debug why you're running into this.  However  
I've been using wicd for over two years and never had this problem, but I'm 
also running a custom-built kernel (and have been for a long time).

Any idea why wicd would prevent your laptop from suspending?  The best first 
guess I have is perhaps a bug with the wireless card driver or firmware such 
that it won't enter the suspend state.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


-- 
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/201203292323.52948.chris.kna...@coredump.us

Re: On init in Debian

[Carlos Alberto Lopez Perez]

On 20/03/12 07:14, Tollef Fog Heen wrote:
> FWIW, I have a proposal for a GSoC task this year to write a
> systemd-to-initscript converter,
> http://wiki.debian.org/SummerOfCode2012/Projects#SysV-init_file_creator_from_systemd_service_files
> 
> The systemd service files are covered by the «interface guarantee»,
> meaning they won't change incompatibly in a future release of systemd,
> so I think having that as the base format would be fairly reasonable,
> though probably just a subset so it's portable to other kernels and init
> systems.

And instead of this... why not simply improving metainit to support also
systemd files?

http://wiki.debian.org/MetaInit

We already have this metainit thing that auto-generates both sysvinit
and upstart files based on an easy common format.

http://darcs.nomeata.de/metainit/examples/




-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Re: On init in Debian

[Carlos Alberto Lopez Perez]

On 19/03/12 14:23, Jon Dowland wrote:
>> I just had a look, and no, that's not what metainit does.
>> > What it does is *generating* an init.d script, using the
>> > metainit syntax as input. IMO, just a normal shell script
>> > tiny library to simplify our init.d scripts would be enough.
> So it does more than enough - sounds to me like it meets your
> requirements (in fact exceeds them) and has the added advantage
> that it *already exists* whereas the hypothetical shell script
> library does not.

I didn't know about this metainit thing and it looks awesome.

http://wiki.debian.org/MetaInit

So we already have a system that generates startup files for both
sysvinit and upstart

... what about extending it to also support systemd?

We can later request all maintainers to port the startup scripts of
their respective packages to metainit via a new debian standard-version
and also with lintian warnings if a startup script other than the
metainit one is detected on the package.


This can be the solution we are looking to tie together the different
init systems.


-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Work-needing packages report for Mar 30, 2012

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 432 (new: 2)
Total number of packages offered up for adoption: 152 (new: 2)
Total number of packages requested help for: 61 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   emacs-jabber (#665954), orphaned 2 days ago
 Description: Jabber client for Emacsen
 Installations reported by Popcon: 230

   pidgin-openpgp (#665748), orphaned 4 days ago
 Description: OpenPGP plugin for Pidgin
 Installations reported by Popcon: 680

430 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   bnfc (#665783), offered 3 days ago
 Description: Compiler front-end generator based on Labelled BNF
 Installations reported by Popcon: 41

   sflphone (#665789), offered 3 days ago
 Description: SIP and IAX2 compatible VoIP phone
 Reverse Depends: sflphone-evolution sflphone-gnome
 Installations reported by Popcon: 348

150 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apache2 (#646208), requested 159 days ago
 Description: Apache HTTP Server
 Reverse Depends: aegis-web apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (175 more
   omitted)
 Installations reported by Popcon: 64071

   apt-xapian-index (#567955), requested 787 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: adept ept-cache fuss-launcher goplay packagesearch
 Installations reported by Popcon: 54406

   asymptote (#517342), requested 1126 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 3191

   athcool (#278442), requested 2711 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 88

   balsa (#642906), requested 186 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 275

   bastille (#592137), requested 600 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 241

   boinc (#511243), requested 1176 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc boinc-amd-opencl boinc-app-milkyway
   boinc-app-seti boinc-dbg boinc-nvidia-cuda
 Installations reported by Popcon: 1853

   cardstories (#624100), requested 339 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 7

   chromium-browser (#583826), requested 669 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-browser chromium-browser-dbg
   chromium-browser-inspector chromium-browser-l10n chromium-dbg
   chromium-l10n mozplugger
 Installations reported by Popcon: 10466

   cryptsetup (#600777), requested 526 days ago
 Description: configures encrypted block devices
 Reverse Depends: cryptsetup cryptsetup-udeb libcryptsetup-dev
   libguestfs0 libpam-mount ltsp-client mandos-client partman-crypto-dm
   rescue-mode systemd
 Installations reported by Popcon: 7790

   debtags (#567954), requested 787 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2605

   doc-central (#566364), requested 796 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 220

   elvis (#432298), requested 1725 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 391

   fbcat (#565156), requested 806 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 153

   flightgear (#487388), requested 1377 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 861

   freeipmi (#628062), requested 308 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: freeipmi-bmc-watchdog freeipmi-ipmidetect
   freeipmi-tools libfreeipmi-dev libfreeipmi10 libipmiconsole-dev
   libipmiconsole2 libipmi

Bug#666242: ITP: clearwaita-theme -- Clearwaita theme for GTK+

[Andrew Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrew Shadura 

* Package name: clearwaita-theme
  Upstream Author : Jean-Philippe Fleury
* URL : http://www.jpfleury.net/en/software/clearwaita.php
* License : GPL-3+
  Description : Clearwaita theme for GTK+

 Clearwaita is a GTK+ 2/GTK+ 3 theme. Files for GTK+ 3 are a modified version
 of Adwaita, the default GNOME 3 theme, to make it visually close to
 Clearlooks. Files for GTK+ 2 come from the unmodified Clearlooks theme.

-- 
WBR, Andrew



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

Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates

[Dennis van Dok]

Package: wnpp
Severity: wishlist
Owner: Dennis van Dok 

* Package name: igtf-policy-bundle
  Version : 1.46
  Upstream Author : David Groep 
* URL : http://www.igtf.net/
* License : Apache 2
  Programming Lang: X.509 CA certificates
  Description : IGTF profiles for Authority Root Certificates

 The International Grid Trust Federation (IGTF) maintains a common
 trust base for the benefit of distributed science and research
 computing infrastructures by maintaining a list of trust anchors, for
 accredited authorities. The distribution contains root certificates,
 certificate revocation list (CRL) locations, contact information, and
 signing policies.

 The package is split up according to the different profiles of the
 IGTF (each profile covers a different set of rules and policies).
 The most important ones are classic, mics (member integrated credential
 service) and slcs (short lived credential service).

 The trust anchors maintained by the IGTF form a trust backbone for many
 large-scale science communities, among which the European Grid
 Infrastructure (http://www.ige.eu/) and the World-wide LHC Computing
 Grid (http://lcg.web.cern.ch/lcg/).

 The certificates are kept in /usr/share/igtf-policy/ and
 /usr/share/ca-certificates/igtf-*/. They are meant to be placed in
 /etc/grid-security/certificates, where the commonly used grid middleware
 will look for it; it is also possible to include (some of) the certificates
 in /etc/ssl/certs by using dpkg-reconfigure ca-certificates.



-- 
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/20120329212923.1102.40995.reportbug@localhost6.localdomain6

Re: On init in Debian

[Milan P. Stanic]

On Thu, 2012-03-29 at 13:07, Russ Allbery wrote:
> Mike Hommey  writes:
> > On Thu, Mar 29, 2012 at 10:09:57AM +0200, Vincent Lefevre wrote:
> >> Well, wicd has its own bugs, such as preventing a laptop from
> >> suspending.
> Works for me; I've never had any trouble at all suspending my laptop and
> I've been using wicd for years.  (The laptop tracks unstable.)

Also for me, my wife, daughter, nephew and son. :-]

[...]

-- 
Kind regards,  Milan
--
Arvanta, IT Securityhttp://www.arvanta.net
Please do not send me e-mail containing HTML code or documents in
proprietary format (word, excel, pps and so on)


-- 
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/20120329205644.ga23...@arvanta.net

Bug#666224: ITP: peg -- recursive-descent parser generators for C

[Giulio Paci]

Package: wnpp
Severity: wishlist
Owner: Giulio Paci 

* Package name: peg
  Version : 0.1.7
  Upstream Author : Ian Piumarta 
* URL : http://piumarta.com/software/peg/
* License : MIT/X
  Programming Lang: C
  Description : recursive-descent parser generators for C



-- 
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/20120329205337.7152.58056.reportbug@geppetto

Re: gconftool

[Svante Signell]

On Thu, 2012-03-29 at 21:38 +0200, Philipp Kern wrote:
> On Fri, Mar 30, 2012 at 12:13:55AM +0800, Thomas Goirand wrote:
> > On 03/24/2012 07:17 AM, Michael Banck wrote:
> > > This is a development list, please discuss user support issues or
> > > general usage questions on debian-user.
> > I don't see his rant against the gnome settings as
> > a "support issue" or "general usage".
> > 
> > By the way, I agree with him about the fact gnome settings
> > are as stupid as the windows registry, and not user friendly
> > at all.
> 
> And what useful contribution should this be to this list?

I think it gives an indication on which packages should be used as
default for Debian GNU/*. And I think that the Debian
preferred/recommended packages has a very large impact on upstream
developers. Of course specific UI usage issues, should not be discussed
on Debian lists. Nevertheless, Debian has a large share of the number of
users[1] out there.

[1]
{\begin rant}
Yes, these bastards using the software and reporting bugs and proposing
patches, not developing it or maintaining it ;).
{\end rant}


-- 
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/1333054403.8013.124.ca...@hp.my.own.domain

Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Wookey]

+++ Raphael Hertzog [2012-03-29 21:06 +0200]:
> Hi,
> 
> On Thu, 29 Mar 2012, Wookey wrote:
> > Anyone know when this happened and what if any, the limitations are?
> > It's certainly true in wheezy, squeeze, precise and oineiric. 
> 
> This has always been the case ever since dpkg-architecture has been
> introduced.

OK, shows how much I know :-)

> But you should not rely on this because calling debian/rules directly
> must be supported.

Hmm, but if a package cannot use the variables set by
dpkg-buildpackage and must set them itself, what is the point of
dpkg-buildpackage setting them? To save the package exporting the
variables?

> > Now, you can build packages without using dpkg-buildpackage by calling
> > rules directly, and in that case the rules file would need to call
> > dpkg-architecture, but someone would have to convince me that that was
> > an interface worth supporting for non-native builds, because I
> > have certainly always considered the minimal interface for cross
> > package-building to be dpkg-buildpackage -a, and in practice
> > there are other things you need to do for non-trivial packages (set
> > CONFIG_SITE, set DEB_BUILD_OPTS=nocheck). (and ensure various things
> > like toolchain and dpkg-cross are installed). And I don't think we want
> > that stuff in every single rules file.
> 
> I don't see why you're differentiating non-native builds from native
> builds (unless you assume different debian/rules files).

Well, perhaps I shouldn't (and indeed I'd like us to get to a point
where we don't), but currently, in practice, non-native builds need
other things setting in the environment anyway so even using
dpkg-buildpackage isn't necessarily sufficient, whereas for a native
build it always is. 

Although what you're telling me is that that's irrelevant because in
fact just calling debian/rules should also always be sufficient. To
make that true for cross-builds requires more than we are putting in
rules files at the moment. So there is a difference.

Now if everyone is happy that debian/rules remains the canonical
interface even for cross-builds and that they should work without
dpkg-buildpackage help then I should start testing on that basis. I
have not done that to date. 

The obvious bits that will be missing in many packages are something
to deal with autoconf cache variables (currently handled by dpkg-cross
and setting CONFIG_SITE externally). And something to set cmake
toolchain file variables (also currently in dpkg-cross, but I suspect
it needs updating for multiarch). 

> In any case, if you're worried about the boilerplate code required to
> get the variables defined, you can now use "include
> /usr/share/dpkg/architecture.mk" to avoid it (but this requires
> dpkg-dev >= 1.16.1).

OK. That's useful to know. And fine from here on in. I'll add that to
the page. Keeping boilerplate in includable snippets seems like an
excellent plan generally.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20120329203052.gu26...@dream.aleph1.co.uk

Bug#664257: Email Id Awarded 750,000.00 GBP in Coca Cola Promo Prize. Provide Info for claims

[CLINT HEAD]

Provide::   Names:..  e.t.c..

Re: On init in Debian

[Russ Allbery]

Mike Hommey  writes:
> On Thu, Mar 29, 2012 at 10:09:57AM +0200, Vincent Lefevre wrote:

>> Well, wicd has its own bugs, such as preventing a laptop from
>> suspending.

Works for me; I've never had any trouble at all suspending my laptop and
I've been using wicd for years.  (The laptop tracks unstable.)

> Or an absolutely horrible UI,

Works for me, but a matter of taste, of course.  :)  I like it much better
than the NM GUI.

> no helper for vpns,

Haven't tried.

> auto-reconnection not working after a connection loss (works at boot,
> fortunately),

Works for me and tested regularly.  Be sure that you have the
"automatically connect to this network" option selected.

> randomly taking 30 seconds to shutdown,

Works for me.

> and not able to connect to WPA enterprise.

Pretty sure this worked for me, but it's not something I use regularly.

> And this is not just years-old hearsay, like most complains about NM,
> it's first-hand experience with the package currently in
> wheezy/unstable.

> I could file bugs, but I have so many problems that I'm better off
> switching to NM.

Well, it seems like you should file bugs if you can, because a lot of
these are not universal problems and therefore probably aren't known
issues.

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

Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Julien Cristau]

On Thu, Mar 29, 2012 at 19:10:05 +0100, Wookey wrote:

> Should a package depending on this behaviour build-dep on a particular
> dpkg version? As it already works in build-essential in stable do the
> same rules apply as essential packages in stable (i.e no explicit
> dependency required)? That would be consistent. Maybe it's been doing
> it since forever?
> 
A package may not depend on this behaviour.  The interface to build a
package is still debian/rules, not dpkg-buildpackage.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: gconftool

[Philipp Kern]

On Fri, Mar 30, 2012 at 12:13:55AM +0800, Thomas Goirand wrote:
> On 03/24/2012 07:17 AM, Michael Banck wrote:
> > This is a development list, please discuss user support issues or
> > general usage questions on debian-user.
> I don't see his rant against the gnome settings as
> a "support issue" or "general usage".
> 
> By the way, I agree with him about the fact gnome settings
> are as stupid as the windows registry, and not user friendly
> at all.

And what useful contribution should this be to this list?

Kind regards
Philipp Kern 


signature.asc
Description: Digital signature

re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[peter green]

Now, you can build packages without using dpkg-buildpackage by calling
rules directly, and in that case the rules file would need to call
dpkg-architecture, but someone would have to convince me that that was
an interface worth supporting for non-native builds

The big reason it's worth supporting IMO is that with most packages you
can "resume" after a failld build by manually running debian/rules 
build. When fixing compile errors in a large package I don't want to 
have to restart the build from scratch after every file I fix.


Of course I will do a "proper" build with dpkg-buildpackage at the end
but only after i've fixed all the compile errors.


--
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/4f74b2cd.5070...@p10link.net

Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Raphael Hertzog]

Hi,

On Thu, 29 Mar 2012, Wookey wrote:
> Anyone know when this happened and what if any, the limitations are?
> It's certainly true in wheezy, squeeze, precise and oineiric. 

This has always been the case ever since dpkg-architecture has been
introduced.

But you should not rely on this because calling debian/rules directly
must be supported.

dpkg-buildpackage(1) clearly states:
| Even if dpkg-buildpackage exports some variables, debian/rules should
| not rely  on their  presence  and  should  instead  use the respective
| interface to retrieve the needed values.

And this interface is "dpkg-architecture" itself in this case.

> Now, you can build packages without using dpkg-buildpackage by calling
> rules directly, and in that case the rules file would need to call
> dpkg-architecture, but someone would have to convince me that that was
> an interface worth supporting for non-native builds, because I
> have certainly always considered the minimal interface for cross
> package-building to be dpkg-buildpackage -a, and in practice
> there are other things you need to do for non-trivial packages (set
> CONFIG_SITE, set DEB_BUILD_OPTS=nocheck). (and ensure various things
> like toolchain and dpkg-cross are installed). And I don't think we want
> that stuff in every single rules file.

I don't see why you're differentiating non-native builds from native
builds (unless you assume different debian/rules files).

In any case, if you're worried about the boilerplate code required to
get the variables defined, you can now use "include
/usr/share/dpkg/architecture.mk" to avoid it (but this requires
dpkg-dev >= 1.16.1).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
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/20120329190625.ge9...@rivendell.home.ouaza.com

Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Jonathan Nieder]

Hi Wookey,

Wookey wrote:

> I recently noticed that when building with dpkg-buildpackage there is
> no need for the 
>
> DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
> DEB_HOST_GNU_TYPE  := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)

Don't you mean "?="?

[...]
> You can just do the test:
> ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
>
> and it works, so it looks like dpkg-buildpackage is now setting those
> vars for us. This is good and sensible, it's just that it's news to me.
>
> Anyone know when this happened and what if any, the limitations are?

It happened years ago, but it's not guaranteed by policy.  As you
wrote:

[...]
> Now, you can build packages without using dpkg-buildpackage by calling
> rules directly, and in that case the rules file would need to call
> dpkg-architecture, but someone would have to convince me that that was
> an interface worth supporting for non-native builds, because I
> have certainly always considered the minimal interface for cross
> package-building to be dpkg-buildpackage -a, and in practice
> there are other things you need to do for non-trivial packages (set
> CONFIG_SITE, set DEB_BUILD_OPTS=nocheck).

I believe invoking debian/rules by hand is an interface worth
supporting, even for cross builds, but the person calling debian/rules
by hand is certainly responsible for setting DEB_BUILD_OPTIONS=nocheck!

Hope that helps,
Jonathan


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

dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?

[Wookey]

I recently noticed that when building with dpkg-buildpackage there is
no need for the 

DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
DEB_HOST_GNU_TYPE  := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)

boilerplate in debian/rules 

You can just do the test:
ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))

and it works, so it looks like dpkg-buildpackage is now setting those
vars for us. This is good and sensible, it's just that it's news to me.

Anyone know when this happened and what if any, the limitations are?
It's certainly true in wheezy, squeeze, precise and oineiric. 

Should a package depending on this behaviour build-dep on a particular
dpkg version? As it already works in build-essential in stable do the
same rules apply as essential packages in stable (i.e no explicit
dependency required)? That would be consistent. Maybe it's been doing
it since forever?

Now, you can build packages without using dpkg-buildpackage by calling
rules directly, and in that case the rules file would need to call
dpkg-architecture, but someone would have to convince me that that was
an interface worth supporting for non-native builds, because I
have certainly always considered the minimal interface for cross
package-building to be dpkg-buildpackage -a, and in practice
there are other things you need to do for non-trivial packages (set
CONFIG_SITE, set DEB_BUILD_OPTS=nocheck). (and ensure various things
like toolchain and dpkg-cross are installed). And I don't think we want
that stuff in every single rules file.

This actually leads to a wider discussion about which tools should be
responsible for setting which things in order to get a consistent
build-environment for crossing. I don't think we've ever really
thought about it very hard - conventional practices have just sort of
collected.

Should dpkg-buildpackage set everything needed, or can we require a
higher-level cross-aware too for that? I have thus far taken the view
that dpkg-buildpackage does no more than set the architecture. A
calling tool (sbuild for multiarch building or xdeb for dpkg-cross
building) is responsible for setting up anything else in the
environment. But I reserve the right to modify this view over time. 

I've started a wiki page to collect good-practice guidelines.
contributions welcome.

http://wiki.debian.org/CrossBuildPackagingGuidelines

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20120329181005.gs26...@dream.aleph1.co.uk

Re: gconftool

[David Weinehall]

On Fri, Mar 30, 2012 at 12:13:55AM +0800, Thomas Goirand wrote:
> On 03/24/2012 07:17 AM, Michael Banck wrote:
> > This is a development list, please discuss user support issues or
> > general usage questions on debian-user.
> >   
> I don't see his rant against the gnome settings as
> a "support issue" or "general usage".

No, you're right. Rants don't really belong on any of our lists...

Also, we're not upstream.  Any issues that aren't Debian specific
should be filed in the upstream Bugzilla.


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20120329181453.gg17...@suiko.acc.umu.se

Re: [OT] NM vs. wicd (was: Re: On init in Debian)

[The Fungi]

On 2012-03-29 11:15:30 +0100 (+0100), Philip Hands wrote:
[...]
> I'd only use either to make flipping between wireless networks something
> where I don't need to keep the comandline incantations in my head
[...]

And indeed, I just "keep the commandline incantations in my head"
for ifupdown, wireless-tools, wpa_supplicant and friends with
reasonably flexible configurations. Roaming between known networks
works automatically, but sure when I want to connect to a new
wireless network I resort to scanning from the CLI to identify the
ESSID and then stuffing that into my config and restarting a few
things. I certainly wouldn't suggest it as a default for the Desktop
task, requires root privs among other issues, but there are
definitely still working solutions out there for those of us who
would rather wrestle with a manpage than some GUI (even a
curses-based one).
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }


-- 
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/20120329171013.gd...@yuggoth.org

Re: gconftool

[Thomas Goirand]

On 03/24/2012 07:17 AM, Michael Banck wrote:
> This is a development list, please discuss user support issues or
> general usage questions on debian-user.
>   
I don't see his rant against the gnome settings as
a "support issue" or "general usage".

By the way, I agree with him about the fact gnome settings
are as stupid as the windows registry, and not user friendly
at all.

Thomas


-- 
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/4f748a43.3020...@debian.org

Bug#666194: ITP: librg-blast-parser-perl -- very fast NCBI BLAST parser - binding for perl

[Laszlo Kajan]

Package: wnpp
Severity: wishlist
Owner: Laszlo Kajan 

* Package name: librg-blast-parser-perl
  Version : 0.02
  Upstream Author : Laszlo Kajan 
* URL : http://rostlab.org/
* License : Artistic
  Programming Lang: Perl
  Description : very fast NCBI BLAST parser - binding for perl

 This package contains perl binding for a very fast C/C++ library for NCBI
 BLAST -m 0 (default) output parsing.  BLAST results are returned in a
 convenient hash structure.



-- 
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/20120329154711.4428.73210.reportbug@debian-unstable.rostclust

Bug#666193: ITP: librostlab-blast -- very fast C++ library for parsing NCBI BLAST output

[Laszlo Kajan]

Package: wnpp
Severity: wishlist
Owner: Laszlo Kajan 

* Package name: librostlab-blast
  Version : 1.0.0
  Upstream Author : Laszlo Kajan 
* URL : http://rostlab.org/
* License : LGPL
  Programming Lang: C, C++
  Description : very fast C++ library for parsing NCBI BLAST output

 This package provides a very fast library for parsing the NCBI BLAST default
 (-m 0) output.



-- 
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/20120329154627.4377.87212.reportbug@debian-unstable.rostclust

Bug#666192: ITP: librostlab -- C++ library from the Rost Lab

[Laszlo Kajan]

Package: wnpp
Severity: wishlist
Owner: Laszlo Kajan 

* Package name: librostlab
  Version : 1.0.20
  Upstream Author : Laszlo Kajan 
* URL : http://rostlab.org/
* License : LGPL-3+
  Programming Lang: C++
  Description : C++ library from the Rost Lab

 The library provides the following facilities:
 * current working directory resource
 * exception with stack backtrace
 * file lock resource
 * passwd and group structures for C++
 * effective uid and gid resource
 * rostlab::bio::seq class with stream input operator for FASTA format
 * umask resource



-- 
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/20120329153955.4331.70988.reportbug@debian-unstable.rostclust

Re: [OT] NM vs. wicd (was: Re: On init in Debian)

[Vincent Lefevre]

On 2012-03-29 11:15:30 +0100, Philip Hands wrote:
> I'd only use either to make flipping between wireless networks something
> where I don't need to keep the comandline incantations in my head
> anyway, so the last thing I need is NM noticing that I've plugged or
> unplugged an ethernet cable, and doing something about it.
> 
> Clearly, other people want to be able to plug an ethernet cable in and
> have it Just Work.

Well, wicd has problems when I unplug an ethernet cable and plug it
again: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557156

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20120329111705.gm9...@xvii.vinc17.org

Re: test "/etc/init.d/MyPackage start" before shipping, please

[Jon Dowland]

On Sat, Mar 24, 2012 at 10:32:00AM +0800, jida...@jidanni.org wrote:
> It doesn't matter who is to blame.
> A simple /etc/init.d/... start test could catch such grave bugs before
> they hit the user.
> Who is to blame could be figured out internally.

Of course it matters.  If you don't understand the explanations being
offered to you then kindly stop offering half-baked "suggestions" to
real developers and let them get on with their volunteering in peace.


-- 
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/20120329105201.GD32743@debian

[OT] NM vs. wicd (was: Re: On init in Debian)

[Philip Hands]

On Thu, 29 Mar 2012 10:20:50 +0200, Mike Hommey  wrote:
...
> I could file bugs, but I have so many problems that I'm better off
> switching to NM.

Well, that's constructive -- well done.

I think you'll find that there are two groups of users (at least), one
that is relatively happy with the assumptions made by the NM developers,
another who are driven immediately insane by how broken those
assumptions are.

I'm in the latter camp, so I ran screaming from NM to wicd, and have
been fairly happy ever since, but then I don't use gnome, I do use
interesting bridging and VPN setups, and I fairly often have wired and
wireless connections running at the same time, so I shouldn't really
expect NM to be a good fit for me, and I don't.

Wicd does have rough edges, but they make some sort of sense to me,
whereas NM just fights with what I wanted to happen.

I'd only use either to make flipping between wireless networks something
where I don't need to keep the comandline incantations in my head
anyway, so the last thing I need is NM noticing that I've plugged or
unplugged an ethernet cable, and doing something about it.

Clearly, other people want to be able to plug an ethernet cable in and
have it Just Work.

It seems to me that most of the people complaining about either of these
are actually complaining about their own preferences, and how they are
not served as well by one tool than another.

This has sod all to do with init variants.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgp4vT4beJ65R.pgp
Description: PGP signature

Re: On init in Debian

[Mike Hommey]

On Thu, Mar 29, 2012 at 10:09:57AM +0200, Vincent Lefevre wrote:
> On 2012-03-29 02:43:33 +0200, Carlos Alberto Lopez Perez wrote:
> > $ sudo apt-get remove network-manager*
> > $ sudo apt-get install wicd wicd-curses wicd-gtk
> > ^ wicd-kde ?
> > $ wicd-curses
> > 
> > And enjoy your network without the NM mess :)
> 
> Well, wicd has its own bugs, such as preventing a laptop from
> suspending.

Or an absolutely horrible UI, no helper for vpns, auto-reconnection not
working after a connection loss (works at boot, fortunately), randomly
taking 30 seconds to shutdown, and not able to connect to WPA
enterprise.

And this is not just years-old hearsay, like most complains about NM,
it's first-hand experience with the package currently in
wheezy/unstable.

I could file bugs, but I have so many problems that I'm better off
switching to NM.

Mike


-- 
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/20120329082050.ga12...@glandium.org

Re: On init in Debian

[Vincent Lefevre]

On 2012-03-29 02:43:33 +0200, Carlos Alberto Lopez Perez wrote:
> $ sudo apt-get remove network-manager*
> $ sudo apt-get install wicd wicd-curses wicd-gtk
> ^ wicd-kde ?
> $ wicd-curses
> 
> And enjoy your network without the NM mess :)

Well, wicd has its own bugs, such as preventing a laptop from
suspending.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20120329080957.gl9...@xvii.vinc17.org

Re: On init in Debian

[Svante Signell]

On Thu, 2012-03-29 at 15:35 +0900, Miles Bader wrote:
> Carlos Alberto Lopez Perez  writes:
> > $ sudo apt-get remove network-manager*
> > $ sudo apt-get install wicd wicd-curses wicd-gtk
> > ^ wicd-kde ?
> > $ wicd-curses
> >
> > And enjoy your network without the NM mess :)
> 
> ... unless, of course, you're using gnome-shell, which currently doesn't
> work without network-manager...!

I'm using the fall-back mode of gnome3, i.e. no gnome-shell, right? Then
I would be safe.


-- 
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/1333005709.8013.98.ca...@hp.my.own.domain