# pkg repository for FreeBSD 10



## vanessa (Oct 28, 2013)

For all of you looking for a pkg repository for FreeBSD 10 - it turns out that PC-BSD has the first one (again) in place over here:
http://pkg.cdn.pcbsd.org/10-STABLE/amd64/

Haven't tried it though myself because I discovered it today.


----------



## vanessa (Oct 28, 2013)

Here is how to use it:

Create /usr/local/etc/pkg.conf with this content: 

```
packagesite: [url]http://pkg.cdn.pcbsd.org/10-STABLE/amd64[/url]
PUBKEY: /usr/local/etc/pkg-pubkey.cert
PKG_CACHEDIR: /usr/local/tmp
```

 Download pkg-pubkey.cert to /usr/local/etc.
 Upgrade your packages with `pkg upgrade -fy`.


----------



## Beastie (Oct 28, 2013)

For amd64 only, as one would expect. Too bad. :\


----------



## vanessa (Oct 28, 2013)

Do you *really* work on a x86:32!? Almost all CPUs since 2006 are amd64. Even mobile phones and tablets are 64bit now.


----------



## rusty (Oct 28, 2013)

Thanks for posting this. I saw http://pkg1.nyi.freebsd.org/ posted in another thread if people are looking for x86:32


----------



## Beastie (Oct 28, 2013)

vanessa said:
			
		

> Do you *really* work on a x86!?


Really really.



			
				vanessa said:
			
		

> Almost all CPUs since 2006 are amd64.


Ah okay, I'll keep a note to dump my perfectly-fine 32-bit machines in the trash first thing in the morning... Not!



			
				vanessa said:
			
		

> Even mobile phones and tablets are 64bit now.


Yep, too bad I don't use that many.


----------



## break19 (Oct 29, 2013)

vanessa said:
			
		

> Do you *really* work on a x86:32!? Almost all CPUs since 2006 are amd64. Even mobile phones and tablets are 64bit now.



I have an AthlonXP 2000+ still running FreeBSD.  It is 32bit, and is my home NAS, as well as a backup desktop for when my Phenom2 crashes.


----------



## break19 (Oct 29, 2013)

In other words, the architecture that could MOST BENEFIT from, don't have packages, because it takes FOREVER to build on it, was dropped. Nice.


----------



## kpa (Oct 29, 2013)

vanessa said:
			
		

> Do you *really* work on a x86:32!? Almost all CPUs since 2006 are amd64. Even mobile phones and tablets are 64bit now.



I do because the only equipment I have that is totally silent and is otherwise suitable for my application (firewall) happens to be a VIA C7 based mini-itx motherboard that is not AMD64 compatible. The i386 architecture is not going anywhere soon.

All my other machines are 64-bit capable though but they are too noisy and use too much power to keep running 24/7.


----------



## tzoi516 (Oct 29, 2013)

vanessa said:
			
		

> Do you *really* work on a x86:32!? Almost all CPUs since 2006 are amd64. Even mobile phones and tablets are 64bit now.



Most are multi-core, but I believe the 5S is the first 64-bit mobile device. Samsung is on board with going 64-bit, so should be seeing some next year.


----------



## SirDice (Oct 29, 2013)

break19 said:
			
		

> In other words, the architecture that could MOST BENEFIT from, don't have packages, because it takes FOREVER to build on it, was dropped. Nice.



Not exactly. PC-BSD stopped with 32 bit because they're using ZFS by default. And ZFS on 32 bit simply has too many issues. That's why they dropped support for 32 bit. Also keep in mind that PC-BSD is a separate project.


----------



## vanessa (Oct 29, 2013)

Beastie said:
			
		

> Really really.
> Ah okay, I'll keep a note to dump my perfectly-fine 32-bit machines in the trash first thing in the morning... Not!



No offence, I thought I am the only one with some 32-bit machines lying around. But I definitely don't use them for FreeBSD, because, as @break19 said, it takes forever to compile something.


----------



## SirDice (Oct 29, 2013)

One misconception about 64 bit seems to linger. It's not faster than 32 bit! Both 32 bit and 64 instructions are processed in exactly the same amount of time on the processor. Only certain floating point operations are faster because they're implemented differently. Building world or the kernel doesn't use floating point operations so building on the same machine using 32 bit or 64 bit takes the same amount of time.


----------



## vanessa (Oct 29, 2013)

kpa said:
			
		

> I do because the only equipment I have that is totally silent and is otherwise suitable for my application (firewall) happens to be a VIA C7 based mini-itx motherboard that is not AMD64 compatible. The i386 architecture is not going anywhere soon.
> 
> All my other machines are 64-bit capable though but they are too noisy and use too much power to keep running 24/7.



Yes, the VIA C7 is a fine one. However I don't think that 32-bit automatically means less noise and power. This is because the C7 is a processor, optimised for power efficiency. I am sure that the new A7 ARM in the iPhone 5S is even more power efficient (despite being 64-bit) and being on par with or faster than the C7.


----------



## vanessa (Oct 29, 2013)

SirDice said:
			
		

> One misconception about 64 bit seems to linger. It's not faster than 32 bit! Both 32 bit and 64 instructions are processed in exactly the same amount of time on the processor. Only certain floating point operations are faster because they're implemented differently. Building world or the kernel doesn't use floating point operations so building on the same machine using 32 bit or 64 bit takes the same amount of time.



Yes, this is true. The speed loss comes from the age


----------



## Beastie (Oct 29, 2013)

break19 said:
			
		

> In other words, the architecture that could MOST BENEFIT from, don't have packages, because it takes FOREVER to build on it, was dropped. Nice.


Spot on!



			
				SirDice said:
			
		

> Not exactly. PC-BSD stopped with 32 bit because they're using ZFS by default. And ZFS on 32 bit simply has too many issues. That's why they dropped support for 32 bit. Also keep in mind that PC-BSD is a separate project.


You're exactly right about why the PC-BSD project dropped the i386 architecture, that is ZFS optimally requiring 4 GB of memory and KDE (the default DE) requiring at least 512 MB to run decently.

But I believe you misunderstood what @break19 meant: i386 machines (being much older than most modern amd64 ones) have barely enough memory and processing power to build some of the huge applications such as X.Org, Firefox, Chromium, GIMP, Open-/LibreOffice, etc. or essential dependencies such as Perl, Python, GTK, etc.



			
				vanessa said:
			
		

> No offence, I thought I am the only one with some 32-bit machines lying around.


None taken at all. My post was entire humorous; maybe I should've added more smilies (at the risk of angering our dear mods).


----------



## SirDice (Oct 29, 2013)

Beastie said:
			
		

> But I believe you misunderstood what @break19 meant: i386 machines (being much older than most modern amd64 ones) have barely enough memory and processing power to build some of the huge applications such as X.Org, Firefox, Chromium, GIMP, Open-/LibreOffice, etc. or essential dependencies such as Perl, Python, GTK, etc.


I have to disagree. I've been building those since the 3.x era and most of the time it was on i386. Yes, it will take some time. Building XFree86 on FreeBSD 3.x took almost a day. Things have very much improved since.

If you have multiple machines I'd suggest doing the building on a fast machine, build your own packages and transfer those to the 'slow' machines. You can quite easily build i386 packages on an AMD64 machine.


----------



## vanessa (Oct 29, 2013)

tzoi516 said:
			
		

> Most are multi-core, but I believe the 5S is the first 64-bit mobile device. Samsung is on board with going 64-bit, so should be seeing some next year.



True, but the 5S is already here - unfortunately not in my pocket  
The new iPad Air has got the same chip too.


----------



## Beeblebrox (Oct 29, 2013)

My experience in building binaries from ports has been that the speed limit is more dependent on HDD throughput rather than CPU speed. I'm isolating the "number of cores" factor from my statement, because obviously the number of poudriere build environments is directly dependent on number of CPU cores. But speed per core is not the issue.

If one does not have an amd64 (with multiple cores) based compiler unit and an i386 poudriere build jail, the next best thing to do would be to dramatically improve the HDD throughput speed on the i386 system.

This can be done by purchasing a PCI card providing SATA-III port outlets and an appropriate SATA-III HDD which will be plugged into the PCI card. The compile speed improvement should be quite noticeable.


----------



## vanessa (Oct 29, 2013)

Personally I lose hours and days by fixing ports not willing to compile, dropping options or drawing dependencies maps. HDD throughput or 32 vs. 64 bit don't even come to count in such a situation.


----------



## phoenix (Oct 30, 2013)

pkg.freebsd.org is now live.  You can't browse that address directly, it's just a bunch of SRV records that point to the actual mirrors that host the actual files.  But you can get the list of mirrors like so:


```
$ host -t srv _http._tcp.pkg.freebsd.org
_http._tcp.pkg.freebsd.org has SRV record 10 10 80 pkg0.bme.freebsd.org.
_http._tcp.pkg.freebsd.org has SRV record 10 10 80 pkg0.isc.freebsd.org.
_http._tcp.pkg.freebsd.org has SRV record 10 10 80 pkg1.nyi.freebsd.org.
```

And you can then browse the individual mirrors to see what packages are available for which release on which architecture.  Just use the pkg.freebsd.org address in your pkg.conf to auto-select the best mirror.


----------



## vanessa (Nov 11, 2013)

*H*owever it doesn't seem to work 

```
$ host -t srv _http._tcp.pkg.freebsd.org
_http._tcp.pkg.freebsd.org has no SRV record
```


----------



## kpa (Nov 11, 2013)

Works here. You might be behind some weird proxy that breaks DNS look ups of SRV records or the DNS forwarder you're using strips them for some reason. Worth checking.


----------



## vanessa (Nov 11, 2013)

Yes, you are right. I tested it from another machine and it works. But not from home


----------



## kpa (Nov 11, 2013)

A simple fix might be just changing your router to use the Google DNS forwarders 8.8.8.8 and 8.8.4.4 instead of those provided by your ISP.


----------



## TroN-0074 (Nov 12, 2013)

rusty said:
			
		

> Thanks for posting this. I saw http://pkg1.nyi.freebsd.org/ posted in another thread if people are looking for x86:32



Any guide on how to use that repo? I need to be able to use pkg because portmaster and portupgrade aren't doing it for me

I did Create the file /usr/local/etc/pkg/repos/FreeBSD.conf with:

```
FreeBSD: {
  url: "http://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  enabled: "yes"
}
```
and got

```
pkg: [url]http://pkg.FreeBSD.org/freebsd:9:x86...Leay-1.55.txz:[/url] No address record
```
I modified the file to look like

```
FreeBSD: {
  url: "http://pkg.us-east.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  enabled: "yes"
}
```
and got

```
pkg: [url]http://pkg.us-east.FreeBSD.org/freebsd:9:x86:32/latest/All/libexecinfo-1.1_3.txz:[/url] No route to host
```

I have lots of packages that are stale and I would like to find a way to upgrade. I am on FreeBSD 9.2, 32 bit. I will appreciate it.


----------



## kpa (Nov 12, 2013)

I got the binary packages working on FreeBSD 9.2 AMD64 without using the /usr/local/etc/pkg/repos/FreeBSD.conf file. I used the standard /usr/local/etc/pkg.conf configurtion file with these contents:


```
packagesite: http://pkg.FreeBSD.org/${ABI}/latest
```

If that doesn't work for you change it to the address of one of the mirrors, for example:


```
packagesite: http://pkg1.nyi.FreeBSD.org/${ABI}/latest
```


I'm guessing the repos/FreeBSD.conf is for the multi-repository feature of pkg(8) and not needed by those who want to use just the official packages.


----------



## kpa (Nov 12, 2013)

One reason why the SRV record method for finding mirrors may fail is that the when the first query that is done with the UDP protocol fails with a "TRUNCATED" status because the result is too large to fit in the UDP reply packet the query should resume using the TCP protocol. There are still many broken routers out there that fail to do so or even worse, the firewall/proxy between you and the internet is blocking outgoing traffic to TCP port 53.

Reference:

http://tools.ietf.org/html/rfc5966


----------

