Re: [blfs-dev] What's left for the 9.0 release?
On September 1, 2019 3:09:29 AM CDT, Pierre Labastie via blfs-dev wrote: >On 31/08/2019 21:12, DJ Lucas via blfs-dev wrote: >> >> >> On 8/31/2019 12:25 PM, Pierre Labastie via blfs-dev wrote: >>> On 31/08/2019 17:25, Xi Ruoyao via blfs-dev wrote: I failed. Either I misused jhalfs or it has a bug. I got some >"Error 2" from make and was able to "fix" some of them. But at last I can't >continue anymore. >>> At which stage did it fail? make in the jhalfs dir or make in >packages? >>> I'm sorry about the doc. I do not work much on it. Roger Koehler >gave the >>> necessary bits. I do not know what to add without knowing where it >failed. >>> >>> Pierre > >It is very important for me to get some feedback, so thanks for >sharing: > >> I have the same issues (I think just not breaking it up into parts). >The sgml >> stuff all fails when adding catalogs, these must be edited prior to >running, >> killing off the destdir catalogs, otherwise you will need to edit >> /etc/sgml/catalog.cat before proceeding. Another thing is that binary >texlive >> probably needs to be installed to avoid editing files that depend on >it >> because we do not have a concept of dependencies for command blocks >in the >> book. I've taken to install texlive manually. That said, blfs-tool >has come a >> long long way. Looking good. In addition to the list you posted >above, I have >> the following: >> >> GTK2 and GTK3: the commands to update the iconcache and db should be >removed >> from the DESTDIR install >> QT5: set QT5PREFIX and required configuration changes if you want to >install >> into /usr >> Postfix: this was mentioned, but to be a bit more clear, make sure >you have >> your link and C args in there for rebuilding the makefile >> >> Even with this number of issues, I have to congratulate you on the >work you've >> done. A very large portion of the book can be built using it. Yes, >there are >> some issues, some of these could be addressed in the book source >while staying >> on db4.5, but the tools have come a long, long way. > >Thanks a lot. I'm amazed you keep talking about destdir installs in >blfs >tools: there is no possibility for that, is there? Oh, I see, you use >the >packInstall.sh for dpkg or pacman, don't you? I've never tested that, I >use >porg. I even believed there was no way to use destdir installs in blfs >tools, >because some directories have to be created before some instructions >are run. > >Concerning texlive, the binary build could be added if you request it, >but for >texlive, the build time is not very long compared to the download time >anyway, >so I always install texlive from source. > >Normally, now, all commands that depend on texlive or doxygen are >commented >out as being remap='doc' instructions, so there are no circular >dependencies >for those. Scripts need to be edited to use doxygen and/or texlive >instead >(uncomment the corresponding instructions). > >Pierre >-- >http://lists.linuxfromscratch.org/listinfo/blfs-dev >FAQ: http://www.linuxfromscratch.org/blfs/faq.html >Unsubscribe: See the above information page Then I am doing something wrong. I'll go back and check it out and report back. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 31/08/2019 21:12, DJ Lucas via blfs-dev wrote: > > > On 8/31/2019 12:25 PM, Pierre Labastie via blfs-dev wrote: >> On 31/08/2019 17:25, Xi Ruoyao via blfs-dev wrote: >>> I failed. Either I misused jhalfs or it has a bug. I got some "Error 2" >>> from >>> make and was able to "fix" some of them. But at last I can't continue >>> anymore. >>> >> At which stage did it fail? make in the jhalfs dir or make in packages? >> I'm sorry about the doc. I do not work much on it. Roger Koehler gave the >> necessary bits. I do not know what to add without knowing where it failed. >> >> Pierre It is very important for me to get some feedback, so thanks for sharing: > I have the same issues (I think just not breaking it up into parts). The sgml > stuff all fails when adding catalogs, these must be edited prior to running, > killing off the destdir catalogs, otherwise you will need to edit > /etc/sgml/catalog.cat before proceeding. Another thing is that binary texlive > probably needs to be installed to avoid editing files that depend on it > because we do not have a concept of dependencies for command blocks in the > book. I've taken to install texlive manually. That said, blfs-tool has come a > long long way. Looking good. In addition to the list you posted above, I have > the following: > > GTK2 and GTK3: the commands to update the iconcache and db should be removed > from the DESTDIR install > QT5: set QT5PREFIX and required configuration changes if you want to install > into /usr > Postfix: this was mentioned, but to be a bit more clear, make sure you have > your link and C args in there for rebuilding the makefile > > Even with this number of issues, I have to congratulate you on the work you've > done. A very large portion of the book can be built using it. Yes, there are > some issues, some of these could be addressed in the book source while staying > on db4.5, but the tools have come a long, long way. Thanks a lot. I'm amazed you keep talking about destdir installs in blfs tools: there is no possibility for that, is there? Oh, I see, you use the packInstall.sh for dpkg or pacman, don't you? I've never tested that, I use porg. I even believed there was no way to use destdir installs in blfs tools, because some directories have to be created before some instructions are run. Concerning texlive, the binary build could be added if you request it, but for texlive, the build time is not very long compared to the download time anyway, so I always install texlive from source. Normally, now, all commands that depend on texlive or doxygen are commented out as being remap='doc' instructions, so there are no circular dependencies for those. Scripts need to be edited to use doxygen and/or texlive instead (uncomment the corresponding instructions). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 8/31/2019 12:25 PM, Pierre Labastie via blfs-dev wrote: On 31/08/2019 17:25, Xi Ruoyao via blfs-dev wrote: On 2019-08-30 21:44 +0200, Pierre Labastie via blfs-dev wrote: On 30/08/2019 17:44, Xi Ruoyao via blfs-dev wrote: On 2019-08-30 10:24 -0500, Douglas R. Reno wrote: On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote: On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: All packages have now been tagged and all tickets closed for the 9.0 release. What other things are remaining that we need to address before the Sunday release? -- Bruce It seems #12448 and #12459 contain various security fixes. Should we backport them to 9.0? -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one from 2015. The problem with backporting updates is that I believe that everything that links to them has to be retested. That being said though, I'd give a +1 to backporting them. I'll try a full jhalfs build to verify 9.0 tomorrow. I hope I can use jhalfs correctly and my 16-core workstation will work fine. But I can't guarantee any success. If you need anything, please tell me. I think a full blfs can be built by editing at most 30 scripts, most notably: I failed. Either I misused jhalfs or it has a bug. I got some "Error 2" from make and was able to "fix" some of them. But at last I can't continue anymore. At which stage did it fail? make in the jhalfs dir or make in packages? I'm sorry about the doc. I do not work much on it. Roger Koehler gave the necessary bits. I do not know what to add without knowing where it failed. Pierre I have the same issues (I think just not breaking it up into parts). The sgml stuff all fails when adding catalogs, these must be edited prior to running, killing off the destdir catalogs, otherwise you will need to edit /etc/sgml/catalog.cat before proceeding. Another thing is that binary texlive probably needs to be installed to avoid editing files that depend on it because we do not have a concept of dependencies for command blocks in the book. I've taken to install texlive manually. That said, blfs-tool has come a long long way. Looking good. In addition to the list you posted above, I have the following: GTK2 and GTK3: the commands to update the iconcache and db should be removed from the DESTDIR install QT5: set QT5PREFIX and required configuration changes if you want to install into /usr Postfix: this was mentioned, but to be a bit more clear, make sure you have your link and C args in there for rebuilding the makefile Even with this number of issues, I have to congratulate you on the work you've done. A very large portion of the book can be built using it. Yes, there are some issues, some of these could be addressed in the book source while staying on db4.5, but the tools have come a long, long way. --DJ -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 31/08/2019 17:25, Xi Ruoyao via blfs-dev wrote: > On 2019-08-30 21:44 +0200, Pierre Labastie via blfs-dev wrote: >> On 30/08/2019 17:44, Xi Ruoyao via blfs-dev wrote: >>> On 2019-08-30 10:24 -0500, Douglas R. Reno wrote: On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote: > On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: >> All packages have now been tagged and all tickets closed for the 9.0 >> release. What other things are remaining that we need to address >> before >> the Sunday release? >> >>-- Bruce > > It seems #12448 and #12459 contain various security fixes. Should we > backport > them to 9.0? > -- > Xi Ruoyao > School of Aerospace Science and Technology, Xidian University #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one from 2015. The problem with backporting updates is that I believe that everything that links to them has to be retested. That being said though, I'd give a +1 to backporting them. >>> >>> I'll try a full jhalfs build to verify 9.0 tomorrow. I hope I can use >>> jhalfs >>> correctly and my 16-core workstation will work fine. But I can't guarantee >>> any >>> success. >>> >> >> If you need anything, please tell me. I think a full blfs can be built by >> editing at most 30 scripts, most notably: > > I failed. Either I misused jhalfs or it has a bug. I got some "Error 2" from > make and was able to "fix" some of them. But at last I can't continue > anymore. > At which stage did it fail? make in the jhalfs dir or make in packages? I'm sorry about the doc. I do not work much on it. Roger Koehler gave the necessary bits. I do not know what to add without knowing where it failed. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On Sat, Aug 31, 2019, 9:33 AM Xi Ruoyao via blfs-dev < blfs-dev@lists.linuxfromscratch.org> wrote: > On 2019-08-30 21:44 +0200, Pierre Labastie via blfs-dev wrote: > > On 30/08/2019 17:44, Xi Ruoyao via blfs-dev wrote: > > > On 2019-08-30 10:24 -0500, Douglas R. Reno wrote: > > > > On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote: > > > > > On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: > > > > > > All packages have now been tagged and all tickets closed for the > 9.0 > > > > > > release. What other things are remaining that we need to > address > > > > > > before > > > > > > the Sunday release? > > > > > > > > > > > >-- Bruce > > > > > > > > > > It seems #12448 and #12459 contain various security fixes. Should > we > > > > > backport > > > > > them to 9.0? > > > > > -- > > > > > Xi Ruoyao > > > > > School of Aerospace Science and Technology, Xidian University > > > > > > > > #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and > one > > > > from 2015. The problem with backporting updates is that I believe > that > > > > everything that links to them has to be retested. That being said > > > > though, I'd give a +1 to backporting them. > > > > > > I'll try a full jhalfs build to verify 9.0 tomorrow. I hope I can use > > > jhalfs > > > correctly and my 16-core workstation will work fine. But I can't > guarantee > > > any > > > success. > > > > > > > If you need anything, please tell me. I think a full blfs can be built by > > editing at most 30 scripts, most notably: > > I failed. Either I misused jhalfs or it has a bug. I got some "Error 2" > from > make and was able to "fix" some of them. But at last I can't continue > anymore. > > I'll read its documentation again... > The main things to remember before starting a jhalfs build are: 1. All necessary tools are installed. 2. You are either connected to the internet or you have all the necessary packages in your archive and you have a local copy of the book xml files. 3. You have mounted the partition you intend to install on. 4. The user you are logged in as has write permission on the mounted install partition 5. If you are using package management, make sure you have created or copied the two necessary scripts. If I remember those things, I usually don't have any errors. > -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 2019-08-30 21:44 +0200, Pierre Labastie via blfs-dev wrote: > On 30/08/2019 17:44, Xi Ruoyao via blfs-dev wrote: > > On 2019-08-30 10:24 -0500, Douglas R. Reno wrote: > > > On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote: > > > > On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: > > > > > All packages have now been tagged and all tickets closed for the 9.0 > > > > > release. What other things are remaining that we need to address > > > > > before > > > > > the Sunday release? > > > > > > > > > >-- Bruce > > > > > > > > It seems #12448 and #12459 contain various security fixes. Should we > > > > backport > > > > them to 9.0? > > > > -- > > > > Xi Ruoyao > > > > School of Aerospace Science and Technology, Xidian University > > > > > > #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one > > > from 2015. The problem with backporting updates is that I believe that > > > everything that links to them has to be retested. That being said > > > though, I'd give a +1 to backporting them. > > > > I'll try a full jhalfs build to verify 9.0 tomorrow. I hope I can use > > jhalfs > > correctly and my 16-core workstation will work fine. But I can't guarantee > > any > > success. > > > > If you need anything, please tell me. I think a full blfs can be built by > editing at most 30 scripts, most notably: I failed. Either I misused jhalfs or it has a bug. I got some "Error 2" from make and was able to "fix" some of them. But at last I can't continue anymore. I'll read its documentation again... -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 30/08/2019 17:44, Xi Ruoyao via blfs-dev wrote: > On 2019-08-30 10:24 -0500, Douglas R. Reno wrote: >> On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote: >>> On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: All packages have now been tagged and all tickets closed for the 9.0 release. What other things are remaining that we need to address before the Sunday release? -- Bruce >>> >>> It seems #12448 and #12459 contain various security fixes. Should we >>> backport >>> them to 9.0? >>> -- >>> Xi Ruoyao >>> School of Aerospace Science and Technology, Xidian University >> >> #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one >> from 2015. The problem with backporting updates is that I believe that >> everything that links to them has to be retested. That being said >> though, I'd give a +1 to backporting them. > > I'll try a full jhalfs build to verify 9.0 tomorrow. I hope I can use jhalfs > correctly and my 16-core workstation will work fine. But I can't guarantee > any > success. > If you need anything, please tell me. I think a full blfs can be built by editing at most 30 scripts, most notably: - PAM (choose which "system-password" file) - openldap (choose between server and client) - mariadb and posgresql (add a sleep 1 after starting the daemon, and some config files for mariadb) - kerberos (the config needs to be done manually) - aspell (choose a dictionary) - sendmail, postfix, and exim (choose one, and verify config files) - openssh (needs manual intervention for generating key and sending it to remote) - rust (the instructions for creating /opt/rust are wrongly wrapped into porg instructions, if you use porg) - bind, bind-utils, and unbound (choose one, and verify config files) - cups, and some other packages, may have instructions like gtk-update-icon-cache or update-desktop-database before the corresponding program is installed. - java binary (choose 32/64 bits) - openjdk (unset MAKEFLAGS) - gtk2 (check config) - dhcp, dhcpcd (choose one, and check config) - tripwire - almost all the packages that install bootscripts which need some configuration in /etc/sysconfig (ftp programs, DM, and DE, network interfaces, etc) - package using tex (need to add the directory of tex binaries to PATH when running sudo, not sure it is needed anymore, but I do it :) - mozilla packages (edit config) - the environment scripts (xorg-env, kf5-intro) - kf5-frameworks and plasma (remove bash -e and exit, since they break scripts), and also edit some /opt settings. Also, it is usually necessary to rebuild poppler after qt5 (if built before), otherwise okular does not compile. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 2019-08-30 11:10, Bruce Dubbs via blfs-dev wrote: On 8/30/19 10:24 AM, Douglas R. Reno via blfs-dev wrote: On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote: On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: All packages have now been tagged and all tickets closed for the 9.0 release. What other things are remaining that we need to address before the Sunday release? It seems #12448 and #12459 contain various security fixes. Should we backport them to 9.0? #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one from 2015. The problem with backporting updates is that I believe that everything that links to them has to be retested. That being said though, I'd give a +1 to backporting them. Webkit has gnome/applications/evolution.xml gnome/platform/yelp.xml gnome/platform/gnome-online-accounts.xml gnome/platform/zenity.xml xsoft/graphweb/epiphany.xml xsoft/other/balsa.xml Ruby has: server/databases/mariadb.xml x/lib/webkitgtk.xml postlfs/editors/vim.xml xincludes/texruntime.xml general/graphlib/gegl.xml general/prog/subversion.xml general/genutils/graphviz.xml pst/xml/docbook-xsl.xml libgcrypt has: networking/netprogs/samba.xml networking/netutils/wireshark.xml x/lib/gtk-vnc.xml x/installing/mesa.xml x/installing/xorg-server.xml x/dm/lightdm.xml postlfs/virtualization/qemu.xml postlfs/security/cryptsetup.xml postlfs/security/gnupg2.xml multimedia/libdriv/gst10-plugins-bad.xml multimedia/videoutils/vlc.xml kde/kf5/kf5-frameworks.xml gnome/applications/vino.xml gnome/platform/gcr.xml gnome/platform/totem-pl-parser.xml gnome/platform/gvfs.xml gnome/platform/libsecret.xml general/sysutils/accountsservice.xml general/sysutils/systemd.xml general/sysutils/rasqal.xml general/genlib/libxslt.xml general/genlib/qca.xml general/genlib/libssh2.xml xsoft/office/abiword.xml xsoft/other/tigervnc.xml xsoft/other/pidgin.xml Do we have any volunteers? The alternative is to update after release and publish notification in the errata. I'll note that we get these types of security updates continuously thoughout the year. webkit and firefox seem to get them quite often. -- Bruce I was going to take the day off, but I can handle it. I have all of those built anyway. I'll have 'em in by later tonight or tomorrow morning. I'll start in around an hour and fetch the three tickets. I'm going to do ruby first, then WebKitGTK+, and then libgcrypt. Going for libgcrypt last because it has the most to reverify. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 8/30/19 10:24 AM, Douglas R. Reno via blfs-dev wrote: On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote: On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: All packages have now been tagged and all tickets closed for the 9.0 release. What other things are remaining that we need to address before the Sunday release? It seems #12448 and #12459 contain various security fixes. Should we backport them to 9.0? #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one from 2015. The problem with backporting updates is that I believe that everything that links to them has to be retested. That being said though, I'd give a +1 to backporting them. Webkit has gnome/applications/evolution.xml gnome/platform/yelp.xml gnome/platform/gnome-online-accounts.xml gnome/platform/zenity.xml xsoft/graphweb/epiphany.xml xsoft/other/balsa.xml Ruby has: server/databases/mariadb.xml x/lib/webkitgtk.xml postlfs/editors/vim.xml xincludes/texruntime.xml general/graphlib/gegl.xml general/prog/subversion.xml general/genutils/graphviz.xml pst/xml/docbook-xsl.xml libgcrypt has: networking/netprogs/samba.xml networking/netutils/wireshark.xml x/lib/gtk-vnc.xml x/installing/mesa.xml x/installing/xorg-server.xml x/dm/lightdm.xml postlfs/virtualization/qemu.xml postlfs/security/cryptsetup.xml postlfs/security/gnupg2.xml multimedia/libdriv/gst10-plugins-bad.xml multimedia/videoutils/vlc.xml kde/kf5/kf5-frameworks.xml gnome/applications/vino.xml gnome/platform/gcr.xml gnome/platform/totem-pl-parser.xml gnome/platform/gvfs.xml gnome/platform/libsecret.xml general/sysutils/accountsservice.xml general/sysutils/systemd.xml general/sysutils/rasqal.xml general/genlib/libxslt.xml general/genlib/qca.xml general/genlib/libssh2.xml xsoft/office/abiword.xml xsoft/other/tigervnc.xml xsoft/other/pidgin.xml Do we have any volunteers? The alternative is to update after release and publish notification in the errata. I'll note that we get these types of security updates continuously thoughout the year. webkit and firefox seem to get them quite often. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 2019-08-30 23:44 +0800, Xi Ruoyao wrote: > On 2019-08-30 10:24 -0500, Douglas R. Reno wrote: > > On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote: > > > On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: > > > > All packages have now been tagged and all tickets closed for the 9.0 > > > > release. What other things are remaining that we need to address > > > > before > > > > the Sunday release? > > > > > > > >-- Bruce > > > > > > It seems #12448 and #12459 contain various security fixes. Should we > > > backport > > > them to 9.0? > > > -- > > > Xi Ruoyao > > > School of Aerospace Science and Technology, Xidian University > > > > #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one > > from 2015. The problem with backporting updates is that I believe that > > everything that links to them has to be retested. That being said > > though, I'd give a +1 to backporting them. > > I'll try a full jhalfs build to verify 9.0 tomorrow. I hope I can use jhalfs > correctly and my 16-core workstation will work fine. But I can't guarantee > any > success. > > And volume-key can be built with Python 3 now. It should be OK to move the P2 > dependency to optional (for Python 2 binding). Should it be done in 9.0 or > 9.1? Sorry not volume-key but I can't recall which one now... I built "that" package a week ago I think. Defer it to 9.1. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 2019-08-30 10:24 -0500, Douglas R. Reno wrote: > On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote: > > On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: > > > All packages have now been tagged and all tickets closed for the 9.0 > > > release. What other things are remaining that we need to address > > > before > > > the Sunday release? > > > > > >-- Bruce > > > > It seems #12448 and #12459 contain various security fixes. Should we > > backport > > them to 9.0? > > -- > > Xi Ruoyao > > School of Aerospace Science and Technology, Xidian University > > #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one > from 2015. The problem with backporting updates is that I believe that > everything that links to them has to be retested. That being said > though, I'd give a +1 to backporting them. I'll try a full jhalfs build to verify 9.0 tomorrow. I hope I can use jhalfs correctly and my 16-core workstation will work fine. But I can't guarantee any success. And volume-key can be built with Python 3 now. It should be OK to move the P2 dependency to optional (for Python 2 binding). Should it be done in 9.0 or 9.1? -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 2019-08-30 10:22, Xi Ruoyao via blfs-dev wrote: On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: All packages have now been tagged and all tickets closed for the 9.0 release. What other things are remaining that we need to address before the Sunday release? -- Bruce It seems #12448 and #12459 contain various security fixes. Should we backport them to 9.0? -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University #12456 (Ruby) has a fix for two vulnerabilities - one from 2012 and one from 2015. The problem with backporting updates is that I believe that everything that links to them has to be retested. That being said though, I'd give a +1 to backporting them. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 2019-08-30 09:20 -0500, Bruce Dubbs via blfs-dev wrote: > All packages have now been tagged and all tickets closed for the 9.0 > release. What other things are remaining that we need to address before > the Sunday release? > >-- Bruce It seems #12448 and #12459 contain various security fixes. Should we backport them to 9.0? -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] What's left for the 9.0 release?
On 2019-08-30 09:20, Bruce Dubbs via blfs-dev wrote: All packages have now been tagged and all tickets closed for the 9.0 release. What other things are remaining that we need to address before the Sunday release? -- Bruce There are a few things that I'd like to suggest (my apologies for the text wrapping if it comes out wrong, using the webmail interface since I'm at a Windows machine). One thing that I'd like to see addressed is the installation of systemd units in xfce4-notifyd and Thunar. That should most certainly be fixed before release. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
