Re: [CFT] packaging the base system with pkg(8)

On 2016-04-18 8:17 PM, Alfred Perlstein wrote: Can someone on the "too many packages" campaign here explain to me how having too fine a granularity stops you from making macro packages containing packages? Because honestly I can't see how having granularity hurts at all when if someone wanted

Re: [CFT] packaging the base system with pkg(8)

Maybe what the "too many packages" folks need to do is write some code to hide that it's so many packages. :) I think the rule of two feet should be applied here. What we have is people that have worked quite hard to bring us something that we can easily work with, and on the other hand some

Re: [CFT] packaging the base system with pkg(8)

On 2016-04-18 7:01 PM, Roger Marquis wrote: Can you explain what would be accomplished by testing all or even a fraction of the possible permutations of base package combinations? We don't do that for ports. The ports tree isn't a mandatory part of the system. And by definition it could not

Re: [CFT] packaging the base system with pkg(8)

Lyndon Nerenberg wrote: There aren't enough seconds in the universe to test all the viable combinations for one single release. Can you explain what would be accomplished by testing all or even a fraction of the possible permutations of base package combinations? We don't do that for ports.

Re: [CFT] packaging the base system with pkg(8)

On 2016-04-18 5:09 PM, Nathan Whitehorn wrote: I'm not so sure about these statements. Maintaining groups of packages can be easier, but it can be also be harder. The goal is to find the right level. And I haven't seen a case where an 800-packages level of granularity is helpful. Not to

Re: [CFT] packaging the base system with pkg(8)

On 04/18/16 14:29, Alfred Perlstein wrote: Guys please stop arguing about the number of packages. The high granularity is VERY useful! Managing large groups of small packages is much easier than just having large packages. I'm not so sure about these statements. Maintaining groups of

Re: [CFT] packaging the base system with pkg(8)

On Tue, Apr 19, 2016 at 12:43:08AM +0300, Slawa Olhovchenkov wrote: > On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > > > On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > > > > > > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 > > >

Re: [CFT] packaging the base system with pkg(8)

On Mon, Apr 18, 2016 at 10:30:48PM +0200, Rainer Duffner wrote: > > > Am 18.04.2016 um 22:07 schrieb Lev Serebryakov : > > > > On 18.04.2016 22:40, Glen Barber wrote: > > > >> This granularity allows easy removal of things that may not be wanted > >> (such as *-debug*,

Re: [CFT] packaging the base system with pkg(8)

On Mon, Apr 18, 2016 at 12:21:28PM -0700, Nathan Whitehorn wrote: > > > On 04/18/16 12:14, Glen Barber wrote: > > On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > >> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > >>> I understand, that maybe it is too

Re: [CFT] packaging the base system with pkg(8)

On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > > > > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 > > packages?! WHY?! What are reasons and goals to split base in such > > enormous

Re: [CFT] packaging the base system with pkg(8)

Guys please stop arguing about the number of packages. The high granularity is VERY useful! Managing large groups of small packages is much easier than just having large packages. All this can be done by meta-packages which depend on larger package groups. Later pkg can be augmented to

Re: [CFT] packaging the base system with pkg(8)

On 18.04.2016 23:30, Rainer Duffner wrote: > From the discussion, I believe it’s primarily driven by the need/desire to > have small packages to make updates easier on the mirror-servers. It is bad driver. Mirror servers are hardware. And this enormous number of packages cause problems for

Re: [CFT] packaging the base system with pkg(8)

> Am 18.04.2016 um 22:07 schrieb Lev Serebryakov : > > On 18.04.2016 22:40, Glen Barber wrote: > >> This granularity allows easy removal of things that may not be wanted >> (such as *-debug*, *-profile*, etc.) on systems with little storage. On >> one of my testing systems, I

Re: [CFT] packaging the base system with pkg(8)

On 18.04.2016 22:40, Glen Barber wrote: > This granularity allows easy removal of things that may not be wanted > (such as *-debug*, *-profile*, etc.) on systems with little storage. On > one of my testing systems, I removed the tests packages and all debug > and profiling, and the number of

Re: [CFT] packaging the base system with pkg(8)

On Mon, Apr 18, 2016 at 08:05:05PM +, Glen Barber wrote: > On Mon, Apr 18, 2016 at 11:02:12PM +0300, Slawa Olhovchenkov wrote: > > > This granularity allows easy removal of things that may not be wanted > > > (such as *-debug*, *-profile*, etc.) on systems with little storage. On > > > one

Re: 11.0-RELEASE pkg base & base.txz file

On Mon, Apr 18, 2016 at 03:42:20PM -0400, Ernie Luzar wrote: > Slawa Olhovchenkov wrote: > > On Mon, Apr 18, 2016 at 05:27:09PM +0300, Slawa Olhovchenkov wrote: > > > >> On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote: > >> > >>> On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa

Re: [CFT] packaging the base system with pkg(8)

On Mon, Apr 18, 2016 at 07:40:10PM +, Glen Barber wrote: > On Mon, Apr 18, 2016 at 12:21:28PM -0700, Nathan Whitehorn wrote: > > > > > > On 04/18/16 12:14, Glen Barber wrote: > > >On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > > >>On Apr 18, 2016, at 11:52 AM, Lev Serebryakov

Re: [CFT] packaging the base system with pkg(8)

On Mon, Apr 18, 2016 at 11:02:12PM +0300, Slawa Olhovchenkov wrote: > > This granularity allows easy removal of things that may not be wanted > > (such as *-debug*, *-profile*, etc.) on systems with little storage. On > > one of my testing systems, I removed the tests packages and all debug > >

Re: 11.0-RELEASE pkg base & base.txz file

Slawa Olhovchenkov wrote: On Mon, Apr 18, 2016 at 05:27:09PM +0300, Slawa Olhovchenkov wrote: On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote: On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote: On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov

Re: [CFT] packaging the base system with pkg(8)

On Mon, Apr 18, 2016 at 12:21:28PM -0700, Nathan Whitehorn wrote: > > > On 04/18/16 12:14, Glen Barber wrote: > >On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > >>On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > >>>I understand, that maybe it is too late,

Re: [CFT] packaging the base system with pkg(8)

On 04/18/16 12:14, Glen Barber wrote: On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 packages?! WHY?! What are reasons and goals to split

Re: [CFT] packaging the base system with pkg(8)

On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 > packages?! WHY?! What are reasons and goals to split base in such > enormous number of packages? Just a guess, having done the same thing myself: it

Re: [CFT] packaging the base system with pkg(8)

On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: > On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: > > > > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 > > packages?! WHY?! What are reasons and goals to split base in such > > enormous

Re: [CFT] packaging the base system with pkg(8)

On 18.04.2016 21:52, Lev Serebryakov wrote: > kerberos Ok, kerberos could not be packetized at all, as it is compilation option for many other programs in tree. But 755 packets doesn't solve this problem too. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature

Re: qsort() documentation

On Mon, 18 Apr 2016, Hans Petter Selasky wrote: Hi, Are there any objections adding the following as part of documenting our kernel's qsort function? Index: sys/libkern/qsort.c === --- sys/libkern/qsort.c (revision 298202) +++

Re: Mis-use of BUS_PASS_ORDER_MIDDLE

On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > I noticed several places there are code like this, especially in some arm > low level drivers. > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass, > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); > > ​I feel the usage

Re: CFR: extend use of nitems() macro in the kernel.

On Saturday, April 16, 2016 01:25:09 PM Pedro Giffuni wrote: > Hello; > > Using coccinelle, and some hand re-formatting, I generated a patch to > make use of the nitems() macro in sys, which is too big for > phabricator [1]. > > I was careful to exclude anything from the contrib directory or >

Re: [CFT] packaging the base system with pkg(8)

On 03.03.2016 02:54, Glen Barber wrote: > At present, the base system consists of 755 packages with the default > build (empty src.conf(5) and make.conf(5)) for amd64. The number of > packages depends on several factors, but for most cases a runtime binary > is split into several components. In

Re: CFR: extend use of nitems() macro in the kernel.

On 04/18/16 01:56, Hans Petter Selasky wrote: On 04/16/16 20:25, Pedro Giffuni wrote: M sys/dev/usb/input/ukbd.c M sys/dev/usb/serial/u3g.c M sys/dev/usb/serial/uchcom.c M sys/dev/usb/serial/umcs.c M sys/dev/usb/serial/uplcom.c Approved. Maybe you can remove

Re: qsort() documentation

On Mon, Apr 18, 2016 at 12:13 PM, Hans Petter Selasky wrote: > Did anyone try to generate such a fiendish set of data, and see how > quadratic the FreeBSD's qsort() becomes? > Not me, but it has been done:

Re: qsort() documentation

On 04/18/16 16:49, Ed Schouten wrote: 2016-04-18 15:09 GMT+02:00 Hans Petter Selasky : On 04/18/16 14:16, Aleksander Alekseev wrote: I suggest also add a short description of how it was achieved (randomization?). I think the algorithm is switching to mergesort. I'll look up

Mis-use of BUS_PASS_ORDER_MIDDLE

I noticed several places there are code like this, especially in some arm low level drivers. EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass, 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); ​I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are another macro

Re: objcopy exit with signal 10 trying to update to recent -CURRENT

> On Apr 18, 2016, at 10:59, Renato Botelho do Couto wrote: > > I’m trying to upgrade a -CURRENT amd64 installation from r297492 to r298203 > and got: > > c++ -O2 -pipe > -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/include >

Re: 11.0-RELEASE pkg base & base.txz file

On Mon, Apr 18, 2016 at 05:27:09PM +0300, Slawa Olhovchenkov wrote: > On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote: > > > On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote: > > > On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote: > > > > > >

Re: qsort() documentation

2016-04-18 15:09 GMT+02:00 Hans Petter Selasky : > On 04/18/16 14:16, Aleksander Alekseev wrote: >> I suggest also add a short description of how it was achieved >> (randomization?). > > I think the algorithm is switching to mergesort. I'll look up the paper and > add that

objcopy exit with signal 10 trying to update to recent -CURRENT

I’m trying to upgrade a -CURRENT amd64 installation from r297492 to r298203 and got: c++ -O2 -pipe -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/llvm-tblgen/../../../contrib/llvm/tools/clang/include

Re: 11.0-RELEASE pkg base & base.txz file

On Mon, Apr 18, 2016 at 04:16:01PM +0200, Baptiste Daroussin wrote: > On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote: > > On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote: > > > > > On 04/18/16 10:00, Ernie Luzar wrote: > > > > 11.0 will have pkg base, thats

Re: 11.0-RELEASE pkg base & base.txz file

On Mon, Apr 18, 2016 at 05:14:54PM +0300, Slawa Olhovchenkov wrote: > On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote: > > > On 04/18/16 10:00, Ernie Luzar wrote: > > > 11.0 will have pkg base, thats ok, but what does than mean for the > > > base.txz file? > > > > > > It it going

Re: 11.0-RELEASE pkg base & base.txz file

On Mon, Apr 18, 2016 at 10:05:12AM -0400, Nikolai Lifanov wrote: > On 04/18/16 10:00, Ernie Luzar wrote: > > 11.0 will have pkg base, thats ok, but what does than mean for the > > base.txz file? > > > > It it going to stay as part of FBSD install? > > > > I have many scripts for creating jails

Re: 11.0-RELEASE pkg base & base.txz file

On 04/18/16 10:00, Ernie Luzar wrote: > 11.0 will have pkg base, thats ok, but what does than mean for the > base.txz file? > > It it going to stay as part of FBSD install? > > I have many scripts for creating jails which depend on the base.txz file. It's even easier now: # mkdir -p

11.0-RELEASE pkg base & base.txz file

11.0 will have pkg base, thats ok, but what does than mean for the base.txz file? It it going to stay as part of FBSD install? I have many scripts for creating jails which depend on the base.txz file. ___ freebsd-current@freebsd.org mailing list

Re: qsort() documentation

On Mon, Apr 18, 2016 at 9:09 AM, Hans Petter Selasky wrote > I think the algorithm is switching to mergesort. I'll look up the paper > and add that correctly before commit. > No, it switches to insertion sort, assuming that it's acting on an already sorted array. If that

Re: qsort() documentation

On 04/18/16 14:16, Aleksander Alekseev wrote: I suggest also add a short description of how it was achieved (randomization?). I think the algorithm is switching to mergesort. I'll look up the paper and add that correctly before commit. --HPS ___

Re: qsort() documentation

Hello. I suggest also add a short description of how it was achieved (randomization?). On Mon, 18 Apr 2016 13:43:38 +0200 Hans Petter Selasky wrote: > Hi, > > Are there any objections adding the following as part of documenting > our kernel's qsort function? > > Index:

qsort() documentation

Hi, Are there any objections adding the following as part of documenting our kernel's qsort function? Index: sys/libkern/qsort.c === --- sys/libkern/qsort.c (revision 298202) +++ sys/libkern/qsort.c (working copy) @@ -45,6 +45,10

Re: CFR: extend use of nitems() macro in the kernel.

On 04/16/16 20:25, Pedro Giffuni wrote: M sys/dev/usb/input/ukbd.c M sys/dev/usb/serial/u3g.c M sys/dev/usb/serial/uchcom.c M sys/dev/usb/serial/umcs.c M sys/dev/usb/serial/uplcom.c Approved. Maybe you can remove the superfluous pair of parenthesis after the