Re: pkg and packages
On Mon, 8 May 2017 19:24:10 +0100 RW via freebsd-portswrote: > > Samba + GVFS + Thunar doesn't make your FreeBSD filesystems > > available from Windows machines. It makes your Windows file shares > > available on FreeBSD, and they show up in Thunar just like other > > folders. GVFS uses libsmbclient and/or smbclient itself to access > > the CIFS/SMB shares, and abstracts all that away to make it look > > like just another folder. > > It seems strange that this support is controlled by setting a port > option called "Trash Panel Applet plugin" rather than one called > "Gnome Virtual Filesystem". Few days ago I remove GVFS port, before it I rebuild thunar without "Trash Panel Applet plugin". For samba I use smbfs mount points. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
On Mon, 8 May 2017 09:29:47 -0700 Freddie Cash wrote: > Samba + GVFS + Thunar doesn't make your FreeBSD filesystems > available from Windows machines. It makes your Windows file shares > available on FreeBSD, and they show up in Thunar just like other > folders. GVFS uses libsmbclient and/or smbclient itself to access > the CIFS/SMB shares, and abstracts all that away to make it look like > just another folder. It seems strange that this support is controlled by setting a port option called "Trash Panel Applet plugin" rather than one called "Gnome Virtual Filesystem". ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
On Sun, May 7, 2017 at 4:14 AM,wrote: > [Default] On Sat, 06 May 2017 00:11:00 +0200, Sebastian Schwarz > wrote: > > >On 2017-05-04, scratch65...@att.net wrote: > >> I can't imagine what code could possibly be in thunar and > >> samba that the xfce desktop would need, (...) > > > >Thunar is used to display the icons on the XFCE desktop. It > >depends on gvfs, which is used for accessing remote file systems > >and the trash inside Thunar. gvfs in turn depends on samba44 in > >order to access CIFS/SMB shares. > > > >Strictly speaking some of these features might be optional. But > >as far I know pkg currently doesn't have a concept of optional > >dependencies. So it's an all or nothing decision, when building > >the packages. > > It's really not even "strictly speaking". They always should be > separate installs, not ever bundled together. > > What use can someone have for samba who doesn't have any windows > boxes? > > And since samba is the guy who does all the work to make the > freebsd filesystems look non-threatening to windows, why, really, > is gvfs needed at all? As far as I'm aware, there's no way, > short of finding and installing a copy of that old, unsupported > windows nfs client, for freebsd to access a windows box.. > Samba + GVFS + Thunar doesn't make your FreeBSD filesystems available from Windows machines. It makes your Windows file shares available on FreeBSD, and they show up in Thunar just like other folders. GVFS uses libsmbclient and/or smbclient itself to access the CIFS/SMB shares, and abstracts all that away to make it look like just another folder. I'm not sure how Thunar / GVFS would react if you removed support for SMB shares. Maybe it just wouldn't show that option in the GUI? Maybe it would leave the option in the GUI, but would error out when you try to use it? > And thunar doesn't seem to require the desktop (when are icons > placed on the desktop? I can't recall ever seeing that), since > after my desktop was discarded during the general upgrade, the > panels, icons, and thunar all continued to function as before, > which since xfce is a modular, loosely-coupled system, was not > unexpected. Icons are placed on the desktop when you place them there. I don't think there aren't any there by default. We use XFce for the desktop GUI in our schools, and we place a handful of icons on the desktop by default for students (with a different selection of icons for staff), along with a small selection of icons in the taskbar as well. -- Freddie Cash fjwc...@gmail.com ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
[Default] On Thu, 4 May 2017 14:18:46 +0100, RW via freebsd-portswrote: >AFAIK samba isn't a dependency of XFCE. I don't have it and it's not in >the output of make all-depends-list. Thanks, you beat me to it. I thought such a dependency would be pretty unreasonable. > >Thunar is scarcely "unrelated", it's the XFCE integrated file manager. >XFCE uses the libthunarx library if built with the Thunar option. Sorry, I meant unrelated to the desktop. Thunar kept going normally even after my desktop was discarded by pkg during the general ports upgrade. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
[Default] On Sat, 06 May 2017 00:11:00 +0200, Sebastian Schwarzwrote: >On 2017-05-04, scratch65...@att.net wrote: >> I can't imagine what code could possibly be in thunar and >> samba that the xfce desktop would need, (...) > >Thunar is used to display the icons on the XFCE desktop. It >depends on gvfs, which is used for accessing remote file systems >and the trash inside Thunar. gvfs in turn depends on samba44 in >order to access CIFS/SMB shares. > >Strictly speaking some of these features might be optional. But >as far I know pkg currently doesn't have a concept of optional >dependencies. So it's an all or nothing decision, when building >the packages. It's really not even "strictly speaking". They always should be separate installs, not ever bundled together. What use can someone have for samba who doesn't have any windows boxes? And since samba is the guy who does all the work to make the freebsd filesystems look non-threatening to windows, why, really, is gvfs needed at all? As far as I'm aware, there's no way, short of finding and installing a copy of that old, unsupported windows nfs client, for freebsd to access a windows box.. And thunar doesn't seem to require the desktop (when are icons placed on the desktop? I can't recall ever seeing that), since after my desktop was discarded during the general upgrade, the panels, icons, and thunar all continued to function as before, which since xfce is a modular, loosely-coupled system, was not unexpected. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
On 7/5/17 5:14 am, Kevin Oberman wrote: On Fri, May 5, 2017 at 3:11 PM, Sebastian Schwarzwrote: On 2017-05-04, scratch65...@att.net wrote: I can't imagine what code could possibly be in thunar and samba that the xfce desktop would need, (...) Thunar is used to display the icons on the XFCE desktop. It depends on gvfs, which is used for accessing remote file systems and the trash inside Thunar. gvfs in turn depends on samba44 in order to access CIFS/SMB shares. Strictly speaking some of these features might be optional. But as far I know pkg currently doesn't have a concept of optional dependencies. So it's an all or nothing decision, when building the packages. This is the case. If you want to stick with packages, at least until some new packaging features are available, your best bet is to install ports-mgmt/synth. Then you can use it to add a private repository of all ports that you want built with non-standard options. Then have synth create a custom Thunar package that you can then use to avoid samba (44 or 46) or, if supported, build Thunar against the samba version of your choosing. synth(8) has excellent documentation on how to configure and use it. I recommend it for the type of issue you are running into. (N.B. synth is written in ADA and, for that reason, I don't recommend building synth from source as that requires a major installation of the ADA compiler. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" you can do the same with poudriere, by telling it to keep a set of pre-canned configureations. see: PORT_DBDIRDirectory where the results of configuring OPTIONS are stored. Defaults to /var/db/ports. Each port where OPTIONS have been configured will have a uniquely named sub-directory, containing a single file options. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
On Fri, May 5, 2017 at 3:11 PM, Sebastian Schwarzwrote: > On 2017-05-04, scratch65...@att.net wrote: > > I can't imagine what code could possibly be in thunar and > > samba that the xfce desktop would need, (...) > > Thunar is used to display the icons on the XFCE desktop. It > depends on gvfs, which is used for accessing remote file systems > and the trash inside Thunar. gvfs in turn depends on samba44 in > order to access CIFS/SMB shares. > > Strictly speaking some of these features might be optional. But > as far I know pkg currently doesn't have a concept of optional > dependencies. So it's an all or nothing decision, when building > the packages. > This is the case. If you want to stick with packages, at least until some new packaging features are available, your best bet is to install ports-mgmt/synth. Then you can use it to add a private repository of all ports that you want built with non-standard options. Then have synth create a custom Thunar package that you can then use to avoid samba (44 or 46) or, if supported, build Thunar against the samba version of your choosing. synth(8) has excellent documentation on how to configure and use it. I recommend it for the type of issue you are running into. (N.B. synth is written in ADA and, for that reason, I don't recommend building synth from source as that requires a major installation of the ADA compiler. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
On 2017-05-04, scratch65...@att.net wrote: > I can't imagine what code could possibly be in thunar and > samba that the xfce desktop would need, (...) Thunar is used to display the icons on the XFCE desktop. It depends on gvfs, which is used for accessing remote file systems and the trash inside Thunar. gvfs in turn depends on samba44 in order to access CIFS/SMB shares. Strictly speaking some of these features might be optional. But as far I know pkg currently doesn't have a concept of optional dependencies. So it's an all or nothing decision, when building the packages. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
On Thu, 04 May 2017 07:43:30 -0600 Jim Trigg wrote: > ISTR that it's Thunar that depends on Samba by default. Yes it looks like it came in when Thunar defaulted to depending on the "Trash Panel Applet Plugin". Unfortunately the options framework caches old defaults. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
ISTR that it's Thunar that depends on Samba by default. Jim On May 4, 2017 7:18:46 AM MDT, RW via freebsd-portswrote: >On Thu, 04 May 2017 08:09:47 -0400 >scratch65...@att.net wrote: >> >> I can't imagine what code could possibly be in thunar and samba >> that the xfce desktop would need, particularly since the desktop >> is very simple, and also because I've never got samba >> functionality for free after installing xfce which if you're >> right I should have done. But I'll check on that, and report >> back. > >AFAIK samba isn't a dependency of XFCE. I don't have it and it's not in >the output of make all-depends-list. > >Thunar is scarcely "unrelated", it's the XFCE integrated file manager. >XFCE uses the libthunarx library if built with the Thunar option. > >If you want something without integrated utilities you might be better >off with a window manager, like Fluxbox, rather than a desktop >environment. > >It is possible to have XFCE without THUNAR from ports, or by building >custom packages. >___ >freebsd-ports@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-ports >To unsubscribe, send any mail to >"freebsd-ports-unsubscr...@freebsd.org" -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
On Thu, 04 May 2017 08:09:47 -0400 scratch65...@att.net wrote: > > I can't imagine what code could possibly be in thunar and samba > that the xfce desktop would need, particularly since the desktop > is very simple, and also because I've never got samba > functionality for free after installing xfce which if you're > right I should have done. But I'll check on that, and report > back. AFAIK samba isn't a dependency of XFCE. I don't have it and it's not in the output of make all-depends-list. Thunar is scarcely "unrelated", it's the XFCE integrated file manager. XFCE uses the libthunarx library if built with the Thunar option. If you want something without integrated utilities you might be better off with a window manager, like Fluxbox, rather than a desktop environment. It is possible to have XFCE without THUNAR from ports, or by building custom packages. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
On Thu, May 04, 2017 at 08:09:47AM -0400, scratch65...@att.net wrote: > On Wed, 3 May 2017 16:53:41 +0100, Matthew Seaman >wrote: > > >>> Trying to install the desktop package, I discovered that it's > >>> bundled with at least 2 unrelated pieces of software: Thunar, > >>> and samba44. That bothered me, but I needed the desktop. > > > >'Bundling' isn't the right term -- Thunar and samba44 are /dependencies/ > >of the xfce4-desktop. That is: other packages that need to be installed > >before the package in question will work. Sorting out dependency trees > >like this is much of what pkg(8) exists for. > > I can't imagine what code could possibly be in thunar and samba > that the xfce desktop would need, particularly since the desktop > is very simple, and also because I've never got samba > functionality for free after installing xfce which if you're > right I should have done. But I'll check on that, and report > back. > > That kind of tight coupling at the macro level *is* a very > serious problem for the ports system, though. It's strangling > it. > > How many ports just build, first go? Are there *any*? I suspect > not. And yet the maintainers presumably thought they would. > > I stopped trying to build ports because I could never get a make > to run to completion. There was always at least one dependency > that (a) couldn't be found at all, (b) was the wrong version, or > (c) failed compilation. That didn't happen when I was writing > stuff under sco or sys v. > > It shouldn't happen with our ports system, either, because it > completely prevents code freeze and stability, a basic > requirement for high-quality software. The stuff being fetched > from Timbuktu or somebody's cat's litter box should be cleaned > up, built into a library, and be fetched from there subsequently. > There should never be a dependency on code that the ports project > doesn't control. > > > >The thing that seems to trip most people up is thinking they can > >substitute some other package instead of the exact dependency listed in > >the package metadata. This is not an unreasonable request, especially > >when you know your alternate package does exactly the same thing as the > >one you want to replace. Unfortunately it just doesn't work right now, > >and it would take quite a lot of disruptive change in the ports tree and > >to pkg(8) itself to make that happen. > > You call it "disruptive" change, but from here it looks exactly > like *healthy*, *professional* change. Really. There is no garanty the libsmb.so.X provided by samba44 is binary compatible with the one from samba46 this is why there is a strong dependency here. For more defaly look at my answer here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219036 Bapt signature.asc Description: PGP signature
Re: pkg and packages
On Wed, 3 May 2017 16:53:41 +0100, Matthew Seamanwrote: >>> Trying to install the desktop package, I discovered that it's >>> bundled with at least 2 unrelated pieces of software: Thunar, >>> and samba44. That bothered me, but I needed the desktop. > >'Bundling' isn't the right term -- Thunar and samba44 are /dependencies/ >of the xfce4-desktop. That is: other packages that need to be installed >before the package in question will work. Sorting out dependency trees >like this is much of what pkg(8) exists for. I can't imagine what code could possibly be in thunar and samba that the xfce desktop would need, particularly since the desktop is very simple, and also because I've never got samba functionality for free after installing xfce which if you're right I should have done. But I'll check on that, and report back. That kind of tight coupling at the macro level *is* a very serious problem for the ports system, though. It's strangling it. How many ports just build, first go? Are there *any*? I suspect not. And yet the maintainers presumably thought they would. I stopped trying to build ports because I could never get a make to run to completion. There was always at least one dependency that (a) couldn't be found at all, (b) was the wrong version, or (c) failed compilation. That didn't happen when I was writing stuff under sco or sys v. It shouldn't happen with our ports system, either, because it completely prevents code freeze and stability, a basic requirement for high-quality software. The stuff being fetched from Timbuktu or somebody's cat's litter box should be cleaned up, built into a library, and be fetched from there subsequently. There should never be a dependency on code that the ports project doesn't control. >The thing that seems to trip most people up is thinking they can >substitute some other package instead of the exact dependency listed in >the package metadata. This is not an unreasonable request, especially >when you know your alternate package does exactly the same thing as the >one you want to replace. Unfortunately it just doesn't work right now, >and it would take quite a lot of disruptive change in the ports tree and >to pkg(8) itself to make that happen. You call it "disruptive" change, but from here it looks exactly like *healthy*, *professional* change. Really. Slàinte mhath! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg and packages
On 2017/05/03 15:53, Chris H wrote: > On Wed, 03 May 2017 08:03:36 -0400wrote > >> After doing a general pkg upgrade on my server-of-all-work, I >> discovered after some research that the Big Grey Background I was >> left with was due to pkg having deleted, but not replaced, xfce4 >> desktop. This is an annoying effect when it happens unexpectedly. However, I can't see how pkg(8) could behave otherwise. What happens is that if you say: pkg install foo pkg(8) works under the quite reasonable impression that you want foo installed. Now, if foo conflicts with another package you have installed, say 'bar', then pkg(8) will deinstall bar as an essential step towards getting foo installed. In general, this is what you would want to happen. 'Conflicts' here means either that the packages in question each install one or more files of the same name as one from the other package, or that one installs a shared library with an ABI version that matches the other package. The problem from your point of view is that as an intelligent being you see samba44 and samba46 as essentially different versions of the same thing. pkg(8) (all appearances to the contrary) is not at all intelligent, and can only treat the two different samba packages as completely distinct things. What would be great is if we could give a list of alternates as dependencies when creating packages, but unfortunately the packaging system does not have that capability. Yet. >> Trying to install the desktop package, I discovered that it's >> bundled with at least 2 unrelated pieces of software: Thunar, >> and samba44. That bothered me, but I needed the desktop. 'Bundling' isn't the right term -- Thunar and samba44 are /dependencies/ of the xfce4-desktop. That is: other packages that need to be installed before the package in question will work. Sorting out dependency trees like this is much of what pkg(8) exists for. >> pkg got totally confused during the install, first downloading 44 >> and THEN noticing the conflict with 46. So it downloaded 46, >> too(!), deleted the existing 46, installed 44, and then tried to >> re-install 46, failing with a complaint because it had just >> installed 44 and that created a conflict. >> >> But it gets better. Trying to reinstall the samba46 package, I >> discovered that I'd have to sacrifice the desktop that I just >> installed. >> >> Clearly, no good can come of packaging unrelated software >> together, so there needs to be a way to prevent that, or at least >> criticise those who do it. >> >> And pkg should (a) check for later versions *before* downloading >> older ones, (b) preferably not install old versions over newer >> without explicit permission, and (c) as a fallback should allow >> packages to be decomposed at install time such that installation >> is not a yes/no all-or-nothing choice. > > In pkg(8)'s humble defense; it simply *expedites* your request. > It isn't the QA dept. for [port] Maintainers. > Mind you; I *fully* appreciate your position. I'm simply trying to > indicate *where*, or at *whom* to point fingers. :-) Yes, indeed. pkg(8) does have a tendency to do exactly what you tell it, and sometimes that is not what you would intuitively expect. The thing that seems to trip most people up is thinking they can substitute some other package instead of the exact dependency listed in the package metadata. This is not an unreasonable request, especially when you know your alternate package does exactly the same thing as the one you want to replace. Unfortunately it just doesn't work right now, and it would take quite a lot of disruptive change in the ports tree and to pkg(8) itself to make that happen. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: pkg and packages
On Wed, 03 May 2017 08:03:36 -0400wrote > After doing a general pkg upgrade on my server-of-all-work, I > discovered after some research that the Big Grey Background I was > left with was due to pkg having deleted, but not replaced, xfce4 > desktop. > > Trying to install the desktop package, I discovered that it's > bundled with at least 2 unrelated pieces of software: Thunar, > and samba44. That bothered me, but I needed the desktop. > > pkg got totally confused during the install, first downloading 44 > and THEN noticing the conflict with 46. So it downloaded 46, > too(!), deleted the existing 46, installed 44, and then tried to > re-install 46, failing with a complaint because it had just > installed 44 and that created a conflict. > > But it gets better. Trying to reinstall the samba46 package, I > discovered that I'd have to sacrifice the desktop that I just > installed. > > Clearly, no good can come of packaging unrelated software > together, so there needs to be a way to prevent that, or at least > criticise those who do it. > > And pkg should (a) check for later versions *before* downloading > older ones, (b) preferably not install old versions over newer > without explicit permission, and (c) as a fallback should allow > packages to be decomposed at install time such that installation > is not a yes/no all-or-nothing choice. In pkg(8)'s humble defense; it simply *expedites* your request. It isn't the QA dept. for [port] Maintainers. Mind you; I *fully* appreciate your position. I'm simply trying to indicate *where*, or at *whom* to point fingers. :-) --Chris ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
pkg and packages
After doing a general pkg upgrade on my server-of-all-work, I discovered after some research that the Big Grey Background I was left with was due to pkg having deleted, but not replaced, xfce4 desktop. Trying to install the desktop package, I discovered that it's bundled with at least 2 unrelated pieces of software: Thunar, and samba44. That bothered me, but I needed the desktop. pkg got totally confused during the install, first downloading 44 and THEN noticing the conflict with 46. So it downloaded 46, too(!), deleted the existing 46, installed 44, and then tried to re-install 46, failing with a complaint because it had just installed 44 and that created a conflict. But it gets better. Trying to reinstall the samba46 package, I discovered that I'd have to sacrifice the desktop that I just installed. Clearly, no good can come of packaging unrelated software together, so there needs to be a way to prevent that, or at least criticise those who do it. And pkg should (a) check for later versions *before* downloading older ones, (b) preferably not install old versions over newer without explicit permission, and (c) as a fallback should allow packages to be decomposed at install time such that installation is not a yes/no all-or-nothing choice. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg: fetching packages for 10.2 on 11-CURRENT
On Mon, 5 Oct 2015 18:55:06 +0200 Baptiste Daroussinwrote: > On Mon, Oct 05, 2015 at 07:00:01AM +0200, O. Hartmann wrote: > > Is it possible and doable via a simple setup (script/environment) to fetch > > pre-built packages for 10.2-STABLE/10.2-RELEASE with pkg/pkgng on > > 11-CURRENT? > > > > Background: running a development system on 11-CURRENT, on which I prefer to > > build my packages in the traditional way from sources without that massive > > overhead poudriere pushes me sometimes into the situation for the need of > > ordinary binary packages for a 10.2-platform. On 11-CURRENT, I use a lot of > > individual configurations on the ports making the binary packages useless, > > but for that specific project (based on NanoBSD), it would be great to to > > simply fetch binary packages for a "foreign" system's version. > > > > Thank you very much in advance and pelase do CC me, I'm not subscribing the > > list. > > as root > pkg -o ABI=FreeBSD:10:amd64 -o ALTABI=freebsd:10:x86:64 -o > PKG_DBDIR=/tmp/tothrowaway fetch ... or as a user > pkg -o ABI=FreeBSD:10:amd64 -o ALTABI=freebsd:10:x86:64 -o > PKG_DBDIR=/tmp/tothrowaway -o INSTALL_AS_USER=yes fetch ... > > > The fact you have to specify both ABI and ALTABI is a bug I will fix. > > Best regards, > Bapt Thank you very much. This sounds easy to perform. Sorry for the late response. Regards, Oliver ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg: fetching packages for 10.2 on 11-CURRENT
On Mon, Oct 05, 2015 at 07:00:01AM +0200, O. Hartmann wrote: > Is it possible and doable via a simple setup (script/environment) to fetch > pre-built packages for 10.2-STABLE/10.2-RELEASE with pkg/pkgng on 11-CURRENT? > > Background: running a development system on 11-CURRENT, on which I prefer to > build my packages in the traditional way from sources without that massive > overhead poudriere pushes me sometimes into the situation for the need of > ordinary binary packages for a 10.2-platform. On 11-CURRENT, I use a lot of > individual configurations on the ports making the binary packages useless, but > for that specific project (based on NanoBSD), it would be great to to simply > fetch binary packages for a "foreign" system's version. > > Thank you very much in advance and pelase do CC me, I'm not subscribing the > list. as root pkg -o ABI=FreeBSD:10:amd64 -o ALTABI=freebsd:10:x86:64 -o PKG_DBDIR=/tmp/tothrowaway fetch ... or as a user pkg -o ABI=FreeBSD:10:amd64 -o ALTABI=freebsd:10:x86:64 -o PKG_DBDIR=/tmp/tothrowaway -o INSTALL_AS_USER=yes fetch ... The fact you have to specify both ABI and ALTABI is a bug I will fix. Best regards, Bapt signature.asc Description: PGP signature
pkg: fetching packages for 10.2 on 11-CURRENT
Is it possible and doable via a simple setup (script/environment) to fetch pre-built packages for 10.2-STABLE/10.2-RELEASE with pkg/pkgng on 11-CURRENT? Background: running a development system on 11-CURRENT, on which I prefer to build my packages in the traditional way from sources without that massive overhead poudriere pushes me sometimes into the situation for the need of ordinary binary packages for a 10.2-platform. On 11-CURRENT, I use a lot of individual configurations on the ports making the binary packages useless, but for that specific project (based on NanoBSD), it would be great to to simply fetch binary packages for a "foreign" system's version. Thank you very much in advance and pelase do CC me, I'm not subscribing the list. Regards, Oliver ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
pkg: No packages matching with www/mod_wsgi3 based on argument order
Hello, I just updated our ports tree and we are now running pkg v1.2.5. I've rebuilt all of our ports (via poudriere) and have done a `pkg upgrade -f` several times. I'm trying to install www/mod_wsgi3 but get different results based on the order of arguments on my command line: $ sudo pkg install -y www/mod_wsgi3 www/apache22 Updating repository catalogue pkg: No packages matching 'www/apache22' available in the repositories $ sudo pkg install -y www/apache22 www/mod_wsgi3 Updating repository catalogue apache22-2.2.26 already installed The following 1 packages will be installed: Installing ap22-mod_wsgi3: 3.4_1 Yes, I know that www/mod_wsgi3 depends on apache and doesn't need to be explicitly stated. However, our deployment system generates a list of packages to install from various sources which don't/can't inspect individual package dependencies and happens to pass them to pkg in same order as the bad example above. Has anyone else ran into this? Thanks Kimo ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org