Re: spammers closing bugs in BTS
On 18/08/16 10:48, Holger Levsen wrote: > On Wed, Aug 17, 2016 at 06:14:38PM +0200, Daniel Pocock wrote: >> I received a notification that a bug was closed. >> >> The email that closed the bug was a spam email sent to the >> address (bug-number)-d...@bugs.debian.org > [...] >> Maybe time to start requiring PGP signatures on control emails to >> the BTS? > > there are >80 bugs in the BTS and you evidence abuse on one > single bug and that causes you to suggest to change workflows which > have worked for many years? > > don't you think you are reacting a bit too fast? > > Is this the only bug where this ever occurred? If so, I feel like I have just wont the lottery then. When attackers find a 0 day exploit, don't they react as fast as they can? For anybody wanting to cause massive irritation to the project, all they have to do is put up a static web page containing all the possible "-done" addresses and let spammers do the rest.
Re: spammers closing bugs in BTS
On 2016-08-20 09:07 +0200, Daniel Pocock wrote: > On 18/08/16 10:48, Holger Levsen wrote: >> On Wed, Aug 17, 2016 at 06:14:38PM +0200, Daniel Pocock wrote: >>> I received a notification that a bug was closed. >>> >>> The email that closed the bug was a spam email sent to the >>> address (bug-number)-d...@bugs.debian.org >> [...] >>> Maybe time to start requiring PGP signatures on control emails to >>> the BTS? >> >> there are >80 bugs in the BTS and you evidence abuse on one >> single bug and that causes you to suggest to change workflows which >> have worked for many years? >> >> don't you think you are reacting a bit too fast? >> >> > > Is this the only bug where this ever occurred? If so, I feel like I > have just wont the lottery then. Of course not. Like many other subjects on debian-devel, this one has been discussed extensively more than ten years ago[1,2]. Cheers, Sven 1. https://lists.debian.org/debian-devel/2004/03/msg00847.html 2. https://lists.debian.org/debian-devel/2005/07/msg01106.html
Bug#834876: ITP: haskell-persistable-record -- Haskell library, binding between SQL database values and haskell records
Package: wnpp Severity: wishlist Owner: Kei Hibino * Package name: haskell-persistable-record Version : 0.4.0.2 Upstream Author : Key Hibino * URL : http://khibino.github.io/haskell-relational-record/ * License : BSD3 Programming Lang: Haskell Description : Haskell library, binding between SQL database values and haskell records This Haskell library contiains types to represent table constraints and interfaces to bind between SQL database values and Haskell records. - This package is part of Haskell Relatoinal Record ( http://khibino.github.io/haskell-relational-record/ ) project. - I'm planning to maintain this package inside the pkg-haskell team. - I need a sponsor.
Bug#834877: ITP: haskell-relational-query -- Haskell library, Typeful, Modular, Relational, algebraic query building DSL
Package: wnpp Severity: wishlist Owner: Kei Hibino * Package name: haskell-relational-query Version : 0.8.3.1 Upstream Author : Kei Hibino * URL : http://khibino.github.io/haskell-relational-record/ * License : BSD3 Programming Lang: Haskell Description : Haskell library, Typeful, Modular, Relational, algebraic query building DSL This package contiains typeful relation structure and relational-algebraic query building DSL which can translate into SQL query. Supported query features are below: - Type safe query building - Restriction, Join, Aggregation - Modularized relations - Typed placeholders - This package is part of Haskell Relatoinal Record ( http://khibino.github.io/haskell-relational-record/ ) project. - I'm planning to maintain this package inside the pkg-haskell team. - I need a sponsor.
Bug#834878: ITP: haskell-relational-schemas -- Haskell library, RDBMSs' schema templates for relational-query
Package: wnpp Severity: wishlist Owner: Kei Hibino * Package name: haskell-relational-schemas Version : 0.1.3.1 Upstream Author : Kei Hibino * URL : http://khibino.github.io/haskell-relational-record/ * License : BSD3 Programming Lang: Haskell Description : Haskell library, RDBMSs' schema templates for relational-query This package contains some RDBMSs' schema structure definitions. Supported RDBMS schemas are below: - IBM DB2 - PostgreSQL - Microsoft SQLServer - SQLite3 - Oracle - MySQL - This package is part of Haskell Relatoinal Record ( http://khibino.github.io/haskell-relational-record/ ) project. - I'm planning to maintain this package inside the pkg-haskell team. - I need a sponsor.
Bug#834879: ITP: haskell-relational-query-hdbc -- Haskell library, HDBC instance of relational-query and typed query interface for HDBC
Package: wnpp Severity: wishlist Owner: Kei Hibino * Package name: haskell-relational-query-hdbc Version : 0.6.0.2 Upstream Author : Kei Hibino * URL : http://khibino.github.io/haskell-relational-record/ * License : BSD3 Programming Lang: Haskell Description : Haskell library, HDBC instance of relational-query and typed query interface for HDBC This Haskell library contains the HDBC instance of relational-query and the typed query interface for HDBC. Generating Database table definitions and functions for relational-query by reading table and index definitions from Database system catalogs. - This package is part of Haskell Relatoinal Record ( http://khibino.github.io/haskell-relational-record/ ) project. - I'm planning to maintain this package inside the pkg-haskell team. - I need a sponsor.
Bug#834880: ITP: haskell-persistable-types-hdbc-pg -- Haskell library, HDBC and Relational-Record instances of PostgreSQL extended types
Package: wnpp Severity: wishlist Owner: Kei Hibino * Package name: haskell-persistable-types-hdbc-pg Version : 0.0.1.4 Upstream Author : Kei Hibino * URL : http://khibino.github.io/haskell-relational-record/ * License : BSD3 Programming Lang: Haskel Description : Haskell library, HDBC and Relational-Record instances of PostgreSQL extended types This Haskell library contains HDBC Convertible instances and Relational-Record persistable instances of PostgreSQL extended types Supported extended types: inet, cidr - This package is part of Haskell Relatoinal Record ( http://khibino.github.io/haskell-relational-record/ ) project. - I'm planning to maintain this package inside the pkg-haskell team. - I need a sponsor.
Bug#834940: ITP: lambda-align -- Local Aligner for Massive Biological DatA
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: lambda-align Version : 1.0.0 Upstream Author : Hannes Hauswedell * URL : https://seqan.github.io/lambda * License : GPL Programming Lang: C++ Description : Local Aligner for Massive Biological DatA Lambda is a local biosequence aligner optimized for many query sequences and searches in protein space. It is compatible to the de facto standard tool BLAST, but often outperforms the best currently available alternatives at reproducing BLAST’s results and is the fastest compared with the current state of the art at comparable levels of sensitivity. This package will be maintained under the umbrella of the Debian Med Team.
Results for Declassifying debian-private
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sun Aug 21 00:00:12 2016
Option 1 "Allow declassifying parts of debian-private"
Option 2 "Further Discussion"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2
=== ===
Option 1 118
Option 2134
Looking at row 2, column 1, Further Discussion
received 134 votes over Allow declassifying parts of debian-private
Looking at row 1, column 2, Allow declassifying parts of debian-private
received 118 votes over Further Discussion.
Option 1 Reached quorum: 118 > 43.6548966325657
Dropping Option 1 because of Majority.
(0.880597014925373134328358208955223880597) 0.881 (118/134) < 1
The Schwartz Set contains:
Option 2 "Further Discussion"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 2 "Further Discussion"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"Allow declassifying parts of debian-private\n0.88" [ style="filled" ,
color="pink", shape=octagon, fontname="Helvetica", fontsize=10 ];
"Further Discussion" -> "Allow declassifying parts of debian-private\n0.88" [
label="16" ];
"Further Discussion" [ style="filled" , color="powderblue", shape=egg,
fontcolor="NavyBlue", shape=diamond, fontcolor="Red", fontname="Helvetica",
fontsize=10 ];
}
pgpCoIehm_551.pgp
Description: PGP signature
Bug#834969: ITP: librt-extension-repeatticket-perl -- Perl module for repeating tickets in RT (Request Tracker) based on schedule
Package: wnpp Severity: wishlist * Package name: librt-extension-repeatticket-perl * URL : https://metacpan.org/release/RT-Extension-RepeatTicket * License : GPL-2 Description : Perl module for repeating tickets in RT (Request Tracker) based on schedule The RepeatTicket extension for the Request Tracker trouble-ticket tracking system allows you to set up recurring tickets so new tickets are automatically created based on a schedule. The new tickets are populated with the subject and initial content of the original ticket in the recurrence. . After you activate the plugin by adding it to your RT_SiteConfig.pm file, all tickets will have a Recurrence tab on the create and edit pages. To set up a repeating ticket, click the checkbox to "Enable Recurrence" and fill out the schedule for the new tickets. . New tickets are created when you initially save the recurrence, if new tickets are needed, and when your daily cron job runs the rt-repeat-ticket script. I've chosen to name this package "librt-extension-repeatticket-perl", following naming convention of CPAN packages. I am aware of the rt4-extension-* packages (like e.g. rt4-extension-calendar), but feel the name librt-extension-repeatticket-perl is more suitable to fit in pkg-perl policy. People looking for this package will find it anyway. I'll work on the packaging using pkg-perl's git at Alioth https://anonscm.debian.org/cgit/pkg-perl/packages/librt-extension-repeatticket-perl.git/ . Bye, Joost signature.asc Description: Digital signature
Re: Porter roll call for Debian Stretch
Kurt Roeckx:
> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>> * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>also apply to this port? [0]
>
> If -fPIE is the default will -fPIC override it?
>
> It will also default to tell the linker to use -pie, but then
> don't do it when you want to create a shared library?
>
I believe so. At least, Ubuntu made PIE default in their compiler
without having to change all SO packages to still build.
Admittedly, it could also be that GCC uses some built "compiler spec"
files for this case (a la an implicit "-specs=$FILE"), which are similar
to those Redhat uses for this purposes (see [1] for an example of such
files).
Regardless, it seems to "just work(TM)" if you pass the proper flags
when compiling your SOs.
>>From what I understand, depending on what the .o file is going to
> be used for you want different things:
> - shared library: -fPIC
> - executable: -fPIC or -fPIE both work, but prefer -fPIE
> - static library: Same as executables
>
> For static libraries we now have a policy to not use -fPIC,
> should that then get replaced by using -fPIE?
>
>
>
> Kurt
>
Honestly, I had not thought about that. From the looks of it, de facto
we will end up with -fPIE being the default for static libraries as well.
I would be supporting that change on the assumption that it requires
less work from individual maintainers (and presumably has no notable
downsides in the final result).
Thanks,
~Niels
[1] Example spec files for this case seems to be something like:
pie-compile.specs
"""
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
"""
pie-link.specs:
"""
*self_spec:
+ %{!shared:%{!r:-pie}}
"""
NB: I manually carved them out of a diff without testing them.
