Re: Slowing down for the release
> 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
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
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
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
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
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
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
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
On Mon, Jul 11, 2016 at 12:40 PM, Stuart Hendersonwrote: > 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
> sysutils/openpoppassd This one is done. -- Antoine
Re: Slowing down for the release
> 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
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
Stuart Hendersonwrites: > 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
On 2016/07/07 18:43, Jeremie Courreges-Anglas wrote: > Theo de Raadtwrites: > > >> 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
> 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
Christian Weisgerberwrites: > 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