fre 2022-04-01 klockan 12:14 +0200 skrev Jonathan Schleifer:
> Has anyone seen or knows how to contact hno? hno maintains electrum
> and
> is unresponsive on bugs, PRs and direct e-mails.
I am around. But not very active at the computer at home. Expect a week
or two response time normally.
>
tor 2021-09-23 klockan 11:29 +0200 skrev Miro Hrončok:
>
> However, I think side-tags should be the preferred solution, as their
> impact is
> isolated. Buildroot overrides create temporary broken dependencies
> for
> everybody, while side-tags don't.
For stable releases I think I agree, even
I recently took ownership of Radare2 after it was orphaned,
unfortunately unknowing of the current turmult in the Radare2 project.
Now realizing that it has a dependent Fedora package Cutter (cutter-re)
which is at the edge of this turmult. And pushing an update of Radare2
will break Cutter.
It
I recently took ownership of Radare2 after it was orphaned,
unfortunately unknowing of the current turmult in the Radare2 project.
Now realizing that it has a dependent Fedora package Cutter (cutter-re)
which is at the edge of this turmult. And pushing an update of Radare2
will break Cutter.
It
I recently took over Radare2 maintenance for Fedora after it was
orphaned, and now noticed it is also packaged in EPEL-8.
I am not in a good position to actively maintain the EPEL-8 release. I
am not an EPEL user, no interest in EPEL, and and not very comfortable
with doing "blind" maintenance by
These are python packages currently assigned to me but I am not in a
position to keep maintainging them.
If there is anyone interested in taking over them please speak up.
Otherwise I will orphan them in 2 weeks. Thise in CC are either co-
maintainer of one of the packages or have indicated
lör 2011-11-19 klockan 00:23 -0500 skrev Gregory Maxwell:
This use to be more true, but there are multiple levels of -Wstrict-aliasing
and
I would be _highly_ surprised if the default gave a false alarm. I think you
can reliably say that if you get a warning at the default level then you do
tis 2011-11-22 klockan 17:51 + skrev Jóhann B. Guðmundsson:
What do people see as pros and cons continuing to use the current
package ownership model?
ownership is some times misappropriated with others doing all the work,
but it's also of little practical meaning in the end.
Would
tis 2011-11-22 klockan 13:03 -0800 skrev Adam Williamson:
* Any custom choices the package maintainer opts to provide, via some
kind of interface to Bodhi
* Checkboxes per bug assigned to the update for indicating that the
update have been verified to fix that specific bug.
* When the update
tis 2011-11-22 klockan 14:03 -0800 skrev Adam Williamson:
The proposal is to treat a PT hitting the panic button even more
dramatically than a registered user hitting it, the idea being that PTs
should be somewhat better informed and hence less likely to trigger it
falsely, and that we have
lör 2011-11-12 klockan 09:04 -0500 skrev Sam Varshavchik:
For the longest time, I was able to upgrade an existing system by copying
over the pxeboot vmlinuz and initrd.img, sticking them into menu.lst, and
directing grub to load them.
This is also how I install. Have worked fine with both
ons 2011-11-09 klockan 02:06 +0100 skrev Lennart Poettering:
That said, I am not particularly keen on having an inflation of subdirs
in /tmp created at early boot. I'd much prefer if we design our stuff in
a robust way so that directories are created when they are needed, but
without them
fre 2011-11-04 klockan 13:12 -0400 skrev Tom Lane:
Packages that rebuilt successfully with 1.5 658
Packages that FTBFS for non-libpng reasons186
Packages that rebuilt with 1.4, but not 1.5 74
Packages that need help even with 1.4 46
With this data my gut feeling is to go for
fre 2011-11-04 klockan 11:53 -0600 skrev Kevin Fenzi:
If we do this, next cycle we should NOT do any 'two part' go/no-go
meetings.
The two part meetings were both about critical blockers that were
known and actively being worked on at the time of the meeting. This
situation will happen no
sön 2011-10-23 klockan 23:45 -0700 skrev Adam Williamson:
This would cause significant problems around crunch times. We would wind
up having to have releng super-push far more updates because we simply
don't always *have* three days to wait to hit deadlines.
note that I only proposed
sön 2011-10-23 klockan 17:04 -0500 skrev Rex Dieter:
The fail(*), imo, was with 12.999 going stable containing known-regressions.
So, any suggestions, if any, to prevent any similar series of events?
My suggestions:
Disable automatic push to stable when there is any negative karma,
tor 2011-10-13 klockan 12:32 -0600 skrev Kevin Fenzi:
Currently there's not a way to do this, but there really should be.
https://fedorahosted.org/fedora-infrastructure/ticket/2977
Not even uploading an empty key file?
--
devel mailing list
devel@lists.fedoraproject.org
The password change is understandable, but why force an SSH key change
with such short notice?
And what if the SSH key is a hard token (smartcard) which can not be
copied or trivially changed? Switching to a soft key would be mostly
counter-productive from a security point of view. Now I were not
tis 2011-10-11 klockan 10:49 -0700 skrev Adam Williamson:
There obviously is a _legitimate_ question as to whether you ought to be
able to add your package into anyone else's update if you aren't a
provenpackager; it's not necessarily something we'd want to do. But I
think provenpackagers
mån 2011-10-10 klockan 20:44 +0200 skrev Thomas Spura:
Forcing only critpath packages being in updates-testing and the rest
being allowed to push to stable directly would help to fix issues much
faster.
You could set stable karma threshold to 1. It's then sufficient one
tester gives positive
ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
Lots of people use and share keys across different projects.
There is no security issue in sharing kes across different projects,
other than that it gives a strong hint that you are the same person in
both projects, much stronger than name
ons 2011-10-12 klockan 13:25 -0500 skrev Jon Ciesla:
Plus, you could have multiple
keys, all with the same passphrase, for different things, should you so
desire.
That's effectively one shared key for all. If one of them are
compromized them most likely all of them are, as the attacker
ons 2011-10-12 klockan 19:22 +0100 skrev Peter Robinson:
If your using a hard token you should be using a subkeys I believe and
not the root key, not sure if that's gpg or ssh or both.
subkeys is not relevant to the SSH world. That's a OpenPGP thing where
the main key should only be used for
ons 2011-10-12 klockan 12:20 -0700 skrev Adam Williamson:
Sure there is. There's the exact same problem as using the same password
across multiple projects: if someone compromises the key they have
compromised all of those projects. If you use a different key for each
project, an attacker can
ons 2011-10-12 klockan 13:49 -0600 skrev Kevin Fenzi:
If you can't change your token, then I would posit you have a problem.
What if you KNEW your private key was compromised? Surely there is a
way to generate a new one...
I can change it, but it means changing it for all sytems I access
ons 2011-10-12 klockan 14:59 -0500 skrev Mike McGrath:
1) People share keys across different projects.
Yes.
2) We've found PRIVATE keys on our servers
Which should lead to immediate account suspension, no matter if that key
is the Fedora key or some other key.
And in reality it's not
ons 2011-10-12 klockan 15:15 -0500 skrev Jon Ciesla:
Well, no, actually it just means you just need to use a different key for
Fedora. There's no reason you can't keep using that key everywhere else
you're using it.
Sure I could buy another token just for fedora, just don't see what it
would
ons 2011-10-12 klockan 21:41 +0200 skrev Thomas Spura:
I set them often to 1, but don't want to upkarma my own update because
it feels like cheating...
Especially updates, that fix a broken package, are an examples, that the
current path (with forcing updates in updates-testing) taken is
lör 2011-05-14 klockan 12:10 -0400 skrev Dave Jones:
It used to be a module, but was converted to built-in as we were always
loading it in the network scripts. A lot of the decisions made in
those '5 second boot' days seem a bit boneheaded in hindsight.
For f16, we should do a good re-review
lör 2011-05-14 klockan 19:33 +0200 skrev Xose Vazquez Perez:
default is 24010, but it was reduced to 1024 by
user(included root) in: /etc/security/limits.d/90-nproc.conf
to prevent accidental fork bombs(see rhbz #432903).
Is it still worth it? The kernel brings oom_kill.
Yes it's needed.
fre 2011-01-14 klockan 16:16 -0500 skrev Nathaniel McCallum:
I still think migrating to GNOME shell by default was a mistake if the
proper fallbacks were not in place. If the developers knew the
fallbacks were not implemented (this seems to be the case), why was it
ever enabled by default?
lör 2010-12-25 klockan 17:09 -0500 skrev Orcan Ogetbil:
On Sat, Dec 25, 2010 at 5:02 PM, Tom Lane wrote:
Michael Schwendt writes:
On Sat, 25 Dec 2010 14:33:37 -0500, Tom wrote:
I'm still on F13, but theoretically it should be the same no?
You are on x86_64, right?
I would estimate
tis 2010-12-21 klockan 11:47 -0500 skrev Colin Walters:
But they still have uid 0, which typical system installation allows
root to do things. For example, /bin/sh is 0755 and /bin is also 0755
perms. A disarmed root process can still trojan a system. But what if
we got rid of all the
tis 2010-12-21 klockan 18:52 -0500 skrev i.g...@comcast.net:
Ok, so who says that the files must be owned by root? Make them owned by
some other user -- say, bin? (or does that have another use that my
google search isn't coming up with?)
Better to make the process not run as root imho.
ons 2010-12-22 klockan 00:59 +0100 skrev Miloslav Trmač:
This is possible, but it would be a much larger change to the system.
To take a particular example, look at /etc/shadow.
It needs to be protected against attackers, so it should not be owned by
root - let's make it owned by adm, say.
tis 2010-12-21 klockan 13:02 -0500 skrev Matt McCutchen:
updates-testing explicitly. Either variant of the approach has the
danger though that because a build needs one thing from updates-testing,
it will end up getting something else from updates-testing that the
maintainer didn't expect.
tis 2010-12-21 klockan 09:50 -0700 skrev Kevin Fenzi:
Basically it's changing spec files BuildRequires to suit our build
setup and not for 'the version this package needs to build'.
True. And it's use should be limited to the release branches of a
package, not master/rawhide.
Imho it adds
fre 2010-12-17 klockan 11:22 +0100 skrev Michael Schwendt:
+1 to some way of automating koji buildroot overrides (perhaps based
on FAS group membership such as provenpackagers) in order to remove
the releng bottleneck.
Suggestion on how to express this in the packaging process:
BuildRequires
fre 2010-12-17 klockan 11:08 -0700 skrev Kevin Fenzi:
For the second point, I'm not sure what the delay time people are
seeing is. Currently Rex is doing almost all of these overrides.
Perhaps we could get some more folks to step up to process them? Or
open them up to provenpackagers or
mån 2010-12-20 klockan 15:58 -0500 skrev seth vidal:
So you want contingency fall-through deps?
ie: BuildRequires: foo = 1.1.1 (but if that's not available foo =
1.0.0)?
No, not quite.
pull in foo-1.1.1 from updates-testing if the requirement can not be
satisfied from updates. Applied
mån 2010-12-20 klockan 16:01 -0500 skrev Tom Callaway:
I think a simpler idea is a minimal webapp (and perhaps a CLI interface)
that lets you login with your FAS account and request an override on a
built package that you have permissions for (and at the same time,
choose how long the
mån 2010-12-20 klockan 16:15 -0500 skrev seth vidal:
So you want to give updates-testing preferential value over updates
despite their being no e-v-r difference between the pkgs? If so - you
can do that now with yum's cost value.
No. The stable repositories (updates / dist) always have
mån 2010-12-20 klockan 14:42 -0800 skrev Jesse Keating:
Perhaps you don't understand how the buildsystem works. The build
system does not use our external Updates or updates-testing
repositories. It doesn't use multiple repositories either. It uses an
internal repository that is the latest
mån 2010-12-20 klockan 18:12 -0500 skrev Matt McCutchen:
That will work, assuming the user has permission to do the tagging; it
is essentially a buildroot override in reverse. So the question is just
what we want to optimize for: more testing of packages while they are in
testing, or less
tis 2010-12-07 klockan 19:20 -0500 skrev Doug Ledford:
For non-boot devices, loopback works. You only need the hardware if you
are testing boot time capabilities (which, admittedly, is the far more
important aspect of testing for this package).
And if you don't have spare systems with more
ons 2010-12-08 klockan 11:41 + skrev Peter Robinson:
It was my understanding that abrt was suppose to block on backtraces
without debuginfo but I still regularly get bugs with little or no
decent info.
True. I accidently filed a such abrt report some time ago. I assumed it
would fetch the
tis 2010-12-07 klockan 20:53 +0100 skrev Andreas Tunek:
Shouldn't the end of life message reflect that then? It should tell me
to contact a bug zapper to move the bug report.
I think the reporter can move the bug report as well. At least I have a
memory of doing so on some of the bugs I have
tis 2010-12-07 klockan 10:20 -0800 skrev Jesse Keating:
While I'm looking into the git setup and ACLs and all this, I have a
question.
Is anybody seeing any real value of having different commit ACLs per
Fedora branch? I've seen some argument for EPEL vs Fedora, but is there
real value in
mån 2010-11-22 klockan 18:51 +0100 skrev Björn Persson:
Henrik Nordström wrote:
* Slight adjustment of karma to provide choices Works for me, Problem
still present and New problems seen
* Works for me is a +1, and also adds the refereced bug as fixed by
the update if not already
sön 2010-11-21 klockan 11:00 +0100 skrev Till Maas:
I guess this can be somehow automated. E.g. change Bodhi to drop the
karma requirements for packages that had e.g. two subsequent updates
without any Bodhi feedback and re-enable it if they get feedback.
That would be somewhat counter
fre 2010-11-05 klockan 12:53 + skrev Jóhann B. Guðmundsson:
Reports came in Auto responce reply back to the reporter -- QA
verified try to duplicate bug -- Bug set to maintainer -- Bug stayed
like that until EOL
You forgot
Bug was actually fixed from upstream relase, but the
lör 2010-11-06 klockan 14:08 +0100 skrev Till Maas:
I have no problem to verify a bug when the maintainer is ready to fix
it. But it is pretty annoying to verify it within a small time window
regularly just to have it ignored till the next EOL date.
Understood. And the same issue is also on
fre 2010-11-05 klockan 21:37 +0100 skrev Michael Schwendt:
Something is terribly wrong here, if reporter adjusts F12 - F13 - F14
over a period of N months in reply to the automated NEEDINFO requests and
still doesn't get any response other than another automated one after
six more months.
tis 2010-11-02 klockan 00:32 +0200 skrev alekc...@googlemail.com:
What can expect user that have system booting with GRUB2 and installing
Fedora? It is natural to expect that after Fedora installation will be
bootable both systems Fedora and other distro.
As with all boot loaders it depends
mån 2010-11-01 klockan 10:09 -0700 skrev Adam Williamson:
I disagree. The evidence you cite does not support this conclusion. We
implemented the policies for three releases. There are significant
problems with one release. This does not justify the conclusion that the
policies should be
fre 2010-10-29 klockan 08:32 -0400 skrev James Antill:
I don't think you need to display them, just display something that
says this is more than it seems ... like ACLs. Something as simple as
-rwcr-xr-x. instead of -rwsr-xr-x. for setuid.
I.e. kind of like what ls --color does?
Regards
mån 2010-11-01 klockan 15:12 -0700 skrev Adam Williamson:
This is a reasonable modification of the idea that an update should only
require karma for one release (which would be nice if it were true but
unfortunately isn't). In practice, though, there isn't much wiggle room
for requiring
[changing topic to split this out to it's own thread]
mån 2010-11-01 klockan 15:12 -0700 skrev Adam Williamson:
We also need some obvious ways where users in general can subscribe to
testing updates of stuff that they care about, to expand the userbase
that performs testing of updates.
58 matches
Mail list logo
