Ahh that's good to know. Adding that archive got me further, but there are
some other gnarly-looking problems I'm hitting now.
Trying to install libudev-dev:arm64 now gives me:
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you
arm64 is on a different archive in Ubuntu. You'll need to add
deb [arch=arm64] http://ports.ubuntu.com/ xenial main universe
to your /etc/apt/sources.list
After an "apt update", libudev-dev:arm64 should be available.
2018-07-04 21:42 GMT+02:00 Kevin Greene :
> Thanks Simon. I have tried doing
I can install the x86_64 package just fine. But when I try to install the
arm64 package for cross-compiling on my x86_64 machine, I get the errors
above.
2018-07-04 13:32 GMT-07:00 Cristian Rodríguez :
>
>
> El 04-07-2018 a las 15:42, Kevin Greene escribió:
>
>> Thanks Simon. I have tried doing
El 04-07-2018 a las 15:42, Kevin Greene escribió:
Thanks Simon. I have tried doing that actually, but the arm64 version
doesn't seem to be available. I'm on Ubuntu 16.04 fwiw.
Are you entirely sure that's the case?.. I mean.. you do not go very far
without libudev-dev in a modern binary
Thanks Simon. I have tried doing that actually, but the arm64 version
doesn't seem to be available. I'm on Ubuntu 16.04 fwiw.
Here's the output I get from trying to install it:
$ sudo apt-get install libudev-dev:arm64
[sudo] password for kevin:
Reading package lists... Done
Building
On Wed, 04 Jul 2018 at 11:36:23 -0700, Kevin Greene wrote:
> 2018-07-03 18:18 GMT-07:00 Mike Gilbert :
> Why not just install the libudev-dev package on a Ubuntu dev
> system/chroot? That would be much simpler than building libudev from
> scratch, and would ensure you build against the
2018-07-03 18:18 GMT-07:00 Mike Gilbert :
> On Tue, Jul 3, 2018 at 7:55 PM, Kevin Greene wrote:
> > I am building libusb, and I want to build it with udev support. I don't
> need
> > to build anything in systemd except udev. Is there a good way to do that?
> >
> > I'm deploying to machines
On Mi, 04.07.18 13:03, Lennart Poettering (lenn...@poettering.net) wrote:
> I'll add a brief note about this to the NEWS file, since this might be
> something other folks using network-facing NSS modules might run into.
>
> It might be worth finding a way to turn off nss-resolve automatically
>
On Mi, 04.07.18 14:50, Mantas Mikulėnas (graw...@gmail.com) wrote:
> (I think glibc's nscd should also not be forgotten, since it offloads *all*
> modules into a single caching daemon. Would have protected against last
> year's glibc libnss_dns CVE, I'm sure.)
glibc's nscd is not really useful
On Mi, 04.07.18 14:05, Vlad (vo...@vovan.nl) wrote:
> Lennart,
>
> Thanks for all the information amd explanation! Below is all the details:
> - systemd-239
> - systemd-resolve as well ass all systemd related users are defined in
> /etc/passwd
> - nss_ldap is configured via
On Wed, Jul 4, 2018 at 3:22 PM Vlad wrote:
> Mantas,
>
> I'm aware of all the software you mentioned, but there's a few things to
> consider:
> - nslcd is quite old and personally I don't think it's the way to go
>
Well, the original nss_ldap is also quite old, and we don't think it's the
way
Mantas,
I'm aware of all the software you mentioned, but there's a few things to
consider:
- nslcd is quite old and personally I don't think it's the way to go
- the glibc's nscd wouldn't help in this case and will bring just
troubles (based as well on my experiences). More and more admins (since
Lennart,
Thanks for all the information amd explanation! Below is all the details:
- systemd-239
- systemd-resolve as well ass all systemd related users are defined in
/etc/passwd
- nss_ldap is configured via nss_initgroups_ignoreusers to not lookup
groups fro all system related users include all
On Wed, Jul 4, 2018 at 2:03 PM Lennart Poettering
wrote:
> I am pretty sure it's not the best design today that nss-ldap inserts
> a complex, network facing piece of code into all kinds of system
> processes the way it does, even the most benign ones such as
> "ls". This is security sensitive
Lets see if I have understood the process:
1. The display manager shall start the specific
"[desktop]-session.target", by running "systemctl --user start
[desktop]-session.target"
2. "[desktop]-session.target" shall start "graphical-session.target", by
containing
On Di, 03.07.18 22:16, Vlad (vo...@vovan.nl) wrote:
> Hello,
>
> It looks like the combination of systemd-resolved service for DNS name
> resolution with nss_ldap hangs the system during boot. Particularly the
> following configuration in nsswitch.conf leads to boot problem:
Which systemd
On Mi, 04.07.18 11:24, Dimitri John Ledkov (x...@ubuntu.com) wrote:
> Hi,
>
> On 4 July 2018 at 10:22, Lennart Poettering wrote:
> > On Mi, 04.07.18 07:24, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de)
> > wrote:
> >
> >> Dear systemd folks,
> >>
> >>
> >> Debian uses a shell script as
Dear Dimitri,
Am 04.07.2018 um 12:24 schrieb Dimitri John Ledkov:
On 4 July 2018 at 10:22, Lennart Poettering wrote:
On Mi, 04.07.18 07:24, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:
Dear systemd folks,
Debian uses a shell script as `/init` in initrd, and I like to extend
Hi,
On 4 July 2018 at 10:22, Lennart Poettering wrote:
> On Mi, 04.07.18 07:24, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de)
> wrote:
>
>> Dear systemd folks,
>>
>>
>> Debian uses a shell script as `/init` in initrd, and I like to extend that,
>> to set the time stamps for the initrd
On Mi, 04.07.18 07:24, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:
> Dear systemd folks,
>
>
> Debian uses a shell script as `/init` in initrd, and I like to extend that,
> to set the time stamps for the initrd execution.
This is part of the data that is serialized during the
Hello Alberto,
Alberto Salvia Novella [2018-07-04 1:56 +0200]:
> Requested on:
> - gitlab.gnome.org/GNOME/gdm/issues/396
> - github.com/CanonicalLtd/lightdm/issues/29
> - github.com/sddm/sddm/issues/1044
> - bugs.freedesktop.org/show_bug.cgi?id=107107
These are invalid, please see my previous
21 matches
Mail list logo
