On 26/08/10 at 00:32 +0200, Ana Guerrero wrote:
> On Thu, Aug 26, 2010 at 12:08:54AM +0200, Lucas Nussbaum wrote:
> > > About the change, I think caring about the status in Ubuntu should be
> > > something you choose and not something that is thrown at you by default
> > > whether you want it or n
Recebi e estou repassando...
dicas valiosas de como evitar os roubos e assaltos, repassem para seus
seguidores...
assista o video em >>>
http://www.youtube.com/watch?v=u3DLbvIOR4o&feature=player_embedded
Fiquem com Deus
Aline Ferraz
São Paulo/SP.
On Wed, Aug 25, 2010 at 6:38 PM, Christian PERRIER wrote:
> Quoting Russ Allbery (r...@debian.org):
>
>> > Hmhm, out of curiosity, why is t-p-u “way riskier”.
>>
>> Mostly because there isn't any large pool of systems using t-p-u the way
>> there is for unstable, so the aging process where we get
Chris writes:
> I admit, I am still very new to this process.
> If I can, I would be glad to help out during the Freeze process
> if any kind soul would be willing to discuss this off list with me.
For the benefit of readers of debian-devel who don't read
debian-mentors:
I already replied to Ch
On Wed, 25 Aug 2010 02:09:03 +0100
Ben Hutchings wrote:
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can
> add stuff to the next release.
>
> Ben.
>
Greetings everyone,
I admit, I am still very new to th
* Ian Jackson [2010-08-25 13:42 +0100]:
> Perhaps the right answer is to simply ask people to upload
> non-release-related stuff to experimental rather than unstable. That
> way one can do the itch-scratching right away; moving packages from
> experimental to unstable later is easy ...
>
> Even be
Cyril Brulebois wrote:
> Kamaraju S Kusumanchi (25/08/2010):
>> How do I obtain a list of packages that have FTBFS bugs filed on
>> them and that are currently failing to build on i386 architecture?
>
> https://buildd.debian.org/status/architecture.php?a=i386&suite=unstable
>
> Click “Failed”.
On Wed, Aug 25, 2010 at 03:08:59PM +0200, Mike Hommey wrote:
> > - Improve or remove the restart popup that shows up when upgrading the
> > package.
One of the issues: the notification is shown when the upgrade starts, not
when it's actually done. This is especially bad when several dependant
p
On Thu, Aug 26, 2010 at 12:08:54AM +0200, Lucas Nussbaum wrote:
>
> Maybe (as often) only the ones disagreeing decided to participate in the
> thread on -...@? Also, the thread has been silent since the end of
> Debconf, so I'm quite surprised this come up now.
>
You sent the email in a very bad
Hi,
On 25/08/10 at 23:51 +0200, Ana Guerrero wrote:
> On Tue, Aug 03, 2010 at 11:19:06AM -0400, Lucas Nussbaum wrote:
> > On 01/08/10 at 17:00 -0400, Lucas Nussbaum wrote:
> > > Hi,
> > >
> > > There's an Ubuntu column on http://qa.debian.org/developer.php, but it
> > > is hidden by default, so m
On Tue, Aug 03, 2010 at 11:19:06AM -0400, Lucas Nussbaum wrote:
> On 01/08/10 at 17:00 -0400, Lucas Nussbaum wrote:
> > Hi,
> >
> > There's an Ubuntu column on http://qa.debian.org/developer.php, but it
> > is hidden by default, so many people ignore it exists.
> >
> > I propose to make it visibl
Kamaraju S Kusumanchi (25/08/2010):
> How do I obtain a list of packages that have FTBFS bugs filed on
> them and that are currently failing to build on i386 architecture?
https://buildd.debian.org/status/architecture.php?a=i386&suite=unstable
Click “Failed”. Usually, you get a “failing reason”
Goswin von Brederlow writes ("Re: Atlas proposal [and 1 more messages]"):
> Just dumping the compiled files into /usr/lib/ I find quite unacceptable
> too.
No, it is absolutely fine and it is what atlas-auto should do. It is
a simple matter for its postinst and postrm to deal with these files
exp
Ian Jackson writes:
> Goswin von Brederlow writes ("Re: Atlas proposal"):
>> I also have a package "local-archive" that depends on reprepro,
>> generates a local signing key on first install, adds that to the apt-get
>> keyring and adds a file:/// url in /etc/apt/sources.list.d/.
>
> I think this
Mike Hommey writes ("Re: For those who care about their packages in Debian"):
> On Wed, Aug 25, 2010 at 01:42:34PM +0100, Ian Jackson wrote:
> > Even better would be an option to write something in your .dsc which
> > would cause automatic transfer of your package into unstable when
> > testing is
Package: wnpp
Severity: wishlist
Owner: José Manuel Santamaría Lema
X-Debbugs-CC: debian-devel@lists.debian.org
Package name: krazy2
Version: 0
Upstream Author: Allen Winter
URL: http://www.englishbreakfastnetwork.org/
License: LGPL, MIT/X11 and others.
Description: KDE source code checker
Kraz
Package: wnpp
Severity: wishlist
Owner: Colin Watson
* Package name: dumpet
Version : 2.0
Upstream Author : Peter Jones
* URL : https://fedorahosted.org/dumpet/
* License : GPL-2+
Programming Lang: C
Description : dump information about bootable CDs a
On Wed, 25 Aug 2010 13:42:34 +0100, Ian Jackson
wrote:
>Perhaps the right answer is to simply ask people to upload
>non-release-related stuff to experimental rather than unstable. That
>way one can do the itch-scratching right away;
... if apt would finally support wildcards in preferences file'
Christoph Anton Mitterer writes:
> On Wed, 2010-08-25 at 11:05 +0200, Goswin von Brederlow wrote:
>> We already have the logic in there to mount anything as /.
> Well. at least if it's a very plain setup... (see
> http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices)
>
>
Manoj Srivastava writes:
> On Wed, Aug 25 2010, Ian Jackson wrote:
>
>> Goswin von Brederlow writes ("Re: Bug#592839: dpkg-source option to remove
>> files on unpack: debian/source/remove-files"):
>>> That was my point. Legally we CAN use those files. But we don't WANT to
>>> use them for DFSG r
On Wed, Aug 25 2010, Ian Jackson wrote:
> Goswin von Brederlow writes ("Re: Bug#592839: dpkg-source option to remove
> files on unpack: debian/source/remove-files"):
>> That was my point. Legally we CAN use those files. But we don't WANT to
>> use them for DFSG reasons.
>
> I think we are in vigo
So maybe these transient homepages (remember they only show up when
the xulrunner version changes, which won't happen in squeeze
stable/security updates or when running iceweasel for the first
time) should just thank users, and point to some useful links/rss
feeds and be done with it.
On the oth
On Wed, Aug 25, 2010 at 03:44:54PM +0200, Fabian Greffrath wrote:
> >So maybe these transient homepages (remember they only show up when
> >the xulrunner version changes, which won't happen in squeeze
> >stable/security updates or when running iceweasel for the first
> >time) should just thank user
On 25/08/10 at 09:05 -0400, Kamaraju S Kusumanchi wrote:
> How do I obtain a list of packages that have FTBFS bugs filed on them and
> that are currently failing to build on i386 architecture?
>
> I can see a list of RC-bugs at http://bugs.debian.org/release-
> critical/debian/main.html . I can d
On Wed, 2010-08-25 at 11:05 +0200, Goswin von Brederlow wrote:
> We already have the logic in there to mount anything as /.
Well. at least if it's a very plain setup... (see
http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices)
> /usr can't be
> any harder so that isn't
On Wed, Aug 25, 2010 at 01:42:34PM +0100, Ian Jackson wrote:
> Russ Allbery writes ("Re: For those who care about their packages in Debian"):
> > Ben Hutchings writes:
> >
> > > Please stop filing ITPs and concentrate on packages that should be
> > > included in squeeze. The sooner squeeze is ou
Hi,
For those not reading debian-rele...@l.d.o, I planned to include some
further changes to iceweasel before the freeze, except that the freeze
happened earlier than I expected. Anyways, the plan was more or less
accepted by the release team, but now that I actually started to make
the changes, I
How do I obtain a list of packages that have FTBFS bugs filed on them and
that are currently failing to build on i386 architecture?
I can see a list of RC-bugs at http://bugs.debian.org/release-
critical/debian/main.html . I can download that page and grep it for FTBFS.
However, most of the FTBF
Russ Allbery writes ("Re: For those who care about their packages in Debian"):
> Ben Hutchings writes:
>
> > Please stop filing ITPs and concentrate on packages that should be
> > included in squeeze. The sooner squeeze is out, the sooner you can add
> > stuff to the next release.
>
> This come
On Wed, Aug 25, 2010 at 11:37:44 (CEST), Goswin von Brederlow wrote:
> I also have a package "local-archive" that depends on reprepro,
> generates a local signing key on first install, adds that to the apt-get
> keyring and adds a file:/// url in /etc/apt/sources.list.d/.
This sounds interesting
On Wed, 2010-08-25 at 00:45 -0700, Russ Allbery wrote:
[...]
> That last bucket of time is simply not available to work on the squeeze
> release, period. If I weren't spending it on packaging new things for
> Debian, I would not be spending it on Debian *at all*. I don't think you
> actually woul
Goswin von Brederlow writes ("Re: Atlas proposal"):
> I also have a package "local-archive" that depends on reprepro,
> generates a local signing key on first install, adds that to the apt-get
> keyring and adds a file:/// url in /etc/apt/sources.list.d/.
I think this scheme is a very bad idea. I
Goswin von Brederlow writes ("Re: Bug#592839: dpkg-source option to remove
files on unpack: debian/source/remove-files"):
> That was my point. Legally we CAN use those files. But we don't WANT to
> use them for DFSG reasons.
I think we are in vigorous agreement, but your tone makes me hesitate.
L
Quoting Russ Allbery (r...@debian.org):
> > Hmhm, out of curiosity, why is t-p-u “way riskier”.
>
> Mostly because there isn't any large pool of systems using t-p-u the way
> there is for unstable, so the aging process where we get testing in
> unstable before migrating the package never happens.
On 25/08/10 at 11:43 +0200, Yves-Alexis Perez wrote:
> On 25/08/2010 10:13, Russ Allbery wrote:
> > Yves-Alexis Perez writes:
> >> Hmhm, out of curiosity, why is t-p-u “way riskier”.
> >
> > Mostly because there isn't any large pool of systems using t-p-u the way
> > there is for unstable,
>
> Y
Le mercredi 25 août 2010 à 11:37 +0200, Goswin von Brederlow a écrit :
> To support building atlas on one system and installing it on many you
> may want to use Depends: libatlas3gf-base | libatlas3gf-auto |
> libatlas3gf-remote, libatlas3gf-base | libatlas3gf-custom.
>
> The -base is the prebuild
On 25/08/2010 10:13, Russ Allbery wrote:
> Yves-Alexis Perez writes:
>> Hmhm, out of curiosity, why is t-p-u “way riskier”.
>
> Mostly because there isn't any large pool of systems using t-p-u the way
> there is for unstable,
Yeah, good point.
>
>> Would it be possible (at one point) to “fix”
Sylvestre Ledru writes:
> For now, the solution I imagine is:
> * build the package libatlas3gf-base just like it is now
> * the libatlas3gf-auto package contains the upstream tarball + the
> content of the debian/ directory
> * libatlas3gf-auto has dependencies on the build dependencies
> * when
Package: wnpp
Severity: wishlist
Owner: Alessio Treglia
* Package name: dkopp
Version : 5.4
Upstream Author : Michael Cornelison
* URL : http://kornelix.squarespace.com/dkopp/
* License : GPL
Programming Lang: C
Description : incremental backup tool to
The Fungi writes:
> On Fri, Aug 20, 2010 at 10:45:04PM +0200, Christoph Anton Mitterer wrote:
>> Of course,.. but only because your /usr is on the root-fs.
>>
>> And there are many good reasons to put it on its own fs, as already
>> outlayed here...
> [...]
>
> No disagreement there... I'm much
Ian Jackson writes:
> Goswin von Brederlow writes ("Re: Bug#592839: dpkg-source option to remove
> files on unpack: debian/source/remove-files"):
>> No. The files must be legal to be included. They are distributed in the
>> tarball after all. So deleting or not deleting makes absolutely no
>> di
Simon Richter writes:
> Hi,
>
> I think that we should be aiming towards descriptive domain-specific
> languages rather than imperative catch-all ones wherever possible. In
> the old days before debhelper, the rules file would explicitly move
> files around, and I think .install files are a huge
Yves-Alexis Perez writes:
> On 25/08/2010 10:02, Russ Allbery wrote:
>> Uploading new versions of leaf software isn't *as* big of a disaster,
>> but it does mean that updates to that software that should go into
>> testing can't go through the normal testing process and have to go
>> through test
On 25/08/2010 10:02, Russ Allbery wrote:
> Uploading new versions of leaf software isn't *as* big of a disaster, but
> it does mean that updates to that software that should go into testing
> can't go through the normal testing process and have to go through
> testing-proposed-updates, which is way
Ben Finney writes:
> But the solution would best entail allowing ‘unstable’ to continue to be
> used for the same purpose regardless of whether a freeze is currently
> active, no?
This, *in general*, doesn't work because of the way library transitions
work. If you upload a new upstream version
Russ Allbery writes:
> I, and I suspect many other people who are working on packaging new
> software for their own reasons, am quite aware of the release and are
> trying to stay out of the way.
+1
Though I'm not currently packaging any new software during this freeze,
I've worked with people
Ben Hutchings writes:
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can add
> stuff to the next release.
This comes up with every release, so I guess I'll reiterate what I end up
saying during every release.
Le mercredi 25 août 2010 à 02:09 +0100, Ben Hutchings a écrit :
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can add
> stuff to the next release.
I second that, and would also suggest to extend this to the ti
Ben Hutchings wrote:
Hi,
> Please stop filing ITPs and concentrate on packages that should be
> included in squeeze. The sooner squeeze is out, the sooner you can add
> stuff to the next release.
I'd add: stop uploading new upstream versions to unstable, or actually
any revision that isn't nee
49 matches
Mail list logo
