On Wed, Oct 28, 2009 at 01:02:10PM +0900, Charles Plessy wrote:
> I think that some of these checks are ‘bikeshedding’ my work as a packager,
> enforcing a parallel and undocumented Policy, and lessering the usefuleness of
> Lintian now that some Lintian warnings are FTPmaster errors and vice-versa
On Mon, Oct 26, 2009 at 02:29:47PM -0500, Adam Majer wrote:
> Or here's a radical idea - allow source only uploads of packages.
He, radical, but not new :) It has been discussed to death various
times. The most likely (and IMO better) alternative to that is uploading
binaries but trowing them away
Le Tue, Oct 27, 2009 at 07:35:04PM -0500, Manoj Srivastava a écrit :
>
> Can we identify people who might feel like second class citizens
> when an effort is made to improve bad packages? I am pretty sure
> Debian would be improved.
I think that some of these checks are ‘bikeshedding’
On Tue, Oct 27, 2009 at 02:57:35PM +, Simon McVittie wrote:
> - statically-linked-binary
This is not always a bug. e.g. dar-static is supposed to be statically linked!
My packages produce a number of lintian errors/warnings that I don't consider
to be a problem (like this one) - it would
(On vacation with intermittant access, so it may be a while before I see
responses.)
Ryan Niebur writes:
> this is probably a question more for lintian maintainers, but... what
> should we do if lintian is buggy and falsely claims our package has
> one of these tags?
The same as what you would
(On vacation with intermittant access, so may not see responses for a
while.)
Ryan Niebur writes:
> On Tue, Oct 27, 2009 at 11:03:06PM +, Mark Brown wrote:
>> On Tue, Oct 27, 2009 at 03:59:52PM -0700, Ryan Niebur wrote:
>>> I completely disagree with this lintian warning and prefer to use
>>
Hi, with the current version of texi2html (1.82-1), I'm getting lots of build
failures like (from diffutils-doc):
...
debian/rules build
/usr/bin/make
make[1]: Entering directory `/tmp/buildd/diffutils-doc-2.8.1'
makeinfo --output=diff.info diff.texi
texi2html -split_chapter diff.texi
make[1]: L
["Mail-Followup-To: debian-devel-annou...@lists.debian.org" -- nice]
On Tue, Oct 27, 2009 at 03:06:07PM +0100, Joerg Jaspert wrote:
> Heyho,
>
> we are turning on lintian based autorejects within the next few days.
> This means that packages failing a defined set of lintian tags will no
> longer
On Wed, Oct 28, 2009 at 01:34:11AM +0100, Cyril Brulebois wrote:
> Stephen Gran (28/10/2009):
> > What that has to do with lintian based auto-rejects, I'm not really
> > sure, but thanks.
>
> Files were installed in binary packages (built on autobuilders with
> the brand new toolchain packages) w
On Tue, Oct 27, 2009 at 11:03:06PM +, Mark Brown wrote:
> On Tue, Oct 27, 2009 at 03:59:52PM -0700, Ryan Niebur wrote:
>
> > I completely disagree with this lintian warning and prefer to use
> > "Author(s)".
>
> I do agree that rejecting on this is probably excessive but I'm curious
> as to w
On Tue, Oct 27 2009, Bernd Eckenfels wrote:
> In article <8763a0fq30@anzu.internal.golden-gryphon.com> you wrote:
>>About time we took a stand against junk packages.
>
> Not helpfull to attack people. You will just lose a lot developers
> when they feel second class.
Packages
2009/10/27 Ben Hutchings :
> On Tue, Oct 27, 2009 at 12:15:39PM +0100, Petter Reinholdtsen wrote:
>
>> I believe a better approach is to collect stats on who upload packages
>> which fail to build on all architectures, and add a process to
[...]
> Well you can kick out the kernel team then, becaus
Stephen Gran (28/10/2009):
> What that has to do with lintian based auto-rejects, I'm not really
> sure, but thanks.
Files were installed in binary packages (built on autobuilders with
the brand new toolchain packages) within unusual locations (resulting
in quite broken packages), which lintian w
Hi,
On Tue, Oct 27, 2009 at 10:19:22PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 27 Oct 2009, Kees Cook wrote:
> > > > It seems the kernel will not be happy if the stack protector is switched
> > > > on unconditionally:
> > > >
> > > > http://osdir.com/ml/linux-kernel/2009-10/msg07064.h
Bernd Eckenfels writes:
> In article <8763a0fq30@anzu.internal.golden-gryphon.com> you wrote:
> >About time we took a stand against junk packages.
>
> Not helpfull to attack people. You will just lose a lot developers
> when they feel second class.
Non sequitur. Manoj's advice has no
On Tue, 27 Oct 2009, Kees Cook wrote:
> > > It seems the kernel will not be happy if the stack protector is switched
> > > on unconditionally:
> > >
> > > http://osdir.com/ml/linux-kernel/2009-10/msg07064.html
> >
> > Indeed. The kernel build system needs to be able to command whether
> > stackp
This one time, at band camp, Cyril Brulebois said:
> Joerg Jaspert (27/10/2009):
> > No. Not much helpful to reject buildd packages.
>
> Like the ones totally broken due to “toolchain” issues? The
> dbus/debhelper joke comes to mind: The sourceful upload was
> OK. Due to bad timing, the autobuilt
In article <8763a0fq30@anzu.internal.golden-gryphon.com> you wrote:
>About time we took a stand against junk packages.
Not helpfull to attack people. You will just lose a lot developers when they
feel second class.
Gruss
Bernd
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.
Lucas Nussbaum wrote:
> On 27/10/09 at 14:57 +, Simon McVittie wrote:
> Also, lots of packages currently in our archive already have those
> errors. What do you plan to do with those? If you auto-reject packages
> that introduce those errors, it would be logical to file RC bugs and/or
> remove
On Tue, Oct 27, 2009 at 03:59:52PM -0700, Ryan Niebur wrote:
> I completely disagree with this lintian warning and prefer to use
> "Author(s)".
I do agree that rejecting on this is probably excessive but I'm curious
as to why you think it's incorrect?
--
To UNSUBSCRIBE, email to debian-devel-r
On Tue, Oct 27, 2009 at 09:15:58PM +0100, Thijs Kinkhorst wrote:
> On tiisdei 27 Oktober 2009, Joerg Jaspert wrote:
> > we are turning on lintian based autorejects within the next few days.
> > This means that packages failing a defined set of lintian tags will no
> > longer be accepted into the ar
On Mon, Oct 26, 2009 at 09:41:59PM +0100, Christoph Anton Mitterer wrote:
> Ever thought about integrating PaX [0] per default in Debian?
What features does the grsecurity patch provide currently? I know that
several of the mentioned PaX features are supported in vanilla kernel in
the meantime:
-
On Tue, Oct 27 2009, Lucas Nussbaum wrote:
> Also, lots of packages currently in our archive already have those
> errors. What do you plan to do with those? If you auto-reject packages
> that introduce those errors, it would be logical to file RC bugs and/or
> remove them from the archive.
On Tue, 2009-10-27 at 15:48 +0800, Paul Wise wrote:
> http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
> http://kernel-handbook.alioth.debian.org/ch-source.html#s-acceptance
The thing is,..
A patch like PaX would (IMHO) improve security a lot,... and it would be
worth thinking for a dis
On Tue, 2009-10-27 at 09:32 +0800, Paul Wise wrote:
> Any idea if these patches will be merged upstream?
It's probably quite unlikely,... although I never understood why,..
Even though it's available for some architectures,.. it would improve
security at least on them.
Cheers,
--
To UNSUBSCRIB
Hi,
On Tue, Oct 27, 2009 at 01:30:12PM -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 26 Oct 2009, Gabor Gombas wrote:
> > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > > I would like to propose enabling[1
Kees Cook, le Tue 27 Oct 2009 14:11:43 -0700, a écrit :
> On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > > uses[2].
> >
> > How do they
On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > uses[2].
>
> How do they work? Do they also change the free-standing compiler or only
> the
Joerg Jaspert (27/10/2009):
> No. Not much helpful to reject buildd packages.
Like the ones totally broken due to “toolchain” issues? The
dbus/debhelper joke comes to mind: The sourceful upload was
OK. Due to bad timing, the autobuilt packages were not.
Mraw,
KiBi.
signature.asc
Description: D
>> Those automated rejects will only be done on sourceful uploads to
>> unstable and experimental.
> Are there any plans to extend this on binary-only uploads?
No. Not much helpful to reject buildd packages.
--
bye, Joerg
Von einem Besucher auf dem LT:
Die 3 Microsoft-Leute auf Ihrem Stand müs
On 27/10/09 at 14:57 +, Simon McVittie wrote:
> I realise this is somewhat deliberate, to give maintainers a strong incentive
> to fix their packages. However, it seems disproportionate: we don't enforce
> that for RC bugs, even those with severity 'critical', so this is effectively
> creating
On tiisdei 27 Oktober 2009, Joerg Jaspert wrote:
> we are turning on lintian based autorejects within the next few days.
> This means that packages failing a defined set of lintian tags will no
> longer be accepted into the archive, but get rejected immediately.
> This should help to get rid of the
Hi,
Thilo Six wrote:
> Hello
>
> i have a question regarding above named DSA. It has been announced on
> October 23th but still the mirror i am using doesn't have it:
>
[...]
>
> The DSA said:
>
> <- *snip* ->
> Due to a bug in the archive system, the fix for the stable distribution
> (lenny
Hi,
CC'ing debian-i18n since it's certainly a good place to discuss this.
On Tue, Oct 27, 2009 at 11:17:34PM +0900, Junichi Uekawa wrote:
[..]
> I think someone who is not logged in is removing the comments and being
> disruptive.
>
> Is there a good way to fight against it?
* Add authenticati
Hello
i have a question regarding above named DSA. It has been announced on October
23th but still the mirror i am using doesn't have it:
$ apt-cache policy kdelibs
kdelibs:
Installed: 4:3.5.10.dfsg.1-0lenny2
Candidate: 4:3.5.10.dfsg.1-0lenny2
Version table:
*** 4:3.5.10.dfsg.1-0lenny2 0
This one time, at band camp, Holger Levsen said:
> Hi,
>
> On Dienstag, 27. Oktober 2009, Stephen Gran wrote:
> > While I'm happy to see some of the out of tree munin plugins getting
> > shipped, I wonder if it makes sense to have a larger bundle package,
> > something like munin-plugins-extra? T
On Tue, Oct 27, 2009 at 06:06:12PM +0100, Bernhard R. Link wrote:
> * Joerg Jaspert [091027 15:06]:
> > Those automated rejects will only be done on sourceful uploads to
> > unstable and experimental.
> Are there any plans to extend this on binary-only uploads?
First there needs to be proper hand
On Tue, Oct 27, 2009 at 12:15:39PM +0100, Petter Reinholdtsen wrote:
>
> [Charles Plessy]
> > Why don’t we remove the key of the developers uploading “crap
> > packages” from the Debian keyring?
>
> I believe a better approach is to collect stats on who upload packages
> which fail to build on al
Hi Joerg, ftp people,
2009/10/27 Joerg Jaspert :
> Heyho,
>
> we are turning on lintian based autorejects within the next few days.
> This means that packages failing a defined set of lintian tags will no
> longer be accepted into the archive, but get rejected immediately.
> This should help to ge
Hi again,
I was working through some RC bugs recently and came across 3 roxen
packages. They have recently been orphaned and roxen4 seems to possibly
have some non-free jar files in it.
I am planning on just removing them (at least roxen4, libroxen-ecms, and
libroxen-form initially) since they h
* Joerg Jaspert [091027 15:06]:
> we are turning on lintian based autorejects within the next few days.
> This means that packages failing a defined set of lintian tags will no
> longer be accepted into the archive, but get rejected immediately.
> This should help to get rid of the worst policy vi
On Tue, Oct 27 2009, Simon McVittie wrote:
> Some examples of tags I consider reasonable to auto-reject, because they
> should be easy to fix (but many of them should be bug reports anyway):
> - binary-file-compressed-with-upx
> - copyright-lists-upstream-authors-with-dh_make-boilerplate
On Tuesday 27 October 2009, Joerg Jaspert wrote:
> Now, in this case there is no need to move it, as looking at
> http://lintian.debian.org/tags/no-standards-version-field.html shows
> that we do not see any of the D-I packages, so I assume lintian is
> detecting it properly and we do not need to m
On 11916 March 1977, Frans Pop wrote:
> Looks like it's named "nowayout".
Thats just because I didnt copy the very latest version of it over to
ries. Done now.
>> overridden. Those are tags corresponding to packaging errors serious
>> enough to mark a package unfit for the archive and should nev
On Mon, 26 Oct 2009, Gabor Gombas wrote:
> On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > > uses[2].
> >
> > How do they work? Do they
On Tue, Oct 27 2009, Steve Langasek wrote:
> On Tue, Oct 27, 2009 at 08:17:08AM -0500, Manoj Srivastava wrote:
>
>> >> Not needed. If init has been just upgraded, it has been already
>> >> told to init -u itself.
>
>> > This does not appear to be true for upstart, which it's planned to sw
On Tue, Oct 27, 2009 at 02:57:35PM +, Simon McVittie wrote:
>
> Some examples of tags I consider reasonable to auto-reject, because they
> should be easy to fix (but many of them should be bug reports anyway):
> - binary-file-compressed-with-upx
> - copyright-lists-upstream-authors-wit
On Tue, 27 Oct 2009 at 15:06:07 +0100, Joerg Jaspert wrote:
> The second category is named "error" and the tags listed can not be
> overridden.
I don't think it's appropriate to make, for instance, dir-or-file-in-var-www
instantly fatal without following the usual mass-bug-filing procedure. If
you
On Mon, Oct 26, 2009 at 10:56:16PM -0700, Steve Langasek wrote:
> Huh, isn't that an FHS violation? /dev/initctl isn't much better, but seems
> to be covered by "special files"; upstart doesn't use either of these
> locations, fwiw.
I think the issue came down to the fact that with kFreeBSD, /dev
Hi,
It's not clear just from the logs, but for example:
1246176855 fetched by yy_y_ja_jp
1246176856 processed from todo
1246176866 fetched by yy_y_ja_jp
1247572419 fetched by yy_y_ja_jp
1256308334 updated text by ipv6waterstar (ii)
1256308472 change-comment-only by 203.141.158.41
1256374546 updat
On Tuesday 27 October 2009, Joerg Jaspert wrote:
> The second category is named "error" and the tags listed can not be
Looks like it's named "nowayout".
> overridden. Those are tags corresponding to packaging errors serious
> enough to mark a package unfit for the archive and should never happen.
On Tue, Oct 27, 2009 at 08:17:08AM -0500, Manoj Srivastava wrote:
> >> Not needed. If init has been just upgraded, it has been already
> >> told to init -u itself.
> > This does not appear to be true for upstart, which it's planned to switch to
> > on Linux for squeeze.
> Well,
Greetings,
I am glad to bring this to your knowledge that we are launching a Web Portal
- *www.lawyersclinic.com -* which will provide *Customized Legal
Services*to help the
*General Public* to understand their *Legal Rights. * It will also assist
them to understand the necessary actions to be ta
Josselin Mouette writes:
> Le lundi 26 octobre 2009 à 01:17 +0100, Norbert Preining a écrit :
>> I would suggest on the contrary that HOME *will* be set by all scripts
>> to a newly created empty directory.
>
> Iâd rather suggest that it will be set to a non-existent directory. If
> possible
Manoj Srivastava writes:
> On Fri, Oct 23 2009, Bernd Eckenfels wrote:
>
>> In article <87r5sudn0p.fsf...@anzu.internal.golden-gryphon.com> you wrote:
>>> [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe
>>> 2>/dev/null)" ] ; then
>>> # So, init exists, and there is a linu
On Tue, Oct 27 2009, Bernd Eckenfels wrote:
> In article <873a59ens7@anzu.internal.golden-gryphon.com> you wrote:
>>> Maybe another check besides inode idendity is better, otherwise it will not
>>> be able to be used afer an upgrade (and before reboot), or?
>>
>>Not needed. If init ha
On Tue, Oct 27 2009, Steve Langasek wrote:
> On Fri, Oct 23, 2009 at 05:41:28PM -0500, Manoj Srivastava wrote:
>> > In article <87r5sudn0p.fsf...@anzu.internal.golden-gryphon.com> you wrote:
>> >> [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe
>> >> 2>/dev/null)" ] ; then
>>
[Charles Plessy]
> Why don’t we remove the key of the developers uploading “crap
> packages” from the Debian keyring?
I believe a better approach is to collect stats on who upload packages
which fail to build on all architectures, and add a process to
review/requalify a Debian Developer if this h
http://digg.com/tech_news/Google_Search_goes_Social_Online_Marketing_Blog
Regards
Ashok Kumar
Hi,
On Dienstag, 27. Oktober 2009, Stephen Gran wrote:
> While I'm happy to see some of the out of tree munin plugins getting
> shipped, I wonder if it makes sense to have a larger bundle package,
> something like munin-plugins-extra? There are loads of useful out of
> tree munin plugins floating
On Tue, 27 Oct 2009, Stephen Gran wrote:
> This one time, at band camp, Rodolphe Quiédeville said:
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Rodolphe Quiédeville"
> >
> > * Package name: muninpgplugins
>
> While I'm happy to see some of the out of tree munin plugins getting
> shi
This one time, at band camp, Rodolphe Quiédeville said:
> Package: wnpp
> Severity: wishlist
> Owner: "Rodolphe Quiédeville"
>
> * Package name: muninpgplugins
While I'm happy to see some of the out of tree munin plugins getting
shipped, I wonder if it makes sense to have a larger bundle pac
On Tue, Oct 27, 2009 at 2:52 PM, Yves-Alexis Perez wrote:
> On mar., 2009-10-27 at 09:32 +0800, Paul Wise wrote:
>> On Tue, Oct 27, 2009 at 4:41 AM, Christoph Anton Mitterer
>> wrote:
>>
>> > Ever thought about integrating PaX [0] per default in Debian?
>> > I'm however not sure how much this act
Le Mon, Oct 26, 2009 at 11:07:19PM +, Roger Leigh a écrit :
>
> While most developers are conscientious enough to make sure their
> packages build, one does see enough crap packages that IMO this
> (minimal) bar should probably be kept.
Hi all,
Why don’t we remove the key of the developers u
In article <873a59ens7@anzu.internal.golden-gryphon.com> you wrote:
>> Maybe another check besides inode idendity is better, otherwise it will not
>> be able to be used afer an upgrade (and before reboot), or?
>
>Not needed. If init has been just upgraded, it has been already
> told to
65 matches
Mail list logo
