From owner-freebsd-hackers@freebsd.org Sun Sep 4 16:31:58 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B89E2A9D182 for ; Sun, 4 Sep 2016 16:31:58 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-2.server.virginmedia.net (know-smtprelay-omc-2.server.virginmedia.net [80.0.253.66]) by mx1.freebsd.org (Postfix) with ESMTP id 07C45AF3 for ; Sun, 4 Sep 2016 16:31:57 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.100] ([86.10.211.13]) by know-smtprelay-2-imp with bizsmtp id fUWm1t00f0HtmFq01UWnKT; Sun, 04 Sep 2016 17:30:47 +0100 X-Originating-IP: [86.10.211.13] X-Spam: 0 X-Authority: v=2.1 cv=XKnNMlVE c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xNf9USuDAAAA:8 a=YP7sCgzeefOMQuQX9vwA:9 a=STRA4GCowSDswhwE:21 a=CZUBl5_0Cegob8Ac:21 a=QEXdDO2ut3YA:10 a=SEwjQc04WA-l_NiBhQ7s:22 To: Joe Marcus Clarke References: <20160831104556.mihpyoi3lodnikmw@perpetual.pseudorandom.co.uk> Subject: Mass bug filing: use and misuse of dbus-launch (dbus-x11) Cc: debian-devel@lists.debian.org, FreeBSD Hackers , "supervision@list.skarnet.org" , Antoine Jacoutot From: Jonathan de Boyne Pollard Message-ID: Date: Sun, 4 Sep 2016 17:30:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160831104556.mihpyoi3lodnikmw@perpetual.pseudorandom.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 16:31:58 -0000 Simon McVittie: > This can already work. If you put XDG_RUNTIME_DIR in user programs' > environment, and arrange for your favourite service manager to make a > dbus-daemon (or something else that speaks the same protocol) listen > on $XDG_RUNTIME_DIR/bus before any user process would try to connect > to it, then modern versions of at least libdbus, GDBus and sd-bus will > connect to it by default with no additional effort on your part. This > client-side code path does not depend on systemd, does not depend on > libsystemd (except obviously sd-bus which is part of libsystemd), and > is compiled in for all supported Unix platforms. > That's the problem. No the whole unix:runtime=yes mechanism is not. As I said, this is something that you and Joe Marcus Clarke and whomever else have to sort out with each other. I'm unfortunately stuck in the middle, here. Please do whatever it is that you need to do with each other to make your program understand address=systemd: and address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD. It does not do so. Simon McVittie: > Meanwhile, if you want the relevant integration files (your favourite > service manager's equivalent of systemd units) to be part of dbus (the > reference implementation of D-Bus), please propose tested patches; if > they follow the "user session" model[1], they could eventually go in > dbus-user-session.deb, with its dependencies changed from the current > systemd-sysv to "systemd-sysv | your-service-manager". > Kudos for being the first project to offer integration, ever. (-: Yes, down the road it would be marvellous if people included service bundles in their own projects. Yes, I'd like to see the day when the number of service bundles in the nosh-bundles package actually starts going down, because people are taking on shipping their own service bundles for their own services, instead of going up. So yes, eventually you'll be taken up on that offer I hope. But one step at a time. Simon McVittie: >> As for what I would like, I'd like you (where that's plural, >> including Joe Marcus Clarke or whomever else) to please make either >> address=systemd: or address=unix:runtime=yes work in your program on >> FreeBSD/PC-BSD/OpenBSD. >> > To the best of my knowledge, the listenable address "unix:runtime=yes" > (as in "dbus-daemon --address=unix:runtime=yes") does work on generic > Unix, and should interoperate fine with the XDG_RUNTIME_DIR/bus > fallback used by clients with no DBUS_SESSION_BUS_ADDRESS. It is > compiled and tested whenever DBUS_UNIX is defined (i.e. everything > except Windows), and I haven't seen bug reports about that test failing. > There you go, then. New knowledge. (-: It doesn't work with your program as ported to FreeBSD/TrueOS/OpenBSD. Joe Marcus Clarke is the porter for FreeBSD, according to the port information, and Antoine Jacoutot the porter for OpenBSD. This is why I am saying that it's something that you (plural, remember) need to sort out amongst yourselves. We users stuck in the middle cannot use address=systemd: and address=unix:runtime=yes with your program on these systems. As I said, it's something that I had to fix in November 2015, to stop trying to use address=systemd: on FreeBSD/TrueOS because it turned out that it didn't actually work. I thought that address=unix:runtime=yes might, but that did not either. Simon McVittie: > I am *not* going to go looking for patches on display at the bottom of > a locked filing cabinet stuck in a disused lavatory with a sign on the > door saying "beware of the leopard"; > Luckily, you didn't need to. The page that I hyperlinked before pointed directly to Pierre-Yves Ritschard's and Cameron T. Norman's actual code, even down to positioning the window around the first lines of the functions. Now if one *did* want to follow the Debian way of having mention of these things buried down in the depths, in a bug report from years ago, then this is a truly excellent example of the genre that one could enjoy. One should begin with Cameron T. Norman's post here, roughly one thousand eight hundred messages down, in a bug report from 3 years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1859 (-: Simon McVittie: > To be brutally honest, there is a fairly low limit to how much benefit > I can create by giving new things to PC-BSD users, [...] > That's not the right way to look at it. You yourself have just said several times that this is stuff that is supposed to be on "supported Unix platforms". This isn't giving new things to anyone. This is making existing things, that you yourself think are existing, work. I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD (now rebranded as TrueOS Desktop a few days ago -- I just got through changing a whole load of preset file and -run package names.) is the BSD that comes in the box with the desktop environments and with all of the desktop programs that use Desktop Bus. Yes, people can and do run all of this stuff on FreeBSD and OpenBSD from ports. But PC-BSD^H^H^H^H^H^H ... Gah! ... TrueOS Desktop is where it comes in the box and is run as standard in the default install. TrueOS Desktop is where one ends up choosing from running PCDMd, kdm, lxdm, or gdm; and where one gets lots of little Desktop Bus brokers all over the place in various ways from these different systems. TrueOS Desktop is where the people who are behind the operating system will be strongly motivated towards improving the desktop subsystems and the Desktop Bus. You're pushing your new way of per-user Desktop Bus brokers at the world. I can give the TrueOS Desktop people, and the the UbuntuBSD people, and the Debian FreeBSD people, a service management system that I know can run per-user Desktop Bus brokers on a FreeBSD kernel. It already does. I published it last year. If you, the Desktop Bus people, can give us these mechanisms in your program actually working on these operating systems, then the TrueOS people get the opportunity to simplify some of the scaffolding that they have had to erect (PCDM-session writing out nonce scripts that invoke dbus-launch, for example), and you get less of the world still using your old way of doing things. From owner-freebsd-hackers@freebsd.org Mon Sep 5 16:54:21 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A575CB968A5 for ; Mon, 5 Sep 2016 16:54:21 +0000 (UTC) (envelope-from slitt@troubleshooters.com) Received: from troubleshooters.com (troubleshooters.com [69.5.27.237]) by mx1.freebsd.org (Postfix) with SMTP id 6F60BEC4 for ; Mon, 5 Sep 2016 16:54:20 +0000 (UTC) (envelope-from slitt@troubleshooters.com) Received: (qmail 10355 invoked from network); 5 Sep 2016 16:47:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; h=X-Originating-IP:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:Organization:X-Mailer:MIME-Version:Content-Type:Content-Transfer-Encoding; s=default; d=troubleshooters.com; b=O9O7N/VFZHLEoyfCkWK3PI+B5vpHPL2g8z6TSCjyJ6NEfzUkGR4634U25DGgXdZzhN6XvVPwhCxyVteW4Frmcmi4YDgZnkkSvqXrLcdrrUt4HokAihUepEomkpf5hT6gs3NUOElJEAi0lWDRugoQmv3dBHN4NGwHZ2zzhg2FwNY=; DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=troubleshooters.com; s=default; t=1473094058; bh=ZqUHcsnZI9EBQUTqKW3oBuE5f2s=; l=8888; h=X-Originating-IP:Date:From:To:Cc:Subject:Message-ID:In-Reply-To: References:Organization:X-Mailer:MIME-Version:Content-Type: Content-Transfer-Encoding; b=cfdJMAEfgsljkEeiLm556mUsk/oVF+w1kOWgJwgZtC3PAeN8S3jikYVHfm+0nYujC k22GBVqmiW6woL7tYe7Fr90vMtxoq8tMnM4R3KA2LsEROoYrBsxWBAJ20SK5N2jmoX 8eNvfipnGnpGdSCLaf16xrOIx7a3bsWuvMfqZHjw= X-Originating-IP: [72.188.235.106] Date: Mon, 5 Sep 2016 12:47:37 -0400 From: Steve Litt To: Jonathan de Boyne Pollard Cc: Joe Marcus Clarke , debian-devel@lists.debian.org, FreeBSD Hackers , "supervision@list.skarnet.org" , Antoine Jacoutot , dng Subject: Re: Mass bug filing: use and misuse of dbus-launch (dbus-x11) Message-ID: <20160905124737.47d1c473@mydesk.domain.cxm> In-Reply-To: References: <20160831104556.mihpyoi3lodnikmw@perpetual.pseudorandom.co.uk> Organization: Troubleshooters.Com X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 05 Sep 2016 18:13:15 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 16:54:21 -0000 On Sun, 4 Sep 2016 17:30:43 +0100 Jonathan de Boyne Pollard wrote: > Simon McVittie: > > > This can already work. If you put XDG_RUNTIME_DIR in user programs' > > environment, and arrange for your favourite service manager to make > > a dbus-daemon (or something else that speaks the same protocol) > > listen on $XDG_RUNTIME_DIR/bus before any user process would try to > > connect to it, then modern versions of at least libdbus, GDBus and > > sd-bus will connect to it by default with no additional effort on > > your part. This client-side code path does not depend on systemd, > > does not depend on libsystemd (except obviously sd-bus which is > > part of libsystemd), and is compiled in for all supported Unix > > platforms. > That's the problem. No the whole unix:runtime=yes mechanism is not. > As I said, this is something that you and Joe Marcus Clarke and > whomever else have to sort out with each other. I'm unfortunately > stuck in the middle, here. Please do whatever it is that you need to > do with each other to make your program understand address=systemd: > and address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD. It does not > do so. > > Simon McVittie: > > > Meanwhile, if you want the relevant integration files (your > > favourite service manager's equivalent of systemd units) to be part > > of dbus (the reference implementation of D-Bus), please propose > > tested patches; if they follow the "user session" model[1], they > > could eventually go in dbus-user-session.deb, with its dependencies > > changed from the current systemd-sysv to "systemd-sysv | > > your-service-manager". > Kudos for being the first project to offer integration, ever. (-: Danger Will Robinson. "Integration" in cases of systemd and its venus fly trap, dbus, is more Embrace, Extend, Extinguish than integration. The Rube Goldbergesque system described in the preceding quoted context exquisitely highlights that fact. Do not cooperate with systemd. The systemd proponents don't cooperate with anyone else. > Yes, down the road it would be marvellous if people included service > bundles in their own projects. What would be marvellous is if people would simply ignore systemd, opting for a real init system (not a conglomeration of welded krap trying to supercede what we've had for years). > Yes, I'd like to see the day when the > number of service bundles in the nosh-bundles package actually starts > going down, because people are taking on shipping their own service > bundles for their own services, instead of going up. So yes, > eventually you'll be taken up on that offer I hope. But one step at a > time. Ooohhhh, "service bundles." My runit run scripts average about 6 lines long. Any fool can make them. Behold the power of a real init: An init that knows it's an init, and does only what inits are designed to do. I highlight runit out of familiarity, but my use of s6 and Epoch indicate that both are equally as simple, when defining service startup, runit. > > Simon McVittie: > > >> As for what I would like, I'd like you (where that's plural, > >> including Joe Marcus Clarke or whomever else) to please make > >> either address=systemd: or address=unix:runtime=yes work in your > >> program on FreeBSD/PC-BSD/OpenBSD. > >> > > To the best of my knowledge, the listenable address > > "unix:runtime=yes" (as in "dbus-daemon --address=unix:runtime=yes") > > does work on generic Unix, and should interoperate fine with the > > XDG_RUNTIME_DIR/bus fallback used by clients with no > > DBUS_SESSION_BUS_ADDRESS. It is compiled and tested whenever > > DBUS_UNIX is defined (i.e. everything except Windows), and I > > haven't seen bug reports about that test failing. > There you go, then. New knowledge. (-: It doesn't work with your > program as ported to FreeBSD/TrueOS/OpenBSD. Joe Marcus Clarke is > the porter for FreeBSD, according to the port information, and > Antoine Jacoutot the porter for OpenBSD. To the *BSD communities: Please do not let the systemd camel get his nose in your tent. Systemd is a repudiation of everything Unix, created by a guy who makes no bones of his hate for Posix. > This is why I am saying > that it's something that you (plural, remember) need to sort out > amongst yourselves. We users stuck in the middle cannot use > address=systemd: and address=unix:runtime=yes with your program on > these systems. As I said, it's something that I had to fix in > November 2015, to stop trying to use address=systemd: on > FreeBSD/TrueOS because it turned out that it didn't actually work. I > thought that address=unix:runtime=yes might, but that did not either. > [snip] > > Simon McVittie: > > > To be brutally honest, there is a fairly low limit to how much > > benefit I can create by giving new things to PC-BSD users, [...] > > > That's not the right way to look at it. This is precisely the right way to look at it, when it pertains to systemd. > You yourself have just said > several times that this is stuff that is supposed to be on "supported > Unix platforms". This isn't giving new things to anyone. This is > making existing things, that you yourself think are existing, work. If these existing things can't be made to work without systemd incorporation, they should be torn out and replaced. Encumbering a good system with systemd is not the answer. > > I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD > (now rebranded as TrueOS Desktop a few days ago -- I just got through > changing a whole load of preset file and -run package names.) is the > BSD that comes in the box with the desktop environments and with all > of the desktop programs that use Desktop Bus. Yes, people can and do > run all of this stuff on FreeBSD and OpenBSD from ports. But > PC-BSD^H^H^H^H^H^H ... Gah! ... TrueOS Desktop is where it comes in > the box and is run as standard in the default install. TrueOS > Desktop is where one ends up choosing from running PCDMd, kdm, lxdm, > or gdm; and where one gets lots of little Desktop Bus brokers all > over the place in various ways from these different systems. TrueOS > Desktop is where the people who are behind the operating system will > be strongly motivated towards improving the desktop subsystems and > the Desktop Bus. To those who care about simplicity and user-maintainable software, the preceding paragraph appears to be one possible strategy to continue eliminating non-systemd choices. Beware. > > You're pushing your new way of per-user Desktop Bus brokers at the > world. I can give the TrueOS Desktop people, and the the UbuntuBSD > people, and the Debian FreeBSD people, a service management system > that I know can run per-user Desktop Bus brokers on a FreeBSD > kernel. It already does. I published it last year. If you, the > Desktop Bus people, can give us these mechanisms in your program > actually working on these operating systems, then the TrueOS people > get the opportunity to simplify some of the scaffolding that they > have had to erect (PCDM-session writing out nonce scripts that invoke > dbus-launch, for example), and you get less of the world still using > your old way of doing things. LOL, per-user desktops. There must be a zillion different ways to have sterminal hung off a Linux box each get their own GUI. I'd do it myself, except that's not my itch. In a world where a COTS desktop is $600 USD, laptop $500 USD, and used but still perfectly functional computers can be had for $50-$200, hanging terminals makes little economic sense. I'm sure the systemd afficianados will find such a use case, and proclaim that use case must be served, but we all know it's FUD. The systemd folks shout from the mountaintops that sysvinit is 32 years old or whatever, and how that alone is enough reason to use systemd, and yet these same monuments to modern software proclaim their multiseat, terminal-enabling technology is a reason to switch to systemd, even though terminals had their heyday in 1984. Talk about greybeards. One more thing: They talk about dbus as if it's a good thing. Even before systemd, I tried to stay away from a bus system that was pretty much like a traffic circle enabling everything to talk to everything else, addressing allowing. What could *possibly* go wrong? The subject of this thread is "Mass bug filing: use and misuse of dbus-launch (dbus-x11)". If you're a software user, use dbus as little as possible. If you're a developer, find other communication methods, and don't incorporate dbus. Because, as evidenced by this thread, dbus is now just a pretty entry point to systemd. SteveT Steve Litt From owner-freebsd-hackers@freebsd.org Wed Sep 7 10:42:01 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62D30BCFDC9; Wed, 7 Sep 2016 10:42:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4CC67698; Wed, 7 Sep 2016 10:41:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA29124; Wed, 07 Sep 2016 13:41:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bhaIn-000MVm-Bc; Wed, 07 Sep 2016 13:41:57 +0300 To: freebsd-hackers , FreeBSD Current From: Andriy Gapon Subject: kldload intpm Message-ID: <9db20b27-254f-b0a5-8f6c-f1eeaadf7829@FreeBSD.org> Date: Wed, 7 Sep 2016 13:40:56 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 10:42:01 -0000 Has kldload intpm ever worked? Ditto for other smbus drivers. The reason I am asking is that it doesn't work for me on the latest head. And it doesn't work because device_probe_and_attach(sc->smbus) fails in intsmb_attach(). With a little help from DTrace I obtained the following output: CPU ID FUNCTION:NAME 0 41924 devclass_add_driver:entry devclass = 0xfffff8000675b700, name = pci, driver = 0xffffffff832ed058, name = intsmb 0 32121 device_probe_child:entry parent = 0xfffff8000af78100, nameunit = intsmb0, devclass = 0xfffff8001d955880, name = intsmb, driver = 0x0, name = child = 0xfffff8001d933500, nameunit = smbus1, devclass = 0xfffff8001d955780, name = smbus kernel`device_probe+0x9d kernel`device_probe_and_attach+0x2e intpm.ko`intsmb_attach+0x651 kernel`device_attach+0x41d kernel`pci_driver_added+0xed kernel`devclass_driver_added+0x7d kernel`devclass_add_driver+0x144 kernel`module_register_init+0xb0 kernel`linker_load_module+0xc88 kernel`kern_kldload+0xa7 kernel`sys_kldload+0x5b kernel`amd64_syscall+0x2db kernel`0xffffffff80e918ab 1 41924 devclass_add_driver:entry devclass = 0xfffff8001d955880, name = intsmb, driver = 0xffffffff832ee930, name = smbus My interpretation is that intsmb_attach() is called before the smbus driver is associated with the intsmb devclass. That means that the devclass does not have any drivers at all when intsmb_attach() calls device_probe_and_attach() on its smbus child. It's too late when the smbus driver is added to the intsmb devclass. Okay, writing the above gave me an idea to try to change the order of DRIVER_MODULE() lines in intpm.c and that fixed the problem. But I seem to recall that some years ago kldload intpm worked without the change. Perhaps the order has changed in the module loading code. Anyway, this seems to be very subtle and error prone. I wonder if we could make it more robust. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Wed Sep 7 17:49:42 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C319BD0E37; Wed, 7 Sep 2016 17:49:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6C56C6B5; Wed, 7 Sep 2016 17:49:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 6D10210AF43; Wed, 7 Sep 2016 13:49:40 -0400 (EDT) From: John Baldwin To: Andriy Gapon Cc: freebsd-hackers , FreeBSD Current Subject: Re: kldload intpm Date: Wed, 07 Sep 2016 10:49:33 -0700 Message-ID: <16067820.jTuOsBSZ6N@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: <9db20b27-254f-b0a5-8f6c-f1eeaadf7829@FreeBSD.org> References: <9db20b27-254f-b0a5-8f6c-f1eeaadf7829@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 07 Sep 2016 13:49:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 17:49:42 -0000 On Wednesday, September 07, 2016 01:40:56 PM Andriy Gapon wrote: > > Has kldload intpm ever worked? > Ditto for other smbus drivers. > > The reason I am asking is that it doesn't work for me on the latest head. > And it doesn't work because device_probe_and_attach(sc->smbus) fails in > intsmb_attach(). > > With a little help from DTrace I obtained the following output: > CPU ID FUNCTION:NAME > 0 41924 devclass_add_driver:entry devclass = 0xfffff8000675b700, name > = pci, driver = 0xffffffff832ed058, name = intsmb > > 0 32121 device_probe_child:entry > parent = 0xfffff8000af78100, nameunit = intsmb0, devclass = 0xfffff8001d955880, > name = intsmb, driver = 0x0, name = > child = 0xfffff8001d933500, nameunit = smbus1, devclass = 0xfffff8001d955780, > name = smbus > > kernel`device_probe+0x9d > kernel`device_probe_and_attach+0x2e > intpm.ko`intsmb_attach+0x651 > kernel`device_attach+0x41d > kernel`pci_driver_added+0xed > kernel`devclass_driver_added+0x7d > kernel`devclass_add_driver+0x144 > kernel`module_register_init+0xb0 > kernel`linker_load_module+0xc88 > kernel`kern_kldload+0xa7 > kernel`sys_kldload+0x5b > kernel`amd64_syscall+0x2db > kernel`0xffffffff80e918ab > > 1 41924 devclass_add_driver:entry devclass = 0xfffff8001d955880, name > = intsmb, driver = 0xffffffff832ee930, name = smbus > > My interpretation is that intsmb_attach() is called before the smbus driver is > associated with the intsmb devclass. That means that the devclass does not have > any drivers at all when intsmb_attach() calls device_probe_and_attach() on its > smbus child. It's too late when the smbus driver is added to the intsmb devclass. > > Okay, writing the above gave me an idea to try to change the order of > DRIVER_MODULE() lines in intpm.c and that fixed the problem. > > But I seem to recall that some years ago kldload intpm worked without the > change. Perhaps the order has changed in the module loading code. > Anyway, this seems to be very subtle and error prone. I wonder if we could make > it more robust. You can request a specific ordering via DRIVER_MODULE_ORDERED (you can specify the SI_ORDER to use as an extra argument). The typical practice is to load the "base" driver (the one that attaches highest up the device hierarchy) "last" so that all other drivers are registered once it tries to attach. For example, in xl(4) this is used to to have the PCI attachment register last so that the miibus driver is registered when xl0 attaches: DRIVER_MODULE_ORDERED(xl, pci, xl_driver, xl_devclass, NULL, NULL, SI_ORDER_ANY); DRIVER_MODULE(miibus, xl, miibus_driver, miibus_devclass, NULL, NULL); DRIVER_MODULE() uses SI_ORDER_MIDDLE by default. This probably needs to be fixed in all of the smbus controller drivers. -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Sep 7 23:18:16 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D737BD0336; Wed, 7 Sep 2016 23:18:16 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8409363; Wed, 7 Sep 2016 23:18:15 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190c-d97ff700000032e7-c4-57d09f01e176 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 50.DD.13031.10F90D75; Wed, 7 Sep 2016 19:13:06 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u87ND53F022820; Wed, 7 Sep 2016 19:13:05 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u87ND2d2006020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Sep 2016 19:13:05 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u87ND2VK007425; Wed, 7 Sep 2016 19:13:02 -0400 (EDT) Date: Wed, 7 Sep 2016 19:13:02 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: Call for 2016Q3 quarterly status reports Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixG6noss0/0K4wen1ohZz3nxgsti++R+j A5PHjE/zWQIYo7hsUlJzMstSi/TtErgyLv12L7jMVfFhqXwD4zuOLkZODgkBE4l1/5YzdzFy cQgJtDFJnD25B8rZwChx//MHVgjnIJNE++XZ7CAtQgL1Ej1fWoGqODhYBLQk/k5KBQmzCahJ rF9xjRliqqLE5lOTwGwRAXmJfU3vwVqZgewtqyezgdjCAoYS18+dYAGxeQUcJDa9+wAWFxXQ kVi9fwpUXFDi5MwnLBC9WhLLp29jmcDIPwtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5 qUW6hnq5mSV6qSmlmxhBocYpybOD8cwbr0OMAhyMSjy8HNIXwoVYE8uKK3MPMUpyMCmJ8voU A4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8G6aCZTjTUmsrEotyodJSXOwKInzds04EC4kkJ5Y kpqdmlqQWgSTleHgUJLgZZ0H1ChYlJqeWpGWmVOCkGbi4AQZzgM0/N9ckOHFBYm5xZnpEPlT jIpS4ryf5gAlBEASGaV5cL3gVLCbSfUVozjQK8K8yiAreIBpBK77FdBgJqDBQqfOgwwuSURI STUwbnt55cI7qd29K8QPCf6T+ZZ/bAaXZUbP7UUa52qif9W80pJldJd5e2rT8WKvNmWuFpU6 34JtoiqTVbpPsa7lrSqt1G1vufZvX5Ll6+fTbvz6uLxnn/uzX39FWo56tx+T7JS8y/RFhjdw TuovtmklDWpPuWJd8qpOePT3XTrY9JM3KkLQaYuQEktxRqKhFnNRcSIAUNiXQeACAAA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 23:18:16 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is October 7, 2016, for work done in July through September. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly at FreeBSD.org . There is also an XML template [2] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We are looking forward to all of your 2016Q3 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2016-01-2016-03.html [4] https://www.FreeBSD.org/news/status/report-2016-04-2016-06.html From owner-freebsd-hackers@freebsd.org Thu Sep 8 10:02:50 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12015BD1295; Thu, 8 Sep 2016 10:02:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9C1E99; Thu, 8 Sep 2016 10:02:48 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA03554; Thu, 08 Sep 2016 13:02:47 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bhwAR-000NjG-DK; Thu, 08 Sep 2016 13:02:47 +0300 Subject: Re: kldload intpm To: John Baldwin References: <9db20b27-254f-b0a5-8f6c-f1eeaadf7829@FreeBSD.org> <16067820.jTuOsBSZ6N@ralph.baldwin.cx> Cc: freebsd-hackers , FreeBSD Current From: Andriy Gapon Message-ID: <8bb32155-0365-bcd4-d487-b1932b34fb6f@FreeBSD.org> Date: Thu, 8 Sep 2016 13:01:26 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <16067820.jTuOsBSZ6N@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 10:02:50 -0000 On 07/09/2016 20:49, John Baldwin wrote: > You can request a specific ordering via DRIVER_MODULE_ORDERED (you can specify the > SI_ORDER to use as an extra argument). The typical practice is to load the "base" > driver (the one that attaches highest up the device hierarchy) "last" so that all > other drivers are registered once it tries to attach. For example, in xl(4) this > is used to to have the PCI attachment register last so that the miibus driver is > registered when xl0 attaches: > > DRIVER_MODULE_ORDERED(xl, pci, xl_driver, xl_devclass, NULL, NULL, > SI_ORDER_ANY); > DRIVER_MODULE(miibus, xl, miibus_driver, miibus_devclass, NULL, NULL); > > DRIVER_MODULE() uses SI_ORDER_MIDDLE by default. > > This probably needs to be fixed in all of the smbus controller drivers. Thank you for the advice. I'm going to fix intpm. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Fri Sep 9 16:06:24 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B55EBD2415 for ; Fri, 9 Sep 2016 16:06:24 +0000 (UTC) (envelope-from alexandre.martins@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21AE2A44 for ; Fri, 9 Sep 2016 16:06:22 +0000 (UTC) (envelope-from alexandre.martins@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 749EB37603FB for ; Fri, 9 Sep 2016 18:04:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 66F2637604D4 for ; Fri, 9 Sep 2016 18:04:18 +0200 (CEST) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ym07vZ-PNNCn for ; Fri, 9 Sep 2016 18:04:18 +0200 (CEST) Received: from pc-alex.localnet (fwlabo.stormshield.eu [10.2.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 4785B37603FB for ; Fri, 9 Sep 2016 18:04:18 +0200 (CEST) From: Alexandre Martins To: "freebsd-hackers@freebsd.org" Subject: Compillation issue on armv6 with GCC 5.4 Date: Fri, 09 Sep 2016 18:06:16 +0200 Message-ID: <70164921.hECqgmmyGd@pc-alex> Organization: NETASQ User-Agent: KMail/4.14.3 (FreeBSD/10.2-RELEASE; KDE/4.14.3; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1491071.o8fiXrMiiC"; micalg="sha256"; protocol="application/pkcs7-signature" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 16:06:24 -0000 --nextPart1491071.o8fiXrMiiC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi, I'm currently facing an annoying problem when compiling a STATIC binary= with gcc5 on ARM architecture, with FreeBSD 10.3. The problem is some of the softfloat symbols are coming from two source= s: - The libc (/usr/lib/libc.a) - The libgcc (/usr/local/lib/gcc5/gcc/armv6-portbld-freebsd10.2/5.4.0/= libgcc.a) The firsts duplicated symbols that the linker complain are "__subdf3" ,= "__adddf3", "__floatsidf", "__extendsfdf2", ... I don't know how to fix that or, perhaps, use a workaround. Can you help me ? Best regards, =2D-=20 Alexandre Martins --nextPart1491071.o8fiXrMiiC Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCOUw ggSGMIICbqADAgECAgUA28zw7TANBgkqhkiG9w0BAQsFADBIMQswCQYDVQQGEwJGUjEUMBIGA1UE CgwLU1RPUk1TSElFTEQxIzAhBgNVBAMMGlN0b3Jtc2hpZWxkIFJvb3QgQXV0aG9yaXR5MB4XDTE0 MDkwNDE1MDcxMFoXDTI0MDkwMTE1MDcxMFowSTELMAkGA1UEBhMCRlIxFDASBgNVBAoMC1NUT1JN U0hJRUxEMSQwIgYDVQQDDBtTdG9ybXNoaWVsZCBVc2VycyBBdXRob3JpdHkwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDChwWgC/6VWKL7jgWI3eA2sVvRdOwuHcXsRAAXVWdlMC0ygg7u 45E78GhAnpdl8QbIu7x/Q2zOq6KttspwDEIjkoMLTZngLLlGjYJZPfuSoC6hl9R7vRd5f8Fhu3v0 xQ/7vzKYz4C836IGCrk31gmrPO0H0fxkyxCMfhoTTzue3oXW1IsmQwCrOPOu2Y82QANDhbifWLjI WJetnj58YRKR82KBs3Flbqxtp0mi9+IswMvCCRSoT+ORB73Cl6URt7Qm7BcD+qnkJ9uwlUC94dIl T2hX4ybY/w/ssA17Ew418fgyRCWQXzgjZgZ/XUcw2WP9dIggA7Pg+c/xeROJH1zvAgMBAAGjdjB0 MB0GA1UdDgQWBBShbYRsooCFBXx8dXWANMETW5fXgTAfBgNVHSMEGDAWgBS4Qqn6Z0Twf9NhjOyl x1CutL3sozAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjARBglghkgBhvhCAQEEBAMC AQYwDQYJKoZIhvcNAQELBQADggIBAE6C9zkt2J6dPm2KLbzRS6rBIYZNFi0X59g3ekQ2Sc4UWsq+ B3L86j5xnQSRnIM/DKV1+Q2UHbU/qsh4cto2fwTV6V+aJ07Vu/bJE1rAN4AI4V26ytf7VoBcBjVZ Jq8pHOMp/G2eQH7F1xqzml68DpKku66aUalkcC9IM82m7AW3YAyvDoYEAchv4qyL8qhVLLp6LNru 8ZOhMELhZLWl4ulw/SFDMhcBS6I4wC6icj71MLGSrr61vMktMdwQ+CGFQ5z5JbaxM61VgzKay8+g lw+xTbpnitrDfhkzHs2fdwOOur3vtNnNsrdBWiYPseJ2k4VGD7ov5kITQZckmZyF/V+Ir//agJQG VuwhDZCXgXOvrje+FLYp7tQ9pgSvLbluh1A+ywfyHnFI4n6tZy9SD3MIDgWR4KwFLM1Qmt3NQb32 tkq9Vm0jUcQXFfbnWKLA9krw3m8NmCqhL5PzpfOegYOc0QJWfMQamxeWxXMLk6uKisS//+VqfpCa 5Jx53t+9DmoN1+ob4jOprPaX6tfBBr5djah2yzPGjHEB52VgWXxIF9lCM2z7Qw+zFb2PIdNeSjIk NEFg/1orKAAa5gQXAQynN2J7E+aLf2XLhHcS0v+9yoisPEw9+Tb5F1uQh+gzYD5JUUYcYWncnX8g P8k6X+F5mQ/81IoNL/IejxJgy/LoMIIEVzCCAz+gAwIBAgIFAIUoy7swDQYJKoZIhvcNAQELBQAw STELMAkGA1UEBhMCRlIxFDASBgNVBAoMC1NUT1JNU0hJRUxEMSQwIgYDVQQDDBtTdG9ybXNoaWVs ZCBVc2VycyBBdXRob3JpdHkwHhcNMTYwOTAxMTUxMTA4WhcNMTcwOTAxMTUxMTA4WjBwMQswCQYD VQQGEwJGUjEUMBIGA1UECgwLU1RPUk1TSElFTEQxGjAYBgNVBAMMEUFsZXhhbmRyZSBNQVJUSU5T MS8wLQYJKoZIhvcNAQkBFiBhbGV4YW5kcmUubWFydGluc0BzdG9ybXNoaWVsZC5ldTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMN+CnvE13jKEwJ+OyMzwBpC02dY+LpD5luJwnJTVnV2 9aUjEMI+xGFMMHd9kSIVInbk4WDe1ELOKerg0dzgnkRiOHECSGum1UhcZABxQgY2cmSffNQ6JVro 52UaBlt3aTOk3imYJCHUIGgOWMvOtRc8BxyBHdi15FZPj/F9I+AKufRFsBXUakplFIAPEwy3m2eR a/eCMLqGJUyK7YmsAlEnYn2mA38zIoqtKvL6KPHtrV8fw1SRLQ13+j9nu1LlCaqhmLtILFxhV0/9 uDTvx5cKtZ8Xj1nPM6NUUrso9qlXwm4On6Y34pVTtnYGMQRuljil3Hiz84RJjPDJYRGwbgkCAwEA AaOCAR0wggEZMB0GA1UdDgQWBBTmRLIwSfhNwbdfV13xt0G0JHYjPDAfBgNVHSMEGDAWgBShbYRs ooCFBXx8dXWANMETW5fXgTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwID6DARBglghkgBhvhCAQEE BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0 dHBzOi8vcGtpLm5ldGFzcS5jb20vYXV0aC9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0LmNybDAR BgNVHSAECjAIMAYGBFUdIAAwKwYDVR0RBCQwIoEgYWxleGFuZHJlLm1hcnRpbnNAc3Rvcm1zaGll bGQuZXUwDQYJKoZIhvcNAQELBQADggEBALT9NWiAaE6nDev34vShhsyb9lWBOQfCnAMyKwtFy/cU uIoHsxyOanIIQHz0ZtB76GCHDo7RStMyp6RYIefIsxABLhSr4hHapJka9g/X/nxexyr0xyT3IpYQ dmyMSHRT18Z/ZaBlQdyfnS2PYkPHJAHl4iqB4SnQlh3rwFdKTJMgCz413cDxQHytgRPGTiXOhyV7 aS3ANJFha6ZHA8HU9sTslY8ZXSUu94iD3t2kcF3gBb432UKALwryKqnrwzFX68pFpqO5QAjEHaF6 6p1agMb2b3HlQGZrME5wSO6rsZJPYvJEyvrwHxCxjSTkOdPw6GriWGTMrVMU0fVrfptMS1gxggIT MIICDwIBATBSMEkxCzAJBgNVBAYTAkZSMRQwEgYDVQQKDAtTVE9STVNISUVMRDEkMCIGA1UEAwwb U3Rvcm1zaGllbGQgVXNlcnMgQXV0aG9yaXR5AgUAhSjLuzANBglghkgBZQMEAgEFAKCBkzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MDkxNjA2MTZaMCgGCSqG SIb3DQEJDzEbMBkwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMC8GCSqGSIb3DQEJBDEiBCDIg9Wv fyfnOCDHZJoXJvLRF61CLdkiq5pVmEo2sHkufTANBgkqhkiG9w0BAQEFAASCAQCuOB6SfoTpqYe7 mtMFhFFkIAcVtgoaP9/r2FpN3xyAwHrLqjHGU9RBLd7fs0I4T2J2r1SxnCK1jD87Aih7lr03G8zm qeRpMsjJZ4rlX+ELRNvTCNAFvTR2n6FsVS7e4XyWeRsFynuhpVkXzU5KAezSTjLZl0yngNcugIdH zGzhz8pKAbDo9S00C+iNTnIw8HbF6RHJxQt7sOK59vL+To8snzD6os7R31aAU4Auq0R387/GPlW2 CRANupq1pjbaBZmWt1y7mOjmxZJqzsBSaHjyDN0sc5oq70v0yXjdtI/Qn9B4cKQE54457mTkSbdz UrS6PGjlaSA/63R9Aab6+7tPAAAAAAAA --nextPart1491071.o8fiXrMiiC--