Re: [Slackbuilds-users] UID/GID for another Dovecot case
On Sun, 15 Feb 2015, Willy Sudiarto Raharjo wrote: > > So, please consider this a request for either discussion or simply > > for an assigned uid/gid for a vmail user. > please use 303 for vmail 303 is a bad choice for the vmail uid because then you'll need further adjustments in the Dovecot config to work around a security feature to prevent users from ever logging in as daemons (i.e. with uids < 500). A vmail user is not required at build time and not necessarily at runtime. When it is, the choice depends on the environment and on what one is trying to achieve. A static entry in the list of recommended UIDs/GIDs doesn't look sensible to me. -- ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/15/2015 03:36 AM, Rob McGee wrote: > I never have understood why so many small-time users want to have > "virtual mail accounts." What is the appeal? "Gee whiz, all I do > when I add a domain is enter it in mysql." Well, uh, how often do > you add domains? I can see it if you're a large scale hosting > provider. Why is that so good if you're not? > In the small-timer case, delivery to system accounts is far more > powerful and flexible. You can keep all your mail in your $HOME; > you're able to run commands on certain incoming mail; you have many > more options for storing and sorting mail. I was running multiple Dovecot/Postfix instances for years, and I had the biggest problems with upgrading/migration etc. with system accounts. With virtual vmail accounts moving configs with e-mail storage among servers is much easier, so now I'm using vmail everywhere. > Furthermore, it's considerably less secure to have all mail under a > single UID/GID, as most of these virtual/mysql howtos seem to > advocate. A compromise of that user means all mail is at risk. > With system users, each recipient has her own UID, and compromises > are limited. Yes, but You already said "small-time users", so probably one-two domains, one owner, a single company etc. You can use multiple vmail users/groups (vmail1, vmail2) to separate customers. And when we're already in the subject of security, I would not give users access to their home dirs on an MTA. I would run an MTA in a separated vmachine instead of running multiple services on the same machine. And that's what I'm doing :-) > (Actually that can be done with virtual also; both Postfix and > Dovecot support map lookups for the UID & GID. But few howtos -- if > any? I don't think I have seen one -- show how this is done.) > So my concern here is twofold: one, it promotes "virtual mail" to > users who should not be using it; and two, it promotes the less > secure means of doing it, under a single UID/GID. As I already stated in this thread, I don't think that defining a vmail user/group in http://slackbuilds.org/uid_gid.txt is a good idea. IMO it's a bad idea and an unnecessary step :-) And uid 303 is really bad, because almost all howtos suggest 5000. -- Thomas Szteliga smime.p7s Description: S/MIME Cryptographic Signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/14/2015 10:21 PM, Slacker wrote: > I am writing a Slackdocs article for setting up a virtual mail server > using Postfix, Dovecot and MySQL. > In this use case we require a separate non-priv user/group for which the > Dovecot documents suggest "vmail" ( http://wiki.dovecot.org/VirtualUsers > ), and which I have used in my own implementation. > This is purely a configuration option and is not required to build the > Dovecot package. But it seems to me it is a common enough use case and > that having an SBo assigned uid/gid for "vmail" would dovetail nicely > with the dovecot docs and simplify virtual mail setup for those building > with SBo scripts. It would also simplify my Slackdocs article. > So, please consider this a request for either discussion or simply for > an assigned uid/gid for a vmail user. Hello Slacker, please consider using the default uid 5000 http://wiki2.dovecot.org/HowTo/VirtualUserFlatFilesPostfix https://wiki.archlinux.org/index.php/Virtual_user_mail_system http://www.stefan-seelmann.de/wiki/mailserver-postfix-dovecot and please let us know when Your article is published :-) -- Thomas Szteliga smime.p7s Description: S/MIME Cryptographic Signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/15/2015 01:42 AM, Willy Sudiarto Raharjo wrote: > please use 303 for vmail I'm not sure if this (303) is a good idea? Everywhere I look I see uid 5000. I'm running Dovecot + Postfix on multiple machines, and I'm always using vmail/5000. http://wiki2.dovecot.org/HowTo/VirtualUserFlatFilesPostfix https://workaround.org/book/export/html/60 https://workaround.org/ispmail/squeeze/setting-up-dovecot http://www.openchange.org/cookbook/backends/sogo/dovecot.html https://www.linode.com/docs/email/postfix/email-with-postfix-dovecot-and-mysql-on-centos-5 And as Slacker stated, this is not required for building packages, so I don't think this should be defined in http://slackbuilds.org/uid_gid.txt The vmail user/group is not required for packaging and fully optional during dovecot usage. Slackbuilds do not create users/groups so the vmail group should not be defined there. For example, on some machines I'm using separate vmail groups for separate customers, starting with vmail/5000, vmail2/5001, vmail3/5002... -- Thomas Szteliga smime.p7s Description: S/MIME Cryptographic Signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/15/2015 03:36 AM, Rob McGee wrote: On Sat, Feb 14, 2015 at 02:21:26PM -0700, Slacker wrote: I am writing a Slackdocs article for setting up a virtual mail server using Postfix, Dovecot and MySQL. In this use case we require a separate non-priv user/group for which the Dovecot documents suggest "vmail" ( http://wiki.dovecot.org/VirtualUsers ), and which I have used in my own implementation. This is purely a configuration option and is not required to build the Dovecot package. But it seems to me it is a common enough use case and that having an SBo assigned uid/gid for "vmail" would dovetail nicely with the dovecot docs and simplify virtual mail setup for those building with SBo scripts. It would also simplify my Slackdocs article. So, please consider this a request for either discussion or simply for an assigned uid/gid for a vmail user. I never have understood why so many small-time users want to have "virtual mail accounts." What is the appeal? "Gee whiz, all I do when I add a domain is enter it in mysql." Well, uh, how often do you add domains? I can see it if you're a large scale hosting provider. Why is that so good if you're not? In the small-timer case, delivery to system accounts is far more powerful and flexible. You can keep all your mail in your $HOME; you're able to run commands on certain incoming mail; you have many more options for storing and sorting mail. Furthermore, it's considerably less secure to have all mail under a single UID/GID, as most of these virtual/mysql howtos seem to advocate. A compromise of that user means all mail is at risk. With system users, each recipient has her own UID, and compromises are limited. (Actually that can be done with virtual also; both Postfix and Dovecot support map lookups for the UID & GID. But few howtos -- if any? I don't think I have seen one -- show how this is done.) So my concern here is twofold: one, it promotes "virtual mail" to users who should not be using it; and two, it promotes the less secure means of doing it, under a single UID/GID. Very well said. I would like to think that vmail *example* group was intentionally left out from uid_gid.txt to let user take a chunk of uid/gid mappings and do it properly. I also think that Slackdocs shouldn't be another copy/paste with a few minor changes; in fact, if done right it could fill that gap Rob is talking about :-) -- Mario ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] Problems With Postfix: post-install line 504 and SASL type
On 02/15/2015 12:21 AM, Rich Shepard wrote: When I build postfix-2.11.3 (or the new -3.0.0) there is an error that prevents postfix from starting. In /usr/libexec/postfix/post-install, on line 504 the error message is '... test: too many arguments'. This did not happen in earlier versions and I've no idea how to fix it. This question was answered a month ago and it can be found on this list. To answer it once more, you are probably missing quotes in main.cf (path variables). To make sure, you should probably check this and any other files that postfix loads. When I build postfix with SASL=dovecot, trying to start postfix causes it to throttle and generate continuous error messages. Care to share those errors? A week ago I wrote to the maintainer but have not received a reply. Resolving these two issues is important. Actually, I've been sending in updates to postfix/dovecot for past 4-5 years. I am not the official maintainer, so I tried to keep changes small, for better or worse. -- Mario ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] Problems With Postfix: post-install line 504 and SASL type
On Sat, Feb 14, 2015 at 04:10:07PM -0800, Rich Shepard wrote: > Any thoughts on why specifying DASL=dovecot does not work here? While "DASL" is clearly a typo, no, it makes no sense that Postfix would have a compile-time problem with Dovecot SASL. In fact no linkage takes place. Postfix communicate with Dovecot SASL over a socket, and the SASL implementation is entirely internal on the Dovecot side. The compile-time setting merely enables the code in Postfix to communicate with that socket. One might ask, why do you need Cyrus SASL if you have Dovecot installed? Typically you do not; only in the less usual case of Postfix having to authenticate at an upstream relay, would Cyrus become necessary. All the details are here: http://www.postfix.org/SASL_README.html -- Rob McGee - /dev/rob0 - r...@slackbuilds.org ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On Sat, Feb 14, 2015 at 02:21:26PM -0700, Slacker wrote: > I am writing a Slackdocs article for setting up a virtual mail > server using Postfix, Dovecot and MySQL. > > In this use case we require a separate non-priv user/group > for which the Dovecot documents suggest "vmail" ( > http://wiki.dovecot.org/VirtualUsers ), and which I have used > in my own implementation. > > This is purely a configuration option and is not required to build > the Dovecot package. But it seems to me it is a common enough use > case and that having an SBo assigned uid/gid for "vmail" would > dovetail nicely with the dovecot docs and simplify virtual mail > setup for those building with SBo scripts. It would also simplify > my Slackdocs article. > > So, please consider this a request for either discussion or simply > for an assigned uid/gid for a vmail user. I never have understood why so many small-time users want to have "virtual mail accounts." What is the appeal? "Gee whiz, all I do when I add a domain is enter it in mysql." Well, uh, how often do you add domains? I can see it if you're a large scale hosting provider. Why is that so good if you're not? In the small-timer case, delivery to system accounts is far more powerful and flexible. You can keep all your mail in your $HOME; you're able to run commands on certain incoming mail; you have many more options for storing and sorting mail. Furthermore, it's considerably less secure to have all mail under a single UID/GID, as most of these virtual/mysql howtos seem to advocate. A compromise of that user means all mail is at risk. With system users, each recipient has her own UID, and compromises are limited. (Actually that can be done with virtual also; both Postfix and Dovecot support map lookups for the UID & GID. But few howtos -- if any? I don't think I have seen one -- show how this is done.) So my concern here is twofold: one, it promotes "virtual mail" to users who should not be using it; and two, it promotes the less secure means of doing it, under a single UID/GID. -- Rob McGee - /dev/rob0 - r...@slackbuilds.org ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
[Slackbuilds-users] Updates - 20150215.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sun Feb 15 00:58:28 UTC 2015 academic/GeoGebra: Updated for version 5.0.62.0. academic/Mnemosyne: Updated for version 2.3.1. academic/patsy: Added (statistical models). audio/MusicMixer: Fixed download link. audio/atunes: Set ARCH=noarch. desktop/insync-thunar: Updated for version 1.1.5.32051. desktop/plasma-eyasdp: Added (Enhanced yaSDP). desktop/seafile-gui: Updated for version 4.0.7. development/Bottleneck: Updated for version 1.0.0. development/SDL2_gfx: Updated for version 1.0.1. development/bpython: Updated for version 0.13.2. development/coccinelle: Updated for version 1.0.0-r24. development/codelite: Added (cross platform IDE). development/eagle: Updated for version 7.2.0 + new maintainer. development/kelbt: Fixed download link and homepage. development/mono2: Updated for version 2.10.9. development/mphidflash: Added (command-line tool). development/pandas: Updated for version 0.15.2. development/poedit: Updated for version 1.7.4. development/ragel: Updated for version 6.9. development/textadept: Updated for version 7.8 & fixed symlinks. development/tstoolbox: Updated for version 0.9.4. development/uemacs: Updated for version 20141208. games/galaxyv2: Updated for version 1.85. games/lutris: Add optional DEPS. games/mednafen: Updated for version 0.9.38.1. games/xspacewarp: New maintainer. gis/OWSLib: Updated for version 0.8.13. gis/geopy: Updated for version 1.9.0. graphics/brlcad: Updated for version 7.24.2 + new maintainer. graphics/fim: Updated for version 0.5. graphics/leocad: Fix shortcut. graphics/pngquant: Updated for version 2.3.4. graphics/pygraphviz: Updated for version 1.3rc2. graphics/qcad: Updated for version 3.8.1.0. libraries/gtkdatabox: Added (GTK+ widget). libraries/libmspack: Updated for version 0.5alpha. libraries/libtar: Updated for version 1.2.20 + new maintainer. libraries/libucil: Added (a functions library). libraries/libunicapgtk: Added (GTK Widget). libraries/live555: Updated for version 2015.02.10. libraries/pymdstat: Added (library to parse /proc/mdstat). libraries/stfl: Updated for version 0.24. libraries/tinyxml2: Updated for version 2.2.0. libraries/wxGTK: New maintainer. misc/vdpauinfo: Updated for version 0.9. multimedia/Mopidy: Updated for version 0.19.5. multimedia/beets: Updated for version 1.3.10. multimedia/picard-plugins: Updated for version 20150131. multimedia/plex-home-theater: Updated for version 1.3.6.441. multimedia/ucview: Added (video capture and display program). network/Pafy: Updated for version 0.3.72. network/bottle: Added (Python web framework). network/ccnet: Updated for version 4.0.6. network/dropbox: Updated for version 3.2.6. network/graphite-carbon: Copy README.SLACKWARE into doc dir. network/insync: Updated for version 1.1.5.32051. network/iojs: Updated for version 1.2.0. network/mps-youtube: Updated for version 0.2.2. network/owncloud-server: Updated for version 8.0.0. network/postfix: Updated for version 2.11.4. network/seafile-client: Updated for version 4.0.6. network/seahub: Updated for version 4.0.6. network/youtube-dl-server: Updated for version 0.1.2. office/MasterPDFEditor: Updated for version 2.2.15. office/TaskCoach: Updated for version 1.4.2. office/libreoffice-helppack: Fix README. office/lyx: Updated for version 2.1.3. office/taskjuggler: Added (Project Management). perl/perl-AppConfig: Updated for version 1.69. python/APScheduler: Updated for version 3.0.1. python/Paver: Updated for version 1.2.3. python/babelfish: Updated for version 0.5.4. python/clint: Updated for version 0.4.1. python/curtsies: Updated for version 0.1.18. python/flake8: Updated for version 2.3.0. python/guessit: Updated for version 0.10.1. python/hg-git: Updated for version 0.8.0. python/hgsubversion: Updated for version 1.8. python/invoke: Updated for version 0.9.0. python/jmespath: Updated for version 0.6.1. python/jsonschema: Updated for version 2.4.0. python/lxml: Updated for version 3.4.2. python/mando: Added (Create Python CLI apps). python/monty: Updated for version 0.6.3. python/msgpack-python: Updated for version 0.4.5. python/path.py: Updated for version 7.2. python/pep8: Updated for version 1.6.1. python/pip: Updated for version 6.0.8. python/psutil: Updated for version 2.2.1. python/pygrametl: Updated for version 2.3.2. python/pysetuptools: Updated for version 12.0.5. python/pytest-cov: Updated for version 1.8.1. python/pytest: Updated for version 2.6.4. python/python-certifi: Updated for version 14.05.14. python/python-oauthlib: Updated for version 0.7.2. python/python-twitter: Updated for version 2.2. python/selenium: Updated for version 2.44.0. python/sge-pygame: Updated for version 0.16. python/thunarx-python: Fixed VERSION. python/virtualenv: Updated for version 12.0.7. system/TLP: Updated for version 0.7. system/gitolite: Added (Hosting git repositories). system/glances: Update optional dependencies. system/inxi: Updated for version 2.2.18. system/iucode_tool: Added (Intel Processor Microcode
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/14/2015 05:42 PM, Willy Sudiarto Raharjo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So, please consider this a request for either discussion or simply for an assigned uid/gid for a vmail user. please use 303 for vmail Thanks! ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > So, please consider this a request for either discussion or simply > for an assigned uid/gid for a vmail user. please use 303 for vmail - -- Willy Sudiarto Raharjo -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlTf628ACgkQiHuDdNczM4EQLACfRzJaQM5YZlt5gHDmgRDtiGaf HM4An0oDoN4VoRhvfY153/+GNkkK+NyI =zxOh -END PGP SIGNATURE- ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] libreoffice help pack README
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > FYI, The README states that the default build is for the en-GB > locale but the slackbuild script says > > LOLANG=${LOLANG:-en-US} > > which is also the locale or the download file. Thanks for spotting it It should be en-US for helppack and en-GB for langpack it will be fixed in my branch - -- Willy Sudiarto Raharjo -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlTf6ZAACgkQiHuDdNczM4FynwCgiTUoJxZ8L8NDd0cEQjnZz4QX xd0AnijCGu53FAFgxy8PP6OR07iB5cge =6/PN -END PGP SIGNATURE- ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] Problems With Postfix: post-install line 504 and SASL type
On Sat, 14 Feb 2015, B Watson wrote: On 2/14/15, Rich Shepard wrote: 504 -> #test -r $path -a "$type" != "d" && obsolete="$obsolete $path" Probably it's better to put double-quotes around $path: test -r "$path" -a ...blahblah That does work. So, are the missing double quotes a postfix or slackbuilds error? Thanks for that lesson. Any thoughts on why specifying DASL=dovecot does not work here? Much appreciated, Rich ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] Problems With Postfix: post-install line 504 and SASL type
On 2/14/15, Rich Shepard wrote: > 504 -> #test -r $path -a "$type" != "d" && obsolete="$obsolete $path" Probably it's better to put double-quotes around $path: test -r "$path" -a ...blahblah ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
[Slackbuilds-users] Problems With Postfix: post-install line 504 and SASL type
When I build postfix-2.11.3 (or the new -3.0.0) there is an error that prevents postfix from starting. In /usr/libexec/postfix/post-install, on line 504 the error message is '... test: too many arguments'. This did not happen in earlier versions and I've no idea how to fix it. Last Sunday I rebuilt and re-installed -2.11.3 from a fresh download of the postfix and SlackBuild files tarballs. The kludge that allowed me to get postfix working again was to comment out line 504 in /usr/libexec/postfix/post-install: # Flag obsolete objects. XXX Solaris 2..9 does not have "test -e". if [ -n "$obsolete_flag" ] then 504 -> #test -r $path -a "$type" != "d" && obsolete="$obsolete $path" continue; else keep_list="$keep_list $path" fi Both cyrus and dovecot are install here (latest versions from SBo). And this is another issue I'd like to resolve. When I build postfix with SASL=dovecot, trying to start postfix causes it to throttle and generate continuous error messages. Building postfix with SASL=cyrus produces a working set of tools. Installed here are dovecot-2.2.13-i486-1_SBo and qca-cyrus-sasl-2.0.0_beta3-i486-1. A week ago I wrote to the maintainer but have not received a reply. Resolving these two issues is important. Thanks in advance, Rich ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
[Slackbuilds-users] UID/GID for another Dovecot case
I am writing a Slackdocs article for setting up a virtual mail server using Postfix, Dovecot and MySQL. In this use case we require a separate non-priv user/group for which the Dovecot documents suggest "vmail" ( http://wiki.dovecot.org/VirtualUsers ), and which I have used in my own implementation. This is purely a configuration option and is not required to build the Dovecot package. But it seems to me it is a common enough use case and that having an SBo assigned uid/gid for "vmail" would dovetail nicely with the dovecot docs and simplify virtual mail setup for those building with SBo scripts. It would also simplify my Slackdocs article. So, please consider this a request for either discussion or simply for an assigned uid/gid for a vmail user. Thanks! Robert ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
[Slackbuilds-users] libreoffice help pack README
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI, The README states that the default build is for the en-GB locale but the slackbuild script says LOLANG=${LOLANG:-en-US} which is also the locale or the download file. - -Ed -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlTfty8ACgkQXvwMaW61dLc9DACgrVmL79O+HxU5UxZMF/L8MrOo Du8AnirlxiUYi4P1boTu+jn0IC6zHniG =e5WN -END PGP SIGNATURE- ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] atunes.SlackBuild
2015-02-14 16:19 GMT+01:00 Panagiotis Nikolaou : > Hi!, > > I notice atunes.SlackBuild and MusicMixer.SlackBuild > package gets an "i486" architecture tag instead of "x86_64". > > comments on MusicMixer.SlackBuild: ARCH=i486 # hardcoded for 32bit > > Is this correct? MusicMixer is a 32bit only application: notice that the download link is broken, but you can find it here http://ponce.cc/slackware/sources/repo/MusicMixer_x86_1.8.tgz I will fix it in our git. atunes is a java application and should be architecture indipendent (ARCH=noarch): I'll fix that too. Thanks for reporting! Matteo ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
[Slackbuilds-users] atunes.SlackBuild
Hi!, I notice atunes.SlackBuild and MusicMixer.SlackBuild package gets an "i486" architecture tag instead of "x86_64". comments on MusicMixer.SlackBuild: ARCH=i486 # hardcoded for 32bit Is this correct? Thanks. ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] docker build fail on x86_64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > The current slackbuild fails on my slackare64-14.1 machine fully > updated with : > > patching file daemon/graphdriver/btrfs/btrfs.go >> Hunk #1 succeeded at 4 with fuzz 1. # WARNING! I don't seem to be >> running in the Docker container. # The result of this command >> might be an incorrect build, and will not be # officially >> supported. # # Try this instead: make all # >> >> ---> Making bundle: dynbinary (in bundles/1.4.1/dynbinary) >> Created binary: >> /tmp/SBo/docker-1.4.1/bundles/1.4.1/dynbinary/dockerinit-1.4.1 # >> github.com/docker/docker/daemon/graphdriver/btrfs >> ../package-docker/usr/share/gocode/src/ >> github.com/docker/docker/daemon/graphdriver/btrfs/version.go:6:27: >> fatal error: btrfs/version.h: No such file or directory #include >> ^ compilation terminated. >> > > It's not a full install but I don't think I am missing any > dependency. > > On another 64 bits machine running current the slackbuild was also > failing with the same error until the latest update of btrfs-progs > which include the missing header file. See current changelog below > : > > a/btrfs-progs-20141107-x86_64-1.txz: Upgraded. >> Added the header files to the package. Thanks to Vincent Batts. >> > > I am missing something or does the slackbuild requires this header > ? Yes, i confirmed that it does indeed failed to build on -stable releases I have notified Pat and see if he agreed to add the missing header to - -stable release as well - -- Willy Sudiarto Raharjo -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlTfR2wACgkQiHuDdNczM4FocwCdFACVLrD1LhRWSCTgrt1Wud0h UQUAoJrDYs+PBMhyyBFMiwAU8vEKgt4i =6s5w -END PGP SIGNATURE- ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
[Slackbuilds-users] docker build fail on x86_64
Hi, The current slackbuild fails on my slackare64-14.1 machine fully updated with : patching file daemon/graphdriver/btrfs/btrfs.go > Hunk #1 succeeded at 4 with fuzz 1. > # WARNING! I don't seem to be running in the Docker container. > # The result of this command might be an incorrect build, and will not be > # officially supported. > # > # Try this instead: make all > # > > ---> Making bundle: dynbinary (in bundles/1.4.1/dynbinary) > Created binary: > /tmp/SBo/docker-1.4.1/bundles/1.4.1/dynbinary/dockerinit-1.4.1 > # github.com/docker/docker/daemon/graphdriver/btrfs > ../package-docker/usr/share/gocode/src/ > github.com/docker/docker/daemon/graphdriver/btrfs/version.go:6:27: fatal > error: btrfs/version.h: No such file or directory > #include >^ > compilation terminated. > It's not a full install but I don't think I am missing any dependency. On another 64 bits machine running current the slackbuild was also failing with the same error until the latest update of btrfs-progs which include the missing header file. See current changelog below : a/btrfs-progs-20141107-x86_64-1.txz: Upgraded. >Added the header files to the package. Thanks to Vincent Batts. > I am missing something or does the slackbuild requires this header ? Thanks for your help ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/