Bug#657824: ITP: fftpack5 -- FORTRAN library of fast Fourier transforms

[Youhei SASAKI]

Package: wnpp
Owner: Youhei SASAKI 
Severity: wishlist

* Package name: fftpack5
  Version : 5.1
  Upstream Author : Paul Swarztrauber, Dick Valent
  Copyright holder: University Corporation for Atmospheric Research
* URL or Web page : https://www2.cisl.ucar.edu/resources/legacy/fftpack5
* License : NCL Source Code License (BSD-3-clause like)
  Description : FORTRAN library of fast Fourier transforms

The Library FFTPACK 5.1 contains 1D, 2D, and multiple fast Fourier
subroutines, written in Fortran 77, for transforming real and complex
data, real even and odd wave data, and real even and odd quarter-wave
data.

This library is extended version of fftpack, distributed at netlib.org
---
Youhei SASAKI 
  
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07



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

Bug#657825: ITP: umegaya -- Umegaya is a MEtadata GAtherer using YAml

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy 

  Package name: umegaya
  Version : 0
  Upstream Author : Charles Plessy 
  URL : http://upstream-metadata.debian.net/
  License : BOLA-1.1
  Programming Lang: Perl
  Description : Umegaya is a MEtadata GAtherer using YAml

Hello everybody,

I really liked one thing Raphaël wrote during his DPL campaign:

  “Use what we package and package what we use.”

I therefore plan to package the scripts running upstream-metadata.debian.net.

I hope that it will help to make the service more reliable, and help
people to understand how it works.

Have a nice Sunday,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan



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

Bug#657897: ITP: blimps -- FHCRC BLocks IMProved Searcher

[Laszlo Kajan]

Package: wnpp
Severity: wishlist
Owner: Laszlo Kajan 


* Package name: blimps
  Version : 3.9
  Upstream Author : Jorja Henikoff 
* URL : ftp://ftp.ncbi.nih.gov/repository/blocks/unix/blimps/
* License : FHCRC NONCOMMERCIAL LICENSE 

  Programming Lang: C
  Description : blocks database improved searcher

BLIMPS (BLocks IMProved Searcher) is a searching tool that scores
a sequence against blocks or a block against sequences.



-- 
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/20120129173819.11090.15839.report...@rostlab.informatik.tu-muenchen.de

Re: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
> Featuresets
> ---
> 
> The only featureset provided will be 'rt' (realtime), currently built
> for amd64 only.  If there is interest in realtime support for other
> architectures, we may be able to add that.  However, we do need to
> consider the total time taken to build binary packages for each
> architecture.
> 
> If there are particular container features that should be enabled or
> backported to provide a useful replacement for OpenVZ or VServer,
> please let us know.  We cannot promise that these will all be enabled
> but we need to know what is missing. 

So in the end what are the reasons for not trying the grsecurity
featureset? #605090 lacks any reply from the kernel team since quite a
while, and especially after answers were provided to question asked.

Not doing anything is indeed a way to just get rid of the question, but
I would have at least appreciated a definitive answer on the bug rather
than via the dda mail.

Regards,
-- 
Yves-Alexis


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

Re: alioth is down (again)

[Poison Bit]

On Sun, Jan 29, 2012 at 2:15 PM, Stephen Gran  wrote:
> Hello,
>
> Unfortunately, one of the pair of machines providing the alioth service
> (vasks.debian.org) won't power on.  We are working on it, and apologize
> for any inconvenience caused.
>
> Cheers,


Hello,

  First, thanks from a plain user, to all people working to provide
infrastructure to Debian project.

  Second, a suggestion or some brain dump about ideas on howto improve
the issues communication:

  I imagine the scenario, where some DD is trying to work from any
place in the world. Nowadays, there are many points to check if a
service is not working... is it my last upgrade? is it my last config
change? is it my ISP? is it some intermediate ISP? is it the service
that is really down? of course, this kind of email notifications are
just fine to notify a known issue.

   So I ask myself... the reason to do not run "any" public monitoring
system, is much increase in the workload of the sysadmins ?  There are
different approaches to do it...

   approach one)  Run a public nagios, monit, whatever, configured
with templates to notify to this list on defined events (i.e. more
than 10 minutes down? the service, the DNS, the whole machine, the
whole network? is service recovered again?

   approach two)  Search across available opensource monitoring
systems, some than can run some "status.debian.org", so instead of
emails, users having an issue can lookup such dashboard, and see
present and past status or issues.

approach three)  Write a fast and furious bash/perl/python script
(can be cool to just use priority >= standard or as few depends as
possible), that takes a debian.org/infrastructure.yaml file (or .json
or .txt or xml or ...) that defines Debian machines and services...
the CLI client runs against such file (so it diagnoses that network
connection to d.o is ok in first instance) and prints a report of
unreachable services... (one run, one check. So no too much overload
unless lot of users synchronize a DoS, that can be done with or
without this tool).

approach four) Search or write a distributed monitoring service,
that provides the "one" or "two" approaches, but from different
geolocalized places, so after detect that a service/machine is down
"from here", it tries to communicate with other continents monitoring
systems and contrast results before "validate" the issue.

approach five) ... sure that people more clever than me, can
propose better solutions, to automate issue notification and
tracking... please do!

This is not one big neither important, "improvement front", to
Debian, these are just suggestions on ideas to improve the process,
from my personal view point, that of course maybe plainly wrong from
outside the project.  I can just help with details on the ideas, with
code if needed, and collaborate from my home aDSL to distributed
monitoring in case it's needed, but I think that my home connection
fails more often than Debian machines do.

Again thanks to every people doing the work.


--
Iñigo


--
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/CAKDTd8QhJ14=ubtwvstvqzxrfd5ejs9m9bhipkn_ha8w6nz...@mail.gmail.com

Re: alioth is down (again)

[Poison Bit]

On Sun, Jan 29, 2012 at 8:40 PM, Poison Bit  wrote:
[]

Add more brain dump:

The solution can be split:  monitoring for DD/NM services, and
monitoring for final users (i.e. websites, wiki, mailing lists and
official mirrors). Monitoring, dashboard, yaml file or whatever.

I use to think too much as final user... I.E. I could love to use a
Debian "anonymous DNS" servers instead of be tracked on 8.8.8.8 to get
publicity. Sorry it that annoys to someone.



Greetings.


-- 
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/CAKDTd8STJR1apjGDuUNk14-TDTz-=alj2b5rfvzmzg6kbun...@mail.gmail.com

Re: alioth is down (again)

[Martin Zobel-Helas]

Hi, 

On Sun Jan 29, 2012 at 20:40:57 +0100, Poison Bit wrote:
> On Sun, Jan 29, 2012 at 2:15 PM, Stephen Gran  wrote:
>   Second, a suggestion or some brain dump about ideas on howto improve
> the issues communication:
> 
>   I imagine the scenario, where some DD is trying to work from any
> place in the world. Nowadays, there are many points to check if a
> service is not working... is it my last upgrade? is it my last config
> change? is it my ISP? is it some intermediate ISP? is it the service
> that is really down? of course, this kind of email notifications are
> just fine to notify a known issue.
> 
>So I ask myself... the reason to do not run "any" public monitoring
> system, is much increase in the workload of the sysadmins ?  There are
> different approaches to do it...

There is a monitoring, but it seems most DDs and non-DDs do not care and
start to pester the admins directly [1].

URL and access to the monitoring is documented publicly.


[1] http://lists.debian.org/debian-services-admin/2012/01/msg3.html
-- 
 Martin Zobel-Helas   | Debian System Administrator
 Debian & GNU/Linux Developer   |   Debian Listmaster
 GPG key http://go.debian.net/B11B627B  | 
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


-- 
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/20120129201303.gc3...@ftbfs.de

Re: alioth is down (again)

[Andrew Starr-Bochicchio]

On Sun, Jan 29, 2012 at 3:13 PM, Martin Zobel-Helas  wrote:
> Hi,
>
> On Sun Jan 29, 2012 at 20:40:57 +0100, Poison Bit wrote:
>> On Sun, Jan 29, 2012 at 2:15 PM, Stephen Gran  wrote:
>>   Second, a suggestion or some brain dump about ideas on howto improve
>> the issues communication:
>>
>>   I imagine the scenario, where some DD is trying to work from any
>> place in the world. Nowadays, there are many points to check if a
>> service is not working... is it my last upgrade? is it my last config
>> change? is it my ISP? is it some intermediate ISP? is it the service
>> that is really down? of course, this kind of email notifications are
>> just fine to notify a known issue.
>>
>>    So I ask myself... the reason to do not run "any" public monitoring
>> system, is much increase in the workload of the sysadmins ?  There are
>> different approaches to do it...
>
> There is a monitoring, but it seems most DDs and non-DDs do not care and
> start to pester the admins directly [1].
>
> URL and access to the monitoring is documented publicly.

Do you mean: http://db.debian.org/machines.cgi

If so, it's not reporting vasks as down, but that still seems to be
the case. If you're referring to something else, I'd love to know
about it.

Thanks!

-- Andrew Starr-Bochicchio

   Ubuntu Developer 
   Debian Maintainer

   PGP/GPG Key ID: D53FDCB1


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

Re: alioth is down (again)

[Patrick Matthäi]

Am 29.01.2012 20:52, schrieb Poison Bit:
> On Sun, Jan 29, 2012 at 8:40 PM, Poison Bit  wrote:
> []

[...]

> I use to think too much as final user... I.E. I could love to use a
> Debian "anonymous DNS" servers instead of be tracked on 8.8.8.8 to get
> publicity. Sorry it that annoys to someone.

Providing infrastructure services like DNS is not the job of a
distribution, but providing software for doing this on your own, which
is the case :-)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Re: alioth is down (again)

[Salvatore Bonaccorso]

Hi Andrew

On Sun, Jan 29, 2012 at 03:53:21PM -0500, Andrew Starr-Bochicchio wrote:
> On Sun, Jan 29, 2012 at 3:13 PM, Martin Zobel-Helas  wrote:
> > Hi,
> >
> > On Sun Jan 29, 2012 at 20:40:57 +0100, Poison Bit wrote:
> >> On Sun, Jan 29, 2012 at 2:15 PM, Stephen Gran  wrote:
> >>   Second, a suggestion or some brain dump about ideas on howto improve
> >> the issues communication:
> >>
> >>   I imagine the scenario, where some DD is trying to work from any
> >> place in the world. Nowadays, there are many points to check if a
> >> service is not working... is it my last upgrade? is it my last config
> >> change? is it my ISP? is it some intermediate ISP? is it the service
> >> that is really down? of course, this kind of email notifications are
> >> just fine to notify a known issue.
> >>
> >>    So I ask myself... the reason to do not run "any" public monitoring
> >> system, is much increase in the workload of the sysadmins ?  There are
> >> different approaches to do it...
> >
> > There is a monitoring, but it seems most DDs and non-DDs do not care and
> > start to pester the admins directly [1].
> >
> > URL and access to the monitoring is documented publicly.
> 
> Do you mean: http://db.debian.org/machines.cgi
> 
> If so, it's not reporting vasks as down, but that still seems to be
> the case. If you're referring to something else, I'd love to know
> about it.

Martin Zobel-Helas is probably refering to the DSA Wiki [1].

 [1] http://dsa.debian.org/

Hope that helps,
Salvatore


signature.asc
Description: Digital signature

Re: from / to /usr/: a summary

[Wouter Verhelst]

On Sat, Jan 28, 2012 at 09:41:37PM +0100, Marco d'Itri wrote:
> On Jan 27, Wouter Verhelst  wrote:
> 
> > Do I understand you correctly that an empty configuration file in /etc
> > will override its 'full' equivalent in /usr? I.e., just an empty file
> > full of comments saying "this is what you can do with this file" will
> > break some things?
> This is correct.
> 
> > If so, are there some things in udev which intrinsically depend on that
> > behaviour?
> Documentation and consistency with all other distributions.

I wasn't trying to suggest Debian-specific changes. Upstream mistakes
(if they are that) should be fixed upstream, not in Debian.

> The only alternative solution which I consider acceptable would be to
> move everything back to /etc and then symlink the /usr/lib/ directory to
> the /etc/ directory.
> But I am sure that you can understand why this transition would be hard
> and messy for the maintainers of the affected packages at this point in 
> time.

Sure.

> BTW, I want to point out that Rusty Russell neatly summarized the points 
> of the / to /usr argument: http://rusty.ozlabs.org/?p=236 .

Yes, though it's a fairly silly representation of the "anti" side.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20120129212319.gd4...@grep.be

Re: Linux 3.2 in wheezy

[Ben Hutchings]

On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
> On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
> > Featuresets
> > ---
> > 
> > The only featureset provided will be 'rt' (realtime), currently built
> > for amd64 only.  If there is interest in realtime support for other
> > architectures, we may be able to add that.  However, we do need to
> > consider the total time taken to build binary packages for each
> > architecture.
> > 
> > If there are particular container features that should be enabled or
> > backported to provide a useful replacement for OpenVZ or VServer,
> > please let us know.  We cannot promise that these will all be enabled
> > but we need to know what is missing. 
> 
> So in the end what are the reasons for not trying the grsecurity
> featureset? #605090 lacks any reply from the kernel team since quite a
> while, and especially after answers were provided to question asked.

You already know the main reason:
> Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
> gcc plugins or hardening features like symbols hiding, fix bugs (for
> example in RBAC code), while few of them reach mainline.

I realise that the mainline Linux developers have sometimes been
unreasonably resistant to these changes and I'm not intending to assign
blame for this.  But practically this means that we have to either carry
the featureset indefinitely or disappoint users by removing it in a
later release.  (See the complaints about removing OpenVZ in wheezy
despite 4 years' advance notice of this.)

It also appears that you never had any response to your question to
upstream about minimising the patch set.

> Not doing anything is indeed a way to just get rid of the question, but
> I would have at least appreciated a definitive answer on the bug rather
> than via the dda mail.

I'm sorry about that; it completely slipped my mind as there have been
no discussions about it for some months.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.


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

-fPIE and stuff

[Sune Vuorela]

Hi

One of my upstreams of a collection of shared libraries is about to make
a change that is going to require all executables built against these
shared libraries to be built with -fPIE (and libraries with -fPIC).

Is there anything I should be aware of?

A bit of background:
http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/
http://www.macieira.org/blog/2012/01/update-and-benchmark-on-the-dynamic-library-proposals/

/Sune


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

Re: -fPIE and stuff

[Russ Allbery]

Sune Vuorela  writes:

> One of my upstreams of a collection of shared libraries is about to make
> a change that is going to require all executables built against these
> shared libraries to be built with -fPIE (and libraries with -fPIC).

> Is there anything I should be aware of?

First, the bit that you already know, but saying it for the record here:
Libraries with -fPIC is, of course, already expected.  There are only a
few exceptions for speed reasons on register-constrained architectures.
I'd generally say that if the library isn't so performance-critical that
the maintainers consider reimplementing parts of it in hand-coded
assembly, just always use -fPIC.

For PIE, the main practical problem with PIE is that PIE and PIC conflict,
so you can't just add -fPIE to the compiler flags of a package that builds
both executables and libraries.  That's the only reason why I'm not now
building all of my binaries PIE.  So I think there's no problem with just
going along with upstream on this change; more and more of the archive is
going to be built PIE anyway as hardening flags slowly make their way into
our packages.

Both consume a register on i386, which is a problem because i386 is
ridiculously register-constrained.  But it's not a significant issue on
amd64, which the trend lines all say is the direction everything is going
anyway.

Debian doesn't currently do prelinking; Red Hat does (optionally), and
it's extremely annoying for intrusion detection software like Tripwire,
since the prelinking goes through and changes installed files and now the
checksums don't match.  That's the main reason why I'm not sure prelinking
is worth it; I'll take the speed hit from using non-prelinked binaries in
exchange for verifiable checksums.  (Of course, it would be great to have
both.)

> A bit of background:
> http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/
> http://www.macieira.org/blog/2012/01/update-and-benchmark-on-the-dynamic-library-proposals/

These are excellent, and a good companion to Ulrich Drepper's paper (also
linked there).  They go over good C shared library behavior; some of those
techniques (like hidden visibility for internal symbols and -Bsymbolic)
I've been using for some of my shared libraries for years now.

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

Re: Linux 3.2 in wheezy

[Christoph Anton Mitterer]

On Sun, 2012-01-29 at 21:26 +, Ben Hutchings wrote:
> > So in the end what are the reasons for not trying the grsecurity
> > featureset? #605090 lacks any reply from the kernel team since quite a
> > while, and especially after answers were provided to question asked.
Whew I'd also be waiting for this since... well since I knew about PaX ;)

I think, given the great security benefits it can give, it would be
really worth to have it in debian.

Especially as the linux-patch-grsecurity2 package uses to be heavily
unmaintained. :(


> You already know the main reason:
> > Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
> > gcc plugins or hardening features like symbols hiding, fix bugs (for
> > example in RBAC code), while few of them reach mainline.
> 
> I realise that the mainline Linux developers have sometimes been
> unreasonably resistant to these changes and I'm not intending to assign
> blame for this.
Yeah,... seeing it merged upstream would be the best, of course.


> But practically this means that we have to either carry
> the featureset indefinitely or disappoint users by removing it in a
> later release.  (See the complaints about removing OpenVZ in wheezy
> despite 4 years' advance notice of this.)
Well I guess you really don't have to bother on this :)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Linux 3.2 in wheezy

[Adam Borowski]

On Sun, Jan 29, 2012 at 09:26:11PM +, Ben Hutchings wrote:
> On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
> > On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
> > > Featuresets
> > > ---
> > > 
> > > The only featureset provided will be 'rt' (realtime)
> > > 
> > > If there are particular container features that should be enabled or
> > > backported to provide a useful replacement for OpenVZ or VServer,
> > > please let us know.  We cannot promise that these will all be enabled
> > > but we need to know what is missing. 
>  
> See the complaints about removing OpenVZ in wheezy despite 4 years'
> advance notice of this.

lxc wasn't anywhere near feature parity with vserver/openvz then.

It would be nice to have some documentation about how lxc is different from
them, and how to work around bugs and limitations.  I for one spent ~10
hours (ok, only) checking out lxc and I'm nowhere near comfortable enough to
even think about production use or migration yet.  There are tens of
thousands of sysadmins in this state so a list of caveats would be nice
(rather than mere howtos).

Example problems:

* how to uncorrupt ttys (ssh in works fine)?  Unlike a serial console,
  setting TERM, stty and TIOCGWINSZ seems to be not enough.

* how to execute a command in a running VM?  lxc-execute complains that the
  container is busy, forcing it results in processes in both sessions not
  seeing each other (ie, they end up in different cgroups instead of
  entering the existing one).

* how to ensure good isolation while still being able to do useful work? 
  The point of vserver is that even root inside a VM shouldn't be able to
  affect the host, on lxc you keep hurting the host by accident.  Messing
  with capabilities blindly is trial and error, which is precisely what you
  don't want to do in a system meant for security.

And so on, so on.  I bet there is documentation for every quirk somewhere
out there -- it's just that researching every question takes a long time
spent googling rather than doing useful work.  This is what people complain
about.

Such a list of migration issues won't write itself, but I'm afraid it would
take someone who knows lxc well rather than a person who takes features of
vserver or openvz for granted.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
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/20120130004459.ga22...@angband.pl

Bug#657932: ITP: ical2html -- create an HTML table from icalendar data

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: ical2html
  Version : 2.0
  Upstream Author : Bert Bos 
* URL : http://www.w3.org/Tools/Ical2html/
* License : W3C-Software 20021231
  Programming Lang: C
  Description : create an HTML table from icalendar data

 ical2html takes an iCalendar file and outputs an HTML file showing one
 or more months in the form of tables.
 .
 Also includes the iCalender utilities icalmerge and icalfilter.



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

Re: Summary of C++ symbols experience (was: Do symbols make sense for C++)

[Lisandro Damián Nicanor Pérez Meyer]

On Sáb 28 Ene 2012 02:28:25 Russ Allbery escribió:
[snip] 
> 2. Build and upload this version of the package.  Now wait for all the
>buildds to fail (because they will, on probably nearly every other
>architecture than your local one).

Sometimes we may expect FTBFSs due to changes in other archs toolchains not 
catched by the local arch, like missing symbols. This is when this may come 
handy:

override_dh_makeshlibs:
dh_makeshlibs -- -c0

If in your local arch you couldn't find missing symbols that create and ABI 
change, then chances that missing symbols in other archs are safe to ignore.

But take into account that I'm writing all this out of pure empiric trials, 
which are clearly not enough to assert it.

Kinds regards, Lisandro.

-- 
Wiki participants are, by nature, a pedantic, ornery, and unreasonable bunch.
So there's a camaraderie here we seldom see outside of our professional
contacts.
  http://www.c2.com/cgi/wiki?WhyWikiWorks

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Re: Summary of C++ symbols experience

[Russ Allbery]

Lisandro Damián Nicanor Pérez Meyer  writes:

> Sometimes we may expect FTBFSs due to changes in other archs toolchains not 
> catched by the local arch, like missing symbols. This is when this may come 
> handy:

> override_dh_makeshlibs:
> dh_makeshlibs -- -c0

> If in your local arch you couldn't find missing symbols that create and ABI 
> change, then chances that missing symbols in other archs are safe to ignore.

Oh!  I didn't know about that.  Yes, that would be superior to the
procedure that I outlined, since the diffs would still accumulate in the
build logs but one could then apply them at one's leisure instead of
needing to do another upload ASAP to solve FTBFS problems.

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

Re: Linux 3.2 in wheezy

[Marco d'Itri]

On Jan 30, Adam Borowski  wrote:

> lxc wasn't anywhere near feature parity with vserver/openvz then.
And it still isn't.

> It would be nice to have some documentation about how lxc is different from
> them, and how to work around bugs and limitations.  I for one spent ~10
Let's start with this: in its current form, it is not designed to
protect the host system from an untrusted root user in a guest.
So far lxc is nice for testing, but not much more.

http://blog.bofh.it/debian/id_413

> * how to execute a command in a running VM?  lxc-execute complains that the
Lack of something like VE_ENTER also makes it unsuitable for me.

>   container is busy, forcing it results in processes in both sessions not
>   seeing each other (ie, they end up in different cgroups instead of
>   entering the existing one).
AFAIK there is still no way to attach a process to an existing cgroup, 
so you need to have a sshd in the guest.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Kemeja seragam kerja, Kaos polo Shirt, kaos pilkada, kaos olahraga, kaos promosi dll.............................

[baru ams]

Salam persahabatan...
Sebelumnya kami mohon maaf jika Email ini mengganggu anda...

http://www.a-metrosport.com/

Kami menjual/ Ready Stock dan terima pesanan Kemeja seragam kerja, Kaos polo 
Shirt,
kaos seragam olah raga, Kaos promosi, kaos oblong polos, Kaos krah seragam, 
Stelan Training,
Seragam pabrik, seragam sekolah, Topi, Tas, training Dll. untuk keperluan apa 
saja. 


silahkan kunjungi toko online kami disini http://www.a-metrosport.com/


Data kontak bpk. mardhot
Telp  : 021- 315 9246
Hp:
Simpati : 0821 148999 71
XL : 0878 756132 77
Mentari : 0815 883 93 35
email: a.metrosp...@yahoo.co.id
   baru@gmail.com
Ym Id   : a.metrosport

Terima Kasih Telah Bersedia membaca email ini.


--
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/BARUAMSPC024b1398c90843beb56ffc5dcf0508ab@BaruAMSPC

Re: alioth is down (again)

[Paul Wise]

On Mon, Jan 30, 2012 at 3:40 AM, Poison Bit wrote:

>   approach one)  Run a public nagios, monit, whatever, configured
> with templates to notify to this list on defined events (i.e. more
> than 10 minutes down? the service, the DNS, the whole machine, the
> whole network? is service recovered again?

I don't think it would be appropriate to notify d-d-a or d-i-a on
every service flap. Servers are already monitored:

http://dsa.debian.org/
https://nagios.debian.org/nagios3/
http://munin.debian.org/

>   approach two)  Search across available opensource monitoring
> systems, some than can run some "status.debian.org", so instead of
> emails, users having an issue can lookup such dashboard, and see
> present and past status or issues.

http://dsa.debian.org/
https://nagios.debian.org/nagios3/
http://munin.debian.org/

>    approach three)  Write a fast and furious bash/perl/python script
> (can be cool to just use priority >= standard or as few depends as
> possible), that takes a debian.org/infrastructure.yaml file (or .json
> or .txt or xml or ...) that defines Debian machines and services...
> the CLI client runs against such file (so it diagnoses that network
> connection to d.o is ok in first instance) and prints a report of
> unreachable services... (one run, one check. So no too much overload
> unless lot of users synchronize a DoS, that can be done with or
> without this tool).

I guess DSA would welcome a patch adding machine-parsable output and
status information to this:

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

I guess the devscripts maintainers would also welcome a script to read
the resulting info and print it out.

>    approach four) Search or write a distributed monitoring service,
> that provides the "one" or "two" approaches, but from different
> geolocalized places, so after detect that a service/machine is down
> "from here", it tries to communicate with other continents monitoring
> systems and contrast results before "validate" the issue.

Sounds like something that would be doable with nagios, I suggest you
send a patch for DSA's puppet configuration when alioth returns:

git://anonscm.debian.org/mirror/dsa-puppet.git (currently down due to
alioth being down)
http://dsa.debian.org/howto/puppet-setup/

-- 
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/CAKTje6GLfm768u0Z1dvY2UjMU-jKXTk4Hnp=2qxkrlt82hv...@mail.gmail.com