Build failed in Jenkins: FreeBSD_HEAD-tests2 #144

[jenkins-admin]

See 

--
[...truncated 22 lines...]
FreeBSD 11.0-CURRENT #1618: Wed Oct 29 05:42:13 UTC 2014
jenk...@jenkins-10.freebsd.org:/usr/obj/builds/FreeBSD_HEAD/sys/GENERIC 
amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
WARNING: WITNESS option enabled, expect reduced performance.
CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz (2399.77-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c  Stepping=2
  
Features=0x9f83ab7f
  
Features2=0x829e6257
  AMD Features=0x24100800
  AMD Features2=0x1
  TSC: P-state invariant
Hypervisor: Origin = "bhyve bhyve "
real memory  = 2147483648 (2048 MB)
avail memory = 2040360960 (1945 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
random device not loaded; using insecure entropy
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
random:  initialized
module_register_init: MOD_LOAD (vesa, 0x80dae150, 0) error 19
acpi0:  on motherboard
acpi0: Power Button (fixed)
atrtc0:  port 0x70-0x71 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 1000 Hz quality 950
Event timer "HPET" frequency 1000 Hz quality 550
Event timer "HPET1" frequency 1000 Hz quality 450
Event timer "HPET2" frequency 1000 Hz quality 450
Event timer "HPET3" frequency 1000 Hz quality 450
Event timer "HPET4" frequency 1000 Hz quality 450
Event timer "HPET5" frequency 1000 Hz quality 450
Event timer "HPET6" frequency 1000 Hz quality 450
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
isab0:  at device 1.0 on pci0
isa0:  on isab0
virtio_pci0:  port 0x2000-0x201f mem 
0xc000-0xc0001fff irq 16 at device 2.0 on pci0
vtnet0:  on virtio_pci0
virtio_pci0: host features: 0x1018020 
virtio_pci0: negotiated features: 0x18020 
vtnet0: Ethernet address: 58:9c:fc:00:00:2e
ahci0:  mem 0xc0002000-0xc00023ff irq 17 at 
device 3.0 on pci0
ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported
ahcich0:  at channel 0 on ahci0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (9600,n,8,1)
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
qpi0:  on motherboard
sc0:  at flags 0x100 on isa0
sc0: MDA <16 virtual consoles, flags=0x100>
vga0:  at port 0x3b0-0x3bb iomem 0xb-0xb7fff on isa0
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
ppc0: cannot reserve I/O port range
Timecounters tick every 1.000 msec
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0:  ATA-8 SATA 2.x device
ada0: Serial Number 123456
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 2048MB (4194304 512 byte sectors: 16H 63S/T 4161C)
ada0: Previously was known as ad4
random: unblocking device.
SMP: AP CPU #1 Launched!
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from ufs:/dev/ufs/TESTROOT [rw]...
Setting hostuuid: 2efd6eda-5f30-11e4-8bbc-589cfc2e.
Setting hostid: 0x7af35512.
No suitable dump device was found.
Entropy harvesting: interrupts ethernet point_to_point swi.
Starting file system checks:
/dev/ufs/TESTROOT: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/TESTROOT: clean, 1053174 free (398 frags, 131597 blocks, 0.0% 
fragmentation)
Mounting local file systems:.
Writing entropy file:.
/etc/rc: WARNING: $hostname is not set -- see rc.conf(5).
Starting Network: lo0 vtnet0.
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
inet 127.0.0.1 netmask 0xff00 
nd6 options=21
vtnet0: flags=8902 metric 0 mtu 1500
options=80028
ether 58:9c:fc:00:00:2e
nd6 options=29
media: Ethernet 10Gbase-T 
status: active
Starting devd.
Starting Network: vtnet0.
vtnet0: flags=8902 metric 0 mtu 1500
options=80028
ether 58:9c:fc:00:00:2e
nd6 options=29
media: Ethernet 10Gbase-T 
status: active
Starting pflogd: 
add net fe80::: gateway ::1
add net ff02::: gateway ::1
add net :::0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
Generating host.conf.
Creating and/or trimming log files.
Starting syslogd.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib
32-bit compatibility ldconfig path: /usr/lib32
Starting casperd.
Clearing /tmp (X related).
Updating motd:.
Mounting late file systems:.
Config

Re: issues w/ installing stuff multiple times...

[Garrett Cooper]

On Oct 27, 2014, at 15:10, Brooks Davis  wrote:

> On Mon, Oct 27, 2014 at 02:55:09PM -0700, Garrett Cooper wrote:
>> 
>>> On Oct 27, 2014, at 14:50, John-Mark Gurney  wrote:
>>> 
>>> There are issues w/ installing tests where the test files get installed
>>> multiple times.
>>> 
>>> To reproduce this, use the following steps:
>>> make installworld -j 8 DESTDIR= -DNO_ROOT
>>> 
>>> Once you have done the above, in  there will be the file
>>> METALOG, run:
>>> grep -v type=dir /METALOG | awk '{ print $1 }' | sort | uniq 
>>> -d
>>> 
>>> This will print out the current list if files that get installed multiple
>>> times
>>> 
>>> Currently, it looks like all the tests subdirs are installed a second
>>> time...
>>> 
>>> Could someone look at making it so that they don't get installed
>>> multiple times?
>> 
>> Hi jmg!
>>I have a patch out for this that I need to commit today. Thank you for 
>> the reminder.
> 
> Great to hear this will be fixed.  Once we've fixed them all, it would be
> really good to have a test in Jenkins looking out for new duplicate files
> since they are always bugs.

I got swamped at $work yet again. I need to do a bit more testing for the 
patch, but I’ll try to get it out this week after I’ve done the necessary 
testing.
Thank you,


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/

[Ed Maste]

On 28 October 2014 23:04, Kevin Oberman  wrote:
>
> Finally! This is great news.
>
> /usr/lib seems like an odd place, though. Does not seem to match the
> description in hier(7) (not that the man page can't be updated). Looks to me
> like it fits /var a bit better, though I'm not sure that much data is
> appropriate for many /var partitions.

/usr/lib/debug is the standard location for standalone debug data
established by GDB, and seems like a decent enough location. I'll make
sure to update the man page.

-Ed
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/

[Kevin Oberman]

On Tue, Oct 28, 2014 at 5:20 PM, Ed Maste  wrote:

> I am preparing to move the standalone kernel debug data out of
> /boot/kernel/ into /usr/lib/debug/boot/kernel/, mirroring the approach
> used for userland debug data. This significantly reduces the boot
> partition size requirement, and is a step towards supporting the
> installation of kernel debug data ony when required. LLDB and GDB
> automatically search for debug data under /usr/lib/debug/ so this
> change should be transparent from an end-user perspective.
>
> The change can be reviewed in Phabricator at
> https://reviews.freebsd.org/D1006 and can be fetched as a unified diff
> from https://people.freebsd.org/~emaste/patches/D1006.diff
>
> This does not change any defaults or knobs: kernel debug files are
> still built by default, and may be disabled by setting
> WITHOUT_KERNEL_SYMBOLS=YES in /etc/src.conf. I hope to rationalize
> this with userland debug in a later step.
>
> Note that the change renames the intermediate and debug data files to
> be consistent with userland debug data: in the build directory the
> kernel with debug data included is now named kernel.full, and and
> kernel.debug is the standalone debug data file.
>
> I plan to merge this in a few days if there are no issues reported in
> further review or testing.
>
> -Ed
>

Finally! This is great news.

/usr/lib seems like an odd place, though. Does not seem to match the
description in hier(7) (not that the man page can't be updated). Looks to
me like it fits /var a bit better, though I'm not sure that much data is
appropriate for many /var partitions.

Still, wherever the symbol files end up, getting them out of root is
something many people have wanted for a long time.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg 1.4 freeze please test test test!

[Don Lewis]

On 29 Oct, Baptiste Daroussin wrote:
> Hi all,
> 
> We are starting the release process of pkg 1.4, we want to have a better 
> release
> process than with every single previous version of pkg. For that we will need
> you help!
> 
> pkg-devel has been updated to the latest version of pkg as of alpha2.
> 
> Changes you can expect in pkg 1.4 are the following:
> - Loads of bug fixes

I kind of doubt that I'll have time to test it, but I've stumbled across
an interesting test case for package building with pkg-1.3.8_3.

When I tried to build a multimedia/2mandvd package with
poudriere (either bulk or testport) in a FreeBSD 10 amd64 host and jail,
pkg-static segfaults.  Portsmon also sees this failure, which also
seems to be affecting head/amd64 as well:


If I run poudriere jail -i to keep the jail around, I don't see any
leftover core files, I'm guessing because pkg-static's cwd is in the r/o
/usr/ports tree.  If I then cd /usr/ports/multimedia/2mandvd in the
jail and run:
make clean
make stage
make package
pkg-static doesn't segfault, but it never exits either.  I left it
running for a couple of days and it was still stuck at 100% CPU.  If
I truss -p the process, I don't get any output, which means it's not
doing any syscalls.

I tried attaching gdb to the process, but got some strange error
messages that I didn't understand.  I then ran pkg-static under gdb with
the same command line arguments and it still looped forever.  I
interrupted it to get a stack trace, but that wasn't helpful because the
executable was stripped.

If I run pkg instead of pkg-static, it seems to work properly.

I was hoping to gather some more information to file a bug report, but
haven't had time to work on this in the last week.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: junior kernel tasks

[Mehmet Erol Sanliturk]

On Tue, Oct 28, 2014 at 1:35 PM, Marcus von Appen  wrote:

>
> Quoting John Baldwin :
>
>  On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote:
>>
>>> Hello,
>>>
>>> In short, nice kernel tasks people with C language skills can do in few
>>> evenings.
>>>
>>> https://wiki.freebsd.org/JuniorJobs
>>>
>>> It is assumed you know how to obtain sources and build the kernel.
>>>
>>> What you can get in return:
>>> - your own code in FreeBSD tree
>>> - eternal glory [1]
>>> - fun [2]
>>>
>>> If you are not interested, but know someone who does, please pass it
>>> down.
>>>
>>> [1] - not really, no
>>> [2] - well, I guess that's subjective, so that's not a "no"
>>>
>>
>> Even though our bugmeisters have decided that we should not have wishlist
>> items in our bug tracker, I really wish we could store the various idea
>> lists
>> (we have several) in an issue tracker instead.  This would allow for
>> folks to
>> comment on ideas, vote for them, etc.  It would also make it easier for
>> more
>> people to submit new ideas.
>>
>>
> Speaking not strictly with the bugmeister hat, but from experience, please
> do
> not let us go down the road of (ab)using a bug tracking solution as task
> and
> idea management system. I think that using the tasks feature of phabricator
> (our reviews instance) would provide better workflow support for those
> things,
> starting out from sketching out rough ideas, discussing them, breaking
> them up
> in seperate tasks (linked to and dependent on each other) and collaborating
> on them (take a look at https://developer.blender.org/T42339 for a brief
> example).
>
> Having said this, let's keep the bug tracker a bug tracker.
>
> Cheers
> Marcus
>
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>


I do not know difficulty of maintaining a tracker such as "bug tracker" , a
different tracker such as "development tracker" may be defined and used .
In that way , ideas which are not expressible as "bug" in "bug tracker" (
because sometimes it is not possible to decide whether a problem is "bug"
or a "design decision" ) may be specified in " development tracker"  and be
followed from there .

With such a structure the improvement ideas will not be lost in individual
mails .
At some point an idea may be considered useless or inapplicable but over
time it may become very feasible but forgotten or the same person may not
mention it once more .

Thank you very much .

Mehmet Erol Sanliturk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg 1.4 freeze please test test test!

[Cassiano Peixoto]

Hi guys,

Congrats, really good job.

How can i test package base? I didn't find any info about that.

Thanks.

On Tuesday, October 28, 2014, Baptiste Daroussin  wrote:

> Hi all,
>
> We are starting the release process of pkg 1.4, we want to have a better
> release
> process than with every single previous version of pkg. For that we will
> need
> you help!
>
> pkg-devel has been updated to the latest version of pkg as of alpha2.
>
> Changes you can expect in pkg 1.4 are the following:
> - Loads of bug fixes
> - Stricter checking of the path passed via the plist
> - Removal of the bundled libyaml
> - new --raw-format to chose the output format for info -R and search -R
> - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become
> FreeBSD:10:amd64)
>   the old ABI is available as a fallback in ALTABI
> - pkg check now support a quiet mode
> - new 3 way merge code ("stolen" from the fossil-scm) to allow automerging
>   configuration files
> - new @config keyword to mark a file as a config file (during
>   upgrade/reinstallation it will try to merge the configuration with the
> one the
>   user may have modified) an option AUTOMERGE is available to prevent
>   automerging if automerge fails a .pkgnew file will be created along with
> the
>   untouched user version of the configuration
> - The update procedure has been improved and speed up a lot (in particular
> for
>   machine with low resources)
> - The unique identifier has been modified to be pkgname meaning now ports
> can be
>   moved in new categories without having to be considered a different
> package
> - Only libraries starting by lib* are added to the provided libraries
> - General speed up of all operations
>
> We need help in testing, but we also need help in writing regression tests
> !
> The more we have tests the more stable the releases will be.
>
> The release will also allow to be able to package base!
>
> regards,
> Bapt
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory)

[Gyrd Thane Lange]

On Tue, 28 Oct 2014 16:45:47 -0700
NGie Cooper  wrote:

> On Tue, Oct 28, 2014 at 4:35 PM, Gyrd Thane Lange
>  wrote:
> > On Tue, 28 Oct 2014 17:01:39 -0600
> > Ian Lepore  wrote:
> >
> >> On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote:
> >> > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
> >>
> >> Do a "make kernel-toolchain" which will build a new ctfconvert and
> >> put it in the right place within /usr/obj to be used during
> >> buildkernel.
> >
> > Thanks, I will try this (building now). But if it works I'll be
> > somewhat confused. I thought kernel-toolchain was implicit when
> > doing a full buildworld (which I've already done), and I already
> > have a ctfconvert
> > (/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert).

Finished a make kernel-toolchain (but it left me with even less binaries
than make buildworld):

# find /usr/src/ /usr/obj -name ctfconvert -type f
(nothing found)

> > The problem looks more like buildkernel is ignoring the ctfconvert
> > tool in /usr/obj/ and instead is expecting to find it in /usr/bin
> > (or some such).
> 
> It should be located in /usr/obj -- we should not expect the tool
> in /usr/bin to be correct/compatible with the source tree.

I agree. :)

while waiting for a proper solution for this, I'll try looking at the
Makefiles and bsd.*.mk files under /usr/src my self, but I have never
looked at them before so I don't expect a speedy success.

Gyrd ^_^

> Cheers!
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

HEADS UP: Standalone kernel debug files moving out of /boot/kernel/

[Ed Maste]

I am preparing to move the standalone kernel debug data out of
/boot/kernel/ into /usr/lib/debug/boot/kernel/, mirroring the approach
used for userland debug data. This significantly reduces the boot
partition size requirement, and is a step towards supporting the
installation of kernel debug data ony when required. LLDB and GDB
automatically search for debug data under /usr/lib/debug/ so this
change should be transparent from an end-user perspective.

The change can be reviewed in Phabricator at
https://reviews.freebsd.org/D1006 and can be fetched as a unified diff
from https://people.freebsd.org/~emaste/patches/D1006.diff

This does not change any defaults or knobs: kernel debug files are
still built by default, and may be disabled by setting
WITHOUT_KERNEL_SYMBOLS=YES in /etc/src.conf. I hope to rationalize
this with userland debug in a later step.

Note that the change renames the intermediate and debug data files to
be consistent with userland debug data: in the build directory the
kernel with debug data included is now named kernel.full, and and
kernel.debug is the standalone debug data file.

I plan to merge this in a few days if there are no issues reported in
further review or testing.

-Ed
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg 1.4 freeze please test test test!

[Allan Jude]

On 2014-10-28 19:35, Baptiste Daroussin wrote:
> On Tue, Oct 28, 2014 at 07:27:10PM -0400, Allan Jude wrote:
>> On 2014-10-28 19:19, Baptiste Daroussin wrote:
>>> Hi all,
>>>
>>> We are starting the release process of pkg 1.4, we want to have a better 
>>> release
>>> process than with every single previous version of pkg. For that we will 
>>> need
>>> you help!
>>>
>>> pkg-devel has been updated to the latest version of pkg as of alpha2.
>>>
>>> Changes you can expect in pkg 1.4 are the following:
>>> - Loads of bug fixes
>>> - Stricter checking of the path passed via the plist
>>> - Removal of the bundled libyaml
>>> - new --raw-format to chose the output format for info -R and search -R
>>> - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become 
>>> FreeBSD:10:amd64)
>>>   the old ABI is available as a fallback in ALTABI
>>> - pkg check now support a quiet mode
>>> - new 3 way merge code ("stolen" from the fossil-scm) to allow automerging
>>>   configuration files
>>> - new @config keyword to mark a file as a config file (during
>>>   upgrade/reinstallation it will try to merge the configuration with the 
>>> one the
>>>   user may have modified) an option AUTOMERGE is available to prevent
>>>   automerging if automerge fails a .pkgnew file will be created along with 
>>> the
>>>   untouched user version of the configuration
>>> - The update procedure has been improved and speed up a lot (in particular 
>>> for
>>>   machine with low resources)
>>> - The unique identifier has been modified to be pkgname meaning now ports 
>>> can be
>>>   moved in new categories without having to be considered a different 
>>> package
>>> - Only libraries starting by lib* are added to the provided libraries
>>> - General speed up of all operations
>>>
>>> We need help in testing, but we also need help in writing regression tests !
>>> The more we have tests the more stable the releases will be.
>>>
>>> The release will also allow to be able to package base!
>>>
>>> regards,
>>> Bapt
>>>
>>
>> Naming the option 'AUTOMERGE' when it stops the automatic merging, seems
>> like a really bad idea. Either make it AUTOMERGE=false or NOAUTHMERGE or
>> something.
> 
> The default it automerge: true you have to change it to automerge: false to
> prevent it to work
> 
> regards,
> Bapt
> 

Right, that makes sense, thank you.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory)

[NGie Cooper]

On Tue, Oct 28, 2014 at 4:35 PM, Gyrd Thane Lange  wrote:
> On Tue, 28 Oct 2014 17:01:39 -0600
> Ian Lepore  wrote:
>
>> On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote:
>> > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
>>
>> Do a "make kernel-toolchain" which will build a new ctfconvert and put
>> it in the right place within /usr/obj to be used during buildkernel.
>
> Thanks, I will try this (building now). But if it works I'll be somewhat
> confused. I thought kernel-toolchain was implicit when doing a full
> buildworld (which I've already done), and I already have a ctfconvert
> (/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert).
>
> The problem looks more like buildkernel is ignoring the ctfconvert
> tool in /usr/obj/ and instead is expecting to find it in /usr/bin (or
> some such).

It should be located in /usr/obj -- we should not expect the tool
in /usr/bin to be correct/compatible with the source tree.
Cheers!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory)

[Gyrd Thane Lange]

On Tue, 28 Oct 2014 17:01:39 -0600
Ian Lepore  wrote:

> On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote:
> > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
> 
> Do a "make kernel-toolchain" which will build a new ctfconvert and put
> it in the right place within /usr/obj to be used during buildkernel.

Thanks, I will try this (building now). But if it works I'll be somewhat
confused. I thought kernel-toolchain was implicit when doing a full
buildworld (which I've already done), and I already have a ctfconvert
(/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert).

The problem looks more like buildkernel is ignoring the ctfconvert
tool in /usr/obj/ and instead is expecting to find it in /usr/bin (or
some such).

Gyrd ^_^

> 
> -- Ian
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg 1.4 freeze please test test test!

[Baptiste Daroussin]

On Tue, Oct 28, 2014 at 07:27:10PM -0400, Allan Jude wrote:
> On 2014-10-28 19:19, Baptiste Daroussin wrote:
> > Hi all,
> > 
> > We are starting the release process of pkg 1.4, we want to have a better 
> > release
> > process than with every single previous version of pkg. For that we will 
> > need
> > you help!
> > 
> > pkg-devel has been updated to the latest version of pkg as of alpha2.
> > 
> > Changes you can expect in pkg 1.4 are the following:
> > - Loads of bug fixes
> > - Stricter checking of the path passed via the plist
> > - Removal of the bundled libyaml
> > - new --raw-format to chose the output format for info -R and search -R
> > - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become 
> > FreeBSD:10:amd64)
> >   the old ABI is available as a fallback in ALTABI
> > - pkg check now support a quiet mode
> > - new 3 way merge code ("stolen" from the fossil-scm) to allow automerging
> >   configuration files
> > - new @config keyword to mark a file as a config file (during
> >   upgrade/reinstallation it will try to merge the configuration with the 
> > one the
> >   user may have modified) an option AUTOMERGE is available to prevent
> >   automerging if automerge fails a .pkgnew file will be created along with 
> > the
> >   untouched user version of the configuration
> > - The update procedure has been improved and speed up a lot (in particular 
> > for
> >   machine with low resources)
> > - The unique identifier has been modified to be pkgname meaning now ports 
> > can be
> >   moved in new categories without having to be considered a different 
> > package
> > - Only libraries starting by lib* are added to the provided libraries
> > - General speed up of all operations
> > 
> > We need help in testing, but we also need help in writing regression tests !
> > The more we have tests the more stable the releases will be.
> > 
> > The release will also allow to be able to package base!
> > 
> > regards,
> > Bapt
> > 
> 
> Naming the option 'AUTOMERGE' when it stops the automatic merging, seems
> like a really bad idea. Either make it AUTOMERGE=false or NOAUTHMERGE or
> something.

The default it automerge: true you have to change it to automerge: false to
prevent it to work

regards,
Bapt


pgp5gdNO3DuKP.pgp
Description: PGP signature

Re: pkg 1.4 freeze please test test test!

[Allan Jude]

On 2014-10-28 19:19, Baptiste Daroussin wrote:
> Hi all,
> 
> We are starting the release process of pkg 1.4, we want to have a better 
> release
> process than with every single previous version of pkg. For that we will need
> you help!
> 
> pkg-devel has been updated to the latest version of pkg as of alpha2.
> 
> Changes you can expect in pkg 1.4 are the following:
> - Loads of bug fixes
> - Stricter checking of the path passed via the plist
> - Removal of the bundled libyaml
> - new --raw-format to chose the output format for info -R and search -R
> - ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10:amd64)
>   the old ABI is available as a fallback in ALTABI
> - pkg check now support a quiet mode
> - new 3 way merge code ("stolen" from the fossil-scm) to allow automerging
>   configuration files
> - new @config keyword to mark a file as a config file (during
>   upgrade/reinstallation it will try to merge the configuration with the one 
> the
>   user may have modified) an option AUTOMERGE is available to prevent
>   automerging if automerge fails a .pkgnew file will be created along with the
>   untouched user version of the configuration
> - The update procedure has been improved and speed up a lot (in particular for
>   machine with low resources)
> - The unique identifier has been modified to be pkgname meaning now ports can 
> be
>   moved in new categories without having to be considered a different package
> - Only libraries starting by lib* are added to the provided libraries
> - General speed up of all operations
> 
> We need help in testing, but we also need help in writing regression tests !
> The more we have tests the more stable the releases will be.
> 
> The release will also allow to be able to package base!
> 
> regards,
> Bapt
> 

Naming the option 'AUTOMERGE' when it stops the automatic merging, seems
like a really bad idea. Either make it AUTOMERGE=false or NOAUTHMERGE or
something.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

pkg 1.4 freeze please test test test!

[Baptiste Daroussin]

Hi all,

We are starting the release process of pkg 1.4, we want to have a better release
process than with every single previous version of pkg. For that we will need
you help!

pkg-devel has been updated to the latest version of pkg as of alpha2.

Changes you can expect in pkg 1.4 are the following:
- Loads of bug fixes
- Stricter checking of the path passed via the plist
- Removal of the bundled libyaml
- new --raw-format to chose the output format for info -R and search -R
- ABI is now follwing MACHINE_ARCH (freebsd:10:x86:64 become FreeBSD:10:amd64)
  the old ABI is available as a fallback in ALTABI
- pkg check now support a quiet mode
- new 3 way merge code ("stolen" from the fossil-scm) to allow automerging
  configuration files
- new @config keyword to mark a file as a config file (during
  upgrade/reinstallation it will try to merge the configuration with the one the
  user may have modified) an option AUTOMERGE is available to prevent
  automerging if automerge fails a .pkgnew file will be created along with the
  untouched user version of the configuration
- The update procedure has been improved and speed up a lot (in particular for
  machine with low resources)
- The unique identifier has been modified to be pkgname meaning now ports can be
  moved in new categories without having to be considered a different package
- Only libraries starting by lib* are added to the provided libraries
- General speed up of all operations

We need help in testing, but we also need help in writing regression tests !
The more we have tests the more stable the releases will be.

The release will also allow to be able to package base!

regards,
Bapt


pgpm5qjnNEcGc.pgp
Description: PGP signature

Re: junior kernel tasks

[Eitan Adler]

On 28 October 2014 15:14, Baptiste Daroussin  wrote:
> On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote:
>>
>> Quoting John Baldwin :
>>
>> > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote:
>> >> Hello,
>> >>
>> >> In short, nice kernel tasks people with C language skills can do in few
>> >> evenings.
>> >>
>> >> https://wiki.freebsd.org/JuniorJobs
>> >>
>> >> It is assumed you know how to obtain sources and build the kernel.
>> >>
>> >> What you can get in return:
>> >> - your own code in FreeBSD tree
>> >> - eternal glory [1]
>> >> - fun [2]
>> >>
>> >> If you are not interested, but know someone who does, please pass it
>> >> down.
>> >>
>> >> [1] - not really, no
>> >> [2] - well, I guess that's subjective, so that's not a "no"
>> >
>> > Even though our bugmeisters have decided that we should not have wishlist
>> > items in our bug tracker, I really wish we could store the various idea 
>> > lists
>> > (we have several) in an issue tracker instead.  This would allow for folks 
>> > to
>> > comment on ideas, vote for them, etc.  It would also make it easier for 
>> > more
>> > people to submit new ideas.
>> >
>>
>> Speaking not strictly with the bugmeister hat, but from experience, please do
>> not let us go down the road of (ab)using a bug tracking solution as task and
>> idea management system. I think that using the tasks feature of phabricator
>> (our reviews instance) would provide better workflow support for those 
>> things,
>> starting out from sketching out rough ideas, discussing them, breaking them 
>> up
>> in seperate tasks (linked to and dependent on each other) and collaborating
>> on them (take a look at https://developer.blender.org/T42339 for a
>> brief example).
>>
>> Having said this, let's keep the bug tracker a bug tracker.
>>
>> Cheers
>> Marcus
>>
>>
>> ___
>> freebsd-hack...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
> I disabled the tasks on phabricator to avoid having it a duplicate of 
> bugzilla,
> but if we have a use for it I can activate it!
>
> Actually I do like the idea of the bug tracker aka bugzilla being only for 
> bugs
> and uxe phabricator for tracking the tasks

having disparate trackers for "wishlist" and "bugs" is quite harmful
and splits the conversations.  It makes people learn multiple systems
and search multiple places - especially if the feature ends up being
submitted as a patch to the bug tracker.

I'd rather keep wishlist items in the bug tracker than split them into two.

(also, fwiw, I'd rather keep the tasks number space clean should we
ever decide to import from bugzilla -> phabricator)


-- 
Eitan Adler
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory)

[Ian Lepore]

On Tue, 2014-10-28 at 23:50 +0100, Gyrd Thane Lange wrote:
> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin

Do a "make kernel-toolchain" which will build a new ctfconvert and put
it in the right place within /usr/obj to be used during buildkernel.

-- Ian


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

buildkernel: make[2]: exec(ctfconvert) failed (No such file or directory)

[Gyrd Thane Lange]

Hi!

I'm trying to build CURRENT r273800 with an empty
(actually nonexisting) /etc/src.conf when it previously had contained:

WITHOUT_MODULES=dtrace
WITHOUT_CDDL=

# uname -a
FreeBSD onyx.thanelange.no 11.0-CURRENT FreeBSD 11.0-CURRENT #7
r273066M: Sun Oct 19 20:12:57 CEST 2014
r...@onyx.thanelange.no:/usr/obj/usr/src/sys/ONYX  amd64

# rm -rf /usr/obj/*
# make buildworld buildkernel

The world build succeeds fine, but the kernel build fails with:

--
>>> stage 3.2: building everything
--
cd /usr/obj/usr/src/sys/ONYX; MAKEOBJDIRPREFIX=/usr/obj
MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
_SHLIBDIRPREFIX=/usr/obj/usr/src/tmp  _LDSCRIPTROOT=  VERSION="FreeBSD
11.0-CURRENT amd64 1100040"  INSTALL="sh /usr/src/tools/install.sh"
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
CC="cc " CXX="c++  "  DEPFLAGS=""  CPP="cpp "  AS="as" AR="ar" LD="ld"
NM=nm  OBJDUMP= OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
make  -m /usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ

cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing
-std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs
-fdiagnostics-show-option  -Wno-error-tautological-compare
-Wno-error-empty-body  -Wno-error-parentheses-equality
-Wno-error-unused-function -nostdinc  -I. -I/usr/src/sys
-I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-gdwarf-2 -mno-aes -mno-avx  -Werror /usr/src/sys/amd64/amd64/locore.S

cc  -c -O2 -pipe -fno-strict-aliasing  -std=c99 -g -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs
-fdiagnostics-show-option  -Wno-error-tautological-compare
-Wno-error-empty-body  -Wno-error-parentheses-equality
-Wno-error-unused-function -nostdinc  -I. -I/usr/src/sys
-I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-gdwarf-2 -mno-aes -mno-avx -Werror  /usr/src/sys/cam/cam.c

ctfconvert -L VERSION -g cam.o
make[2]: exec(ctfconvert) failed (No such file or directory)
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/sys/ONYX
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src


# find /usr/src/ /usr/obj -name ctfconvert -type f | xargs ls -l

-rwxr-xr-x  1 root  wheel  371211 Oct 28 22:06
/usr/obj/usr/src/cddl/usr.bin/ctfconvert/ctfconvert

This tells me that buildworld succeeded in building the ctfconvert
binary, but buildkernel is not picking up the newly built tool.

Any advice on getting around this?

I would prefer not having to install the new world before building and
installing the new kernel.

Best regards,
Gyrd ^_^
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Mounting ZFS with error 5 failed, since r271963 callout convert

[Michael Schmiedgen]

In previous months I had already the same problem with ZFS if
nvidia driver was loaded via /boot/loader.conf. It triggered
the same error. So I loaded the driver on demand with kldload
after login and everything (X + stuff) worked fine.

Very strange...

Does anyone have a clue what is going on here?


So not loading the nvidia driver during boot fixed it?  That seems odd indeed.
Did you recompile the driver after updating?



The nvidia driver problem started long before r271963. If
I update my CURRENT, non base stuff will be deleted and
ports will be completly new installed. The nvidia problem
persisted some of these cycles before I gave up. I can
test if the problem still exists.

But now there is a similar problem with applying kern_cons.c
in r271963. I do not know whether these two are related.

Please let me know if you want to see some configuration
or logs or anything.

Thanks,
  Michael

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: junior kernel tasks

[Baptiste Daroussin]

On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote:
> 
> Quoting John Baldwin :
> 
> > On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote:
> >> Hello,
> >>
> >> In short, nice kernel tasks people with C language skills can do in few
> >> evenings.
> >>
> >> https://wiki.freebsd.org/JuniorJobs
> >>
> >> It is assumed you know how to obtain sources and build the kernel.
> >>
> >> What you can get in return:
> >> - your own code in FreeBSD tree
> >> - eternal glory [1]
> >> - fun [2]
> >>
> >> If you are not interested, but know someone who does, please pass it
> >> down.
> >>
> >> [1] - not really, no
> >> [2] - well, I guess that's subjective, so that's not a "no"
> >
> > Even though our bugmeisters have decided that we should not have wishlist
> > items in our bug tracker, I really wish we could store the various idea 
> > lists
> > (we have several) in an issue tracker instead.  This would allow for folks 
> > to
> > comment on ideas, vote for them, etc.  It would also make it easier for more
> > people to submit new ideas.
> >
> 
> Speaking not strictly with the bugmeister hat, but from experience, please do
> not let us go down the road of (ab)using a bug tracking solution as task and
> idea management system. I think that using the tasks feature of phabricator
> (our reviews instance) would provide better workflow support for those things,
> starting out from sketching out rough ideas, discussing them, breaking them up
> in seperate tasks (linked to and dependent on each other) and collaborating
> on them (take a look at https://developer.blender.org/T42339 for a  
> brief example).
> 
> Having said this, let's keep the bug tracker a bug tracker.
> 
> Cheers
> Marcus
> 
> 
> ___
> freebsd-hack...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

I disabled the tasks on phabricator to avoid having it a duplicate of bugzilla,
but if we have a use for it I can activate it!

Actually I do like the idea of the bug tracker aka bugzilla being only for bugs
and uxe phabricator for tracking the tasks

regards,
Bapt


pgp3JNwdA14ys.pgp
Description: PGP signature

Re: junior kernel tasks

[Marcus von Appen]

Quoting John Baldwin :


On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote:

Hello,

In short, nice kernel tasks people with C language skills can do in few
evenings.

https://wiki.freebsd.org/JuniorJobs

It is assumed you know how to obtain sources and build the kernel.

What you can get in return:
- your own code in FreeBSD tree
- eternal glory [1]
- fun [2]

If you are not interested, but know someone who does, please pass it
down.

[1] - not really, no
[2] - well, I guess that's subjective, so that's not a "no"


Even though our bugmeisters have decided that we should not have wishlist
items in our bug tracker, I really wish we could store the various idea lists
(we have several) in an issue tracker instead.  This would allow for folks to
comment on ideas, vote for them, etc.  It would also make it easier for more
people to submit new ideas.



Speaking not strictly with the bugmeister hat, but from experience, please do
not let us go down the road of (ab)using a bug tracking solution as task and
idea management system. I think that using the tasks feature of phabricator
(our reviews instance) would provide better workflow support for those things,
starting out from sketching out rough ideas, discussing them, breaking them up
in seperate tasks (linked to and dependent on each other) and collaborating
on them (take a look at https://developer.blender.org/T42339 for a  
brief example).


Having said this, let's keep the bug tracker a bug tracker.

Cheers
Marcus


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: junior kernel tasks

[John Baldwin]

On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote:
> Hello,
> 
> In short, nice kernel tasks people with C language skills can do in few
> evenings.
> 
> https://wiki.freebsd.org/JuniorJobs
> 
> It is assumed you know how to obtain sources and build the kernel.
> 
> What you can get in return:
> - your own code in FreeBSD tree
> - eternal glory [1]
> - fun [2]
> 
> If you are not interested, but know someone who does, please pass it
> down.
> 
> [1] - not really, no
> [2] - well, I guess that's subjective, so that's not a "no"

Even though our bugmeisters have decided that we should not have wishlist 
items in our bug tracker, I really wish we could store the various idea lists 
(we have several) in an issue tracker instead.  This would allow for folks to 
comment on ideas, vote for them, etc.  It would also make it easier for more 
people to submit new ideas.

It also provides a better place to store metadata about the issue itself 
(wikis are kind of poor for that).

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Mounting ZFS with error 5 failed, since r271963 callout convert

[John Baldwin]

On Monday, October 27, 2014 6:46:17 pm Michael Schmiedgen wrote:
> On 10/27/2014 22:29, Ryan Stone wrote:
> > On Mon, Oct 27, 2014 at 4:21 PM, Michael Schmiedgen  
wrote:
> >> Hi List,
> >>
> >> my ZFS does not mount. I bifurcated to r271963 that
> >> does not work anymore. The commit seems not directly
> >> related to ZFS, but is rather a conversion from timeout(9)
> >> to callout(9).
> >>
> >> After booting the kernel it drops to the mount prompt,
> >> stating that ZFS cannot be mounted because of 'error 5'.
> >>
> >> Any hints? Can I provide some more information?
> >>
> >> Thanks,
> >>Michael
> >
> > The changes to the 3 files there look to be independent, so can you
> > narrow this down further by applying the patch to only a single file?
> > Of those three only ACPI looks like it could affect ZFS or disks, so
> > this will be the patch to try first:
> >
> > 
https://svnweb.freebsd.org/base/head/sys/dev/acpica/acpi.c?view=patch&r1=271889&r2=271963&pathrev=271963
> >
> > If you can get a verbose boot log from the machine that would be
> > helpful, but you'd need a serial console to capture that.
> >
> 
> I applied first acpi.c, then atkbd.c and at last kern_cons.c that
> triggered the error.
> 
> 
https://svnweb.freebsd.org/base/head/sys/kern/kern_cons.c?r1=271963&r2=271962&pathrev=271963
> 
> In previous months I had already the same problem with ZFS if
> nvidia driver was loaded via /boot/loader.conf. It triggered
> the same error. So I loaded the driver on demand with kldload
> after login and everything (X + stuff) worked fine.
> 
> Very strange...
> 
> Does anyone have a clue what is going on here?

So not loading the nvidia driver during boot fixed it?  That seems odd indeed.  
Did you recompile the driver after updating?

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: missing nullmailer feature in dma(8)/dmagent

[Harald Schmalzbauer]

 Bezüglich Baptiste Daroussin's Nachricht vom 28.10.2014 17:44 (localtime):
…
> The NULLCLIENT feature should exactly be what you are looking for, no?
> As written in the manpage:
>
> 
> Bypass aliases and local delivery, and instead forward all mails to
> the defined `SMARTHOST'.  `NULLCLIENT' requires `SMARTHOST' to be
> set.
> 

Doh… should try harder getting more sleep ;-)
Sorry for the noise, seems indeed to be exactly what I was looking for.
Can't explain why I missed that, thanks!

-Harry



signature.asc
Description: OpenPGP digital signature

Re: missing nullmailer feature in dma(8)/dmagent

[Baptiste Daroussin]

On Tue, Oct 28, 2014 at 11:30:49AM +0100, Harald Schmalzbauer wrote:
>  Hello,
> 
> I haven't found a way to instruct dma(8) to also forward unqualified
> recipients to the relayhost. It always delivers unqualified addresses
> locally (if not translated by "aliases").
> 
> ssmtp(8) provides an option to define a recipient address for all local
> recipients who's ID is <1000.
> nullmailer(7) does exactly what I want, it doesn't care about the host
> part of the recipient address, it just passes it over.
> 
> I'm missing an option for dma(8), which disables local delivery
> completely, or like ssmtp, optionally only for ids <1000 resp. not
> existing local users.
> 
> Why?:
> Maintaining aliases at each machine is too expensive.
> My aim is that any operator or daemon of any (human-users-less) machine
> can simply drop mails to 'chief' or 'root' or 'monitor'. Then there are
> MSAs (I don't call them mailhub, in my world a mailhub stores email,
> which often is called a "mailhost"), and only these MSAs care about
> recipient aliasing and delivery to mailhub or relayhost. With that setup
> I have exactly one (resp. each redundant MSA) place to maintain aliases
> and/or other forwarding rules/mailertables etc. Since most smtp-agent
> implementations handle multiple A records – although I haven't found one
> which evaluates MX records – and I have more than one MSA, I can pretty
> reliably guaranteee that any failing machine/device/daemon can drop a
> note which won't get lost. If I did aliasing on the mailhub instead at
> the interposed MSA, I'd loose poor mans' redundancy…
> 
> According to dma(8) on 11-current, it's the same like in ports
> (mail/dma), which I used for testing.
> I like the decision to replace sendmail, since almost any time in the
> past when I really needed to use the fullfeatured MTA capabilities, I
> had to replace base sendmail with a SASL extended version…
> But I'd still need to spread nullmailer(7) with current's dma featrues
> in 11.
> 

The NULLCLIENT feature should exactly be what you are looking for, no?
As written in the manpage:


Bypass aliases and local delivery, and instead forward all mails to
the defined `SMARTHOST'.  `NULLCLIENT' requires `SMARTHOST' to be
set.


regards,
Bapt


pgp7xmOusYA0m.pgp
Description: PGP signature

Re: can't build CURRENT/amd64 using 9.3?

[owner-freebsd-current]

Fixed by scrubbing 9.3 and installing 10.1-RC3, which solved a
couple of other issues.

Respectfully,


Robert Huff

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: RFC: getting rid of oldnfs

[John Baldwin]

On Saturday, October 25, 2014 6:24:16 pm Rick Macklem wrote:
> Kostik wrote:
> > On Fri, Oct 24, 2014 at 04:43:28PM +0100, Robert Watson wrote:
> > > On Thu, 23 Oct 2014, Rick Macklem wrote:
> > > 
> > > > Someone just pinged me on this and I figured I should bring it
> > > > up.
> > > >
> > > > 1 - Is anyone out there still using oldnfs due to unresolved
> > > >problems with the new one? (I am not aware of any outstanding
> > > >issues in the new nfs that don't exist in the oldnfs.)
> > > > 2 - Does anyone see a problem with getting rid of oldnfs for
> > > >FreebSD-11?
> > > > 3 - If I get rid of it in -head, I can do it either in
> > > > mid-December
> > > >or mid-April. (I can't do commits during the winter.)
> > > >Does anyone have a rough idea when the 11.0 release cycle will
> > > >start, so I can choose which of the above would be preferable?
> > > >(I figured I'd wait until after the last 10.n release that
> > > >happens
> > > > before 11.0, since it will be easier to MFC before the
> > > > removal of
> > > > oldnfs.)
> > > >
> > > > Thanks in advance for any comments, rick
> > > > ps: John, I've cc'd you since I thought you are the guy most
> > > > likely to
> > > >need to do commits/MFCs to oldnfs.
> > > 
> > > I think removing it is fine, but as early as possible (as John
> > > says) to give
> > > our -CURRENT users time to stop working around bugs and start
> > > reporting them
> > > :-).
> > 
> > I remember the main reason for keeping oldnfs, both server and
> > client,
> > around in HEAD was to facilitate MFC of fixes to the branches which
> > still use oldnfs, i.e. stable/8.  If this reason is still valid,
> > oldnfs
> > have to stay in HEAD till stable/8 is supported or interested for
> > developers.
> > 
> > I usually do not like direct commits into the stable branches.
> > Otherwise, I see no reason to keep oldnfs around.
> > 
> Well, the only commits I've done to "old" were bugfixes that applied
> to both old and new.
> 
> John has been the main "fix the old NFS" guy lately. So, John, do you
> anticipate more patches to the old NFS that need to be MFC'd down?

I do not, no.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

missing nullmailer feature in dma(8)/dmagent

[Harald Schmalzbauer]

 Hello,

I haven't found a way to instruct dma(8) to also forward unqualified
recipients to the relayhost. It always delivers unqualified addresses
locally (if not translated by "aliases").

ssmtp(8) provides an option to define a recipient address for all local
recipients who's ID is <1000.
nullmailer(7) does exactly what I want, it doesn't care about the host
part of the recipient address, it just passes it over.

I'm missing an option for dma(8), which disables local delivery
completely, or like ssmtp, optionally only for ids <1000 resp. not
existing local users.

Why?:
Maintaining aliases at each machine is too expensive.
My aim is that any operator or daemon of any (human-users-less) machine
can simply drop mails to 'chief' or 'root' or 'monitor'. Then there are
MSAs (I don't call them mailhub, in my world a mailhub stores email,
which often is called a "mailhost"), and only these MSAs care about
recipient aliasing and delivery to mailhub or relayhost. With that setup
I have exactly one (resp. each redundant MSA) place to maintain aliases
and/or other forwarding rules/mailertables etc. Since most smtp-agent
implementations handle multiple A records – although I haven't found one
which evaluates MX records – and I have more than one MSA, I can pretty
reliably guaranteee that any failing machine/device/daemon can drop a
note which won't get lost. If I did aliasing on the mailhub instead at
the interposed MSA, I'd loose poor mans' redundancy…

According to dma(8) on 11-current, it's the same like in ports
(mail/dma), which I used for testing.
I like the decision to replace sendmail, since almost any time in the
past when I really needed to use the fullfeatured MTA capabilities, I
had to replace base sendmail with a SASL extended version…
But I'd still need to spread nullmailer(7) with current's dma featrues
in 11.

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature