nt comps
>
> I'm in favor of either of these. I'd suggest aiming for the last but
> falling back to the first if it's not working in the beta?
+1
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.
ite good.
> ($129-159/night at the hotels.)
I guess Matthias had in mind airfares, in August it is high season and
airfares will be much higher than at other times.
Unfortunately I cannot check whether there is a difference in price
between last week of august and later because a couple of webs
ster-proposal
> [4] https://fedoraproject.org/wiki/Flock2015-CapeCod-proposal
[1] -> -1
[2] -> -5
[3] -> -1
[4] -> +3
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
mean the only way to build in copr would be to commit in git ?
I build one-off for testing and although I do not put anything "fishy"
in copr, I am not it would have any value to waste permanent space in
git with most of the tests I do.
Simo.
--
Simo Sorce * Red Hat, Inc * N
in advance!
It is current, and Samba in F20 will never have the AD bits.
Maybe F22, or perhaps even F21, the work to replace Heimdal with MIT is
proceeding well enough.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject
e hard work, but I think you overstate the case by a
> long way when you say it'd be impossible. It may be finicky work, but it
> seems unlikely that it'd be easier to write an entirely new partitioning
> app with all of blivet's capabilities from the ground up
o we can have better understanding ?"
When you want someone to participate in something he usually do not do,
you "invite" that person.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo
tallable on Fedora easily. The best thing of
> course is to have upstream use sonames/versioning correctly, and have
> nothing broken; but if that’s not possible, a Fedora-specific fix does
> seem much more preferable.)
Making upstream aware of the problem and sending patches is al
On Fri, 2014-07-11 at 12:52 +0200, Lennart Poettering wrote:
> On Fri, 11.07.14 05:41, Simo Sorce (s...@redhat.com) wrote:
>
> > The reason why we *must* use a notification mechanism is that we
> > maintain a very fast cache as a mmapped database to avoid roundtrips
> >
On Thu, 2014-07-10 at 20:05 +0200, Lennart Poettering wrote:
> On Thu, 10.07.14 12:44, Simo Sorce (s...@redhat.com) wrote:
>
> > On Thu, 2014-07-10 at 17:18 +0200, Jakub Hrozek wrote:
> > > We /do/ plan on the syncing anyway, because some admins are
> > > still used
es and files for the system users.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
y FTBFS
> OKlasso-2.4.0-4.fc21
lasso is built.
Thank you for fixing the spec file and rebuilding, really appreciated.
Simo.
> OKming-0.4.5-4.fc21
>
> Done
>
> Remi.
>
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
if your "transport" is a horse or a car ? You should
just call it "tranmsport", right ?
Anyway I think we should stop with this bikeshedding. The people write
the code decided to call it DNF, and it is their right to do so, it is
their project and they decided they want a new
ransition IMO, and should be followed.
If you like yum you keep the compat package, if you hate it: dnf remove
yum-compat and be happy.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Steve,
didn't we kill libgssglue ?
Is it really still in rawhide ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
is not about being funny, it is about making reasonable decisions.
> /run solved a huge old problem, libexec is pointless and only creates
> needless and nothing but annoying differences.
It's a practical way to keep helpers out of path and autocomplete
without polluting /usr/lib[64]
of binaries
> in both places...
>
> We really should get rid of the destinction, and make all of /bin,
> /sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
> about $PATH orders and namespace collisions...
Is there a description somewhere of why /usr/bin instead of ditching it
and keeping just /bin ? Ie why the '/usr' prefix ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
le. What about domain and search lines? If NetworkManager will always
> use 127.0.0.1, it should still modify resolv.conf with the domain name
> received from DHCP
Why would you care for the domain name as provided by dhcp ?
By default you wouldn't want that as you roam with a fedora la
On Wed, 2014-04-30 at 13:25 +, Colin Walters wrote:
> On Tue, Apr 29, 2014 at 11:23 PM, Simo Sorce wrote:
> >
> > can you use an actual chroot ?
>
> Calling chroot tends to imply running code from the target system. I'd
> prefer to avoid that by default. In p
On Wed, 2014-04-30 at 08:49 +0200, Alexander Larsson wrote:
> On tis, 2014-04-29 at 11:24 -0400, Simo Sorce wrote:
> > On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
> > > On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
> > > > = Proposed Syst
On Mon, 2014-04-28 at 18:50 +, Colin Walters wrote:
> On Mon, Apr 28, 2014 at 1:39 PM, Simo Sorce wrote:
> >
> > We can do that with SSSD, which we are planning to take over all users
> > (though it will leave /etc/passwd on the system for emergency repair
> > and
is no-go.
I have to concur, unix sockets is a dead end, there are tons of
libraries that look at resolv.conf and use the server named there, and
they only support the standard DNS protocol over IP (TCP and UDP).
Are we going to need a way to "bind-mount" local ports to containers
too ?
ough normal routing on a different interface.
However we can perhaps make it listen on a special virtual interface
dedicated to let containers talk to other processes on the host maybe ?
(could even be other privileged containers). There is a question of what
addresses to use thoug
which we are planning to take over all users
(though it will leave /etc/passwd on the system for emergency repair and
backward compatibility).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
on ?
- How do you propose to resolve users from multiple files ?
- Are you going to introduce new nss modules ?
- Are you going to change pam_unix to lookup from all there files in
different ways ?
anything else ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailin
ty, nor
useful.
debug symbols at -O2 are mostly useful to get backtraces, but if you
need to really step through with gdb in some complicated, highly
optimizable code, often it does not cut it, you have to rebuild with -O0
to regain debuggability and sanity.
Simo.
--
Simo Sorce * Re
em with how name resolution works
> > on a Linux system. Windows has had a default system-wide DNS cache
> > for over a decade. It is about time that Linux catches up.
>
> I observe you pointedly ignore the existence of nscd (which does not
> require any changes to resolv.conf)
On Wed, 2014-04-23 at 05:36 +0200, Lennart Poettering wrote:
> On Tue, 22.04.14 09:10, Simo Sorce (s...@redhat.com) wrote:
>
> > > I am pretty sure that a pull model should be the default for everything
> > > we do, and push only be done where realtimish behaviour is
On Tue, 2014-04-22 at 20:58 +0200, Miloslav Trmač wrote:
> 2014-04-22 20:19 GMT+02:00 Simo Sorce :
>
> > On Tue, 2014-04-22 at 19:04 +0200, Miloslav Trmač wrote:
> > > 2014-04-22 15:10 GMT+02:00 Simo Sorce :
> > >
> > > > A good protocol would allow
On Tue, 2014-04-22 at 14:41 -0400, Russell Doty wrote:
> On Tue, 2014-04-22 at 14:23 -0400, Simo Sorce wrote:
> > On Tue, 2014-04-22 at 13:22 -0400, Russell Doty wrote:
> > > On Tue, 2014-04-22 at 19:01 +0200, Miloslav Trmač wrote:
> > > > 2014-04-22 13:
threats to system integrity.
All very true, but you do not remove the Deterrent, just because you
have the other 4 layers (which we do *not* have very much in Fedora when
it is used as a simple workstation).
This is why people say we need to improve the Firewall experience not
ra
On Tue, 2014-04-22 at 19:04 +0200, Miloslav Trmač wrote:
> 2014-04-22 15:10 GMT+02:00 Simo Sorce :
>
> > A good protocol would allow to send a first small
> > packet that establish a connection and a reply that can "push back" on
> > the client w/o re
suchlike.
>
> I am pretty sure the push model concept is one of the major weaknesses
> of the BSD syslog protocol.
Except that the server may not need direct access to the clients (in
NATted LANs for examples), so sometimes push is all you can count on,
make sure you can think how
ome so lengthy and
> complicated that nobody would read them.
>
> I'm not saying adding additional Foundations or rewording the existing
> ones should never be done, but I do think these specific items you
> mention don't necessarily warrant it at this time.
Big +1
Simo.
-
On Wed, 2014-04-16 at 18:43 +0200, Tomasz Torcz wrote:
> On Wed, Apr 16, 2014 at 12:32:02PM -0400, Simo Sorce wrote:
> > > > I think what you are describing could be probably realized with SELinux
> > > > today, just with a special setroubleshoot frontend that catch
On Wed, 2014-04-16 at 15:04 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Apr 15, 2014 at 03:30:57PM -0400, Simo Sorce wrote:
> > > I'd imagine that in a setup with a few servers one would create
> > > the certificates on the receiver machine, copy&pastin
e we can shoot for a simplified middle ground to start
with.
> Otherwise, I won't be astounded at all when FESCo rejects the current
> Change and some users still turn off the firewall as one of the first
> things they do because things don't work.
Right, if nothing is done the only sensible solution is for FESCo to
refuse the change, and then the only recourse a lot of user will have is
to turn it off first thing :-(
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Wed, 2014-04-16 at 05:40 -0700, Daniel J Walsh wrote:
> On 04/15/2014 09:31 AM, Simo Sorce wrote:
> > On Tue, 2014-04-15 at 09:13 -0700, Andrew Lutomirski wrote:
> >> I keep thinking that, if I had unlimited time, I'd write a totally
> >> different kind of firew
s (like home, work, cafe, library, etc..) perhaps by cloning
existing ones and then tweak the list of applications allowed to serve
content in those zones.
It would be better if the association were per-application rather then
nameless ports.
Simo.
--
Simo Sorce * Red Hat, Inc *
On Tue, 2014-04-15 at 20:28 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Apr 15, 2014 at 11:00:45AM -0400, Simo Sorce wrote:
> > On Mon, 2014-04-14 at 15:07 +0200, Jaroslav Reznik wrote:
> > > = Proposed Self Contained Change: Remote Journal Logging =
> >
> &g
vices on bad
networks too, it is not a binary open/close equation when you have
machines (laptops) that roam across a variety of networks.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2014-04-15 at 09:16 -0700, Andrew Lutomirski wrote:
> On Tue, Apr 15, 2014 at 9:07 AM, Simo Sorce wrote:
> > On Tue, 2014-04-15 at 08:47 -0700, Andrew Lutomirski wrote:
> >> I don't know whether this should be a gnome-boxes bug, an rpcbind bug,
> >> or a
nfs-utils exceptions? Should I file a bug against
> libvirt?
Shouldn't rpcbind be simply a dependency for
nfs-server.service/nfs-secure-server.service and be started only if the
nfs server is started ?
I forgot if we need it for anything else.
Simo.
--
Simo Sorce * Red Hat, Inc * New Y
r machines that are regularly brought on insecure networks
(all sorts of open wifi, and foreign LANs).
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
t been considered ?
What are the pros of using HTTP if all you are doing are POSTS to a
hardcoded URL ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
eeded to mark a zone as trusted, in all other
zones the user will have to select explicitly what applications are
allowed.
So the big work here is in the UI you need to build to present these
configurations to the user.
Until then you can present a very simplified UI that just has a big
button/swit
d firewall policy for the workstation product that opens the
> additional ports for DAAP, UPnp, etc.?
Indeed, that would be a more reasonable approach.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.or
On Tue, 2014-04-15 at 13:48 +0930, William Brown wrote:
> On Mon, 2014-04-14 at 23:57 -0400, Simo Sorce wrote:
> > On Tue, 2014-04-15 at 08:49 +0700, Michel Alexandre Salim wrote:
> > > On 04/14/2014 09:21 PM, Andrew Lutomirski wrote:
> > > > On Mon, Apr 14, 2014 at 6
hanism, what you loose is the ability to properly
recover a system.
I am not saying you shouldn't be allowed to do passwd -l, but that
should not be mandated by the system configuration, purely a choice of
individual admins.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Mon, 2014-04-14 at 09:44 +0200, Stanislav Ochotnicky wrote:
> On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
> > [snip] I know little to nothing about java bindings so if it is
> > substantial work I will just remove the java binding and ask rel eng to
> > pull the
On Mon, 2014-04-14 at 09:24 +0100, Mat Booth wrote:
> On 14 April 2014 08:44, Stanislav Ochotnicky wrote:
>
> > On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
> > > [snip] I know little to nothing about java bindings so if it is
> > > substantial work I wil
Thanks a lot,
I will push this patch and rebuild in rawhide.
Simo.
On Mon, 2014-04-14 at 09:44 +0200, Stanislav Ochotnicky wrote:
> On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote:
> > [snip] I know little to nothing about java bindings so if it is
> > substantial work I w
ings and the C library really, but I compiled the java bindings in
if someone wanted to use it.
What is the path forward here ? Should I just drop the java bindings ?
Or do I just get some other dependency in ?
note I know little to nothing about java bindings so if it is
substantial work I will ju
On Sun, 2014-04-13 at 18:18 +0100, Richard W.M. Jones wrote:
> On Sat, Apr 12, 2014 at 04:12:41PM -0400, Simo Sorce wrote:
> > So you've gone out of your way to run a daemon but prevent it from
> > working as configured, instead of just reconfiguring it to do what you
> &g
On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote:
> On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:
> > On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
> >
> > > A system wide resolver I am not opposed to. I am against a system wide
> > > *cachi
for these issues. But of course it is just a
default, on your network you'll be able to change the resolvers however
you want.
The only thing I agree on is that the default MUST use the forwarders
provided by the local DHCP unless the user explicitly configured
otherwise.
Simo.
--
Simo Sorc
tioned the single configuration option need to make your
resolver tweak the TTL locally, what else do you need ? And again why
your preference should be the default ? What compelling arguments can
you make ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
deve
On Sun, 2014-04-13 at 00:52 -0400, Felix Miata wrote:
> On 2014-04-12 16:12 (GMT-0400) Simo Sorce composed:
> > On Sat, 2014-04-12 at 13:11 -0400, Felix Miata wrote:
> >> I've been doing that myself for years on installations that think my
> >> ethernet-only non-wi
SAPI
in internal networks too.
The era of the clear text trusted private network is coming to an end,
whether you like it or not.
> if you don't trust the network itself you are lost anyways
Let me troll a bit, this is why you do all your banking without
HTTPS ? :-)
I am strongly i
t is extremely simple to configure it to
keep fixed DNS Servers as well as have static addresses for ethernet
interfaces.
I find that today, except extremely rare case, all that people that
complain about network management tools interfering are people that
never tried or tried once *years* ago and ne
d
> shouldn't get in the way. All applications/glibc would query
> 127.0.0.1, which would immediately forward all those requests to the
> local unbound+dnssec-triggerd setup. Dnslookupd would only take
> action if unbound died for some reason (and if there was an alternate
&
ly occasionally unbound seem to get
confused, not clear when, it doesn't happen more than twice a month and
systemctl restart unbound.service fixes it.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/li
e
networks. You really want to be able to resolve the local resources and
they are only resolvable if you consult the local DNS as provided to you
by DHCP.
For hotspots in public places that doesn't matter as much of course.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel maili
On Fri, 2014-04-11 at 19:01 +0200, Lennart Poettering wrote:
> On Fri, 11.04.14 12:47, Simo Sorce (s...@redhat.com) wrote:
>
> > > So how about this then, we have a drop-in dir in /usr as above, with
> > > files that list the numeric UID where possible. For the case
), but not for early-boot
> services, which sounds like a OK restriction to make to me.
It is just a recipe for disaster, you are making the whole system
fragile in order to handle a corner case.
> With that in place the population of /etc/passwd would be unnecessary.
>
>
port package installation on top of a
> base tree more complex as we really do need NSS in place during tree
> construction. I'll think about this, but I suspect this may end with
> ostree understanding the NSS configuration.
Keep in mind accounts may not even be in /etc/pass
ough setuid or other mechanisms...The
> following programs are NOT PREVENTED from accessing the root account:
> su, sudo, ssh, scp, sftp"
>
> On Thu, Apr 3, 2014 at 6:06 AM, Simo Sorce wrote:
> > On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote:
> >> On Wed,
On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote:
> On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote:
> > How does someone express strong disagreement to this change ?
>
> Posting here is a good start. You can also add a note in the FESCo ticket
> for approval
but I do
not understand what is the point of blocking console login as root.
Please explain the logic of blocking console logins but allowing SSH
logins, it is completely backwards.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admi
On Thu, 2014-03-27 at 18:18 -0400, Simo Sorce wrote:
> On Thu, 2014-03-27 at 22:59 +0100, Lennart Poettering wrote:
> > On Wed, 26.03.14 13:43, Stephen Gallagher (sgall...@redhat.com) wrote:
> >
> > > > Note that PrivateNetwork=yes should not be used for:
> &
don't even see how
> that could ever work...
>
> > We'd need to think very hard about whether any service should have
> > this turned on by default. If we *do* enable it by default, we should
> > also carefully document how to turn it off for those services if they
>
affect the SSSD daemon. So yeah, that
> would probably work just fine. I didn't think that all the way through
> originally.
>
> This probably can break people using nss_ldap or nss_winbind, though.
Only people using the old nss_ldap.
nss_ldapd, nss_winbind, like nss_sss talks
he
> main developers decide is cool or not at the time. You should give us
> and distributions in general more than 4 days to deal with what lives
> or not. Ultimately systemd is no longer in nappies and is all grown
> up, while you are still it's father it's now a teenager a
her.
Please stop the childish molestation of this list, you know it's
useless, SELinux is not going to be removed or disabled by default.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
atives. Default FS on the Server is not actually a
> massive impact, LVM is a different decision and makes sense there.
> LVM on a workstation though, well, you can make it the default, but a
> couple of releases ago I started turning it off and will continue
> doing so. It adds an
really make me frown loudly...
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
for a Server OS.
Copying TBs of data can take quite some time, and being forced to do
that while keeping the server offline because there is no LVM layer to
automatically move all the blocks really sucks.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
de
t;feel" like
> systemctl, maybe "httpdctl" or so, that covers this, but I am pretty
> strongly of the opinion that that has no place in systemd.
https://httpd.apache.org/docs/current/programs/apachectl.html
But it is nothing like systemd, and does not handle enabling individu
On Fri, 2014-02-21 at 13:28 -0500, Stephen Gallagher wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/21/2014 01:14 PM, Matthias Runge wrote:
> > On Fri, Feb 21, 2014 at 10:36:24AM -0500, Simo Sorce wrote:
> >> +1 I still have an application that
stro, but it makes for a less rigid
> coupling between the OS and what framework version you need to use.
+1 I still have an application that is slowly moving to 1.5 but not
there yet and it is painful to have to keep an older Fedora Version
running just because of that.
Simo.
--
Simo Sorce * Red
edora-preset-workstation and vice-versa.
Both could Provide: 'fedora-preset' though.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
o check for
blacklisted sites and I am not sure what it sends there.
Unfortunately you have to go in about:config to change anything about
that IIRC.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
I think the matter has been expressed
well enough for devel and I do not think we need to further pollute the
list.
Thank you,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Co
On Sun, 2014-01-26 at 13:13 -0700, Chris Murphy wrote:
> On Jan 26, 2014, at 11:41 AM, Simo Sorce wrote:
>
> > I never said it won't work in absolute, it probably will work ok in many
> > cases, just to cause incredible issues in others.
> >
> > It is a fine
On Sat, 2014-01-25 at 15:04 -0500, Colin Walters wrote:
> Hi Simo,
>
> On Sat, 2014-01-25 at 14:55 -0500, Simo Sorce wrote:
>
> > The reason is simple: lot's of software *changes* data as part of its
> > normal functioning, including and often in rollback-incomp
27;s just not that common in my experience.
What about mail application change the format of the mail folders ?
It happens, and it is *not* data you want to risk throwing away. There
are many other examples like this especially on the server side.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
de
On Sat, 2014-01-25 at 17:28 -0700, Chris Murphy wrote:
> On Jan 25, 2014, at 12:55 PM, Simo Sorce wrote:
>
> > The reason is simple: lot's of software *changes* data as part of its
> > normal functioning, including and often in rollback-incompatible ways.
> >
pstreams that care for portability and can't rely
on dbus (yet), so I think you need to care for the problem anyway.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
on as a
new version binary is run.
It is basically impossible to find applications that handle the case
where you downgrade, in any more graceful way than punting and failing
to start in the *good* case. In the bad case they start and trash the
database.
And by database, do not think SQL/NOSQL engines only, it can be any
simple dataset in a file, including configuration files in user's homes.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
quot; if there is no password request.
Of course you need to understand at least a smidget of security to avoid
proposing ludicrous 'defaults'.
> what you propose is the Apple way - not on a linux system please
It is just 'the pwn me' way, nothing more, nothing less.
pen to ideas, thanks.
Does it need all the data upfront ?
Maybe you can have a small place with initial metadata that contains a
subset of the packages and is quick to download so you can show
something then in the background start downloading the real full
metadata and update the UI as data comes
On Mon, 2014-01-20 at 08:42 +0100, Michael Schwendt wrote:
> On Sun, 19 Jan 2014 23:02:24 -0500, Simo Sorce wrote:
>
> > > Anyone not aware of the problem and the fix, who applies the -117.fc20
> > > selinux-policy update in _enforcing_ mode (since it has entered stable
kage is up-to-date. The enhanced fix that adds
> '\*' works also for this extra problem:
>
> setenforce 0
> yum clean expire-cache
> yum update selinux-policy\*
> setenforce 1
>
> [...]
[snip]
--
Simo Sorce * Red Hat, Inc * New York
--
devel ma
On Tue, 2013-11-26 at 08:59 -0500, Stephen Gallagher wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/26/2013 08:34 AM, Simo Sorce wrote:
> > On Tue, 2013-11-26 at 12:02 +0100, Matthias Runge wrote:
> >> On 11/25/2013 06:51 PM, Simo Sorce wrote:
> &
On Tue, 2013-11-26 at 12:02 +0100, Matthias Runge wrote:
> On 11/25/2013 06:51 PM, Simo Sorce wrote:
> > On Mon, 2013-11-25 at 11:24 -0500, Stephen Gallagher wrote:
>
> >>>
> >>
> >> This is kind of why I keep coming back to: "Why do we have
>
uld just be carrying whichever two versions are supported by
> upstream at any given time. Upstream is very good about maintaining
> bugfixes and security fixes in both supported streams.
+1 by changing version the current way, the only ting we can guarantee
is a lot of broken packages all the time.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
or with the upstream libev.
>
> libverto should be fixed upstream here IMHO.
Libverto builds against both libevent and libev being a event loop
abstraction library, if you make libev and libevent conflict libeverto
cannot be built anymore.
It makes not sense to make libev and libeve
't make that assumption only because some people came to a
conclusion you do not like.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
l that I have already used in the past for development.
It makes developing changes to packages and letting other users test
them very easy, thanks a lot!
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ce should be
> completely different than a system level rpm.
Excellent summary Alberto,
I recently felt on my skin what it means to be locked in a buggy version
of LiberOffice. Making it simple for user to install the upstream
version instead of our bundled one would help *a lot* all free software
user
301 - 400 of 693 matches
Mail list logo
