Re: pkg_sign incorrectly assumes -i by default
On Mon, Jun 06, 2016 at 04:14:12PM +1000, Jonathan Gray wrote:
> The behaviour of pkg_sign acts as if -i is always specified and won't
> sign/resign a package if it exists in the output directory.
>
> In OpenBSD/PkgSign.pm sign_existing_package $state->opt('i')
> path is always taken. Does this come from some shared code
> setting a default interactive level for pkg_add's different -i option?
>
> $ pkg_info -v ./hexedit-1.2.12.tgz
> ...
> @signer openbsd-60-pkg
> @digital-signature
> signify:2016-06-05T21:12:25Z:RWQHIajRlT2mX2Co5PKjLtNprvAe8NjNXbxUabL3ySmJfLzFxod5BlCn+RvTB2coDd41rJdPJ+Ob/AUQMeAmEFETgJIVpn5YhAo=
>
> $ signify -Gn -p test-pkg.pub -s test-pkg.sec
> $ doas cp test-pkg.pub /etc/signify/
>
> $ pkg_sign -v -D resign -s signify -s test-pkg.sec ./hexedit-1.2.12.tgz
> Signed ./hexedit-1.2.12.tgz: ok
> $ pkg_info -v ./hexedit-1.2.12.tgz
> ..
> @signer openbsd-60-pkg
> @digital-signature
> signify:2016-06-05T21:12:25Z:RWQHIajRlT2mX2Co5PKjLtNprvAe8NjNXbxUabL3ySmJfLzFxod5BlCn+RvTB2coDd41rJdPJ+Ob/AUQMeAmEFETgJIVpn5YhAo=
>
> $ mkdir out
> $ pkg_sign -v -o out -D resign -s signify -s test-pkg.sec ./hexedit-1.2.12.tgz
> Resigning hexedit-1.2.12
> Signed ./hexedit-1.2.12.tgz: ok
> $ pkg_info -v ./out/hexedit-1.2.12.tgz
> ..
> @signer test-pkg
> @digital-signature
> signify:2016-06-06T05:47:46Z:RWRwvf7+8LjZmCFrf65S/RhowUT4+QvgVnEHg4ztH6ZIEVWDVWjlGyd/SWvb1apmxcoaO+lNFm+83OhvvuGsTyEGC95pcA2PTgc=
>
> $ zfgrep signer ./dtb-4.6.tgz
> $
> $ pkg_sign -v -s signify -s test-pkg.sec ./dtb-4.6.tgz
> $ zfgrep signer ./dtb-4.6.tgz
> $
Yep, definitely inherited that when -i became the default in pkg_add
I'm afraid...
gonna see to it.
Re: pkg_sign incorrectly assumes -i by default
This should fix things.
Index: AddCreateDelete.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/AddCreateDelete.pm,v
retrieving revision 1.34
diff -u -p -r1.34 AddCreateDelete.pm
--- AddCreateDelete.pm 6 Apr 2015 11:07:24 - 1.34
+++ AddCreateDelete.pm 6 Jun 2016 07:09:49 -
@@ -59,25 +59,11 @@ sub handle_options
{
my ($state, $opt_string, @usage) = @_;
- my $i;
- $state->{opt}{i} //= sub {
- $i++;
- };
- $state->SUPER::handle_options($opt_string.'IiL:mnx', @usage);
+ $state->SUPER::handle_options($opt_string.'L:mnx', @usage);
$state->progress->setup($state->opt('x'), $state->opt('m'), $state);
$state->{not} = $state->opt('n');
- if ($state->opt('I')) {
- $i = 0;
- } elsif (!defined $i) {
- $i = -t STDIN;
- }
- if ($i) {
- require OpenBSD::Interactive;
- $state->{interactive} = OpenBSD::Interactive->new($state, $i);
- } else {
- $state->{interactive} = OpenBSD::InteractiveStub->new($state);
- }
+ $state->{interactive} //= OpenBSD::InteractiveStub->new($state);
}
Index: AddDelete.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/AddDelete.pm,v
retrieving revision 1.72
diff -u -p -r1.72 AddDelete.pm
--- AddDelete.pm25 May 2015 07:20:31 - 1.72
+++ AddDelete.pm6 Jun 2016 07:09:49 -
@@ -167,11 +167,24 @@ sub handle_options
$state->{subst}->add($o, 1);
}
};
+ my $i;
+ $state->{opt}{i} //= sub {
+ $i++;
+ };
$state->{no_exports} = 1;
$state->SUPER::handle_options($opt_string.'aciInqsB:F:', @usage);
if ($state->opt('s')) {
$state->{not} = 1;
+ }
+ if ($state->opt('I')) {
+ $i = 0;
+ } elsif (!defined $i) {
+ $i = -t STDIN;
+ }
+ if ($i) {
+ require OpenBSD::Interactive;
+ $state->{interactive} = OpenBSD::Interactive->new($state, $i);
}
# XXX RequiredBy
$main::not = $state->{not};
Re: pkg_sign incorrectly assumes -i by default
On Mon, Jun 06, 2016 at 09:12:04AM +0200, Marc Espie wrote:
>
> This should fix things.
Thanks, things work as expected here with this diff.
>
>
> Index: AddCreateDelete.pm
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/AddCreateDelete.pm,v
> retrieving revision 1.34
> diff -u -p -r1.34 AddCreateDelete.pm
> --- AddCreateDelete.pm6 Apr 2015 11:07:24 - 1.34
> +++ AddCreateDelete.pm6 Jun 2016 07:09:49 -
> @@ -59,25 +59,11 @@ sub handle_options
> {
> my ($state, $opt_string, @usage) = @_;
>
> - my $i;
> - $state->{opt}{i} //= sub {
> - $i++;
> - };
> - $state->SUPER::handle_options($opt_string.'IiL:mnx', @usage);
> + $state->SUPER::handle_options($opt_string.'L:mnx', @usage);
>
> $state->progress->setup($state->opt('x'), $state->opt('m'), $state);
> $state->{not} = $state->opt('n');
> - if ($state->opt('I')) {
> - $i = 0;
> - } elsif (!defined $i) {
> - $i = -t STDIN;
> - }
> - if ($i) {
> - require OpenBSD::Interactive;
> - $state->{interactive} = OpenBSD::Interactive->new($state, $i);
> - } else {
> - $state->{interactive} = OpenBSD::InteractiveStub->new($state);
> - }
> + $state->{interactive} //= OpenBSD::InteractiveStub->new($state);
> }
>
>
> Index: AddDelete.pm
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/AddDelete.pm,v
> retrieving revision 1.72
> diff -u -p -r1.72 AddDelete.pm
> --- AddDelete.pm 25 May 2015 07:20:31 - 1.72
> +++ AddDelete.pm 6 Jun 2016 07:09:49 -
> @@ -167,11 +167,24 @@ sub handle_options
> $state->{subst}->add($o, 1);
> }
> };
> + my $i;
> + $state->{opt}{i} //= sub {
> + $i++;
> + };
> $state->{no_exports} = 1;
> $state->SUPER::handle_options($opt_string.'aciInqsB:F:', @usage);
>
> if ($state->opt('s')) {
> $state->{not} = 1;
> + }
> + if ($state->opt('I')) {
> + $i = 0;
> + } elsif (!defined $i) {
> + $i = -t STDIN;
> + }
> + if ($i) {
> + require OpenBSD::Interactive;
> + $state->{interactive} = OpenBSD::Interactive->new($state, $i);
> }
> # XXX RequiredBy
> $main::not = $state->{not};
>
Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16
On Sun, Jun 05, 2016 at 07:25:30PM +0200, Stefan Sperling wrote:
> On Sun, Jun 05, 2016 at 01:26:41PM +0200, Remi Locherer wrote:
> > On Sun, Jun 05, 2016 at 09:48:47AM +0200, Stefan Sperling wrote:
> > > On Sat, Jun 04, 2016 at 11:16:32PM +0200, Remi Locherer wrote:
> > > > On my installation the upgrade process looks like this (snapshot bsd.rd
> > > > from Jun 2):
> > >
> > > > [...]
> > >
> > > > iwm0: no link ... sleeping
> > >
> > > > My /etc/hostname.iwm0:
> > > >
> > > > nwid tsunami wpakey
> > > > dhcp
> > > > inet6 autoconf
> > > > !pkill -9 -lf wifinwid
> > > > !/etc/wifinwid \$if &
> > >
> > > Please add a 'debug' line at the top of your hostname.iwm0 file.
> > > That might reveal more of what's going on.
> >
> > There is no additional output with debug in hostname.iwm0 when
> > booting bsd.rd (snapshot Jun 2). When booting bsd.mp I see that iwm0
> > does scanning and receives beacons and more.
>
> Strange. ifconfig iwm0 debug definitely works in the ramdisk for me.
>
> Can we set aside the install script and hostname.if magic for a while,
> and just determine whether your device works at all in bsd.rd?
>
> Try the following:
>
> Boot bsd.rd
> Select the (S)hell option
> cd /dev
> sh MAKEDEV sd1
> mount /dev/sd1a /mnt # for firmware
> ifconfig iwm0 debug
> ifconfig iwm0 scan
>
> Repeat the scan command a few times. I expect that, at least after a few
> tries, you should see the same behaviour you would see with GENERIC.
> Is that not the case?
>
> If the scan works, can you manually associate to a network and
> run dhclient iwm0? Does that work?
>
> All of the above works for me.
>
> > > Additionally, could you build a release with IWM_DEBUG defined
> > > in if_iwm.c and try bsd.rd from that? This would again print more.
> >
> > I'll try that next. Is it correct that I need to put the below line
> > in sys/arch/amd64/conf/RAMDISK_CD?
> >
> > option IWM_DEBUG=1
>
> I believe it would be just 'option IWM_DEBUG'.
>
> You could also apply this patch.
>
> Index: if_iwm.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
> retrieving revision 1.86
> diff -u -p -r1.86 if_iwm.c
> --- if_iwm.c 3 Jun 2016 16:16:25 - 1.86
> +++ if_iwm.c 5 Jun 2016 17:23:44 -
> @@ -148,6 +148,7 @@
> #define le16_to_cpup(_a_) (le16toh(*(const uint16_t *)(_a_)))
> #define le32_to_cpup(_a_) (le32toh(*(const uint32_t *)(_a_)))
>
> +#define IWM_DEBUG
> #ifdef IWM_DEBUG
> #define DPRINTF(x) do { if (iwm_debug > 0) printf x; } while (0)
> #define DPRINTFN(n, x) do { if (iwm_debug >= (n)) printf x; } while (0)
Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected.
(dmesg below). These commands are what produced the below dmesg:
ifconfig iwm0
ifconfig iwm0 up
ifconfig iwm0
ifconfig iwm0 scan
ifconfig iwm0 nwid tsunami wpakey XXX
dhclient iwm0
So iwm0 did not work on my notebook with bsd.rd from snapshots (May 31 and
Jun 2 tested).
It works fine with bsd.rd I built today (CVS up from Jun 6).
I have 1 modification in my local tree (Which I hope does not influence iwm
behaviour.):
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.223
diff -u -p -r1.223 dsdt.c
--- dsdt.c 8 May 2016 11:08:01 - 1.223
+++ dsdt.c 6 Jun 2016 12:04:27 -
@@ -1457,7 +1457,7 @@ struct aml_defval {
struct aml_value**gval;
} aml_defobj[] = {
{ "_OS_", AML_OBJTYPE_STRING, -1, osstring },
- { "_REV", AML_OBJTYPE_INTEGER, 2, NULL },
+ { "_REV", AML_OBJTYPE_INTEGER, 5, NULL },
{ "_GL", AML_OBJTYPE_MUTEX, 1, NULL, &aml_global_lock },
{ "_OSI", AML_OBJTYPE_METHOD, 1, aml_callosi },
dmesg from bsd.rd:
OpenBSD 6.0-beta (RAMDISK_CD) #2: Mon Jun 6 13:16:55 CEST 2016
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 8473636864 (8081MB)
avail mem = 8215109632 (7834MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed7d0 (84 entries)
bios0: vendor Dell Inc. version "A07" date 11/11/2015
bios0: Dell Inc. XPS 13 9343
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT
SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.58 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-su
Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16
On Mon, Jun 06, 2016 at 02:15:35PM +0200, Remi Locherer wrote: > Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected. This indicates there is a race condition bug which is avoided by the additional time spent on printing data to the console.
Re: suspend resumes immediately on Toshiba Portege R30-A-1CD
On Sun, Jun 05, 2016 at 09:39:23PM +0200, giova...@paclan.it wrote: > >Synopsis:if I suspend my Toshiba laptop it resumes immediately > >Category:kernel/acpi > >Environment: > System : OpenBSD 6.0 > Details : OpenBSD 6.0-beta (GENERIC.MP) #2150: Mon May 30 20:21:47 > MDT 2016 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > If I suspend my Toshiba Portege R30-A-1CD laptop with lid close or with > zzz(8) it resumes immediately. > Hybernation works as expected. > >How-To-Repeat: > Suspend a Toshiba R30-A-1CD laptop. > >Fix: > Unknown. > by disabling xhci(4) via config(8) I can suspend and resume, a strange thing is that to resume I have to press the power button, any other key does not do the job. Cheers Giovanni
Re: bsd.rd from May 31 fails to load the firmware for iwm-7265-16
On Mon, Jun 06, 2016 at 03:09:34PM +0200, Stefan Sperling wrote: > On Mon, Jun 06, 2016 at 02:15:35PM +0200, Remi Locherer wrote: > > Today I built a bsd.rd with IWM_DEBUG. Now the iwm0 works as expected. > > This indicates there is a race condition bug which is avoided > by the additional time spent on printing data to the console. > I could not get my iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi to find a network, let alone associate with one at all (from bsd.rd). Contrary to what kettenis@ reports, repeated up/down/up/scan/scan/scan doesn't help. As Remi reports, things work just fine when IWM_DEBUG is enabled. I did some bisecting and it turns out that the last version that works on bsd.rd is if_iwm.c -r1.81 (with the old firmware), -r1.82 which made the transition to the new firmware stops working. No problems whatsoever with GENERIC and GENERIC.MP
