r upload
accepted in the archive. The automated upload rejections are just an
additional hurdle to be able to get your upload into the archive, so
should certainly be fixed in whatever upload you do IMHO.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
e new dependencies.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Mike Hommey wrote:
> On Sun, Nov 08, 2009 at 12:53:18PM +0100, Mike Hommey wrote:
>> On Sun, Nov 08, 2009 at 12:48:11PM +0100, Luk Claes wrote:
>>> Hi
>>>
>>> Currently there are 4 rather big transitions going on, none of which is
>>> ready to transi
Mike Hommey wrote:
> On Sun, Nov 08, 2009 at 12:48:11PM +0100, Luk Claes wrote:
>> Hi
>>
>> Currently there are 4 rather big transitions going on, none of which is
>> ready to transition. Following are the things that currently are an
>> issue or that show
iscarded it quite uncomfortable, and a waste of time, disk space and
>> bandwidth.
>
> On the other side it prevents uploading unbuildable packages.
Exactly. This is one of the reasons binaryless uploads are not
considered atm.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-
So if it did not fail in the middle of a file, you can manually upload
the rest of the files with whatever ftp client you like (when you use
the ftp upload queue), you just have to make sure to only upload the
changes file at the end.
I've also experienced that the ssh upload queue does not
, if we're going to this direction, then let
> dput/dupload simply "ignore" .deb in the .changes, and the archive
> queue processes still accepts these "partial" uploads (still checking
> the .deb are in the .changes, of course), we'd have the best of both
>
ing and uploading
would work that would need some effort, though it should not be that
hard AFAICS.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
lications.
>-- The code is modified to interact with the user using a network
> connection
> with extremely low throughput.
Why would that cause any problem? It's not because one needs to provide
the source that it has to be downloaded AFAICS?
>-- The code is modif
for instance.
Thanks for looking at the listed issues though.
> Le dimanche 08 novembre 2009 à 12:48 +0100, Luk Claes a écrit :
>> - anjuta not yet built on all arches
>
> This is a consequence of the subversion FTBFS on said architectures. It
> can be given-back once svn
lem, but would make it smaller though.
I guess patches against wanna-build are welcomed.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
em
> away makes sense? Something that can not be answered without some hard
> data.
Noone is stopping anyone of preparing a service that would accept source
only uploads as a go between to find out at least some numbers and solve
the problem some are having with bandwidth or unre
ink it's good to waste buildd time on failing to build packages.
I also don't think anyone is stopped from setting up a service that
allows source-only uploads as a go-between.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Andreas Tille wrote:
> On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
>> I think one would be surprised how many packages get used on 'exotic'
>> architectures. Most users don't specifically search for a piece of
>> software, they want to hav
Clint Adams wrote:
> On Wed, Nov 18, 2009 at 07:41:51AM +0100, Luk Claes wrote:
>> I don't think it's good to waste buildd time on failing to build packages.
>> I also don't think anyone is stopped from setting up a service that
>> allows source-only uploads a
ld binary package depending on
> the old arch package which otherwise wouldn't be available anymore. From
> what I understand (and tried) apt does the right thing and chooses the
> most recent versions in cases where it doesn't matter anyway.
The solution consists of keeping
ak commands to the release file. This could be consolidated in
> batches and I can help for this, so that the work load is minimum, compared to
> the gain for everybody.
As IMHO there is added value in building a package on all release
architectures, there is no reason to change dpkg-gen
> The buildd would then build all of KDE and the buildd admin could sign
> it all in one go. That way you have potentially 0 uninstallable time.
It's very unlikely that the builds for all these packages ends up on the
same buildd, so in practice that would not work. It could be an
improvement though.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Goswin von Brederlow wrote:
> Philipp Kern writes:
>
>> On 2009-11-19, Luk Claes wrote:
>>> This could only work if the built package is needed on the same buildd
>>> it was built.
>> That depends on the assumptions. If the assumption is that the bui
d
> * Rebuild against newer libicu (Closes: XXX)
>
> to deban/changelog, build with pbuilder, upload with dput --delayed 2, and
> drop a mail to maintainer?
No, something elso should be done.
> Triggering binary-only NMUs on every architecture somehow?
Right [1].
Cheers
Luk
[1] h
strange build failure when generating the
debs, it would be good if someone can reproduce (or not ;-)) any of this
build failures (gnat-4.4, cmake, xulrunner) while the mipsel buildds are
catching up.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
Andreas Marschke wrote:
> On Saturday 28 November 2009 09:46:51 Luk Claes wrote:
>> gnat-4.4 FTBFS on mipsel which is blocking gcc-defaults from migrating
>> to testing which is blocking at least the poppler and gnome related
>> transitions. xulrunner was reuploaded again
Mike Hommey wrote:
> On Sat, Nov 28, 2009 at 09:46:51AM +0100, Luk Claes wrote:
>> Hi
>>
>> gnat-4.4 FTBFS on mipsel which is blocking gcc-defaults from migrating
>> to testing which is blocking at least the poppler and gnome related
>> transitions. xulrunner was
ing this. But until now I didn't get any response, so my question
> is, did I forgot something ? Or sent it to the wrong
> people ?
>
> See the following url too:
> https://buildd.debian.org/~luk/status/package.php?p=pdns-recursor
>
> Hopefully someone can help.
I guess
ct on proposals and hopefully agree on a way forward, there
won't be much disclosed.
I would rather not have sent this mail as some seem to try to block any
solution, though I'm sick of all the FUD and useless discussion and hope
that this will put things in perspective.
Ple
lex issues on the lists. So for these
issues we usually have real discussions on IRC, real life, phone or
private mail. The final result of these discussions is normally also on
the lists as proposals or announcements.
So I still think that Debian is an open project.
Cheers
Luk
--
To UNSUBSCR
in the other.
>
> Many still seem to think that Ubuntu is sufficiently close to Debian
> that work done in it should be easily transferrable. If this is not the
> case, maybe we need to start treating Ubuntu more like we do Fedora.
Because it is sufficiently close, mistakes learnt in on
Stefano Zacchiroli wrote:
> On Thu, Dec 03, 2009 at 07:45:30PM +0100, Luk Claes wrote:
>> Unfortunately Debian does not seem to be able to also have real
>> constructive discussion about complex issues on the lists. So for these
>> issues we usually have real discussions on
f changes if necessary" process. But we so much
> fear that the "private decision taking / announce on d-d-a" process will
> be used again that people ask that all discussions are public.
Yes, the fear is so big that many seem to think so called decisions are
unquestionable ex
on-elementtree
> Matthias Klose
>python2.4-doc
no reverse (build) dependencies
> Python Modules Packaging Team
>
>python-wsgiref (U)
no reverse (build) dependencies
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ges
installed. Note that the build essential set is not directly related to
priorities of packages...
Cheers
Luk
> At Wed, 23 Dec 2009 07:53:54 +0100,
> Soeren Sonnenburg wrote:
>> [1 ]
>> On Wed, 2009-12-23 at 15:28 +0900, Junichi Uekawa wrote:
>>> Sounds like a bug for
Julien Cristau wrote:
> On Sat, Dec 26, 2009 at 23:43:44 +0100, Luk Claes wrote:
>
>> Junichi Uekawa wrote:
>>> It seems like apt is not installed with debootstrap anymore.
>>> And it seems to be staying like this.
>>>
>>> I'm not sure when
age not being binNMUable is also a bug that should be fixed ofcourse...
and which is RC after being binNMUed ;-)
Cheers
Luk
--
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D
signature.asc
Description: OpenPGP digital signature
d Sid all have the necessary version.
> So can this build-dependency be dropped in packages using it?
Yes, it is not needed anymore and can be dropped.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Manoj Srivastava wrote:
> Hi,
>
> I would like to backport SELinux related packages to Etch, and
> thus would like to get my key into the backports key ring.What do I
> need to do to enable that?
Send a message to the Subject you used :-)
Cheers
Luk
--
To UNSUBS
ht want to read the section Testing-only bugs at [0] on why lenny-only
bugs might also be interesting to fix.
Cheers
Luk
[0] http://people.debian.org/~vorlon/rc-bugsquashing.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
versioning instead of less RC bugs, better udeb handling, automate
easy hinting, ease library transitions etc. which would IMHO help CUT.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
removing experimental would bring us anything but a
more experimental unstable...
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Gustavo Franco wrote:
On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote:
Gustavo Franco wrote:
> On 6/12/07, Joey Hess <[EMAIL PROTECTED]> wrote:
>> Gustavo Franco wrote:
I don't get it at all why removing experimental would bring us
anything but a
more experimental
Gustavo Franco wrote:
Hi Luk,
On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote:
Gustavo Franco wrote:
(...)
> * Switch unstable (release) for not automatic updates
They are only automatic as far as the Release Team wants them to be as
explained earlier...
I'm not writing ab
Gustavo Franco wrote:
On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote:
Gustavo Franco wrote:
> Hi Luk,
>
> On 6/12/07, Luk Claes <[EMAIL PROTECTED]> wrote:
>> Gustavo Franco wrote:
>>
>> > The benefit of the approach above from a RM point of view
ght question if the package should
> not be simply removed or uploaded to experimental. But you can simply
> ignore that package, so again, the annoyance should be minimal.
You should usertag these dummy RC bugs and ignore these when sending mails.
Cheers
Luk
--
To UNSUBSCRIBE, email to [
s that
maintainer agrees.
Now to the core:
A package cons that ships /usr/bin/cons and a package pscan that ships
/usr/bin/pscan makes sense and these binaries and project names exist for a
long time. Why do you think a rename of the files /usr/bin/cons and
/usr/bin/pscan in emboss is out of the ques
e forward
> to maintain the package if it is orphaned. If not, the package will
> be dropped eventually.
It probably doesn't put any burden on Debian QA as we will probably just
ignore it, till someone takes it over or we decide to ask for removal. The
reason is that the package has no re
ead upstream is not sufficient cause to drop a package perse. Though it
should be sufficient to think about dropping or migrating the package...
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
atch for all the bugs will probably be clear enough anyway
for these kind of bugs.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
#x27;s
worth to MBF for...
> * Trigger binNMU's for the affected packages (when lintian reports less
> issues
> on the rebuilt package) [2].
No, we are not going to binNMU to get less lintian warnings/errors
unless you could convince us it's worth it for particular clas
start over again. I
don't think we should stop it, rather make it happen soon.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
andard way to do that.
>
>> The standard way is to remove the symlinks in /etc/rc?.d
>
> No, the standard way is to *rename* the S symlinks to K symlinks.
One draw back is that it's not obvious what used to be an S link if you
want to reenable them, that's why I rename them
means that you shouldn't try to fix these kind of bugs via
testing-proposed-updates as they wouldn't be accepted anyway as they
don't get the usual testing from aging in unstable...
Cheers
Luk
> Le dimanche 27 juillet 2008 à 16:00 +0200, Marc 'HE' Brockschmidt a
>
ugh some not as short-term as
others... Long term issues should be in Packages-arch-specific.
Some NFUs are used for long-term (non-)issues currently, though that's
not at all what it's supposed to be used for. It would be better if that
just changed...
Cheers
Luk
--
To UNSUBSCR
ould rather be able to file bugs against 'User's next to
(pseudo)packages which would probably solve the pseudo packages problem
in a cleaner way, would make them dynamic as they should be IMHO and
would not have the disadvantage of namespace issues...
Cheers
Luk
--
To UNSUBSCRIBE, em
James Troup wrote:
> * quinn-diff
I would like to take this one.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Daniel Burrows wrote:
> On Mon, Sep 01, 2008 at 08:01:29AM +0200, Luk Claes <[EMAIL PROTECTED]> was
> heard to say:
>> Release notes
>> ~
>> There is still quite a lot of work to be done on the lenny release notes.
>> Coordination for this
--
Hi
Can someone please propose a text (under a GPL v2 license) regarding
this issue for inclusion in the release notes?
Thanks already.
Luk
--- End Message ---
Hi
Is it still the case that one needs to manually add an (gpg checking)
exception for DVD images for upgrades from etch to lenny? If so, can
someone please provide a text (license: GPL v2) for inclusion in the
release notes?
Thanks already.
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
Jens Seidel wrote:
> On Sat, Oct 04, 2008 at 05:53:22PM +0200, Luk Claes wrote:
>> Is it still the case that one needs to manually add an (gpg checking)
>> exception for DVD images for upgrades from etch to lenny? If so, can
>> someone please provide a text (license: GPL v2)
on your package to be migrated to "Lenny".
>> * You are wasting the buildd's time.
>
> Is there any plan to fix things to allow separate uploads to testing and
> unstable for Lenny+1?
It's already existing, but we like packages to be tested *before* they
en
Russell Coker wrote:
> On Tuesday 07 October 2008 07:25, Luk Claes <[EMAIL PROTECTED]> wrote:
>>> Is there any plan to fix things to allow separate uploads to testing and
>>> unstable for Lenny+1?
>> It's already existing, but we like packages to be
this?
Contact the release team to see if it's possible to unblock the
dependency or if an upload to tpu is preferred.
In this case, please upload to testing-proposed-updates.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gt;
> Seems to be fixed in t-p-u, but hasn't migrated to testing yet. [1] says
> "Unblock request by luk ignored due to version mismatch". Is that normal?
>
> [1] http://packages.qa.debian.org/m/matplotlib.html
Yes, quite normal when the t-p-u version has migrat
gs won't
get fixed. As always we don't object that lenny-ignore bugs would get
fixed before lenny.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Manoj Srivastava wrote:
> On Tue, Oct 21 2008, Luk Claes wrote:
>
>> Manoj Srivastava wrote:
>>> On Mon, Oct 20 2008, Stefano Zacchiroli wrote:
>>>
>>>> On Mon, Oct 20, 2008 at 09:38:00PM +0200, Adeodato Simó wrote:
>>>> ... and if it is *not*
elease Team or the QA Teams have any objection to qmail
> being included in Lenny?
We are in a freeze, having the latest release preparations, so
introducing completely new packages in the release is not an option.
I'm also not convinced that introducing yet another MTA which seems
infer
lthough we made some progress. Personally I
would like to get rid of it before Squeeze preferably with ported
applications or alternatives.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
; ;-)
It was a problem in the interaction of the BTS with the archive AFAIK,
so not only bts.turmzimmer.net, but also for instance all the version
graphs were affected.
It was already known for days, Don was investigating together with FTP
Team was the last update I got.
Cheers
Luk
--
To UNSUBSCRI
Olivier Berger wrote:
> Hi.
>
> Le jeudi 11 décembre 2008 à 19:24 +0100, Luk Claes a écrit :
>> Neil Williams wrote:
>>> On Thu, 11 Dec 2008 11:32:47 +
>>> Neil Williams wrote:
>>>
>>>> The graph on the Unofficial RC bugs count page ha
r have suggested quite some
different things which could have made it cleaner instead IMHO.
> Seems liek there was plenty of time to change things, and add
> some of the power set options on to the ballot. If I had added options
> willy-nilly, you would have screamed again of ab
amp;rev=0&sc=0
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ossibly being fixed in a release update, I would close them
mentioning that the package has been removed.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
S for the core
functionality. If you don't like audacious to get many more users
because of it, we might indeed consider other replacements...
Cheers
Luk
lly modify the RFC text.
Note that it still would be perfectly possible to restrict the use of
'RFC' for these modifications...
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
in wording and not mention GNU (though the actual
procedure you describe may be similar).
http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL
Paraphrasing Luk Claes:
besides we as Debian only want our users the freedom to
be able to if they wanted it, to willy-nilly modify the
imes it's a great help if bug
submitters test if the problem still occurs in the latest version...
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
didn't use this library and know nothing
about complexity of timezones support in computing systems. It is
really hard piece of technology.
It's only logical to NOT start reading a patch of more than 38K lines,
so it's far easier if one would explain beforehand why it's tha
doesn't need to go
through three niveaus before one reaches frequently used programs? If
not would it be possible to consider making a section with the most used
installed programs (based on popcon for instance)?
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
ase stating if a person is MIA or not and just that
> info? It might be quite useful to us, non-DDs, it won't invade
> anyone's privacy and I don't think it would be difficult to implement.
If a person is really MIA they will loose their DD status, either
voluntary or forc
n say there is consensus for bugs older than 7 days. There
is also no real problem with the process for bugs newer than that, but I
would advise to focus on the first category.
The most important thing is of course to respect the maintainer and
please try to make sure your NMU is well tested.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi
Below you'll find a list of longtime orphaned packages with quite some
users. It would be great if people could adopt packages that are still
usefull and give alternatives and/or migration plans for packages that
are rather obsolete or not really usefull anymore.
Cheers
Luk
Bernd Zeimetz wrote:
>> http://packages.qa.debian.org/x/xmms-crossfade.html
>
> If I remember right gtk-1 is supposed to be removed from lenny, so xmms
> will be gone, too.
Yes, but this source package also builds audacious-crossfade which
probably should stay?
Cheers
Luk
--
Michal Čihař wrote:
> Hi
>
> Dne Wed, 31 Oct 2007 17:21:24 +0100
> Luk Claes <[EMAIL PROTECTED]> napsal(a):
>
>> Below you'll find a list of longtime orphaned packages with quite some
>> users. It would be great if people could adopt packages that are still
Bart Samwel wrote:
> tag 438665 wontfix
> merge 438665 445900
> thanks
>
> Clint Adams wrote:
>> reopen 438665
>> quit
>>
>> On Wed, Oct 31, 2007 at 06:22:11PM +0100, Luk Claes wrote:
>>> That sounds like the Dependens should be a Recommends, if s
Thomas Viehmann wrote:
> Luk Claes wrote:
>> http://packages.qa.debian.org/a/autobook.html
> Based on the submitter's observation in #328219, maybe we should remove
> autobook?
> If it's non-free and increasingly outdated and doesn't have anone
> wanting t
Ben Goodger wrote:
> On 31/10/2007, Luk Claes <[EMAIL PROTECTED]> wrote:
>> http://packages.qa.debian.org/libg/libglade.html
>> http://packages.qa.debian.org/libv/libvncserver.html
>
>
> AFAIK these are unofficially or officially deprecated:
> libglade is
d log. To make sure buildds won't wait forever
they stop the build proces, default it's 150 minutes, though it can be
configured per package.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
at hand).
Nowadays there are better alternatives to uploading to unstable for
archive wide testing IMHO. Uploading to experimental is a good thing to
have some initial testing on many architectures, though I would go for a
rebuild of the whole archive for testing things like this for all
packages..
..
> I also don't think that an inactive co-maintainer should be
> a justification to stop a package to migrate to testing.
> What is the rationale here?
Same as above, the active (co-)maintainer should drop the severity
otherwise it's better to orphan the package.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Nico Golde wrote:
> Hi Luk,
> * Luk Claes <[EMAIL PROTECTED]> [2007-12-08 18:21]:
>> Nico Golde wrote:
>>> Hi Mario,
>>> * Mario Iseli <[EMAIL PROTECTED]> [2007-12-06 21:33]:
> [...]
>>> What is the purpose of this? If the package is well
>
RC bug on monday, this might hold up the testing migration for a
> couple of days. Imagine there is a security fix waiting for migration. Do you
> want to keep this from migrating? Please don't make the work of the
> testing-security team harder ;)
By popular demand the MIA Team wi
y mentioned that the team decided to file with
severity important instead...
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Michael Banck wrote:
> On Sun, Dec 09, 2007 at 11:31:27PM +0100, Luk Claes wrote:
>> Please don't answer when you don't have read the whole thread... It was
>> already very clearly mentioned that the team decided to file with
>> severity important instead...
>
nt I feel there is no such a consensus.
I thought this consensus was already a fact and that some maintainers
just disagree and nobody forced them to change yet...
The reasons why it shouldn't be a native package IMHO:
* it's not specific to Debian
* it wastes bandwidth as every upload con
Wouter Verhelst wrote:
> On Sun, Dec 23, 2007 at 07:17:16PM +, Neil Williams wrote:
>> Luk Claes wrote:
>>> Neil Williams wrote:
>>>> i.e. native should be a last resort - used only when it is all but
>>>> impossible for the package to be used outsid
I personaly prefere Idea 1 over 3 over 2, but as said, i want to have an
> consensus and i already heard several other ideas and/or complains.
I would prefer 2 over 1 and 3, though I think it's more important to
have it included in the file than any particular format :-)
Cheers
Luk
ometimes just add an override when
> lintian makes a mistake rather than filing a bug, so this gives us a
> fighting chance of finding those bugs and fixing them. It also uncovers
> some fascinating overrides currently in the archive.
Great!
Cheers
Luk
--
To UNSUBSCRIBE, email t
rent version of
> wanna-build in use on our buildds may be found?
The current version is the one of the repository you mentioned. If you
mean the experimental version, well I suppose that's on one of Ryan's
machines.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
you'll
> have to start taking it over."
We can surely keep all old cruft in the archive and never release again
(or not with these packages anyway), though I don't think that is
preferred from a quality assurance, security nor release point of view...
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
e KDE transition is going
on before python 2.6 will be added.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
d...
>
> I wouldn't worry about that just yet. Unless we're planning
> on switching to gcc-4.5 before the release. And I'm not sure
> we're going to have time for that.
No, we are having a hard time to get the FTBFS issues with gcc-4.4 (some
in combination with eglibc
ean “ACCEPTED” so the package has
> not yet been accepted into the archive.
>
> I see no trace of that upload, for that matters.
The upload was rejected as you can see on merkel in
/srv/ftp.debian.org/queue/rejected/*.reason
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
101 - 200 of 312 matches
Mail list logo
