ejabberd, pam, and setuid root
Hello my fellow Fedora friends! It's 01:00 in my local time and perhaps I should be resting instead of trying to figure out chicken-and-egg problems at such a time, but my tired mind is on the fence about the solution to one of my tickets and I would love the input of others: https://bugzilla.redhat.com/show_bug.cgi?id=1371984 Let's just say that daemon package A creates user/group A and depends on library B. One of library B's binaries needs to be installed setuid root because it is for PAM authentication, but I'd rather install the binary 4750 or 4700 than 4755. To do this, I can only think of four solutions: 0) library B installs with 4700, and daemon package A sets a facl on the binary to allow user A to execute it. This seems pretty cool, but also weird to me since it seems odd for a package to modify a file from another package. Additionally, it seems like future updates to library B might disrupt the facls that were set by daemon package A until the next time it was installed/updated. That sounds right anyway, and if it is right I think this option is a no-go. Simple tests with the install utility on my fs did obliterate facls when new files were installed over existing files. A crazy workaround for this problem might be to detect whether the facls are present before the upgrade with %pre, and restore them in %post. 1) library B creates group A (even though the library isn't necessarily only for daemon package A who is the only package to create this user/group at this time), and then sets its binary to 4750, owned by group A. This one is a little easier than the first option, since I'd only have to make an update to library B rather than both A and B. The only thing is that it seems kind of weird for library B to be creating a group called A, when library B is theoretically generally useful on its own and theoretically could have other packages that pull it in in the future. It would be weird for group A to exist if package A were not installed I think. Fortunately, it wouldn't need to create user A as well, only the group. 2) We could leave the problem up to documentation, instructing users to set the facls or group ownership. However, this will suffer from the same update problem that the first solution suffers from, and the user will need to reset the facls whenever this package were updated. 3) We could rely on an SELinux policy to ensure that only ejabberd can execute this binary. I don't like this for two reasons: users who disable SELinux wouldn't have the fallback regular Unix permissions as the second layer of defense. Secondly, unconfined users would still be able to run the binary. If there were ever security issues found in the binary itself, neither of these situations would be ideal. Option #1 seems to have the fewest technical concerns, so I lean in that direction. Hopefully sleeping will get my mind to its peak efficiency and I'll see some obvious solution in the morning, but I'd love to hear what others think. Is there precedent for this problem? Do you have any other options that I haven't thought of? Thanks for any input you can offer! signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Fedora-packaging] Schedule for Thursday's FPC Meeting (2016-09-01 16:00 UTC)
Of course the date is wrong, due to it already being tomorrow UTC. So the actual date/time is: 2016-09-01 09:00 Thu US/Pacific PDT 2016-09-01 12:00 Thu US/Eastern EDT 2016-09-01 16:00 Thu UTC <- 2016-09-01 17:00 Thu Europe/London BST 2016-09-01 18:00 Thu Europe/Paris CEST 2016-09-01 18:00 Thu Europe/Berlin CEST 2016-09-01 21:30 Thu Asia/Calcutta IST --new day-- 2016-09-02 00:00 Fri Asia/Singapore SGT 2016-09-02 00:00 Fri Asia/Hong_Kong HKT 2016-09-02 01:00 Fri Asia/Tokyo JST 2016-09-02 02:00 Fri Australia/BrisbaneAEST On Wed, 2016-08-31 at 23:30 -0400, James Antill wrote: > Following is the list of topics that will be discussed in the FPC > meeting Thursday at 2016-09-02 16:00 UTC in #fedora-meeting-1 on > irc.freenode.net. > > Local time information (via. rktime): > > 2016-09-02 09:00 Fri US/Pacific PDT > 2016-09-02 12:00 Fri US/Eastern EDT > 2016-09-02 16:00 Fri UTC <- > 2016-09-02 17:00 Fri Europe/London BST > 2016-09-02 18:00 Fri Europe/Paris CEST > 2016-09-02 18:00 Fri Europe/Berlin CEST > 2016-09-02 21:30 Fri Asia/Calcutta IST > --new day-- > 2016-09-03 00:00 Sat Asia/Singapore SGT > 2016-09-03 00:00 Sat Asia/Hong_Kong HKT > 2016-09-03 01:00 Sat Asia/Tokyo JST > 2016-09-03 02:00 Sat Australia/BrisbaneAEST > > Links to all tickets below can be found at: > > https://fedorahosted.org/fpc/report/13 > > = Followups = > > #topic #558 Application/Library distinction and package > splitting > .fpc 558 > https://fedorahosted.org/fpc/ticket/558 > > #topic #610 Packaging guidelines: Check upstream tarball > signatures > .fpc 610 > https://fedorahosted.org/fpc/ticket/610 > > = Open Floor = > > For more complete details, please visit each individual ticket. The > report of the agenda items can be found at: > > https://fedorahosted.org/fpc/report/13 > > If you would like to add something to this agenda, you can reply to > this e-mail, file a new ticket at https://fedorahosted.org/fpc, > e-mail me directly, or bring it up at the end of the meeting, during > the open floor topic. Note that added topics may be deferred until > the following meeting. > -- > packaging mailing list > packag...@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/packaging@lists.fedorapro > ject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Schedule for Thursday's FPC Meeting (2016-09-02 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2016-09-02 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2016-09-02 09:00 Fri US/Pacific PDT 2016-09-02 12:00 Fri US/Eastern EDT 2016-09-02 16:00 Fri UTC <- 2016-09-02 17:00 Fri Europe/London BST 2016-09-02 18:00 Fri Europe/Paris CEST 2016-09-02 18:00 Fri Europe/Berlin CEST 2016-09-02 21:30 Fri Asia/Calcutta IST --new day-- 2016-09-03 00:00 Sat Asia/Singapore SGT 2016-09-03 00:00 Sat Asia/Hong_Kong HKT 2016-09-03 01:00 Sat Asia/Tokyo JST 2016-09-03 02:00 Sat Australia/BrisbaneAEST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/13 = Followups = #topic #558 Application/Library distinction and package splitting .fpc 558 https://fedorahosted.org/fpc/ticket/558 #topic #610 Packaging guidelines: Check upstream tarball signatures .fpc 610 https://fedorahosted.org/fpc/ticket/610 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/13 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: My experiences with KillUserProcesses=yes on F24
On Wed, Aug 31, 2016 at 09:25:22AM -0500, Jason L Tibbitts III wrote: > Hope this is interesting to someone and adds useful content to the > discussion. I think it does — thanks for your real-world observations! -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Naming a sphinx-doc theme: python-sphinx_py3doc_enhanced_theme or python-sphinx-theme-py3doc-enhanced
Thanks for your responses. I think I'll use - As the main name for the package: python-sphinx-theme-py3doc-enhanced - A provide for python-sphinx_py3doc_enhanced_theme This way it can be installed with a nice and consistant name as well with its upstream name. On Wed, 2016-08-24 at 10:25 -0400, Avram Lubkin wrote: > > Frankly I think upstream should have called it py3doc_enhanced and > left out sphinx and theme, but that's beside the point. > > Based on the package naming conventions [1], you name is mainly > correct (more on this later). In the Python modules section [2], it > says: > > The package name should reflect the upstream name of the Python > module, and should generally take into account the name of the module > used when importing it in Python scripts. This name will be prefixed > depending on the type of the package. > > Based on that, the name should really be python-sphinx-theme- > sphinx_py3doc_enhanced_theme, but that is overly confusing. I think > there are two legitimate names: > > python-sphinx-theme-py3doc_enhanced > python-sphinx_py3doc_enhanced_theme > > Some might argue you could replace the underscore in the first one > with a dash, and I wouldn't see a huge problem with that, but I think > it's not necessary. It is justified though because the name is > already changed from the import name and the tarball for the package > uses dashes instead of underscores. > > As far those underscores, that's covered in the separator section > [3]: > > There are a few exceptions to the no underscore '_' rule. > ... > - packages where the upstream name naturally contains an underscore > are excluded from this. > > Based on this rule and the Python module rule, I would say python- > sphinx-py3doc-enhanced-theme would not be an appropriate name. > > So go with one of these: > > python-sphinx-theme-py3doc_enhanced > python-sphinx-theme-py3doc-enhanced > python-sphinx_py3doc_enhanced_theme > > > [1] https://fedoraproject.org/wiki/Packaging:Naming > [2] https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:Nami > ngGuidelines#Python_modules > [3] https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:Nami > ngGuidelines#Separators > > On Wed, Aug 24, 2016 at 3:16 AM, Garrett Holmstrom ect.org> wrote: > > > > On 2016-08-23 10:19, Julien Enselme wrote: > > > > > > Hi, > > > > > > Recently I opened a review [1] for a new sphinx theme: > > > py3doc_enhanced_theme [2] > > > > > > The upstream name is sphinx_py3doc_enhanced_theme, so in my > > > opinion, > > > the the package should be named python- > > > sphinx_py3doc_enhanced_theme. > > > Furthermore, there's another sphinx theme with underscores in its > > > name: python3-sphinx_rtd_theme. So I find it logical that the > > > package > > > is named this way. > > > > > > However, the reviewer (Zbigniew Jędrzejewski-Szmek) pointed out > > > that: > > > > > > - Dashes are preferred (See the guidelines [3]) > > > - Most themes are named with this pattern: python-sphinx-theme- > > > > > > Therefore, it would be consistent to name the package: python- > > > sphinx- > > > theme-py3doc-enhanced and I think that's a good point. > > > > > > A middle ground would be to use provides so the package can be > > > installed with both names, but that leaves the question about the > > > "main" name unresolved. > > > > > > Any thoughts? > > > > > > > Using hyphens in the package name keeps the package collection more > > consistent, and adding a Provides entry that uses underscores will > > more or less seamlessly take care of the case where people > > installing it assume it uses those instead. It's a win-win to do > > it that way, IMO. > > > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproje > > ct.org > > -- Julien Enselme http://www.jujens.eu/ -- Julien Enselme http://www.jujens.eu/ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Kernel 4.7 rebase plans
On Wed, Aug 31, 2016 at 9:36 AM, Alec Leamas wrote: > > > On 31/08/16 17:15, Peter Robinson wrote: >>> >>> Perhaps. But this has been a common problem for me with many recent >>> kernel >>> updates. But if it's only me, I presume it's the mirror. >> >> Tried with "dnf upgrade --refresh" ? >> -- > > > I'm more the sledgehammer type, so I did dnf clean all. But to no avail. I don't think it's with just the kernel though, the recent selinux-policy once stable took more than 24 hours before a dnf update picked it up. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 25-20160831.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Failed openQA tests: 15/89 (x86_64), 5/17 (i386) ID: 31513 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/31513 ID: 31514 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31514 ID: 31520 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31520 ID: 31521 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31521 ID: 31522 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/31522 ID: 31523 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31523 ID: 31524 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31524 ID: 31549 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/31549 ID: 31558 Test: x86_64 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/31558 ID: 31576 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/31576 ID: 31590 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/31590 ID: 31592 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/31592 ID: 31593 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/31593 ID: 31595 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/31595 ID: 31596 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/31596 ID: 31597 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/31597 ID: 31598 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/31598 ID: 31608 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/31608 ID: 31615 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/31615 ID: 31616 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/31616 Passed openQA tests: 69/89 (x86_64), 12/17 (i386), 2/2 (arm) Skipped openQA tests: 5 of 108 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Kernel 4.7 rebase plans
On 31/08/16 17:15, Peter Robinson wrote: Perhaps. But this has been a common problem for me with many recent kernel updates. But if it's only me, I presume it's the mirror. Tried with "dnf upgrade --refresh" ? -- I'm more the sledgehammer type, so I did dnf clean all. But to no avail. --alec -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: My experiences with KillUserProcesses=yes on F24
On 08/31/2016 02:25 PM, Jason L Tibbitts III wrote: More appropriate place would be to post this upstream either on the mailinglist and or as an bug/rfs in the tracker so this issues can be addressed properly. Lingering is a per-user thing so it probably ends up being an per user opt in feature/fix JBG -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Kernel 4.7 rebase plans
Please test and give karma again. A reminder that if you do find regressions please note on the bodhi update corresponding to the kernel you tested AND file a bugzilla with information. >>> It's somewhat hard since the corresponding kernel-devel packages seems to >>> be >>> missing. Is this on purpose? >> >> Uh... what? They're present in the build. Perhaps the mirror you hit is >> stale? >> >> http://koji.fedoraproject.org/koji/buildinfo?buildID=794636 >> > > Perhaps. But this has been a common problem for me with many recent kernel > updates. But if it's only me, I presume it's the mirror. Tried with "dnf upgrade --refresh" ? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Kernel 4.7 rebase plans
>>> Please test and give karma again. A reminder that if you do find >>> regressions please note on the bodhi update corresponding to the >>> kernel you tested AND file a bugzilla with information. >>> >> >> It's somewhat hard since the corresponding kernel-devel packages seems to be >> missing. Is this on purpose? > > Uh... what? They're present in the build. Perhaps the mirror you hit is > stale? > > http://koji.fedoraproject.org/koji/buildinfo?buildID=794636 It's also on the primary mirror: https://dl.fedoraproject.org/pub/fedora/linux/updates/testing/24/x86_64/k/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Kernel 4.7 rebase plans
On 31/08/16 16:41, Josh Boyer wrote: On Wed, Aug 31, 2016 at 10:34 AM, Alec Leamas wrote: On 29/08/16 18:25, Laura Abbott wrote: Please test and give karma again. A reminder that if you do find regressions please note on the bodhi update corresponding to the kernel you tested AND file a bugzilla with information. It's somewhat hard since the corresponding kernel-devel packages seems to be missing. Is this on purpose? Uh... what? They're present in the build. Perhaps the mirror you hit is stale? http://koji.fedoraproject.org/koji/buildinfo?buildID=794636 Perhaps. But this has been a common problem for me with many recent kernel updates. But if it's only me, I presume it's the mirror. --alec -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: My experiences with KillUserProcesses=yes on F24
> "JLT" == Jason L Tibbitts writes: JLT>I've found that if the user's user manager dies (for any reason JLT>you might choose) and linger is enable for them, a new one won't JLT>be started at login. They have to disable linger, log out, and JLT>log back in. Or reboot the machine. I should add an explanation here. This is a problem because without a user manager, systemd-run errors out with "Failed to create bus connection: Connection refused". Your processes are still killed when the session terminates, so if you get into this state you basically can't run persistent jobs at all. - J< -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Kernel 4.7 rebase plans
On Wed, Aug 31, 2016 at 10:34 AM, Alec Leamas wrote: > > > On 29/08/16 18:25, Laura Abbott wrote: >> >> >> Please test and give karma again. A reminder that if you do find >> regressions please note on the bodhi update corresponding to the >> kernel you tested AND file a bugzilla with information. >> > > It's somewhat hard since the corresponding kernel-devel packages seems to be > missing. Is this on purpose? Uh... what? They're present in the build. Perhaps the mirror you hit is stale? http://koji.fedoraproject.org/koji/buildinfo?buildID=794636 josh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
jplesnik uploaded Mail-Sender-0.902.tar.gz for perl-Mail-Sender
ba23b72efb5e5529b80c47c5dd764d37 Mail-Sender-0.902.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Mail-Sender/Mail-Sender-0.902.tar.gz/md5/ba23b72efb5e5529b80c47c5dd764d37/Mail-Sender-0.902.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org
Re: Kernel 4.7 rebase plans
On 29/08/16 18:25, Laura Abbott wrote: Please test and give karma again. A reminder that if you do find regressions please note on the bodhi update corresponding to the kernel you tested AND file a bugzilla with information. It's somewhat hard since the corresponding kernel-devel packages seems to be missing. Is this on purpose? --alec -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
My experiences with KillUserProcesses=yes on F24
After reading (some of) the "discussion" about systemd-logind's
KillUserProcesses setting, I decided that I'd like to try enabling it
and see how it works and how I can make it useful in my environment.
Sorry, it's long, but I though folks might want to know.
Disclaimer:
I quite like systemd and I will try to avoid strong language like
"bizarre", "surprising", "WTF" and except in one case, "bug". This is
all based on systemd 229 in F24; I know 230 changes one thing and maybe
it or future versions will change enough that the issues in this
document go away.
Background:
I run a university department network a bunch of desktops and a pile of
other machines accessed by a few hundred users for various functions.
Around 200 machines total. Where appropriate, I'd like to make sure
that user sessions get shut down properly even when sessions hang or get
confused at startup, but I'd also like to preserve the possibility of
users running background jobs on the desktops (which are often quite
powerful and useful for computation) even after they log out.
So:
I enabled KillUserProcesses on a desktop and rebooted. Some testing
shows that it works as documented and kills processes at logout. But as
with any change, I ran into some problems.
Problem 1:
Need to give users a way to run persistent background jobs without
requiring them to learn systemd-run.
Solution 1:
Provide wrappers in /usr/local/bin for nohup, screen and a couple of
local utilities which use nice and nohup internally. Those wrappers
call systemd-run --user --scope.
Problem 2:
Even under systemd-run --user --scope, things don't persist unless
"linger" is enabled for the user.
Solution 2:
Add loginctl enable-linger to the wrappers.
Problem 3:
loginctl enable-linger requires root privs (in F24's systemd 229; seems
that 230 allows self-lingering by default).
Solution 3:
Add this in /etc/polkit-1/rules.d/50-user-linger.rules:
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.login1.set-user-linger") {
return polkit.Result.YES;
}
});
Now users can run loginctl enable-linger. For any user. Oh, well, I
can live with that for now. And things work! But
Problem 4:
"linger" does more than just allow sessions to persist.
A) It changes the way the "user manager" for that user runs. Without
linger, a user manager is started when the log in, and it goes away
when their last process exits (which given KillUserProcesses is
whenever they log out). When linger is enabled for a user (in
many curcumstances, at least), a user manager is immediately started
if the user isn't already logged in which will never exit. This has
interesting consequences.
I've found that if the user's user manager dies (for any reason you
might choose) and linger is enable for them, a new one won't be
started at login. They have to disable linger, log out, and log back
in. Or reboot the machine.
B) It enables "user units" (probably the wrong terminology) which let
users start up things which run periodically, or at boot, and which
run under their UIDs. In order to make this work, the user manager
will run immediately at system boot time and look in
~/.config/systemd for units.
These seem like good ideas, except that:
i) I don't necessarily want users to be able to start units at boot
time, but that's OK because
ii) I have home dirs on kerberized NFS. So this automounts the home
directories of every lingering user at boot time (which is a problem
for me) and that directory can't be read anyway, even by the proper
UID, if the user doesn't have a kerberos ticket. Plus the network
isn't necessarily up to the point where user homedirs can be
accessed at the time when systemd starts the user managers.
Fortunately in the default case, it doesn't hold open a reference to
the homedir so the automounter will remove it. It can still cause a
lot of mounts, which can take some time and puts more load on my
already loaded file servers.
The bottom line there is user sessions aren't going to work in some
environments, period.
Solution4A:
I don't have one If I'm the one killing their processes (for
whatever reason I might have), I have to make sure to disable lingering
for them at the same time. But if they kill their processes (kill -9 -1
to just terminate everything, if you want to test) then they're
screwed. They have to disable linger, log out and log back in so that a
user manager is created for them. Then they can enable linger again.
This just has to be a bug, so I've filed:
https://bugzilla.redhat.com/show_bug.cgi?id=1371721
Solution4B:
Add the following to /etc/systemd/system/delete-lingers.service:
[Unit]
Description=Delete lingering users
Before=network.target
[Service]
Type=oneshot
ExecStart=/usr/bin/rm -rf /var/lib/systemd/linger
[Install]
WantedBy=multi-user.target
Now at each boot, no users are set to l
Fedora Rawhide-20160831.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Failed openQA tests: 32/89 (x86_64), 4/17 (i386), 1/2 (arm) ID: 31403 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31403 ID: 31405 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/31405 ID: 31406 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31406 ID: 31412 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31412 ID: 31413 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31413 ID: 31414 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/31414 ID: 31415 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31415 ID: 31416 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/31416 ID: 31418 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31418 ID: 31425 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/31425 ID: 31428 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31428 ID: 31430 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/31430 ID: 31436 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/31436 ID: 31438 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/31438 ID: 31441 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/31441 ID: 31453 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/31453 ID: 31457 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/31457 ID: 31468 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/31468 ID: 31470 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/31470 ID: 31471 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/31471 ID: 31472 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/31472 ID: 31473 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/31473 ID: 31474 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/31474 ID: 31475 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/31475 ID: 31476 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/31476 ID: 31477 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/31477 ID: 31478 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/31478 ID: 31479 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/31479 ID: 31482 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/31482 ID: 31484 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/31484 ID: 31485 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/31485 ID: 31487 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/31487 ID: 31488 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/31488 ID: 31489 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/31489 ID: 31490 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/31490 ID: 31507 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/31507 ID: 31508 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/31508 Passed openQA tests: 52/89 (x86_64), 13/17 (i386) Skipped openQA tests: 6 of 108 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Modularity] Messing around with building modules
On Wed, Aug 31, 2016 at 10:32:39AM +0200, Adam Samalik wrote: > We definitely needed something like that, great! > > Do you think it would make sense to split the instructions into two parts? > Something like: > > 1. Prepare your environment to make it work with our dev infra - "the stuff > you won't need to do in the future" > > 2. Build a module - "The actual workflow" > > I guess might make it easier for people to understand it/see it less > complicated more quickly. And then we could even provide a Vagrantfile with > everything from the first part prepared. > > Does it make sense? Yeah, sounds good to me. :) It's a wiki, so if anyone has time to take that on, please feel free to make the edits. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: BuildRequires on obsoleted packages provided by Python
And a clarification here: The plan for renaming python is only for rawhide, while removing the Obsoletes/Provides might as well go in F25 as well, depending on the time frame that maintainers will be able to fix their packages. Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Charalampos Stratakis" To: "Development discussions related to Fedora" Cc: "Fedora Python SIG" Sent: Wednesday, August 31, 2016 2:10:25 PM Subject: BuildRequires on obsoleted packages provided by Python Hello all, While checking out the SPEC file of python, it seems there were some packages that, while separate at some point, they got included in python's stdlib and then obsoleted as standalone packages (thus to cope with the change, python was obsoleting these packages and providing them as well in the SPEC). So every package that currently (Build)Requires any of these packages will essentially drag python with it. I will remove these provides soon, since the packages were orphaned long time ago, but the packages that still require them, will need to be fixed and (Build)Require python instead. Here is a github commit with these changes from a testing repo: https://github.com/fedora-python/python2-spec/commit/dfdd96e653d65ce68359553b378104fec260589c And a list of the provided packages and the affected ones Distutils: None python-sqlite: cas yum python-ctypes: drobo-utils glusterfs-extra-xlators glusterfs-geo-replication python-smbios python-hashlib: pyrpkg python-uuid: dpm-server-mysql oz python2-celery python-argparse: R2spec catkin diskimage-builder euca2ools fedora-review feedstail gfal2-util glacier-cli grin hash-slinger imagefactory instack libstoragemgmt nordugrid-arc-nagios-plugins os-apply-config os-cloud-confic os-collect-confic os-net-config pyrpkg python-amqpclt python-catkin_pkg python-catkin_tools python-cloudservers python-gear python-novaclient python-postman python-requestbuilder python-rosdistro python-rospkg python-sparklines python2-oslo-config repo_manager rpkg vdsm Depending on feedback here I will follow (or not) the mass bug filling procedure so maintainer fix their packages. The reasoning behind this change, at the current time, is that I intent to rename python to python2 soon, which will lead to a re-review of python, so at the moment trying to have things as clear and consistent as possible. Plans for that change is only for rawhide (although it would be nice for f25 as well). Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat ___ python-devel mailing list python-de...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/python-de...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
BuildRequires on obsoleted packages provided by Python
Hello all, While checking out the SPEC file of python, it seems there were some packages that, while separate at some point, they got included in python's stdlib and then obsoleted as standalone packages (thus to cope with the change, python was obsoleting these packages and providing them as well in the SPEC). So every package that currently (Build)Requires any of these packages will essentially drag python with it. I will remove these provides soon, since the packages were orphaned long time ago, but the packages that still require them, will need to be fixed and (Build)Require python instead. Here is a github commit with these changes from a testing repo: https://github.com/fedora-python/python2-spec/commit/dfdd96e653d65ce68359553b378104fec260589c And a list of the provided packages and the affected ones Distutils: None python-sqlite: cas yum python-ctypes: drobo-utils glusterfs-extra-xlators glusterfs-geo-replication python-smbios python-hashlib: pyrpkg python-uuid: dpm-server-mysql oz python2-celery python-argparse: R2spec catkin diskimage-builder euca2ools fedora-review feedstail gfal2-util glacier-cli grin hash-slinger imagefactory instack libstoragemgmt nordugrid-arc-nagios-plugins os-apply-config os-cloud-confic os-collect-confic os-net-config pyrpkg python-amqpclt python-catkin_pkg python-catkin_tools python-cloudservers python-gear python-novaclient python-postman python-requestbuilder python-rosdistro python-rospkg python-sparklines python2-oslo-config repo_manager rpkg vdsm Depending on feedback here I will follow (or not) the mass bug filling procedure so maintainer fix their packages. The reasoning behind this change, at the current time, is that I intent to rename python to python2 soon, which will lead to a re-review of python, so at the moment trying to have things as clear and consistent as possible. Plans for that change is only for rawhide (although it would be nice for f25 as well). Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaning packages
2016-08-30 15:08 GMT+02:00 Antonio Trande : > On 08/30/2016 11:26 AM, Mario Ceresa wrote: >> Dear all, >> I'm orphaning the following packages due to not enough time to be a >> proper mantainer: >> >> * dcmtk (https://admin.fedoraproject.org/pkgdb/package/rpms/dcmtk/) >> * gdcm (https://admin.fedoraproject.org/pkgdb/package/rpms/gdcm/) >> >> I'll still be around to help if needed, just can't be the main point of >> contact. >> >> Best, >> >> Mario >> > > These packages are maintained by other packagers; are they still active? Yes. But as usual co-maintainers are very welcome. Also one more thing to mention. Mario's packages contains a batch of out-of-tree patches which better be proposed to upstream. Some of them were some of them weren't yet. Any help in this particular area is very much appreciated :) -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaning packages
On Wed, Aug 31, 2016 at 11:37 AM, Mario Ceresa wrote: > Hi Antonio, > I think Igor took ownership yesterday after I orphaned them Yes, I took them and added all ACLs for Mario. In week or two I will go through all bugs and will comment them and update packages. > > Best, > Mario > > On Tue, 30 Aug 2016 at 15:09 Antonio Trande wrote: >> >> On 08/30/2016 11:26 AM, Mario Ceresa wrote: >> > Dear all, >> > I'm orphaning the following packages due to not enough time to be a >> > proper mantainer: >> > >> > * dcmtk (https://admin.fedoraproject.org/pkgdb/package/rpms/dcmtk/) >> > * gdcm (https://admin.fedoraproject.org/pkgdb/package/rpms/gdcm/) >> > >> > I'll still be around to help if needed, just can't be the main point of >> > contact. >> > >> > Best, >> > >> > Mario >> > >> >> These packages are maintained by other packagers; are they still active? >> >> -- >> --- >> Antonio Trande >> mailto: sagitter 'at' fedoraproject 'dot' org >> http://fedoraos.wordpress.com/ >> https://fedoraproject.org/wiki/User:Sagitter >> GPG Key: 0x6CE6D08A >> Check on https://keys.fedoraproject.org/ >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Flock 2016 Slices & Videos
Hi, For the person who not attend Flock 2016 event. As I knew the useful page for the event today, let me announce you. You can watch videos and slices from following page. Flock 2016 Talks (Slides, Videos) https://fedoraproject.org/wiki/Flock_2016_Talks As the page has links to slides and videos for some, not all talks, if you are the speaker and you have slide or video, I would like you to upload those to the page. Thank you. -- Jun Aruga -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaning packages
Hi Antonio, I think Igor took ownership yesterday after I orphaned them Best, Mario On Tue, 30 Aug 2016 at 15:09 Antonio Trande wrote: > On 08/30/2016 11:26 AM, Mario Ceresa wrote: > > Dear all, > > I'm orphaning the following packages due to not enough time to be a > > proper mantainer: > > > > * dcmtk (https://admin.fedoraproject.org/pkgdb/package/rpms/dcmtk/) > > * gdcm (https://admin.fedoraproject.org/pkgdb/package/rpms/gdcm/) > > > > I'll still be around to help if needed, just can't be the main point of > > contact. > > > > Best, > > > > Mario > > > > These packages are maintained by other packagers; are they still active? > > -- > --- > Antonio Trande > mailto: sagitter 'at' fedoraproject 'dot' org > http://fedoraos.wordpress.com/ > https://fedoraproject.org/wiki/User:Sagitter > GPG Key: 0x6CE6D08A > Check on https://keys.fedoraproject.org/ > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Modularity] Messing around with building modules
We definitely needed something like that, great! Do you think it would make sense to split the instructions into two parts? Something like: 1. Prepare your environment to make it work with our dev infra - "the stuff you won't need to do in the future" 2. Build a module - "The actual workflow" I guess might make it easier for people to understand it/see it less complicated more quickly. And then we could even provide a Vagrantfile with everything from the first part prepared. Does it make sense? On Tuesday, 30 August 2016, Ralph Bean wrote: > Hi all! > > First, check out the logs/minutes from today's Modularity WG meeting: > > https://meetbot.fedoraproject.org/teams/modularity_wg/ > modularity_wg.2016-08-30-15.00.html > > We identified that we needed a doc on how to fool around with our > prototype build infrastructure (partly staging, partly a dev > environment). We wrote this up which should help if people want to > try it out: > > https://fedoraproject.org/wiki/Modularity/HowToBuildAModuleInStaging > > Let us know in #fedora-modularity if/when something about it doesn't > work and we'll take a look together. :) > > Cheers- > -Ralph > -- Adam Šamalík --- Associate Software Engineer Red Hat -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
