Re: [systemd-devel] taking time off
On 1/15/19 8:58 PM, Michael Biebl wrote: What's going on is just too stupid/crazy. This begs the question what you consider is too stupid/crazy? Is it something here upstream ( which could be improved upon )? Or is it something ( political? ) downstream in Debian? Or both? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] taking time off
Am Di, 15. Jan 2019, um 22:21, schrieb Vito Caputo: > On Tue, Jan 15, 2019 at 09:58:20PM +0100, Michael Biebl wrote: > > Will stop maintaining systemd in debian for a while. > > > > What's going on is just too stupid/crazy. > > > > Michael, as a long-time Debian user, I just wanted to say I appreciate > your work. I'm confident in saying it's no accident that I've been able > to largely ignore systemd on my Debian machines updated over the years. > > Thanks, > Vito Caputo I agree! Thanks for your support in the project! It is not unnoticed. Thanks Manuel Wagesreither ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn: access to disk devices does not work on centos 7/systemd 219
Hi, I'm quite new to systemd-nspawn, I configured a systemd container based on ubuntu bionic using debootstrap. I can start the container from a bionic host (systemd 237) with a command like this one systemd-nspawn -b -D bionic-devel --capability=CAP_SYS_TIME,CAP_SYS_RAWIO --bind=/dev/sda and inside the container I have read/write permissions on /dev/sda, for example cat /dev/sda works fine. If I start the same container from Arch Linux (systemd 240) it works the same way: /dev/sda is accessibile, but if I start this container from centos 7 (systemd 219) I cannot read /dev/sda cat /dev/sda cat: /dev/sda: Operation not permitted I tryed to disable selinux with no luck and I cannot see nothing relevant in the logs, can the problem be related to the old systemd version? Any idea on how to debug this issue? thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
Lennart Poettering on Tue, 2019/01/15 20:00:
> Note that we don't branch releases right now. Instead when we are
> getting closer to a release we simply don't merge PRs we don't
> consider appropriate for the release anymore until after the
> release. Or in other words: the master branch simply "stops" for a
> while getting new stuff, and only gets bugfixes until we release the
> version, which reopens the floodgates
Most people do not notice when this happens. Having milestones on github is
nice, but most of us miss that. Just make it obvious: add a tag when
you start preparation for a release - no matter if you call it 'v241-freeze',
'v241-rc' or whatever. I guess 'communication' on the lowest level can help a
lot here.
(BTW, there's another place I would like to see more tags... Would be nice to
have signed tags whenever a bunch of commits lands in a stable branch.)
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}
pgpqZRBDjeM2i.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: idea for a pstore systemd service
On 1/15/19 6:49 PM, Lennart Poettering wrote: On Di, 15.01.19 11:23, Eric DeVolder (eric.devol...@oracle.com) wrote: Systemd-devel, Below is a write-up I've done to explain a new service for archiving pstore contents. I've attached the pstore.service files (/lib/systemd/system/pstore.service and bin/pstore-tool). These are trivial right now, but easy to build upon if periodic, rather than just on-boot, examination of the pstore is desirable. If you look at the TODO list in our git tree, you'll find that importing and flushing pstore has been a long-time TODO list item for us. Hmm does it need to be another full blown coredump? Looking at his script this should suffice more or less for what he was trying to achive no? Create the tempfile pstore.conf with the following content d /var/lib/pstore 0755 root root - and place that file in /etc/tmpfiles.d/ Then create an path type unit - pstore.path with the following content [Unit] Description=Monitor the pstore directory for files. Documentation=https://www.kernel.org/doc/Documentation/ABI/testing/pstore [Path] PathModified=/sys/fs/pstore/ And place that file in the /etc/systemd/system directory Then create type service unit pstore.service with the following content [Unit] Description=Move pstore files to persistant storage Documentation=https://www.kernel.org/doc/Documentation/ABI/testing/pstore [Service] ExecStart=/bin/bash -c '/usr/bin/mv -t /var/lib/pstore /sys/fs/pstore/*' Restart=on-success And place that file in the /etc/systemd/system directory Then run systemctl daemon-reload and see if this suffices. Admins or whomever can then just do the cat to dmesg vodoo on the files in /var/lib/pstore if and then when they need it JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] taking time off
On Tue, Jan 15, 2019 at 09:58:20PM +0100, Michael Biebl wrote: > Will stop maintaining systemd in debian for a while. > > What's going on is just too stupid/crazy. > Michael, as a long-time Debian user, I just wanted to say I appreciate your work. I'm confident in saying it's no accident that I've been able to largely ignore systemd on my Debian machines updated over the years. Thanks, Vito Caputo ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] taking time off
Will stop maintaining systemd in debian for a while. What's going on is just too stupid/crazy. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Di, 15.01.19 10:36, Filipe Brandenburger (filbran...@google.com) wrote: > So I think all the bits already exist somewhere and perhaps a small > change in naming would go a long way to make these pushes smoother. > > If when we cut v240 from the master branch, we had called it v240-rc1 > instead, perhaps it was clear that it could take some more testing > before it was made official. > > Furthermore, fixes for the breakage were backported into the > v240-stable tree in systemd-stable repository, so perhaps calling the > top of that tree v240 (or v240.0) at some point would have been > helpful. Note that we don't branch releases right now. Instead when we are getting closer to a release we simply don't merge PRs we don't consider appropriate for the release anymore until after the release. Or in other words: the master branch simply "stops" for a while getting new stuff, and only gets bugfixes until we release the version, which reopens the floodgates (well, usually, but for v241 we'll be a bit more conservative, and open the floodgates on v242 instead). I am not convinced we should branch the new release, and let master continue get new stuff. This just makes us loose focus I think, as it means we'd in parallel allow new stuff in and do bugfixes, and I think we should focus on the latter before the release. (Of course, one can disagree with where we draw the line between "bugfix" and "new work", i.e. what kind of stuff we merge and what we don't, but that's a different question). > Having been pushing to systemd-stable this week (fixing one of the > CVEs in previous versions), I have to say that there's some impedance > to contributing to that tree, since I needed a separate fork (GitHub > doesn't want to let me do PRs from my main fork), sometimes it doesn't > build on the latest toolchain and libs (I'm working on fixing that > too), etc. Perhaps having some more of the distro maintainers actively > helping on those branches would be best. I think bringing those > branches into the main repo would help in those regards. Hmm, I'd really like to keep that separate I must say, so that I only see PR/issue notifications for the upstream branch, and not the stable one. I am not sure I grok the GitHub issues you are having? > As distros start to do heavier and broader testing of that > pre-release, we start fixing bugs at trunk, backport them to > release-v241 and after a week or so release v241-rc2. Rinse and > repeat. Well, but why do two branches for that? Why not just do all that in master? This is what we currently do: reduce what we merge that isn't a bugfix, and then open the floodgates again only after the release. In general, I think it's a good thing if we don't have unnecessarily many parallel versions in the wild. For example, you want that the version that is going to be released is also the version the upstream devs run. If you'd suddenly split that in two, then the upstream devs would immediately live in a different world than the "stabilized" version... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: idea for a pstore systemd service
On Di, 15.01.19 11:23, Eric DeVolder (eric.devol...@oracle.com) wrote: > Systemd-devel, > > Below is a write-up I've done to explain a new service for archiving pstore > contents. I've attached the pstore.service files > (/lib/systemd/system/pstore.service and bin/pstore-tool). These are trivial > right now, but easy to build upon if periodic, rather than just on-boot, > examination of the pstore is desirable. If you look at the TODO list in our git tree, you'll find that importing and flushing pstore has been a long-time TODO list item for us. Our original idea was to make this another input for the journal, but as I understand these days the pstore files are not necessarily in log format, hence maybe handling it similar to coredumps is an option too. i.e. drop it into some directory in /var like we do it for /var/lib/coredump/, and then link that up with the journal through some structured log message. So yeah, it appears to me that you have similar ideas there. And yes, we'd welcome such work. ACPI is generic and standard enough to make this generically useful, and the code for this is simple enough hence I think this sounds like something acceptable for our tree. That said, I wonder what else is generally found in pstore these days, besides the dmesg stuff? i.e. is there well-known other stuff, such as firmware stuff? > The questions I have for you are: > > - Is a new unit pstore.service the right approach for this? If not, what > unit do you recommend augmenting with these actions? Well, our own code is usually placed in service units whose name begins with "systemd-", hence systemd-pstore.service sounds more systematic. But yeah, by all means, please submit a proposal as PR. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
So I think all the bits already exist somewhere and perhaps a small change in naming would go a long way to make these pushes smoother. If when we cut v240 from the master branch, we had called it v240-rc1 instead, perhaps it was clear that it could take some more testing before it was made official. Furthermore, fixes for the breakage were backported into the v240-stable tree in systemd-stable repository, so perhaps calling the top of that tree v240 (or v240.0) at some point would have been helpful. Having been pushing to systemd-stable this week (fixing one of the CVEs in previous versions), I have to say that there's some impedance to contributing to that tree, since I needed a separate fork (GitHub doesn't want to let me do PRs from my main fork), sometimes it doesn't build on the latest toolchain and libs (I'm working on fixing that too), etc. Perhaps having some more of the distro maintainers actively helping on those branches would be best. I think bringing those branches into the main repo would help in those regards. Why don't we try something slightly different for the v241 timeline? At the time of the release, we actually create a new *branch* and call it release-v241. We also tag v241-rc1 at the start of that tree and announce the pre-release. (Note that this branch means no need for v241-stable in systemd-stable anymore, so it's not a branch which wouldn't have existed, it's only in a different place now.) As distros start to do heavier and broader testing of that pre-release, we start fixing bugs at trunk, backport them to release-v241 and after a week or so release v241-rc2. Rinse and repeat. After things are stable for a couple of weeks, we can finally just bump the version number, tag v241.0 and announce the final release. Hopefully everything will go very smooth. But, if it doesn't, we can still iterate on that and release v241.1. We can also release v241.2 to address the CVEs that come up a month later (just kidding, of course there won't be any!) >From a developer's point of view, this really doesn't look too painful compared with the current process. And distros will have an useful "almost ready" point where they have time to do one-time testing and start pushing to some users to collect feedback before the final "official" or "stable" release. What do you all think? Cheers, Filipe smime.p7s Description: S/MIME Cryptographic Signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] GithHub / private repos
When you create a new organization you can choose "Team For Open Source" plan. Here is the link https://github.com/account/organizations/new Though, I don't know if it's possible to upgrade the existing systemd organization, sorry. Maybe it's possible to contact github support to ask for this. -- Alex On Mon, Jan 14, 2019 at 7:19 PM Lennart Poettering wrote: > > On Fr, 11.01.19 13:57, Alex Dzyoba (a...@dzyoba.com) wrote: > > > Team plan with unlimited private repos and unlimited collaborators is free > > for open source teams. > > Where do we request that? > > Lennart > > -- > Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] RFC: idea for a pstore systemd service
Systemd-devel,
Below is a write-up I've done to explain a new service for archiving
pstore contents. I've attached the pstore.service files
(/lib/systemd/system/pstore.service and bin/pstore-tool). These are
trivial right now, but easy to build upon if periodic, rather than just
on-boot, examination of the pstore is desirable.
The questions I have for you are:
- Is a new unit pstore.service the right approach for this? If not, what
unit do you recommend augmenting with these actions?
- What are your thoughts/comments/feedback on such a service?
Thank you in advance for your time,
Eric
Oracle ERST usage
The BIOS ACPI error record serialization table, ERST, is an API for
storing data into non-volatile storage, such as hardware errors [1,
Section 18.5 Error Serialization]. The ERST non-volatile storage on
Oracle servers tends to be small, on the order of 64KiB.
The Linux persistent storage subsystem, pstore, supports using the ERST
as a backend for persistent storage [2].
The kernel, with the crash_kexec_post_notifiers command line option,
stores the dmesg into pstore on a panic [3]. This action is available
independent of kdump; as such, the crash backtrace is captured into
pstore for post mortem analysis, regardless of whether kdump is enabled
or working properly.
Since the ERST area is typically small, it is easily filled with the
contents of dmesg upon a kernel panic. As such, there is a need to
archive the contents of kernel dmesg items in the pstore to a normal
filesystem, and then free the dmesg items in the pstore in order to make
room for the dmesg of a subsequent kernel panic.
Therefore, this is a proposal for a new service, pstore.service, that
will archive the dmesg contents in the pstore to a regular filesystem,
and remove those dmesg entries from the pstore. Since Linux exposes the
persistent storage subsystem as a filesystem [2], and the items in the
pstore are available as regular files, this makes archiving and removal
of the entries trivial. This proposal is for a new service instead of
augmenting kdump.service since this is independent of kdump, though both
are related to a kernel crash. Conceivably other items that are stored
in pstore, like hardware errors, could have their own rules for
archiving. The goal of the pstore.service is to attempt to keep the
pstore empty and available for emergent events like hardware errors and
kernel crashes.
Initially the service could be as simple as looking for items upon boot,
but I could see it being extended to periodically check for events like
hardware errors in the pstore. Kernel crash dmesg items are named in a
regular fashion, such as:
-r--r--r-- 1 root root 17716 Nov 20 11:08 dmesg-erst-6625975467788730369
-r--r--r-- 1 root root 17731 Nov 20 11:08 dmesg-erst-6625975467788730370
-r--r--r-- 1 root root 17679 Nov 20 11:08 dmesg-erst-6625975467788730371
And a simple bit of filename manipulation can be used to create archive
sub-directories, say in /var/pstore, with the archived data.
[1] "Advanced Configuration and Power Interface Specification",
version 6.2, May 2017.
https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf
[2] "Persistent storage for a kernel's dying breath",
March 23, 2011.
https://lwn.net/Articles/434821/
[3] "The kernel’s command-line parameters",
https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
[Unit]
Description=pstore archive service
Wants=network-online.target local-fs.target remote-fs.target
After=network-online.target
[Service]
Type=oneshot
StandardOutput=syslog+console
#EnvironmentFile=/etc/default/kdump-tools
#ExecStart=/etc/init.d/pstore-tools start
#ExecStop=/etc/init.d/pstore-tools stop
ExecStart=/root/pstore-tool start
ExecStop=/root/pstore-tool stop
#RemainAfterExit=yes
RemainAfterExit=no
[Install]
#WantedBy=multi-user.target
WantedBy=local-fs.target
#!/bin/sh
# Utility script to archive contents of pstore
#-r--r--r--. 1 root root 1826 Dec 17 10:44 dmesg-efi-154506148323001
#-r--r--r--. 1 root root 1826 Dec 17 10:44 dmesg-efi-154506148324001
pstorefs=/sys/fs/pstore
archivedir=/var/pstore/`date +"%Y-%m-%d-%H:%M"`
pstore_start()
{
echo "PSTORE manager started wtf"
# Note: The -r is essential for dmesg reconstruction
files=`ls -r $pstorefs/dmesg-* 2>/dev/null`
if [ "$files" != "" ];
then
# Archive files
mkdir -p $archivedir
for f in $files;
do
# Reconstruct dmesg
cat $f >> $archivedir/dmesg.txt
mv -f $f $archivedir
done
fi
}
pstore_stop()
{
echo "PSTORE manager stopped"
}
while [[ $# -gt 0 ]]
do
case $1 in
start)
pstore_start
;;
stop)
pstore_stop
;;
*)
echo "pstore-tool: unrecognized option: $1"
;;
esac
shift # on to next argument
done
Re: [systemd-devel] Calling sd_bus_reply_method_return outside method handler
Thank you for your explanation, Lenart. I tried different approach.
Everything is running on a single thread. I have a global
`sd_bus_message* test` variable. I do the following
int method_handler(sd_bus_message* m, void* /*userdata*/,
sd_bus_error* /*error*/) {
test = sd_bus_message_ref(m);
return 0;
}
And create an object with
static const sd_bus_vtable vtable[] = {
SD_BUS_VTABLE_START(0),
SD_BUS_PROPERTY("Description", "s", property_handler, 0,
SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_METHOD("Do", "s", "s", method_handler, SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_VTABLE_END
};
r = sd_bus_add_object_vtable(
bus_,
nullptr,
path,
interface,
vtable,
nullptr
);
Connect to bus, request service name and start waiting for incoming messages
sd_bus_open_user(_);
sd_bus_request_name(bus_, service_name_, 0);
while(true){
sd_bus_process(bus_, NULL);
if (r > 0) {
continue;
}
if (test) {
int r = sd_bus_message_get_errno(test);
if(!r) {
const char* reply = "reply";
r = sd_bus_reply_method_return(test, "s", reply);
}else {
std::cout << "Error\n";
}
sd_bus_message_unref(test);
test = nullptr;
}
r = sd_bus_wait(bus_, 1e+6);
}
sd_bus_reply_method_return(test, "s", reply) doesn't do anything if
called outside method_handler.
I think that the call that is responsible for invoking method_handler
sends an error back to the client when method_handler returns.
Hence the connection to client is actually closed when I call
sd_bus_reply_method_return(test, "s", reply).
In that case I suppose sd_bus_message_get_errno should return an error
but it doesn't.
I'm using mailinglist for the first time so I'm not sure it that OK to
post code here. Hope it will show correctly in your email client.
On Tue, 15 Jan 2019 at 15:05, Lennart Poettering wrote:
>
> On Mo, 14.01.19 21:07, Jean Valjean (valjean.jean1...@gmail.com) wrote:
>
> > I want to send a reply to a method call outside method_handler. Is it
> > possible?
> > In the method_handler I increase reference count of sd_bus_message and send
> > it to the other thread. From there I want to call
> > sd_bus_reply_method_return to send a reply but get Unknown method or
> > interface error when I invoke method with bussctl --user call. If I call
> > the return method from method_handler everything works as expected.
>
> Note that sd-bus is not thread-safe on its own. It's threads-aware
> however: if you are careful to lock around all invocations of sd_bus
> using a single connection (and its associated messages) is generally
> fine, but it's up to you to carefully lock.
>
> So yeah, it's certainly OK to reply to an incoming bus call msgs
> outside of the stack method handler stack frame, but if that means
> threads, then make sure you know what you are doing.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] planned v241 release
Hi everyone, 241 will be released soon. Current list of outstanding tickets [1]: "23 wireguard peers hang systemd-networkd" #11404 opened 3 days ago by darkk network: wait for kernel to reply ipv6 peer address #11428 (needs review) "Bump numbers for v241" #11387 (release mechanics) "Add 'udevadm control --ping'" #11349 I'm haven't looked at this one in a while, but since it was a solution for the udev problems that got solved in the meantime in a different way, I think it may be postponed for v242. "systemd-240 fails to mount squashfs again, waiting for loop0 till timeout bug bug pid1" #11342 "systemd-resolved: TCP connection is prematurely closed when multiple requests are sent on same connection" #11332 "nss-resolve: PROTECT_ERRNO macro interfers with glibc logic to retry queries with a larger buffer" #11321 There were CI troubles. Might get postponed. "tmpfiles.d: allow "C" lines to copy stuff into pre-existing empty destination dirs" #11287 Can be merged if review passes and there are no issues. "USB device still active even after physically unplugged" #7587 We don't have a PR for this one, so it'll get bumped. So there's a few bugs, but small ones (the big ones are left for later). As soon as we merge fixes for them, I plan to make a release candidate and then the release v241 a day or two later. [1] https://github.com/systemd/systemd/milestones/v241 Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On 1/14/19 3:48 PM, Lennart Poettering wrote: On Mo, 14.01.19 08:43, Dave Reisner (d...@falconindy.com) wrote: On Mon, Jan 14, 2019 at 10:59:06AM +0100, Jan Synacek wrote: Hi, since v240 didn't go too well, I would like to suggest that the next one (preferably two) release(s) are bugfix only. Please, consider it. systemd needs better release hygiene, not just a smattering of bugfix releases. As a rolling release distro, we regularly find release-day blockers. That's bad for everyone. v240 was particularly bad as 6 months had elapsed since v239 (and over 3100 commits). That's the longest timespan and most commits in any systemd release in its nearly 9 year history. Well, that sounds as if you want to volunteer as release engineer?;-) Thing is, we are understaffed. I too have a wishlist of things I'd like to see done, but with only two paid full-time upstream engineers there's only so much we can do. Interesting what has happened to the rest? Sometimes helps also just to reach out if things are getting to understaffed/overwhelmed. I'm pretty sure that those of us that partook in this journey from the get go are still here in one form or another. If you (or anyone else in the community) would like to step up and maybe take a position of release engineer, working towards a clearer release cadence I think everybody would love you for that! I know I certainly would. But additional work is not going to be done without anyone doing it. I would not mind partaking in such collaborated effort and at the same time suggest that systemd adapts the upstream kernel release model and ties it's upstream release cycle as close to the upstream kernel releases as in one major release per kernel's development cycle release no later then .rc7 with some middle ground fit's the project to quiet down for that release. With a long term goal here for the linux ecosystem being able to reach a state in which every component that makes up the core/baseOS image ( getting system to boot and run ) and run on for whatever purpose can be released as an single updated image for downstream to consume as an update for their devices/distros and what not thou others opinions might differ in that regard. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Tue, Jan 15, 2019 at 01:09:16PM +0100, Lennart Poettering wrote: > On Mo, 14.01.19 11:26, Dave Reisner (d...@falconindy.com) wrote: > > > > > > Well, that sounds as if you want to volunteer as release engineer? ;-) > > > > > > Thing is, we are understaffed. I too have a wishlist of things I'd > > > like to see done, but with only two paid full-time upstream engineers > > > there's only so much we can do. > > > > Then, IMO, you have a fundamental misalignment. You're prioritizing > > feature work over stability, to the detriment of your customers. I > > Hu? By my "customers" I figure you mean RHEL customers? They don't use > the newest, hottest upstream systemd versions, but a stabilized > version that made its way through Fedora and the RHEL QA > processes. Production distros generally should handle it that way I > guess, not only for systemd, but any other project. > > Yes, we do feature work upstream, where else? > > > really don't think this would be a full time job. There's already a > > Well, fixing bugs is hard work. Release engineering means fixing > bugs. That's a lot of work, and I do a good chunk of it. Please, by > all means, join in, but don't claim it wouldn't be that much work. It > is! A lot! (And thankless work on top) > > > pretty good effort around tagging open issues which provides visibility > > to someone who might be in charge of cutting releases. And, much of what > > I'm suggesting is about *not* merging things after a certain point. > > Well, if you follow our commit history you'll see that quite often we > delay stuff until after a release. For example, right now #9762, > #10495 have been delayed from before the last release that way... > > Again. Step up if you want to have more systematic relase > management. You are invited! I'd very much appreciate if you do. > > > > If you (or anyone else in the community) would like to step up and > > > maybe take a position of release engineer, working towards a clearer > > > release cadence I think everybody would love you for that! I know I > > > certainly would. > > > > > > But additional work is not going to be done without anyone doing it... > > > > Like I said, it's a tradeoff. You currently have someone maintaining a > > stable branch in lieu of making your release snapshots more stable. > > It's not "me" who has that really. It's a group of volunteers doing > that, like a lot in Open Source. They scractched their own itches. If > you want a more strict cadence, the scratch your own itches, too, > please step up, like the folks doing the stable series stepped up! > > > > > Jun: 86 > > > > Jul: 276 > > > > Aug: 241 > > > > Sep: 317 > > > > Oct: 812 > > > > Nov: 882 > > > > Dec: 560 > > > > > > That it slightly misleading though, as a good chunk of those PRs that > > > good merged late where posted much earlier on, but only entered the > > > master branch late. So, most development work is definitely done at > > > the beginning of the cycle than in the end, but it's hard to see that > > > due to rebases/merges... > > > > This is all based on commit date, not merge date. It's not > > misleading. > > Well, we rebase all the time, it's not that easy... > > > > > Please, let's make all future systemd release better, not just the next > > > > 1 or 2. > > > > > > I certainly see the problem, but quite frankly, I don't see the > > > additional workforce for implementing a tighter cadence appear > > > anywhere... :-( > > > > It's really unfortunate that you're not willing to make any tradeoffs > > here. > > Well, I can tell you I will wholeheartedly support anyone stepping up, > and taking over release management. Otherwise we'll just keep trying > our best like we currently do, which isn't good enough for you. > > You know, I try to split my time between new work and bugfixing. I > simply don't won#t to get sucked into just the latter. > > We can certainly repriotize things and more often declassify bugs > hitting more exotic cases as release-crtical, in order to come to a > more strigent release cadence I.e. more aggressively ignore bugs with > exotic archs, non-redhat distros, exotic desktops, exotic libcs, weird > drivers, yadda yadda, and leave them to be fixed by community > patches. But I doubt that is in your interest either, is it? I agree with Lennart here. We have a constant stream of bug reports coming in (yay, successful software, used in ever wider context), and if we decided to fix all bugs before doing feature work, we'd _never_ do any feature work. All of the top contributors already spend a significant chunk of their time doing fixes and cleanups and refactorings and adapting to changes in other components. If you look at the list of patches between v239 and v240, majority is bugfixes and refactorings. We could do this a bit more and then 100% of time would be spent on this, effectively switching to maintenance-only mode. This would be detrimental to our users, because those new features
Re: [systemd-devel] Calling sd_bus_reply_method_return outside method handler
On Mo, 14.01.19 21:07, Jean Valjean (valjean.jean1...@gmail.com) wrote: > I want to send a reply to a method call outside method_handler. Is it > possible? > In the method_handler I increase reference count of sd_bus_message and send > it to the other thread. From there I want to call > sd_bus_reply_method_return to send a reply but get Unknown method or > interface error when I invoke method with bussctl --user call. If I call > the return method from method_handler everything works as expected. Note that sd-bus is not thread-safe on its own. It's threads-aware however: if you are careful to lock around all invocations of sd_bus using a single connection (and its associated messages) is generally fine, but it's up to you to carefully lock. So yeah, it's certainly OK to reply to an incoming bus call msgs outside of the stack method handler stack frame, but if that means threads, then make sure you know what you are doing. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Di, 15.01.19 09:51, Michael Olbrich (m.olbr...@pengutronix.de) wrote: > On Mon, Jan 14, 2019 at 04:36:49PM +0100, Lennart Poettering wrote: > > I'd love to see some more CI hookup with Arch and Debian for example > > (right now there is zero) or even just a git preview package set or so > > that interested people can test. Without either it's very likely that > > things break on those distros, because there's no way we'll catch > > things beforehand. > > I'm not Arch or Debian and I don't have the resources to set up a CI but > I'd like to do more testing before the release. The problem is, that I > don't have the time to test master all the time, so a heads up would be > nice before the release. Just a short mail to the list with the planed > release date a few weeks before the release date. > I think something like this happened in the past, but I didn't see anything > for v240 and v241. We use the milestones to track progress. i.e. currently: https://github.com/systemd/systemd/milestone/18 As the list gets shorter the closer we get to a release. There's also a telegram channel some of us hang out where talk about this, if you want I can add you there. > > (That said v241 is going to be a bugfix release mostly, and is > > currently being prepared.) > > So, any timeline for this? Well, when the list of issues on the milestone linked above gets empty... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Mo, 14.01.19 11:26, Dave Reisner (d...@falconindy.com) wrote: > > > > Well, that sounds as if you want to volunteer as release engineer? ;-) > > > > Thing is, we are understaffed. I too have a wishlist of things I'd > > like to see done, but with only two paid full-time upstream engineers > > there's only so much we can do. > > Then, IMO, you have a fundamental misalignment. You're prioritizing > feature work over stability, to the detriment of your customers. I Hu? By my "customers" I figure you mean RHEL customers? They don't use the newest, hottest upstream systemd versions, but a stabilized version that made its way through Fedora and the RHEL QA processes. Production distros generally should handle it that way I guess, not only for systemd, but any other project. Yes, we do feature work upstream, where else? > really don't think this would be a full time job. There's already a Well, fixing bugs is hard work. Release engineering means fixing bugs. That's a lot of work, and I do a good chunk of it. Please, by all means, join in, but don't claim it wouldn't be that much work. It is! A lot! (And thankless work on top) > pretty good effort around tagging open issues which provides visibility > to someone who might be in charge of cutting releases. And, much of what > I'm suggesting is about *not* merging things after a certain point. Well, if you follow our commit history you'll see that quite often we delay stuff until after a release. For example, right now #9762, #10495 have been delayed from before the last release that way... Again. Step up if you want to have more systematic relase management. You are invited! I'd very much appreciate if you do. > > If you (or anyone else in the community) would like to step up and > > maybe take a position of release engineer, working towards a clearer > > release cadence I think everybody would love you for that! I know I > > certainly would. > > > > But additional work is not going to be done without anyone doing it... > > Like I said, it's a tradeoff. You currently have someone maintaining a > stable branch in lieu of making your release snapshots more stable. It's not "me" who has that really. It's a group of volunteers doing that, like a lot in Open Source. They scractched their own itches. If you want a more strict cadence, the scratch your own itches, too, please step up, like the folks doing the stable series stepped up! > > > Jun: 86 > > > Jul: 276 > > > Aug: 241 > > > Sep: 317 > > > Oct: 812 > > > Nov: 882 > > > Dec: 560 > > > > That it slightly misleading though, as a good chunk of those PRs that > > good merged late where posted much earlier on, but only entered the > > master branch late. So, most development work is definitely done at > > the beginning of the cycle than in the end, but it's hard to see that > > due to rebases/merges... > > This is all based on commit date, not merge date. It's not > misleading. Well, we rebase all the time, it's not that easy... > > > Please, let's make all future systemd release better, not just the next > > > 1 or 2. > > > > I certainly see the problem, but quite frankly, I don't see the > > additional workforce for implementing a tighter cadence appear > > anywhere... :-( > > It's really unfortunate that you're not willing to make any tradeoffs > here. Well, I can tell you I will wholeheartedly support anyone stepping up, and taking over release management. Otherwise we'll just keep trying our best like we currently do, which isn't good enough for you. You know, I try to split my time between new work and bugfixing. I simply don't won#t to get sucked into just the latter. We can certainly repriotize things and more often declassify bugs hitting more exotic cases as release-crtical, in order to come to a more strigent release cadence I.e. more aggressively ignore bugs with exotic archs, non-redhat distros, exotic desktops, exotic libcs, weird drivers, yadda yadda, and leave them to be fixed by community patches. But I doubt that is in your interest either, is it? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On Mon, Jan 14, 2019 at 04:36:49PM +0100, Lennart Poettering wrote: > I'd love to see some more CI hookup with Arch and Debian for example > (right now there is zero) or even just a git preview package set or so > that interested people can test. Without either it's very likely that > things break on those distros, because there's no way we'll catch > things beforehand. I'm not Arch or Debian and I don't have the resources to set up a CI but I'd like to do more testing before the release. The problem is, that I don't have the time to test master all the time, so a heads up would be nice before the release. Just a short mail to the list with the planed release date a few weeks before the release date. I think something like this happened in the past, but I didn't see anything for v240 and v241. > (That said v241 is going to be a bugfix release mostly, and is > currently being prepared.) So, any timeline for this? Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
