From pwcazenave at gmail.com Sun Aug 2 14:00:46 2009 From: pwcazenave at gmail.com (Pierre Cazenave) Date: Sun, 02 Aug 2009 15:00:46 +0100 Subject: [sbopkg-users] Installed packages and queue files Message-ID: <4A759C0E.5030302@gmail.com> Hi all, I'm not sure if this has been discussed before, but I've noticed that if I use a queue file to build a package and its dependencies, then all the packages listed in the queue file will be built, irrespective of whether they're already installed. A useful option would be to have sbopkg skip building those files that are already installed, thus reducing build times considerably. This way, a centrally distributed queue file (like those in /var/lib/sbopkg/queues) wouldn't build packages already installed on a user's system. Pierre From chess.griffin at gmail.com Sun Aug 2 15:04:24 2009 From: chess.griffin at gmail.com (Chess Griffin) Date: Sun, 2 Aug 2009 11:04:24 -0400 Subject: [sbopkg-users] Installed packages and queue files In-Reply-To: <4A759C0E.5030302@gmail.com> References: <4A759C0E.5030302@gmail.com> Message-ID: On Sun, Aug 2, 2009 at 10:00 AM, Pierre Cazenave wrote: > Hi all, > > I'm not sure if this has been discussed before, but I've noticed that if I > use a queue file to build a package and its dependencies, then all the > packages listed in the queue file will be built, irrespective of whether > they're already installed. A useful option would be to have sbopkg skip > building those files that are already installed, thus reducing build times > considerably. This way, a centrally distributed queue file (like those in > /var/lib/sbopkg/queues) wouldn't build packages already installed on a > user's system. > This has come up before. The only difficulty is that this option really could not do a simple check of whether the package in the queue is installed. To do it right, it would essentially first have to determine whether a package in the queue is installed and then also determine whether there is an update to that package. If the package passed both checks -- meaning the package is installed and there is no update -- then conceivably it could be skipped (or the user given the option to skip). Overall, this would probably slow down the queue processing at the outset. This is not an insurmountable problem, but still it is something to consider. I agree that it would be helpful, though. -- Chess Griffin From pwcazenave at gmail.com Sun Aug 2 16:24:33 2009 From: pwcazenave at gmail.com (Pierre Cazenave) Date: Sun, 02 Aug 2009 17:24:33 +0100 Subject: [sbopkg-users] Installed packages and queue files In-Reply-To: References: <4A759C0E.5030302@gmail.com> Message-ID: <4A75BDC1.9060605@gmail.com> Chess Griffin wrote: > On Sun, Aug 2, 2009 at 10:00 AM, Pierre Cazenave wrote: >> Hi all, >> >> I'm not sure if this has been discussed before, but I've noticed that if I >> use a queue file to build a package and its dependencies, then all the >> packages listed in the queue file will be built, irrespective of whether >> they're already installed. A useful option would be to have sbopkg skip >> building those files that are already installed, thus reducing build times >> considerably. This way, a centrally distributed queue file (like those in >> /var/lib/sbopkg/queues) wouldn't build packages already installed on a >> user's system. >> > > This has come up before. The only difficulty is that this option > really could not do a simple check of whether the package in the queue > is installed. To do it right, it would essentially first have to > determine whether a package in the queue is installed and then also > determine whether there is an update to that package. If the package > passed both checks -- meaning the package is installed and there is no > update -- then conceivably it could be skipped (or the user given the > option to skip). Overall, this would probably slow down the queue > processing at the outset. This is not an insurmountable problem, but > still it is something to consider. > > I agree that it would be helpful, though. > Perhaps having the default as it is at the moment, so that there's no increase in time for the standard behaviour, but having a flag like --check-installed could then trigger the slower checks for installed packages? This way a casual-ish user would have the current experience, but if you wanted to avoid the possibility of having to rebuild packages you've already installed, it'd be available as an option. Of course, you can just comment out the installed packages from the queue file, but I don't always remember everything that's installed on my system! I also don't think it'd necessarily have to check for updates to the currently installed packages, as that's more a job for the dedicated update option in sbopkg. Pierre From mauro.giachero at gmail.com Sun Aug 2 16:33:53 2009 From: mauro.giachero at gmail.com (Mauro Giachero) Date: Sun, 2 Aug 2009 18:33:53 +0200 Subject: [sbopkg-users] Installed packages and queue files In-Reply-To: <4A75BDC1.9060605@gmail.com> References: <4A759C0E.5030302@gmail.com> <4A75BDC1.9060605@gmail.com> Message-ID: On Sun, Aug 2, 2009 at 6:24 PM, Pierre Cazenave wrote: > Chess Griffin wrote: > >> On Sun, Aug 2, 2009 at 10:00 AM, Pierre Cazenave >> wrote: >> >>> Hi all, >>> >>> I'm not sure if this has been discussed before, but I've noticed that if >>> I >>> use a queue file to build a package and its dependencies, then all the >>> packages listed in the queue file will be built, irrespective of whether >>> they're already installed. A useful option would be to have sbopkg skip >>> building those files that are already installed, thus reducing build >>> times >>> considerably. This way, a centrally distributed queue file (like those in >>> /var/lib/sbopkg/queues) wouldn't build packages already installed on a >>> user's system. >>> >>> >> This has come up before. The only difficulty is that this option >> really could not do a simple check of whether the package in the queue >> is installed. To do it right, it would essentially first have to >> determine whether a package in the queue is installed and then also >> determine whether there is an update to that package. If the package >> passed both checks -- meaning the package is installed and there is no >> update -- then conceivably it could be skipped (or the user given the >> option to skip). Overall, this would probably slow down the queue >> processing at the outset. This is not an insurmountable problem, but >> still it is something to consider. >> >> I agree that it would be helpful, though. >> >> > Perhaps having the default as it is at the moment, so that there's no > increase in time for the standard behaviour, but having a flag like > --check-installed could then trigger the slower checks for installed > packages? This way a casual-ish user would have the current experience, but > if you wanted to avoid the possibility of having to rebuild packages you've > already installed, it'd be available as an option. > > Of course, you can just comment out the installed packages from the queue > file, but I don't always remember everything that's installed on my system! > > I also don't think it'd necessarily have to check for updates to the > currently installed packages, as that's more a job for the dedicated update > option in sbopkg. The issue here is that you may want to build a package you have already installed. Actually, we have a half-working patch that, in the queue view, instead of "Found" shows whether a package with the same name is installed, and if so which version is installed. You still have to deselect things manually, but at least you have a handy reference. Do you think this would be enough to address the issue? -- Mauro Giachero -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwcazenave at gmail.com Sun Aug 2 16:55:47 2009 From: pwcazenave at gmail.com (Pierre Cazenave) Date: Sun, 02 Aug 2009 17:55:47 +0100 Subject: [sbopkg-users] Installed packages and queue files In-Reply-To: References: <4A759C0E.5030302@gmail.com> <4A75BDC1.9060605@gmail.com> Message-ID: <4A75C513.40008@gmail.com> Mauro Giachero wrote: > On Sun, Aug 2, 2009 at 6:24 PM, Pierre Cazenave wrote: > >> Chess Griffin wrote: >> >>> On Sun, Aug 2, 2009 at 10:00 AM, Pierre Cazenave >>> wrote: >>> >>>> Hi all, >>>> >>>> I'm not sure if this has been discussed before, but I've noticed that if >>>> I >>>> use a queue file to build a package and its dependencies, then all the >>>> packages listed in the queue file will be built, irrespective of whether >>>> they're already installed. A useful option would be to have sbopkg skip >>>> building those files that are already installed, thus reducing build >>>> times >>>> considerably. This way, a centrally distributed queue file (like those in >>>> /var/lib/sbopkg/queues) wouldn't build packages already installed on a >>>> user's system. >>>> >>>> >>> This has come up before. The only difficulty is that this option >>> really could not do a simple check of whether the package in the queue >>> is installed. To do it right, it would essentially first have to >>> determine whether a package in the queue is installed and then also >>> determine whether there is an update to that package. If the package >>> passed both checks -- meaning the package is installed and there is no >>> update -- then conceivably it could be skipped (or the user given the >>> option to skip). Overall, this would probably slow down the queue >>> processing at the outset. This is not an insurmountable problem, but >>> still it is something to consider. >>> >>> I agree that it would be helpful, though. >>> >>> >> Perhaps having the default as it is at the moment, so that there's no >> increase in time for the standard behaviour, but having a flag like >> --check-installed could then trigger the slower checks for installed >> packages? This way a casual-ish user would have the current experience, but >> if you wanted to avoid the possibility of having to rebuild packages you've >> already installed, it'd be available as an option. >> >> Of course, you can just comment out the installed packages from the queue >> file, but I don't always remember everything that's installed on my system! >> >> I also don't think it'd necessarily have to check for updates to the >> currently installed packages, as that's more a job for the dedicated update >> option in sbopkg. > > > The issue here is that you may want to build a package you have already > installed. > > Actually, we have a half-working patch that, in the queue view, instead of > "Found" shows whether a package with the same name is installed, and if so > which version is installed. You still have to deselect things manually, but > at least you have a handy reference. > > Do you think this would be enough to address the issue? > > > ------------------------------------------------------------------------ > > _______________________________________________ > sbopkg-users mailing list > sbopkg-users at sbopkg.org > http://sbopkg.org/mailman/listinfo/sbopkg-users At the moment, the way I use queue files with sbopkg is as follows: sbopkg -i somequeue.sqf Therefore, there's little interaction between me and sbopkg other than the occasional "y" or "q" etc. I think that were I to use it from the dialog-based menu system, having the option to remove packages from a queue file that were already installed on my system would help. There's a certain amount of overlap between different programs which all fill a similar niche, so rebuilding those overlapping dependencies was increasing my build times needlessly. Having to manually remove them from the queue files was difficult (or at least slow), so some option somewhere to disable building those particular dependencies would be nice. Pierre From pwcazenave at gmail.com Sun Aug 2 16:59:14 2009 From: pwcazenave at gmail.com (Pierre Cazenave) Date: Sun, 02 Aug 2009 17:59:14 +0100 Subject: [sbopkg-users] queue files Message-ID: <4A75C5E2.7060504@gmail.com> Hi, I've attached a few queue files I've written, if you're interested. Pierre -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dvdrip_build.sqf URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ffmpeg_build.sqf URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: octave_build.sqf URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: transcode_build.sqf URL: From mauro.giachero at gmail.com Sun Aug 2 16:59:49 2009 From: mauro.giachero at gmail.com (Mauro Giachero) Date: Sun, 2 Aug 2009 18:59:49 +0200 Subject: [sbopkg-users] Installed packages and queue files In-Reply-To: <4A75C513.40008@gmail.com> References: <4A759C0E.5030302@gmail.com> <4A75BDC1.9060605@gmail.com> <4A75C513.40008@gmail.com> Message-ID: On Sun, Aug 2, 2009 at 6:55 PM, Pierre Cazenave wrote: > Mauro Giachero wrote: > >> [snip] >> >> The issue here is that you may want to build a package you have already >> installed. >> >> Actually, we have a half-working patch that, in the queue view, instead of >> "Found" shows whether a package with the same name is installed, and if so >> which version is installed. You still have to deselect things manually, >> but >> at least you have a handy reference. >> >> Do you think this would be enough to address the issue? >> > > At the moment, the way I use queue files with sbopkg is as follows: > > sbopkg -i somequeue.sqf > > Therefore, there's little interaction between me and sbopkg other than the > occasional "y" or "q" etc. I think that were I to use it from the > dialog-based menu system, having the option to remove packages from a queue > file that were already installed on my system would help. > > There's a certain amount of overlap between different programs which all > fill a similar niche, so rebuilding those overlapping dependencies was > increasing my build times needlessly. Having to manually remove them from > the queue files was difficult (or at least slow), so some option somewhere > to disable building those particular dependencies would be nice. > > > Pierre > Point taken. I'll think about this. Thank you. -- Mauro Giachero -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwcazenave at gmail.com Sun Aug 2 17:08:01 2009 From: pwcazenave at gmail.com (Pierre Cazenave) Date: Sun, 02 Aug 2009 18:08:01 +0100 Subject: [sbopkg-users] Installed packages and queue files In-Reply-To: References: <4A759C0E.5030302@gmail.com> <4A75BDC1.9060605@gmail.com> <4A75C513.40008@gmail.com> Message-ID: <4A75C7F1.9020004@gmail.com> Mauro Giachero wrote: > On Sun, Aug 2, 2009 at 6:55 PM, Pierre Cazenave wrote: > >> Mauro Giachero wrote: >> >>> [snip] >>> >>> The issue here is that you may want to build a package you have already >>> installed. >>> >>> Actually, we have a half-working patch that, in the queue view, instead of >>> "Found" shows whether a package with the same name is installed, and if so >>> which version is installed. You still have to deselect things manually, >>> but >>> at least you have a handy reference. >>> >>> Do you think this would be enough to address the issue? >>> >> At the moment, the way I use queue files with sbopkg is as follows: >> >> sbopkg -i somequeue.sqf >> >> Therefore, there's little interaction between me and sbopkg other than the >> occasional "y" or "q" etc. I think that were I to use it from the >> dialog-based menu system, having the option to remove packages from a queue >> file that were already installed on my system would help. >> >> There's a certain amount of overlap between different programs which all >> fill a similar niche, so rebuilding those overlapping dependencies was >> increasing my build times needlessly. Having to manually remove them from >> the queue files was difficult (or at least slow), so some option somewhere >> to disable building those particular dependencies would be nice. >> >> >> Pierre >> > > Point taken. I'll think about this. > Thank you. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > sbopkg-users mailing list > sbopkg-users at sbopkg.org > http://sbopkg.org/mailman/listinfo/sbopkg-users I realise that this is likely to increase the time taken to process queue files which is why in some ways having this as a command-line only option might be easier. That way, the default behaviour within the dialog-based interface remains unchanged, but the possibility exists to omit those files when called as sbopkg -i. I'll see if I can hack a patch together to incorporate this functionality, though it's likely to take me a while to get my head around the code as it stands. Please don't think I'm criticising sbopkg - I use it almost every day and it's made my life significantly easier! Thanks to you all, Pierre P.S. Has any consideration been given to "outsourcing" some of the slower tasks (like checking for updates) to separate python scripts, then calling those as functions from sbopkg? I imagine that python would do the string comparison very quickly indeed... From mauro.giachero at gmail.com Sun Aug 2 17:23:11 2009 From: mauro.giachero at gmail.com (Mauro Giachero) Date: Sun, 2 Aug 2009 19:23:11 +0200 Subject: [sbopkg-users] Installed packages and queue files In-Reply-To: <4A75C7F1.9020004@gmail.com> References: <4A759C0E.5030302@gmail.com> <4A75BDC1.9060605@gmail.com> <4A75C513.40008@gmail.com> <4A75C7F1.9020004@gmail.com> Message-ID: On Sun, Aug 2, 2009 at 7:08 PM, Pierre Cazenave wrote: > > I realise that this is likely to increase the time taken to process queue > files which is why in some ways having this as a command-line only option > might be easier. That way, the default behaviour within the dialog-based > interface remains unchanged, but the possibility exists to omit those files > when called as sbopkg -i. > > I'll see if I can hack a patch together to incorporate this functionality, > though it's likely to take me a while to get my head around the code as it > stands. > > Please don't think I'm criticising sbopkg - I use it almost every day and > it's made my life significantly easier! I never did, and I appreciate your feedback. Sorry if I sounded harsh. > Thanks to you all, You're welcome. > Pierre > > P.S. Has any consideration been given to "outsourcing" some of the slower > tasks (like checking for updates) to separate python scripts, then calling > those as functions from sbopkg? I imagine that python would do the string > comparison very quickly indeed... There has been some resistance to using a different language (and, IIRC, Python has been mentioned before). The rationale usually was: - we'd have to learn another language (I don't know Python yet) - Python is not part of a minimal Slackware install (that is, you can set up a Slackware install without Python, but Bash is always assumed to be available). I personally would love to learn Python (it's in my TODO pile), but looks like there are people appreciating that sbopkg has very minimal software requirements, so I don't think this is going to happen. [Now I'm going to seek for food, or I'll have to dinner with rosemary (it's 7.20pm here). I'll reply to any follow-up later :-)] -- Mauro Giachero -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwcazenave at gmail.com Sun Aug 2 17:36:48 2009 From: pwcazenave at gmail.com (Pierre Cazenave) Date: Sun, 02 Aug 2009 18:36:48 +0100 Subject: [sbopkg-users] Installed packages and queue files In-Reply-To: References: <4A759C0E.5030302@gmail.com> <4A75BDC1.9060605@gmail.com> <4A75C513.40008@gmail.com> <4A75C7F1.9020004@gmail.com> Message-ID: <4A75CEB0.7090807@gmail.com> Mauro Giachero wrote: > On Sun, Aug 2, 2009 at 7:08 PM, Pierre Cazenave wrote: > >> I realise that this is likely to increase the time taken to process queue >> files which is why in some ways having this as a command-line only option >> might be easier. That way, the default behaviour within the dialog-based >> interface remains unchanged, but the possibility exists to omit those files >> when called as sbopkg -i. >> >> I'll see if I can hack a patch together to incorporate this functionality, >> though it's likely to take me a while to get my head around the code as it >> stands. >> >> Please don't think I'm criticising sbopkg - I use it almost every day and >> it's made my life significantly easier! > > > I never did, and I appreciate your feedback. Sorry if I sounded harsh. You didn't, but the internet being what it is, I wasn't sure how things I was saying were coming across. It seems we both did! > > >> Thanks to you all, > > > You're welcome. > > >> Pierre >> >> P.S. Has any consideration been given to "outsourcing" some of the slower >> tasks (like checking for updates) to separate python scripts, then calling >> those as functions from sbopkg? I imagine that python would do the string >> comparison very quickly indeed... > > > There has been some resistance to using a different language (and, IIRC, > Python has been mentioned before). The rationale usually was: > - we'd have to learn another language (I don't know Python yet) > - Python is not part of a minimal Slackware install (that is, you can set up > a Slackware install without Python, but Bash is always assumed to be > available). > > I personally would love to learn Python (it's in my TODO pile), It's been on my TODO list for a while too, so a practical reason to learn it would be nice! :) > but looks > like there are people appreciating that sbopkg has very minimal software > requirements, so I don't think this is going to happen. Perhaps a use_python_functions=0 which python > /dev/null 2>&1 || use_python_functions=1 at the beginning of the script could enable/disable the python functions? But like you say, the benefits are probably small compared to just using pure bash. > > [Now I'm going to seek for food, or I'll have to dinner with rosemary (it's > 7.20pm here). I'll reply to any follow-up later :-)] > Enjoy your meal. It's 6.30pm here, and I'm feeling hungry too now! From pwcazenave at gmail.com Mon Aug 10 13:08:24 2009 From: pwcazenave at gmail.com (Pierre Cazenave) Date: Mon, 10 Aug 2009 13:08:24 +0000 Subject: [sbopkg-users] Example queue files Message-ID: <4A801BC8.9060109@gmail.com> Robby replied to a post I made at LQ.org regarding rebuilding MPlayer to take advantage of libdvdcss, if you want that functionality. Apparently, it's not necessary to recompile applications which could use that since libdvdread does some clever stuff of its own. See [1] for Robby's reply. Thus, the multimedia.sqf file supplied in /var/lib/sbopkg/queue can be modified to reflect that, or a note left to inform the user that it's not strictly necessary. Pierre [1] http://www.linuxquestions.org/questions/showthread.php?p=3637763#post3637763 From chess at chessgriffin.com Mon Aug 10 22:12:00 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Mon, 10 Aug 2009 18:12:00 -0400 Subject: [sbopkg-users] Example queue files In-Reply-To: <4A801BC8.9060109@gmail.com> References: <4A801BC8.9060109@gmail.com> Message-ID: <8682df160908101511sdc187e6hdc83d341ea59dc41@mail.gmail.com> On Mon, Aug 10, 2009 at 9:08 AM, Pierre Cazenave wrote: > Robby replied to a post I made at LQ.org regarding rebuilding MPlayer to > take advantage of libdvdcss, if you want that functionality. Apparently, > it's not necessary to recompile applications which could use that since > libdvdread does some clever stuff of its own. See [1] for Robby's reply. > > Thus, the multimedia.sqf file supplied in /var/lib/sbopkg/queue can be > modified to reflect that, or a note left to inform the user that it's not > strictly necessary. > > Pierre > > [1] > http://www.linuxquestions.org/questions/showthread.php?p=3637763#post3637763 > Thanks, Pierre. I'll make the necessary change to that file. -- Chess Griffin From chess.griffin at gmail.com Mon Aug 10 23:06:55 2009 From: chess.griffin at gmail.com (Chess Griffin) Date: Mon, 10 Aug 2009 19:06:55 -0400 Subject: [sbopkg-users] queue files In-Reply-To: <4A75C5E2.7060504@gmail.com> References: <4A75C5E2.7060504@gmail.com> Message-ID: On Sun, Aug 2, 2009 at 12:59 PM, Pierre Cazenave wrote: > Hi, > > I've attached a few queue files I've written, if you're interested. > > Pierre > Thanks for these too, Pierre -- I'll put them up on the sbopkg site. -- Chess Griffin From chess at chessgriffin.com Mon Aug 24 20:12:00 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Mon, 24 Aug 2009 16:12:00 -0400 Subject: [sbopkg-users] Sbopkg 0.30.0 Released Message-ID: <20090824201200.GB14924@localhost> Howdy folks! Based on the Slackware-current ChangeLog, it seems that a release of Slackware 13.0 is very near. To celebrate this event, and to let folks get their proverbial ducks in a row when it comes to upgrading or installing, we would like to announce the final release of sbopkg version 0.30.0! This update has been many months in the making, and contains many new features, enhancements, and bug-fixes. Please note that this is a *major* upgrade, and will probably require most folks to substantially modify their existing sbopkg.conf (or, more likely, use the sbopkg.conf.new) as well as potentially move or modify their local rsync'd SlackBuilds.org repository. Furthermore, sbopkg 0.27.4 and prior installed to /usr/bin and the new sbopkg 0.30.0 installs to /usr/sbin. As a result, we strongly recommend removing any prior versions of sbopkg before doing a fresh install of version 0.30.0. Also note that with this release, the sbopkg 0.27.x branch will no longer be maintained. This new version of sbopkg has lots of great cleanups, security improvements, and new features. Here is a short, edited list of just some of the items in the ChangeLog: * Move sbopkg to /usr/sbin; remove code related to user-mode support; sbopkg must now be run as root in all cases. * Apply a major code cleanup that touches just about every part of sbopkg. * Implement configurable repository support by introducing a new /etc/sbopkg/repos.d directory where separate repositories files can be maintained and also by adding support for git-based repositories. The Slamd64Builds repository is now listed, to the joy of all the Slamd64 users out there. * Add support for new *.txz, *.tlz, and *.tbz Slackware package extensions. * Require build queuefiles have a '.sqf' file extension and change queuefile format. No longer will the queuefile format be 'APP VERSION ON/OFF' but instead will simply be one 'APP' per line. If a user wants an APP to be deselected in the dialog menus, simply put a '-' in front of it, e.g. '-APP'. This should make creating, using, and sharing queuefiles much easier and more intuitive. Add ability to have recursive queuefiles, so one queuefile named "foo.sqf" may have an entry "@bar" in which case as the foo.sqf queuefile is parsed, it will recursively go down into the 'bar.sqf' queuefile as well. The '@' symbol is used in front of an entry in a queuefile to denote another queuefile. * Add ability to load more than one queuefile at a time when building from command line interface. * Add several new functions related to checking GPG-signed tarballs, such as those that SlackBuilds.org provides. * Add ability to dump all installed packages into a build queue. * Add ability to pass build options in a queuefile when separated by a pipe character, i.e. app | FOO=yes BAR=no * Add support for Slackware 64 by a 'uname -m' test for x86_64 and if true, set ARCH to x86_64. * Add option to retry a failed build. * Add CLEANUP configuration variable, which when set to YES tells sbopkg to delete the extracted sources, and all the associated "residuals" of the build, as soon as the build is finished. * Add a function to delete obsolete (not installed) packages from $OUTPUT. * Add dialog notification of whether a queued package is installed. * Add a dialog option to automatically uncheck installed packages from the active queue, together with a command line option -k that automatically skips such packages when building with -b or -i. * Add ability to 'invert' all selected/deselected in the clear cache and obsolete sources and packages dialogs. * Numerous other user interface improvements. The full ChangeLog.txt can be viewed here: http://www.sbopkg.org/docs/ChangeLog.txt The result of this work is that both the sbopkg.conf and the directory layout for the local rsync copy of the SBo tree has changed fairly significantly. It might be possible to copy your current SBo tree from the old default of /home/sbo/12.2 (for example) to the new default of /var/lib/sbopkg/SBo/12.2 but it might just be easier to let sbopkg make the new directories and perform a fresh rsync. Please make a backup of your local rsync copy and sbopkg.conf if you have made any changes to them. We highly recommend that everyone read the new sbopkg.conf file and the corresponding man page sbopkg.conf(5) -- as well as the main sbopkg(8) man page -- to understand the changes. Also, please be sure to look at the documentation in the doc/ directory. There are documents in there that explain how the queuefiles work and how the new /etc/sbopkg/renames.d and /etc/sbopkg/repos.d directories function. There are many significant changes as compared to sbopkg 0.27.x. Additionally, while sbopkg 0.30.0 may work fine on Slackware 12.2 and below, it is primarily intended to be used on Slackware 13.0. In fact, Slackware 13.0 is now set as the default Slackware version in anticipation of the new release. You can change it back to 12.2 if you wish in the sbopkg.conf file. As you can probably tell, the new queuefile structure underwent a major overhaul, that we think makes the queuefiles much more convenient to use. Several sample queuefiles are provided in the doc/ directory, and others (including user-submitted queuefiles) can be found at the sbopkg.org website: http://www.sbopkg.org/queues/13.0 -- please feel free to contribute more. A package and source tarball for sbopkg 0.30.0 can be found at the sbopkg project website: http://www.sbopkg.org Finally, I would like to thank my two co-developers, Mauro Giachero and slakmagik. Their assistance, advice, and code contributions have been invaluable. I would also like to thank the many users who tested, provided feedback, posted bug reports, or requested enchancements. We tried to keep track of everyone and provide proper credit in the ChangeLog.txt. If we failed to mention someone, please let us know and we will correct the omission. Everyone's contributions have been extremely helpful and we have greatly appreciated the feedback. Thanks and enjoy! -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From gmartin at gmartin.org Mon Aug 24 22:58:38 2009 From: gmartin at gmartin.org (Greg Martin) Date: Mon, 24 Aug 2009 18:58:38 -0400 Subject: [sbopkg-users] Sbopkg 0.30.0 Released In-Reply-To: <20090824201200.GB14924@localhost> References: <20090824201200.GB14924@localhost> Message-ID: <4A931B1E.9050508@gmartin.org> Great job Chess and the other contributers. SBopkg was well conceived and has transformed amazingly fast in the past year. It's become (along with sb.o) a tool that bring Slackware supportability into a new era. Thanks to all for the time investment and commitment. \\Greg Chess Griffin wrote: > Howdy folks! > > Based on the Slackware-current ChangeLog, it seems that a release of > Slackware 13.0 is very near. To celebrate this event, and to let folks > get their proverbial ducks in a row when it comes to upgrading or > installing, we would like to announce the final release of sbopkg > version 0.30.0! This update has been many months in the making, and > contains many new features, enhancements, and bug-fixes. Please note > that this is a *major* upgrade, and will probably require most folks to > substantially modify their existing sbopkg.conf (or, more likely, use > the sbopkg.conf.new) as well as potentially move or modify their local > rsync'd SlackBuilds.org repository. Furthermore, sbopkg 0.27.4 and > prior installed to /usr/bin and the new sbopkg 0.30.0 installs to > /usr/sbin. As a result, we strongly recommend removing any prior > versions of sbopkg before doing a fresh install of version 0.30.0. Also > note that with this release, the sbopkg 0.27.x branch will no longer be > maintained. > > This new version of sbopkg has lots of great cleanups, security > improvements, and new features. Here is a short, edited list of just > some of the items in the ChangeLog: > > * Move sbopkg to /usr/sbin; remove code related to user-mode support; > sbopkg must now be run as root in all cases. > * Apply a major code cleanup that touches just about every part of > sbopkg. > * Implement configurable repository support by introducing a new > /etc/sbopkg/repos.d directory where separate repositories files can > be maintained and also by adding support for git-based repositories. > The Slamd64Builds repository is now listed, to the joy of all the > Slamd64 users out there. > * Add support for new *.txz, *.tlz, and *.tbz Slackware package > extensions. > * Require build queuefiles have a '.sqf' file extension and change > queuefile format. No longer will the queuefile format be 'APP VERSION > ON/OFF' but instead will simply be one 'APP' per line. If a user > wants an APP to be deselected in the dialog menus, simply put a '-' in > front of it, e.g. '-APP'. This should make creating, using, and > sharing queuefiles much easier and more intuitive. Add ability to > have recursive queuefiles, so one queuefile named "foo.sqf" may have > an entry "@bar" in which case as the foo.sqf queuefile is parsed, it > will recursively go down into the 'bar.sqf' queuefile as well. The > '@' symbol is used in front of an entry in a queuefile to denote > another queuefile. > * Add ability to load more than one queuefile at a time when building > from command line interface. > * Add several new functions related to checking GPG-signed tarballs, > such as those that SlackBuilds.org provides. > * Add ability to dump all installed packages into a build queue. > * Add ability to pass build options in a queuefile when separated by > a pipe character, i.e. app | FOO=yes BAR=no > * Add support for Slackware 64 by a 'uname -m' test for x86_64 and > if true, set ARCH to x86_64. > * Add option to retry a failed build. > * Add CLEANUP configuration variable, which when set to YES tells > sbopkg to delete the extracted sources, and all the associated > "residuals" of the build, as soon as the build is finished. > * Add a function to delete obsolete (not installed) packages from > $OUTPUT. > * Add dialog notification of whether a queued package is installed. > * Add a dialog option to automatically uncheck installed packages > from the active queue, together with a command line option -k that > automatically skips such packages when building with -b or -i. > * Add ability to 'invert' all selected/deselected in the clear cache > and obsolete sources and packages dialogs. > * Numerous other user interface improvements. > > The full ChangeLog.txt can be viewed here: > > http://www.sbopkg.org/docs/ChangeLog.txt > > The result of this work is that both the sbopkg.conf and the directory > layout for the local rsync copy of the SBo tree has changed fairly > significantly. It might be possible to copy your current SBo tree from > the old default of /home/sbo/12.2 (for example) to the new default of > /var/lib/sbopkg/SBo/12.2 but it might just be easier to let sbopkg make > the new directories and perform a fresh rsync. Please make a backup of > your local rsync copy and sbopkg.conf if you have made any changes to > them. > > We highly recommend that everyone read the new sbopkg.conf file and the > corresponding man page sbopkg.conf(5) -- as well as the main sbopkg(8) > man page -- to understand the changes. Also, please be sure to look at > the documentation in the doc/ directory. There are documents in there > that explain how the queuefiles work and how the new > /etc/sbopkg/renames.d and /etc/sbopkg/repos.d directories function. > There are many significant changes as compared to sbopkg 0.27.x. > Additionally, while sbopkg 0.30.0 may work fine on Slackware 12.2 and > below, it is primarily intended to be used on Slackware 13.0. In fact, > Slackware 13.0 is now set as the default Slackware version in > anticipation of the new release. You can change it back to 12.2 if you > wish in the sbopkg.conf file. > > As you can probably tell, the new queuefile structure underwent a major > overhaul, that we think makes the queuefiles much more convenient to > use. Several sample queuefiles are provided in the doc/ directory, and > others (including user-submitted queuefiles) can be found at the > sbopkg.org website: http://www.sbopkg.org/queues/13.0 -- please feel > free to contribute more. > > A package and source tarball for sbopkg 0.30.0 can be found at the > sbopkg project website: > > http://www.sbopkg.org > > Finally, I would like to thank my two co-developers, Mauro Giachero and > slakmagik. Their assistance, advice, and code contributions have been > invaluable. I would also like to thank the many users who tested, > provided feedback, posted bug reports, or requested enchancements. We > tried to keep track of everyone and provide proper credit in the > ChangeLog.txt. If we failed to mention someone, please let us know and > we will correct the omission. Everyone's contributions have been > extremely helpful and we have greatly appreciated the feedback. > > Thanks and enjoy! > > > ------------------------------------------------------------------------ > > _______________________________________________ > sbopkg-users mailing list > sbopkg-users at sbopkg.org > http://sbopkg.org/mailman/listinfo/sbopkg-users > From dave at unrealize.co.uk Wed Aug 26 19:19:54 2009 From: dave at unrealize.co.uk (David Woodfall) Date: Wed, 26 Aug 2009 20:19:54 +0100 Subject: [sbopkg-users] Dialog download metre example Message-ID: <20090826191954.GA24370@Junius> For Chess and friends. I was chatting with someone in #slackware the other day about making a download metre bar in dialog. Well I took up the challenge and this is what I came up with: http://www.unrealize.co.uk/scripts/bash/wget-dialog-example I thought it would be pretty neat way to see progress rather than having wget output scroll in console. Hope you find it useful Cheers David (aka dive) -- "You must realize that the computer has it in for you. The irrefutable proof of this is that the computer always does what you tell it to do." -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From mauro.giachero at gmail.com Thu Aug 27 09:23:36 2009 From: mauro.giachero at gmail.com (Mauro Giachero) Date: Thu, 27 Aug 2009 11:23:36 +0200 Subject: [sbopkg-users] Dialog download metre example In-Reply-To: <20090826191954.GA24370@Junius> References: <20090826191954.GA24370@Junius> Message-ID: On Wed, Aug 26, 2009 at 9:19 PM, David Woodfall wrote: > For Chess and friends. > > I was chatting with someone in #slackware the other day about making a > download metre bar in dialog. Well I took up the challenge and this is > what I came up with: > > http://www.unrealize.co.uk/scripts/bash/wget-dialog-example > > I thought it would be pretty neat way to see progress rather than > having wget output scroll in console. > Hope you find it useful > > Cheers > David (aka dive) Interesting hack, thank you. I too don't like the dotted wget style much, so I prefer to set --progress=bar:force in WGETFLAGS which results in a nice text progress bar. If you really like the dialog approach, the following is a much simpler implementation (which I believe to be roughly equivalent): wget --progress=bar:force $URL 2>&1 | while read -d "%" X; do sed 's:^.*[^0-9]\([0-9]*\)$:\1:' <<< "$X"; done | dialog --title "foo" --gauge "bar" 25 40 That being said, I'm dubious about a dialog progress bar because that way processing a queue would continuously switch between a dialog environment (download) and a non-dialog environment (build). IIRC the build itself has been moved out of a dialog environment since it was somewhat problematic. -- Mauro Giachero -------------- next part -------------- An HTML attachment was scrubbed... URL: From chess at chessgriffin.com Fri Aug 28 16:12:51 2009 From: chess at chessgriffin.com (chess at chessgriffin.com) Date: Fri, 28 Aug 2009 12:12:51 -0400 (Eastern Daylight Time) Subject: [sbopkg-users] Sbopkg 0.30.0 Issues Message-ID: First of all, huge congratulations to Patrick and the entire Slackware team on the release of Slackware 13.0. IMHO, this is definitely the best release yet, and the addition of Slackware 64 is awesome. Second, big thanks to everyone associated with SlackBuilds.org -- admins, maintainers, and contributors alike. Getting the repo ready for a new release is a major job by itself, but adding in the Slackware 64 support made it even bigger. Third, unfortunately, there have been a few issues that have cropped up with sbopkg 0.30.0 that we are working to fix. The major issue is that the "Check for Updates" feature seems to be broken when checking for certain updates. We're working on a fix and should have that ready soon. Building and installing stuff with 0.30.0 is working fine, however. Thanks. -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From pwcazenave at gmail.com Fri Aug 28 16:15:00 2009 From: pwcazenave at gmail.com (Pierre Cazenave) Date: Fri, 28 Aug 2009 16:15:00 +0000 Subject: [sbopkg-users] Sbopkg 0.30.0 Issues In-Reply-To: References: Message-ID: <4A980284.6060602@gmail.com> On 28/08/2009 16:12, chess at chessgriffin.com wrote: > First of all, huge congratulations to Patrick and the entire Slackware > team on the release of Slackware 13.0. IMHO, this is definitely the > best release yet, and the addition of Slackware 64 is awesome. > > Second, big thanks to everyone associated with SlackBuilds.org -- > admins, maintainers, and contributors alike. Getting the repo ready > for a new release is a major job by itself, but adding in the > Slackware 64 support made it even bigger. > > Third, unfortunately, there have been a few issues that have cropped > up with sbopkg 0.30.0 that we are working to fix. The major issue is > that the "Check for Updates" feature seems to be broken when checking > for certain updates. We're working on a fix and should have that > ready soon. Building and installing stuff with 0.30.0 is working > fine, however. > > Thanks. > > ------------------------------------------------------------------------ > > _______________________________________________ > sbopkg-users mailing list > sbopkg-users at sbopkg.org > http://sbopkg.org/mailman/listinfo/sbopkg-users > I came across this problem this morning. I've just found the solution, I think. See attached patch (it's a one liner). Pierre -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sbopkg-version-check.patch URL: From mauro.giachero at gmail.com Fri Aug 28 17:15:53 2009 From: mauro.giachero at gmail.com (Mauro Giachero) Date: Fri, 28 Aug 2009 19:15:53 +0200 Subject: [sbopkg-users] Sbopkg 0.30.0 Issues In-Reply-To: <4A980284.6060602@gmail.com> References: <4A980284.6060602@gmail.com> Message-ID: On Fri, Aug 28, 2009 at 6:15 PM, Pierre Cazenave wrote: > On 28/08/2009 16:12, chess at chessgriffin.com wrote: > >> First of all, huge congratulations to Patrick and the entire Slackware >> team on the release of Slackware 13.0. IMHO, this is definitely the best >> release yet, and the addition of Slackware 64 is awesome. >> >> Second, big thanks to everyone associated with SlackBuilds.org -- admins, >> maintainers, and contributors alike. Getting the repo ready for a new >> release is a major job by itself, but adding in the Slackware 64 support >> made it even bigger. >> >> Third, unfortunately, there have been a few issues that have cropped up >> with sbopkg 0.30.0 that we are working to fix. The major issue is that the >> "Check for Updates" feature seems to be broken when checking for certain >> updates. We're working on a fix and should have that ready soon. Building >> and installing stuff with 0.30.0 is working fine, however. >> >> Thanks. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sbopkg-users mailing list >> sbopkg-users at sbopkg.org >> http://sbopkg.org/mailman/listinfo/sbopkg-users >> >> > I came across this problem this morning. I've just found the solution, I > think. See attached patch (it's a one liner). > > Pierre > > _______________________________________________ > sbopkg-users mailing list > sbopkg-users at sbopkg.org > http://sbopkg.org/mailman/listinfo/sbopkg-users > > First off, I'd like to thank everybody who took the time to try to fix this bug, which is admittedly really annoying. The root cause of it is a SBo template change that I (i.e. the one who takes the blame for the updates code) didn't anticipate. Anyway I'm pleased to tell you that this bug, together with another bug found withing 1 day from the release, should be fixed in SVN revision 708. You may want to download that one, and if you do, please report any bugs you find. Thank you -- Mauro Giachero -------------- next part -------------- An HTML attachment was scrubbed... URL: From chess at chessgriffin.com Fri Aug 28 18:23:01 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Fri, 28 Aug 2009 14:23:01 -0400 Subject: [sbopkg-users] Sbopkg 0.30.1 Bugfix Release Message-ID: <20090828182301.GA26149@localhost> We have released sbopkg version 0.30.1, which is intended to address a couple of issues that were identified after Slackware 13.0 was released. We apologize for the inconvenience resulting from these bugs. If you find anything else wonky, please, please file a bug report at the http://code.google.com/p/sbopkg Issue Tracker. Here is the ChangeLog for this release: * Fix the updates code for the 13.0 repo; thanks to everybody who contacted us about this issue. * Fix the $SBOPKGTMP sanity check. Thanks to Ken Roberts for raising the issue. * Update the renames file. A package and tarball can be downloaded from the sbopkg website: http:/www.sbopkg.org Thanks! -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rw at rlworkman.net Fri Aug 28 19:20:46 2009 From: rw at rlworkman.net (Robby Workman) Date: Fri, 28 Aug 2009 14:20:46 -0500 Subject: [sbopkg-users] Sbopkg 0.30.0 Issues In-Reply-To: References: <4A980284.6060602@gmail.com> Message-ID: <20090828142046.09461fef@liberty.rlwhome.lan> On Fri, 28 Aug 2009 19:15:53 +0200 Mauro Giachero wrote: > First off, I'd like to thank everybody who took the time to try to > fix this bug, which is admittedly really annoying. The root cause of > it is a SBo template change that I (i.e. the one who takes the blame > for the updates code) didn't anticipate. I'm curious - what change caused the problem? -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From chess.griffin at gmail.com Fri Aug 28 19:26:16 2009 From: chess.griffin at gmail.com (Chess Griffin) Date: Fri, 28 Aug 2009 15:26:16 -0400 Subject: [sbopkg-users] Sbopkg 0.30.0 Issues In-Reply-To: <20090828142046.09461fef@liberty.rlwhome.lan> References: <4A980284.6060602@gmail.com> <20090828142046.09461fef@liberty.rlwhome.lan> Message-ID: On Fri, Aug 28, 2009 at 3:20 PM, Robby Workman wrote: > On Fri, 28 Aug 2009 19:15:53 +0200 > Mauro Giachero wrote: > >> First off, I'd like to thank everybody who took the time to try to >> fix this bug, which is admittedly really annoying. The root cause of >> it is a SBo template change that I (i.e. the one who takes the blame >> for the updates code) didn't anticipate. > > > I'm curious - what change caused the problem? > > -RW > It was the addition of $PKGTYPE -- something that I should have caught, really. Nobody's fault but mine. :/ -- Chess Griffin