Re: Slowing down for the release

2022-03-27 Thread Theo de Raadt
> It would be good to have Go 1.18 make release - if we're not able
> to do that, then we should update to 1.17.8.

Be very careful, the user testing time for such large software is becoming
exceedingly short, and quickly.



Re: Slowing down for the release

2022-03-27 Thread Joel Sing
On 22-03-24 16:43:28, Christian Weisgerber wrote:
> It's time to start slowing down for the upcoming 7.1 release.
> 
> There are no restrictions on the types of ports commits yet, but I
> would like to ask everybody to keep the approaching release in mind
> and to slowly wind down large ports work.
> 
> As usual, I'm also imploring people to test snapshot packages so
> bugs can be found and fixed before it is too late.

It would be good to have Go 1.18 make release - if we're not able
to do that, then we should update to 1.17.8.



Re: Slowing down for the release

2022-03-24 Thread Tracey Emery
On Thu, Mar 24, 2022 at 04:43:28PM +0100, Christian Weisgerber wrote:
> It's time to start slowing down for the upcoming 7.1 release.
> 
> There are no restrictions on the types of ports commits yet, but I
> would like to ask everybody to keep the approaching release in mind
> and to slowly wind down large ports work.
> 
> As usual, I'm also imploring people to test snapshot packages so
> bugs can be found and fixed before it is too late.
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

I'm working on KiCAD 6.0.4 which is largish, but should be snuck in
before release, since there were some issues with 6.0.2.

-- 

Tracey Emery



Re: Slowing down for the release

2022-03-24 Thread Antoine Jacoutot
On Thu, Mar 24, 2022 at 04:43:28PM +0100, Christian Weisgerber wrote:
> It's time to start slowing down for the upcoming 7.1 release.
> 
> There are no restrictions on the types of ports commits yet, but I
> would like to ask everybody to keep the approaching release in mind
> and to slowly wind down large ports work.
> 
> As usual, I'm also imploring people to test snapshot packages so
> bugs can be found and fixed before it is too late.

I am working on a webkitgtk4 update that I would like to go in.
Otherwise it will be impossible to publish security updates to -stable as
webkit never provides security releases for past releases.
That's unfortunately the situation we have in 7.0 and I would like to prevent it
from happening again.

-- 
Antoine



Re: Slowing down, testing for release

2021-09-13 Thread Theo de Raadt
Christian Weisgerber  wrote:

> We also need to finish the %n cleanup.  It looks like Theo wants
> to ship 7.0 with %n triggering abort(3).  Without testing, we will
> not find all application uses.

It can miss release if it needs to.

But I urge users to install new ports, and test, and not defer %n
removal to next spring.




Re: Slowing down for the release

2016-07-16 Thread Stuart Henderson
On 2016/07/11 22:03, Rafael Sadowski wrote:
> Looks like mc works fine with _shadow (maybe without too).

The only time getpw*_shadow functions are needed are when the password
field (pw_passwd) are used. These don't need just a search-and-replace
for getpw*->getpw*_shadow, they need a small amount of work to figure
out what the code is doing.

> +--- lib/lock.c.orig  Mon Jul 11 18:04:49 2016
>  lib/lock.c   Mon Jul 11 18:07:53 2016
> +@@ -91,7 +91,7 @@ lock_build_name (void)
> + const char *user = NULL;
> + struct passwd *pw;
> + 
> +-pw = getpwuid (getuid ());
> ++pw = getpwuid_shadow (getuid ());
> + if (pw)
> + user = pw->pw_name;
> + if (!user)

>From the filename I thought this might be some screen-lock thing
which might actually need a change, but actually looking at the code
it's just creating a lockfile. So NAK to this one.

> Index: patches/patch-lib_shell_c

And this just wants the shell name.

> Index: patches/patch-lib_utilunix_c

This does ~username -> /home/username etc.

> Index: patches/patch-lib_vfs_interface_c

temp dir creation.

> Index: patches/patch-lib_vfs_utilvfs_c
> Index: patches/patch-src_filemanager_layout_c
> Index: patches/patch-src_vfs_fish_fish_c
> Index: patches/patch-src_vfs_smbfs_helpers_lib_util_c

username/gid lookup.

> Index: patches/patch-src_filemanager_achown_c
> Index: patches/patch-src_filemanager_chown_c

names for list display or something?

> Index: patches/patch-src_filemanager_layout_c.orig

err.. :)

> Index: patches/patch-src_vfs_smbfs_helpers_lib_username_c

This is the only one that actually deals with pw_passwd by
filling it in from (SunOS's?) getpwanam(). But I don't see anything
that actually uses the password field. I think they just pulled
across a bunch of (probably samba) code that they don't need.

So this looks to me like one of the red herrings I mentioned.



Re: Slowing down for the release

2016-07-11 Thread Rafael Sadowski
On Mon Jul 11, 2016 at 11:40:56AM +0100, Stuart Henderson wrote:
> On 2016/07/06 21:41, Christian Weisgerber wrote:
> > The next release, 6.0, is approaching fast.  It's time to wind down
> > the ports churn, focus on fixing problems and stop introducing them.
> > 
> > Over the next few days, please stop importing new ports and regular
> > updates.  If you're in the middle of something, finish it, but by
> > the weekend this should be done, and commits will be increasingly
> > restricted from there.
> 
> Please stop imports now. And updates should be for important fixes
> only. It's not a time to rush things in before release, it's a time
> to polish.
> 
> > What's the situation with wxneeded annotations and getpwnam_shadow?
> > If that work hasn't been completed, it's high time to get it done.
> 
> Very patchy.
> 
> >From my old search for things using pw_passwd here are a few that I
> don't recall seeing updates for.
> 
> Some of them will most likely be red herrings and in codepaths not
> actually used, and obviously for many of them it's only going to be
> certain things which don't work.
> 
> Some of them are very definitely broken and the ports will no
> longer work at all (e.g. some of the pop3 daemons).
> 
> It would be nice if people can check ports which they rely on and
> move things to using the _shadow versions of getpwnam/getpwuid
> where needed. Many of these will have existing code to deal with
> shadow passwords using the standard getspnam functions used on
> other OS; this is a good indication that changes will need to be
> made.
> 
> Unfortunately I accidentally looked at cucipop and now need to go
> and look for a sick bag (or possibly some pokemon) so I'm not sure
> how many I'm going to be able to fix myself.
> 
> biology/emboss
> comms/kermit
> databases/openldap
> databases/openldap23
> databases/tinycdb
> devel/luaposix
> devel/ocaml-lwt
> devel/omake
> editors/jed
> lang/chibi-scheme
> lang/chicken/bootstraP
> lang/chicken/core
> lang/clisp
> lang/gawk
> lang/guile
> lang/guile2
> lang/mono
> lang/ocaml
> lang/php
> lang/python
> lang/ruby
> lang/rust
> lang/scm
> lang/swi-prolog
> lang/tcl
> mail/akpop3d (definitely broken)
> mail/avenger
> mail/cucipop (definitely broken)
> mail/dkim-milter
> mail/dovecot (most people will probably use bsdauth or a db so likely 
> unimportant)
> mail/opensmtpd-extras
> mail/postfix
> mail/procmail
> mail/sendmail
> mail/solid-pop3d
> mail/teapop
> mail/zarafa
> math/grace
> math/octave
> misc/gone
> misc/mc


Looks like mc works fine with _shadow (maybe without too).

- test @amd64 without smb/ssh-fs tests
- add some fprintf error msgs for tests.

Cheerrs,

Rafael


Index: Makefile
===
RCS file: /cvs/ports/misc/mc/Makefile,v
retrieving revision 1.59
diff -u -p -u -p -r1.59 Makefile
--- Makefile25 Apr 2016 13:35:06 -  1.59
+++ Makefile11 Jul 2016 19:58:56 -
@@ -3,7 +3,7 @@
 COMMENT=   free Norton Commander clone with many useful features
 
 DISTNAME=  mc-4.8.16
-REVISION=  0
+REVISION=  1
 CATEGORIES=misc
 
 HOMEPAGE=  http://www.midnight-commander.org/
Index: patches/patch-lib_lock_c
===
RCS file: patches/patch-lib_lock_c
diff -N patches/patch-lib_lock_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-lib_lock_c11 Jul 2016 19:58:56 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- lib/lock.c.origMon Jul 11 18:04:49 2016
 lib/lock.c Mon Jul 11 18:07:53 2016
+@@ -91,7 +91,7 @@ lock_build_name (void)
+ const char *user = NULL;
+ struct passwd *pw;
+ 
+-pw = getpwuid (getuid ());
++pw = getpwuid_shadow (getuid ());
+ if (pw)
+ user = pw->pw_name;
+ if (!user)
Index: patches/patch-lib_shell_c
===
RCS file: patches/patch-lib_shell_c
diff -N patches/patch-lib_shell_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-lib_shell_c   11 Jul 2016 19:58:56 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+--- lib/shell.c.orig   Mon Jul 11 18:05:06 2016
 lib/shell.cMon Jul 11 18:10:32 2016
+@@ -104,9 +104,11 @@ mc_shell_get_name_env (void)
+ /* 2nd choice: user login shell */
+ struct passwd *pwd;
+ 
+-pwd = getpwuid (geteuid ());
++pwd = getpwuid_shadow (geteuid ());
+ if (pwd != NULL)
+ shell_name = g_strdup (pwd->pw_shell);
++else
++fprintf (stderr, _("getpwuid_shadow\n"));
+ }
+ else
+ /* 1st choice: SHELL environment variable */
Index: patches/patch-lib_utilunix_c
===
RCS file: patches/patch-lib_utilunix_c
diff -N patches/patch-lib_utilunix_c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-lib_utilunix_c11 Jul 2016 19:58:56 -
@@ -0,0 +1,31 @@

Re: Slowing down for the release

2016-07-11 Thread Juan Francisco Cantero Hurtado
On Mon, Jul 11, 2016 at 11:40:56AM +0100, Stuart Henderson wrote:
> On 2016/07/06 21:41, Christian Weisgerber wrote:
> > The next release, 6.0, is approaching fast.  It's time to wind down
> > the ports churn, focus on fixing problems and stop introducing them.
> > 
> > Over the next few days, please stop importing new ports and regular
> > updates.  If you're in the middle of something, finish it, but by
> > the weekend this should be done, and commits will be increasingly
> > restricted from there.
> 
> Please stop imports now. And updates should be for important fixes
> only. It's not a time to rush things in before release, it's a time
> to polish.
> 
> > What's the situation with wxneeded annotations and getpwnam_shadow?
> > If that work hasn't been completed, it's high time to get it done.
> 
> Very patchy.
> 
> From my old search for things using pw_passwd here are a few that I
> don't recall seeing updates for.
> 
> Some of them will most likely be red herrings and in codepaths not
> actually used, and obviously for many of them it's only going to be
> certain things which don't work.
> 
> Some of them are very definitely broken and the ports will no
> longer work at all (e.g. some of the pop3 daemons).
> 
> It would be nice if people can check ports which they rely on and
> move things to using the _shadow versions of getpwnam/getpwuid
> where needed. Many of these will have existing code to deal with
> shadow passwords using the standard getspnam functions used on
> other OS; this is a good indication that changes will need to be
> made.
> 
> Unfortunately I accidentally looked at cucipop and now need to go
> and look for a sick bag (or possibly some pokemon) so I'm not sure
> how many I'm going to be able to fix myself.
> 
> biology/emboss
> comms/kermit
> databases/openldap
> databases/openldap23
> databases/tinycdb
> devel/luaposix
> devel/ocaml-lwt
> devel/omake
> editors/jed
> lang/chibi-scheme

chibi doesn't need changes. Everything works fine.

For reference, this is the "lib" which uses getpwnam/getpwuid:
http://synthcode.com/scheme/chibi/lib/chibi/system.html

> lang/chicken/bootstrap
> lang/chicken/core
> lang/clisp
> lang/gawk
> lang/guile
> lang/guile2
> lang/mono
> lang/ocaml
> lang/php
> lang/python
> lang/ruby
> lang/rust
> lang/scm
> lang/swi-prolog
> lang/tcl
> mail/akpop3d (definitely broken)
> mail/avenger
> mail/cucipop (definitely broken)
> mail/dkim-milter
> mail/dovecot (most people will probably use bsdauth or a db so likely 
> unimportant)
> mail/opensmtpd-extras
> mail/postfix
> mail/procmail
> mail/sendmail
> mail/solid-pop3d
> mail/teapop
> mail/zarafa
> math/grace
> math/octave
> misc/gone
> misc/mc
> misc/screen
> net/gopher
> net/libbind
> net/pure-ftpd
> net/samba
> net/tircproxy
> net/uucpd
> net/vsftpd
> net/winexe
> productivity/siag
> security/cyrus-sasl2
> security/dante
> security/dsniff
> security/heimdal
> security/openpam
> security/ssh-ldap-helper
> shells/tcsh
> sysutils/ktsuss
> sysutils/openpoppassd
> sysutils/rtty
> x11/kde/admin3
> x11/kde/base3
> x11/kde4/kuser
> x11/kde4/workspace
> x11/motif
> x11/nx/nxssh
> x11/slim
> x11/x11vnc
> x11/xtacy
> 
> 

-- 
Juan Francisco Cantero Hurtado http://juanfra.info



Re: Slowing down for the release

2016-07-11 Thread David Coppa
On Mon, Jul 11, 2016 at 12:40 PM, Stuart Henderson  wrote:
> On 2016/07/06 21:41, Christian Weisgerber wrote:
>> The next release, 6.0, is approaching fast.  It's time to wind down
>> the ports churn, focus on fixing problems and stop introducing them.
>>
>> Over the next few days, please stop importing new ports and regular
>> updates.  If you're in the middle of something, finish it, but by
>> the weekend this should be done, and commits will be increasingly
>> restricted from there.
>
> Please stop imports now. And updates should be for important fixes
> only. It's not a time to rush things in before release, it's a time
> to polish.
>
>> What's the situation with wxneeded annotations and getpwnam_shadow?
>> If that work hasn't been completed, it's high time to get it done.
>
> Very patchy.
>
> From my old search for things using pw_passwd here are a few that I
> don't recall seeing updates for.
>
> Some of them will most likely be red herrings and in codepaths not
> actually used, and obviously for many of them it's only going to be
> certain things which don't work.
>
> Some of them are very definitely broken and the ports will no
> longer work at all (e.g. some of the pop3 daemons).
>
> It would be nice if people can check ports which they rely on and
> move things to using the _shadow versions of getpwnam/getpwuid
> where needed. Many of these will have existing code to deal with
> shadow passwords using the standard getspnam functions used on
> other OS; this is a good indication that changes will need to be
> made.
>
> Unfortunately I accidentally looked at cucipop and now need to go
> and look for a sick bag (or possibly some pokemon) so I'm not sure
> how many I'm going to be able to fix myself.

> x11/slim

slim works for me (unpatched), I'm using it.



Re: Slowing down for the release

2016-07-11 Thread Antoine Jacoutot
> sysutils/openpoppassd

This one is done.

-- 
Antoine



Re: Slowing down for the release

2016-07-11 Thread Joerg Jung


> Am 11.07.2016 um 12:40 schrieb Stuart Henderson :
> 
>> On 2016/07/06 21:41, Christian Weisgerber wrote:
>> The next release, 6.0, is approaching fast.  It's time to wind down
>> the ports churn, focus on fixing problems and stop introducing them.
>> 
>> Over the next few days, please stop importing new ports and regular
>> updates.  If you're in the middle of something, finish it, but by
>> the weekend this should be done, and commits will be increasingly
>> restricted from there.
> 
> Please stop imports now. And updates should be for important fixes
> only. It's not a time to rush things in before release, it's a time
> to polish.
> 
>> What's the situation with wxneeded annotations and getpwnam_shadow?
>> If that work hasn't been completed, it's high time to get it done.
> 
> Very patchy.
> 
> From my old search for things using pw_passwd here are a few that I
> don't recall seeing updates for.
> 
> Some of them will most likely be red herrings and in codepaths not
> actually used, and obviously for many of them it's only going to be
> certain things which don't work.
> 
> Some of them are very definitely broken and the ports will no
> longer work at all (e.g. some of the pop3 daemons).
> 
> It would be nice if people can check ports which they rely on and
> move things to using the _shadow versions of getpwnam/getpwuid
> where needed. Many of these will have existing code to deal with
> shadow passwords using the standard getspnam functions used on
> other OS; this is a good indication that changes will need to be
> made.
> 
> Unfortunately I accidentally looked at cucipop and now need to go
> and look for a sick bag (or possibly some pokemon) so I'm not sure
> how many I'm going to be able to fix myself.
> 
> biology/emboss
> comms/kermit
> databases/openldap
> databases/openldap23
> databases/tinycdb
> devel/luaposix
> devel/ocaml-lwt
> devel/omake
> editors/jed
> lang/chibi-scheme
> lang/chicken/bootstrap
> lang/chicken/core
> lang/clisp
> lang/gawk
> lang/guile
> lang/guile2
> lang/mono
> lang/ocaml
> lang/php
> lang/python
> lang/ruby
> lang/rust
> lang/scm
> lang/swi-prolog
> lang/tcl
> mail/akpop3d (definitely broken)
> mail/avenger
> mail/cucipop (definitely broken)
> mail/dkim-milter
> mail/dovecot (most people will probably use bsdauth or a db so likely 
> unimportant)
> mail/opensmtpd-extras

I'll take care of -extras. There is an update pending
and required anyway to fix things after recent API changes.
I'll have a look into the getpwnam shadow issue as well.

> mail/postfix
> mail/procmail
> mail/sendmail
> mail/solid-pop3d
> mail/teapop
> mail/zarafa
> math/grace
> math/octave
> misc/gone
> misc/mc
> misc/screen
> net/gopher
> net/libbind
> net/pure-ftpd
> net/samba
> net/tircproxy
> net/uucpd
> net/vsftpd
> net/winexe
> productivity/siag
> security/cyrus-sasl2
> security/dante
> security/dsniff
> security/heimdal
> security/openpam
> security/ssh-ldap-helper
> shells/tcsh
> sysutils/ktsuss
> sysutils/openpoppassd
> sysutils/rtty
> x11/kde/admin3
> x11/kde/base3
> x11/kde4/kuser
> x11/kde4/workspace
> x11/motif
> x11/nx/nxssh
> x11/slim
> x11/x11vnc
> x11/xtacy
> 
> 



Re: Slowing down for the release

2016-07-11 Thread Stuart Henderson
On 2016/07/06 21:41, Christian Weisgerber wrote:
> The next release, 6.0, is approaching fast.  It's time to wind down
> the ports churn, focus on fixing problems and stop introducing them.
> 
> Over the next few days, please stop importing new ports and regular
> updates.  If you're in the middle of something, finish it, but by
> the weekend this should be done, and commits will be increasingly
> restricted from there.

Please stop imports now. And updates should be for important fixes
only. It's not a time to rush things in before release, it's a time
to polish.

> What's the situation with wxneeded annotations and getpwnam_shadow?
> If that work hasn't been completed, it's high time to get it done.

Very patchy.

>From my old search for things using pw_passwd here are a few that I
don't recall seeing updates for.

Some of them will most likely be red herrings and in codepaths not
actually used, and obviously for many of them it's only going to be
certain things which don't work.

Some of them are very definitely broken and the ports will no
longer work at all (e.g. some of the pop3 daemons).

It would be nice if people can check ports which they rely on and
move things to using the _shadow versions of getpwnam/getpwuid
where needed. Many of these will have existing code to deal with
shadow passwords using the standard getspnam functions used on
other OS; this is a good indication that changes will need to be
made.

Unfortunately I accidentally looked at cucipop and now need to go
and look for a sick bag (or possibly some pokemon) so I'm not sure
how many I'm going to be able to fix myself.

biology/emboss
comms/kermit
databases/openldap
databases/openldap23
databases/tinycdb
devel/luaposix
devel/ocaml-lwt
devel/omake
editors/jed
lang/chibi-scheme
lang/chicken/bootstrap
lang/chicken/core
lang/clisp
lang/gawk
lang/guile
lang/guile2
lang/mono
lang/ocaml
lang/php
lang/python
lang/ruby
lang/rust
lang/scm
lang/swi-prolog
lang/tcl
mail/akpop3d (definitely broken)
mail/avenger
mail/cucipop (definitely broken)
mail/dkim-milter
mail/dovecot (most people will probably use bsdauth or a db so likely 
unimportant)
mail/opensmtpd-extras
mail/postfix
mail/procmail
mail/sendmail
mail/solid-pop3d
mail/teapop
mail/zarafa
math/grace
math/octave
misc/gone
misc/mc
misc/screen
net/gopher
net/libbind
net/pure-ftpd
net/samba
net/tircproxy
net/uucpd
net/vsftpd
net/winexe
productivity/siag
security/cyrus-sasl2
security/dante
security/dsniff
security/heimdal
security/openpam
security/ssh-ldap-helper
shells/tcsh
sysutils/ktsuss
sysutils/openpoppassd
sysutils/rtty
x11/kde/admin3
x11/kde/base3
x11/kde4/kuser
x11/kde4/workspace
x11/motif
x11/nx/nxssh
x11/slim
x11/x11vnc
x11/xtacy




Re: Slowing down for the release

2016-07-08 Thread Jeremie Courreges-Anglas
Stuart Henderson  writes:

> On 2016/07/07 18:43, Jeremie Courreges-Anglas wrote:
>> Theo de Raadt  writes:
>> 
>> >> I don't think that getpwnam_shadow is a big concern.  Fixes can be
>> >> applied to -stable with relatively minor churn, if needed.
>> >
>> > They are being discovered slower than I expected.  Maybe there are only
>> > a handful left.
>> >
>> >  > I don't think that 6.0 can ship with wxneeded enforced.  There's just
>> >> too much to do, and afaik no one is trying to fix the few big ports that
>> >> would need it.
>> >
>> > I don't think we are tightening the enforcement.  As a result, 6.0
>> > is probably going out the door with "noisy reporting", and we'll collect
>> > information from the community.  Is that a good strategy?  Or should
>> > we silence it.
>> 
>> The logs could make a serial connection temporarily unusable.  That
>> said, I think that noisy by default would be fine, if it could be
>> disabled.
>
> Theo changed it, it just goes to logs not console now, and it's restricted
> (iirc once per process) rather than being done for every mapping.
> I think the current semantics are good for the release. chrome has a check
> in the wrapper script so people can fairly easily learn about the wxallowed
> flag, the logging is noticeable but not obnoxious, and there's a relatively
> easy way to disable it for a program.

Nice, thanks.

-- 
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: Slowing down for the release

2016-07-07 Thread Stuart Henderson
On 2016/07/07 18:43, Jeremie Courreges-Anglas wrote:
> Theo de Raadt  writes:
> 
> >> I don't think that getpwnam_shadow is a big concern.  Fixes can be
> >> applied to -stable with relatively minor churn, if needed.
> >
> > They are being discovered slower than I expected.  Maybe there are only
> > a handful left.
> >
> >  > I don't think that 6.0 can ship with wxneeded enforced.  There's just
> >> too much to do, and afaik no one is trying to fix the few big ports that
> >> would need it.
> >
> > I don't think we are tightening the enforcement.  As a result, 6.0
> > is probably going out the door with "noisy reporting", and we'll collect
> > information from the community.  Is that a good strategy?  Or should
> > we silence it.
> 
> The logs could make a serial connection temporarily unusable.  That
> said, I think that noisy by default would be fine, if it could be
> disabled.

Theo changed it, it just goes to logs not console now, and it's restricted
(iirc once per process) rather than being done for every mapping.
I think the current semantics are good for the release. chrome has a check
in the wrapper script so people can fairly easily learn about the wxallowed
flag, the logging is noticeable but not obnoxious, and there's a relatively
easy way to disable it for a program.



Re: Slowing down for the release

2016-07-07 Thread Theo de Raadt
> I don't think that getpwnam_shadow is a big concern.  Fixes can be
> applied to -stable with relatively minor churn, if needed.

They are being discovered slower than I expected.  Maybe there are only
a handful left.

 > I don't think that 6.0 can ship with wxneeded enforced.  There's just
> too much to do, and afaik no one is trying to fix the few big ports that
> would need it.

I don't think we are tightening the enforcement.  As a result, 6.0
is probably going out the door with "noisy reporting", and we'll collect
information from the community.  Is that a good strategy?  Or should
we silence it.



Re: Slowing down for the release

2016-07-07 Thread Jeremie Courreges-Anglas
Christian Weisgerber  writes:

> The next release, 6.0, is approaching fast.  It's time to wind down
> the ports churn, focus on fixing problems and stop introducing them.

fwiw I have a security update coming for samba.

> Over the next few days, please stop importing new ports and regular
> updates.  If you're in the middle of something, finish it, but by
> the weekend this should be done, and commits will be increasingly
> restricted from there.
>
> What's the situation with wxneeded annotations and getpwnam_shadow?
> If that work hasn't been completed, it's high time to get it done.

I don't think that getpwnam_shadow is a big concern.  Fixes can be
applied to -stable with relatively minor churn, if needed.

I don't think that 6.0 can ship with wxneeded enforced.  There's just
too much to do, and afaik no one is trying to fix the few big ports that
would need it.

  
https://docs.google.com/spreadsheets/d/1RjfH2_ecaUc_G5kmPAKbH00w0qcR-vWljTiUb4UCVXI/edit?usp=sharing

(looks like it's not up to date)

-- 
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE