Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, 2021-02-23 at 00:02 +0100, Kevin Kofler via devel wrote: > Well, this silent fallback behavior is one of the reasons I have > refused to > use systemd-resolved at all so far. > > The issue with the cloud setups would also have been caught much > earlier if > it had failed right away and not silently used an external DNServer. > Ignoring broken configuration and just using the default is not > useful error > handling. I guess having a fallback is a double-edged sword. On one hand, indeed, this issue with broken cloud-init would have been caught earlier, but on the other hand, some people couldn't care less which DNS servers are being used if things "just work". > > And the real issue is that systemd-resolved has broken cloud-init, so > cloud-init needs to be fixed/updated. Yes, this is the main issue for cloud setups. However, enabling/disabling a fallback is still an issue on its own. I wouldn't add much more since I think Lennart summed that up pretty well in his post. > It is unfortunate that this behavior has changed in an update. This is the thing that is probably hurting users the most. They have a working F33 cloud instance and after systemd is upgraded, the instance will *probably* (i.e. if users didn't configure DNS themselves and relied on cloud-init) be heavily broken, i.e. DNS resolution not working. I actually think it would still be beneficial to flip this change, i.e. remove the "-Ddns-servers=" line (https://src.fedoraproject.org/rpms/systemd/blob/f33/f/systemd.spec#_372 ), for the next F33 systemd update. > This has > happened because all the complaints about the old behavior back when > the > Change proposal was discussed (i.e., BEFORE Fedora 33 was released) > were > completely ignored by the Change owners and by FESCo (even though the > fix > was apparently a one-line change that could easily have been made > before the > release). I didn't follow that so I can't comment on it. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, 2021-02-23 at 08:19 -0600, Michael Catanzaro wrote: > On Tue, Feb 23, 2021 at 10:37 am, Tadej Janež wrote: > > I guess this is a simple solution that would work, but from what I > > understand it would also disable the use of systemd-resolved? > > Nah, it should just switch systemd-resolved into a consumer mode, > where > it reads configuration from /etc/resolv.conf and uses that as its > source of truth. Applications using glibc for name resolution (i.e. > almost everything) will still talk to systemd-resolved and ignore > /etc/resolv.conf. Oh, I see. Thanks for the explanation. > That's not the default configuration in Fedora, though. Writing to a > /etc/systemd/resolved.conf.d/*cloud-init.conf would be better though, > since it would avoid major changes to how systemd-resolved works. Agreed. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Tue, 2021-02-23 at 11:18 +0100, Petr Menšík wrote: > Sure, this part is more complex. But only this part can fix this > problem > from inside the container IMO. Ie. we could fix it faster for any > involved parties. > > I don't really run any container on any cloud service so this is just > my > guess. Who uses cloud-init to prepare the container? If it is used by > cloud provider, I would expect slow updates and conservative > behavior. > Even if we fix it immediately, how fast would appear on the service? > I > think the fix from within can be much sooner be used by users. I think there might be a slight confusion here. The use case I'm talking about doesn't involve any containers and how DNS resolving is performed therein. I'm thinking in terms of a vanilla Fedora Cloud image being used to provision a new VM and cloud-init performing its configuration and initialization. This use case is currently broken (i.e. DNS resolution is broken), since cloud-init doesn't properly configure DNS servers and fallback DNS servers have been removed. To fix this use case, we would just need to patch cloud-init as you described in your 1. solution: cloud-init would check the symlink and target of etc/resolv.conf. If it points to /run/systemd/resolve/*, write DNS=x y into /etc/systemd/resolved.conf.d/*cloud-init.conf And then propose the patch to cloud-init upstream and include it in Fedora's cloud-init package for Fedora 34. As I see it, this could be fixed by Fedora itself and is not blocked on any cloud provider or other external party? signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
Petr, thanks for looking into this. On Mon, 2021-02-22 at 18:30 +0100, Petr Menšík wrote: > After a quick glance at cloud-init code, it seems to me it does not > check /etc/resolv.conf for symlinks. > > It just reads /etc/resolv.conf if it is a file, then writes its own > nameservers into target. I have seen no rm of original > /etc/resolv.conf, > so I guess it rewritten target of symlink on Fedora 33: > /run/systemd/resolve/stub-resolv.conf Indeed, cloud-init just "blindly" amends the /etc/resolv.conf file which is a symlink to /run/systemd/resolve/stub-resolv.conf and hence gets overwritten by systemd-resolved. Here are the relevant snippets from a DigitalOcean instance's /var/log/cloud-init.log: ... trimmed ... digitalocean.py[DEBUG]: added dns servers: ['67.207.67.2', '67.207.67.3'] ... trimmed ... __init__.py[DEBUG]: Selected renderer 'sysconfig' from priority list: None util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth1 - wb: [644] 212 bytes util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- scripts/ifcfg-eth1 (recursive=False) util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- scripts/ifcfg-eth1 (recursive=False) util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth0 - wb: [644] 287 bytes util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- scripts/ifcfg-eth0 (recursive=False) util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network- scripts/ifcfg-eth0 (recursive=False) util.py[DEBUG]: Reading from /etc/resolv.conf (quiet=False) util.py[DEBUG]: Read 729 bytes from /etc/resolv.conf util.py[DEBUG]: Writing to /etc/resolv.conf - wb: [644] 846 bytes util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub- resolv.conf (recursive=False) util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub- resolv.conf (recursive=False) util.py[DEBUG]: Writing to /etc/NetworkManager/conf.d/99-cloud- init.conf - wb: [644] 89 bytes util.py[DEBUG]: Restoring selinux mode for /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False) util.py[DEBUG]: Restoring selinux mode for /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False) util.py[DEBUG]: Writing to /etc/udev/rules.d/70-persistent-net.rules - wb: [644] 192 bytes util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70- persistent-net.rules (recursive=False) util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70- persistent-net.rules (recursive=False) ... trimmed ... > I think there are two possible fixes: > * cloud-init would check the symlink and target of etc/resolv.conf. > If > it points to /run/systemd/resolve/*, write DNS=x y into > /etc/systemd/resolved.conf.d/*cloud-init.conf I think this option would be preferred. > * clound-init would always delete etc/resolv.conf before it writes > into > it, if it was symlink. I guess this is a simple solution that would work, but from what I understand it would also disable the use of systemd-resolved? > * systemd-resolved would check contents of link target of > /etc/resolv.conf on startup. If it leads to systemd, try parsing its > contents. If it does not look like managed contents of systemd, > assume > it might be misdirected resolv.conf configuration. Store it and wait > for > DHCP configuration. If no better configuration arrives, use > nameservers > from misdirected file. Would have to restore original resolv.conf on > shutdown to keep working after restarts. Should move it to > fallback.conf > and use it instead of built-in fallbacks? This seems too complex and error prone. Regards, Tadej signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mon, 2021-02-22 at 11:14 -0600, Michael Catanzaro wrote:
> On Mon, Feb 22, 2021 at 5:46 pm, Tomasz Torcz
> wrote:
> > But "dns = none" seems wrong.
>
> Well it would be the right choice if cloud-init were to manually
> configure a static list of DNS servers in /etc/systemd/resolved.conf
> (or, previously, /etc/resolv.conf), which is probably what you want
> for
> a cloud server.
Yes, cloud-init configures NetworkManager to not manage DNS if it has
DNS servers that it configures statically:
This is the relevant code snippet:
def _render_networkmanager_conf(network_state, templates=None):
content = networkmanager_conf.NetworkManagerConf("")
# If DNS server information is provided, configure
# NetworkManager to not manage dns, so that /etc/resolv.conf
# does not get clobbered.
if network_state.dns_nameservers:
content.set_section_keypair('main', 'dns', 'none')
Source:
https://github.com/canonical/cloud-init/blob/66e2d42dd1b722dc8e59f4e5990cea54f81ccd2a/cloudinit/net/sysconfig.py#L769-L776
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mon, 2021-02-22 at 09:45 -0600, Michael Catanzaro wrote: > On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz > wrote: > > 3) Configure DNS resolvers if you want to use DNS. > > Or dig deeper: why cloud-init disabled DNS on your installation? > > I'm pretty sure cloud-init just doesn't know how to configure > systemd-resolved at all. So I suspect this is a cloud-init bug. See: > https://pagure.io/fedora-server/issue/10. > > I have no strong opinion on whether the fallback should have been > removed or not. The fallback was only hiding the real problem, after > all. Indeed, this appears to be the case. For cloud images, I agree that the correct approach is to fix the root issue, i.e. make cloud-init understand and configure systemd-resolved. Regards, Tadej signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
systemd-resolved fallback DNS servers: usability vs. GDPR
Hi, I would like to question the decision that was made by systemd maintainers to remove the fallback DNS server list: https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d And then backported to F33: https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebcac34bdf7e7c7ae17322a2?branch=f33 On F33, this actually breaks a working vanilla cloud instance by removing the fallback DNS server list in a systemd upgrade, effectively leaving the system with no DNS servers configured. I described this in more detail here: https://lists.fedoraproject.org/archives/list/cl...@lists.fedoraproject.org/thread/72MRKIFGPMFGBS7XJ5T5I23NVDXXWVGR/ Zbigniew Jędrzejewski-Szmek wrote the following in the commit message accompanying the fallback DNS server list removal: > So hopefully users will not see any effect from the change done in > this patch. Right now I think it is better to avoid the legal and > privacy risk. If it turns out this change causes noticable problems, > we might want to reconsider. In particular we could use the fallback > servers only in containers and such which are not "personal" machines > and there is no particular person attached to them. I would argue that the change causes noticeable problems and we want to reconsider this change. In particular, I think cloud image users would prefer to have their cloud instances usable out of the box, i.e. have DNS working out-of-the box. Don't get me wrong, I understand the privacy concerns and I think Fedora should strive to protect the privacy of its users as much as possible, but at the same time, the circumstances of a cloud instance are probably very different from a e.g. workstation instance. Possible solutions that come to mind: 1) Use different defaults for different Fedora editions, e.g. container and cloud images include the fallback DNS servers list while workstation (and similar) images don't. 2) Pick a reputable DNS resolver that preserves users' privacy and doesn't log anything and configure it as a fallback DNS server. Here is a good summary of DNS resolvers and their privacy: https://privacytools.io/providers/dns/#dns Thoughts? Regards, Tadej P.S. I'm subscribed, but please keep me in Cc so I'll notice replies sooner. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Retired packages with maintainers
On Tue, 2020-05-12 at 16:19 -0700, Kevin Fenzi wrote: > On Tue, May 12, 2020 at 03:13:42PM +0200, Pierre-Yves Chibon wrote: > > On Tue, May 12, 2020 at 02:51:03PM +0200, Miro Hrončok wrote: > > > On 12. 05. 20 8:49, Pierre-Yves Chibon wrote: > > > > Finally, does everyone agree about the original request: > > > > "remove all maintainers > > > > of retired packages"? Or should we bring this to FESCo? > > > > > > If the procedure is "remove all maintainers if all branches are > > > retired or > > > EOL" than yes, this is a good thing. However, not sure if worth > > > spending > > > energy on. What are the benefits over status quo? > > > > Someone asked us to look into this, so I did, briefly. > > I am also very happy to close the ticket as "Won't fix" and move on > > :) > > I think it might be worth it... it makes it more clear how many > packages > someone maintains and what their status is. As someone who found himself in the list 3 times I would be very much in favor of removing myself as maintainer of these packages :) And since the script has already been written and it works, I would be in favor of deploying it somewhere where it runs periodically. Tadej ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Unretire Pew, Python environment wrapper
Hi, I would like to un-retire Pew. Upstream (https://github.com/berdario/pew/) is an active project and it was originally retired because it has been orphaned for more than 6 weeks on Dec 24, 2018: https://src.fedoraproject.org/rpms/pew/c/ca9ed68f8ca88ec93b06039f2cc7cf2873af22e3?branch=master. Here is my re-review request: https://bugzilla.redhat.com/show_bug.cgi?id=1720757 Regards, Tadej ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Intent to drop python2-tornado
Hi,
I pushed a new release of bup that removes the bup-web functionality
that depends on Tornado in Fedora 31+.
https://src.fedoraproject.org/rpms/bup/c/b14777d7e8f5ff196e43afbb0ab50e4c2c7a4749?branch=master
https://koji.fedoraproject.org/koji/buildinfo?buildID=1284210
Regards,
Tadej
On Mon, 2019-06-03 at 11:59 +0200, Miro Hrončok wrote:
> On 27. 05. 19 10:54, Miro Hrončok wrote:
> > On 20. 05. 19 11:26, Miro Hrončok wrote:
> > > I intend to drop python2-tornado. There are following dependent
> > > packages:
> > >
> > > - python-httpretty
> > > build time, for Python 2 tests, tests can be disabled
> > >
> > > - python-pika
> > > build time, for Python 2 tests, one file can be skipped
> > >
> > > - python-urllib3
> > > build time, for Python 2 tests, tests can be disabled
> > >
> > > - salt (and salt-{api,cloud,syndic,ssh,master,minion})
> > > runtime, python 3 switch is blocked by a fixable bug
> > > https://github.com/saltstack/salt/issues/51883
> > > salt is not required by anything
> > >
> > > - uwsgi-plugin-python2-tornado (from uwsgi)
> > > runtime, but not required by anything
> > >
> > > - bup and bup-web
> > > runtime and buildtime, but not required by anything
> >
> > https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Removing_Python_2_parts
> >
> >
> >
> > 7 days have passed.
> >
> > $ repoquery --repo=rawhide{,-source} --whatrequires python2-tornado
> > bup-0:0.29.2-3.fc30.src
> > bup-web-0:0.29.2-3.fc30.x86_64
> > python-httpretty-0:0.9.5-5.fc30.src
> > python-pika-0:1.0.1-1.fc31.src
> > python-urllib3-0:1.24.2-1.fc31.src
> > salt-0:2019.2.0-1.fc31.noarch
> > uwsgi-plugin-python2-tornado-0:2.0.17.1-10.fc31.x86_64
> >
> > If anybody wants to package python2-tornado before we drop it, let
> > me know in 2
> > weeks.
>
> Another 7 days have passed.
>
> $ repoquery --repo=rawhide{,-source} --whatrequires python2-tornado
> bup-0:0.29.2-3.fc30.src
> bup-web-0:0.29.2-3.fc30.x86_64
> python-httpretty-0:0.9.5-5.fc30.src
> salt-0:2019.2.0-1.fc31.noarch
> uwsgi-plugin-python2-tornado-0:2.0.17.1-10.fc31.x86_64
>
> If anybody wants to package python2-tornado before we drop it, let me
> know in 1
> week.
>
> > > Reasons below:
> > >
> > > Forwarded Message
> > > Subject: Let's update tornado to 6 and drop python2-torando
> > > Date: Wed, 15 May 2019 16:57:57 +0200
> > > From: Miro Hrončok
> > > Reply-To: Fedora Python SIG > > >
> > > Organisation: Red Hat
> > > To: Fedora Python SIG ,
> > > abomp...@fedoraproject.org, or...@fedoraproject.org,
> > > toms...@fedoraproject.org
> > >
> > > Hi.
> > >
> > > Tornado 6 doesn't support Python 2. Let's update the python-
> > > torando package to
> > > Python 3 only. There are several consumers of python2-torando and
> > > if their
> > > maintainers are interested, they can package it separately.
> > >
> > > $ dnf repoquery --repo=compose{,-source} --whatrequires python2-
> > > tornado
> > > bup-0:0.29.2-3.fc30.src
> > > bup-web-0:0.29.2-3.fc30.x86_64
> > > python-httpretty-0:0.9.5-5.fc30.src
> > > python-pika-0:1.0.1-1.fc31.src
> > > python-urllib3-0:1.24.2-1.fc31.src
> > > salt-0:2019.2.0-1.fc31.noarch
> > > uwsgi-plugin-python2-tornado-0:2.0.17.1-10.fc31.x86_64
> > >
> > > Note that tornado is often used to test things. We can (and
> > > should) just skip
> > > such tests from Python 2 httpretty, pika and urllib3.
> > >
> > > Is the plan OK? I'll talk to the dependent packages maintainers,
> > > but wanted to
> > > check with torando co-maintainers first.
> > >
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS UP: I plan to correct "python3 setup.py build" calls without proper flags
On Thu, 2019-02-07 at 00:45 +0100, Miro Hrončok wrote:
> On 06. 02. 19 22:16, Tadej Janež wrote:
> >
> > I've also found that one of my packages was settings CFLAGS to
> > %{optflags} and fixed it:
> > https://src.fedoraproject.org/rpms/bup/c/e960755aa88e1dcf84463faa66c9806a3508b54a?branch=master
>
> Nope, you've actually unfixed that.
>
> Fedora packages should use %{build_cflags} (historically available
> as
> %{optflags}). They should also use %{build_ldflags}.
>
> Fedora packages should not use %{extension_cflags} or
> %{extension_ldlags}.
Huh, I must have read the Change proposal too quickly. Thanks for
pointing out my mistake.
I've fixed it:
https://src.fedoraproject.org/rpms/bup/c/d2ea14f13fb034edfef46c4b97b23c6ef3ac5852?branch=master
Regarding %{build_ldflags}, I tried setting them via environment
variable:
%make_build CFLAGS="%{build_cflags}" LDFLAGS="%{build_ldflags}"
However, bup's configure script appears to think they are bogus and
reports:
ignoring bogus LDFLAGS="-Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld"
Here is the source code of that configure check:
https://github.com/bup/bup/blob/0.29.2/config/configure.inc#L494-L504
I'm afraid I don't know what's the problem here.
Regards,
Tadej
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: HEADS UP: I plan to correct "python3 setup.py build" calls without proper flags
Hi,
On Wed, 2019-02-06 at 15:04 +0100, Miro Hrončok wrote:
>
> I've grepped the usage and skimmed trough specs, destining the
> following list of
> packages that fail to properly set both flags.
I've also found that one of my packages was settings CFLAGS to
%{optflags} and fixed it:
https://src.fedoraproject.org/rpms/bup/c/e960755aa88e1dcf84463faa66c9806a3508b54a?branch=master
Regards,
Tadej
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
EuroPython 2017 Attende badge
Hi! We are a little late with the EuroPython Attendee badge this year, but nonetheless, it is available and I'm able to award it. So, if you attended this years EuroPython and would like to have this badge, just write to me. For more information, see: http://tadej.ja.nez.si/fedora-europython2017-attendee-badge.html Regards, Tadej ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: EPEL-ANNOUNCE Major par2cmdline update for EPEL7
On Mon, 2017-05-22 at 13:22 +0200, Tadej Janež wrote: > Hi, > > new version of par2cmdline (0.6.14) is available for testing in > EPEL7: > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a952af80fb > > I've decided to to this major update because: > - It switches to the more actively maintained fork: https://github.co > m/ > Parchive/par2cmdline. > - The version that is currently in EPEL7 (0.4.tbb.20100203-19.el7) > was > reported to not repair files and even leave them in worse condition > that before running par2cmdline: https://bugzilla.redhat.com/show_bug > .c > gi?id=1197560. > - The new version (0.6.14) has been included in Fedora 23+ since Nov > 29, 2015: https://bodhi.fedoraproject.org/updates/FEDORA-2015-d36d127 > ea > 7 and there were no reports of major problems. > > Since par2cmdline is used for recovering corrupted files and as part > of > backup solutions, I'm emailing this list to warn people about this > update. > > To give enough time for thorough testing, I'm planning on leaving > this > in testing for at least 2 weeks. Please, test and report back! The new version of par2cmdline (0.6.14) has been pushed to stable yesterday: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a952af80fb Regards, Tadej ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Re: Intent to retire Techne and Billiards
On Fri, 2017-05-12 at 23:02 +0200, Tadej Janež wrote: > > [... snip ...] > > Therefore, I intent to retire both packages in Rawhide in a week. > They have been retired. Regards, Tadej ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Intent to retire Techne and Billiards
Techne is a general purpose, programmable physical simulator and renderer [1]. Billiards is a cue sports simulator built on top of the Techne written by the same author [2]. Currently, billiards in the only package that requires techne. The reasons why I intent to retire them are the following: - Techne depends on webkitgtk which has been retired in Rawhide on Mar 14 2017 [3]. - Upon asking the upstream author whether he has any plans on updating Techne to WebKit2 [4], he said that he hasn't worked on that version of Techne (required by Billiards) for a while and that he hasn't had any communication on Billiards for a long time. - The last release of Billiards is from May 22 2012. - The last release of Techne that is required by Billiards is from May 21 2012. Therefore, I intent to retire both packages in Rawhide in a week. Regards, Tadej [1] http://www.nongnu.org/techne/ [2] http://www.nongnu.org/billiards/ [3] https://lists.fedoraproject.org/archives/list/devel@lists.fedorapro ject.org/message/QW6V6HXOTTCW5OZVEMI3ZVZGIMWTD2X6/ [4] http://lists.nongnu.org/archive/html/techne-devel/2017-04/msg0. html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unable to install packages in a Python 3 virtual environment created with venv module with --system-site-packages option
On Fri, 2017-02-10 at 15:28 +0100, Nick Coghlan wrote: > > On 8 February 2017 at 13:44, Tadej Janež <tade...@nez.si> wrote: > > > > As I see it, there are two issues when one has the aforementioned > > three > > way combination: > > > > 1) Users will probably use 'pip install foo' inside the activated > > virtual environment and be surprised by not being able to install > > anything. > > Many of them might not know the 'python -m pip install foo' > > variant. > > Right, that's why I consider the fact that doesn't work by default a > bug in Fedora's current approach. Agreed. And I'm very glad that this has already been fixed upstream, so we just have to wait until this lands in Fedora. > > 2) Users that know the 'python -m pip install' variant may want to > > install a package inside the virtual environment that is already > > available in system site-packages . The installation won't work > > unless > > they pass the '--ignore-installed' option or they install a newer > > version of the same package with '--upgrade' option. > > This, on the other hand, is why having the system site-packages > visible is discouraged in general - it really is more complicated > than > using an environment that only shares that standard library and the > language runtime. Agreed. This is a caveat with using the system site-packages and one has to accept such things if he needs a virtual environment with the system site-packages enabled. Thanks again for clearing this up for me! Regards, Tadej ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Unable to install packages in a Python 3 virtual environment created with venv module with --system-site-packages option
On Fri, 2017-02-10 at 09:34 -0500, Donald Stufft wrote: > > It’s not a Fedora bug really, it’s a venv bug, virtualenv has special > logic to > ensure pip actually gets installed with system site packages and when > we > Implemented that in venv I forgot to do it. It looks like it’s > already been > fixed upstream - https://bugs.python.org/issue24875. Ooh, that's great, I'm very glad that this has already been fixed upstream. Donald, thanks for the pointer! On Fri, 2017-02-10 at 12:09 -0500, Charalampos Stratakis wrote: > Since it is fixed upstream I'll backport the fix for rawhide and the > stable Fedora's as soon as http://bugs.python.org/issue29523 for > rawhide and the magic number issue for the stable ones are resolved. > Awesome! Charalampos thanks for your effort. Regards, Tadej ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Unable to install packages in a Python 3 virtual environment created with venv module with --system-site-packages option
On Thu, 2017-02-02 at 11:34 -0800, Craig Rodrigues wrote: > > Which in turn means 'pip3 install Django' actually used the system- > > wide > > pip3 command which tried to install Django to the system-wide > > location > > and failed. > > > > > > After you create your Python 3 virtualev, what files are in the bin > directory of your Pythin 3 virtualenv? [vagrant@tadej-zbook ~]$ ls -al myvenv3/bin/ total 20 drwxrwxr-x. 2 vagrant vagrant 4096 Feb 3 08:31 . drwxrwxr-x. 5 vagrant vagrant 4096 Feb 3 08:31 .. -rw-r--r--. 1 vagrant vagrant 2143 Feb 3 08:31 activate -rw-r--r--. 1 vagrant vagrant 1259 Feb 3 08:31 activate.csh -rw-r--r--. 1 vagrant vagrant 2397 Feb 3 08:31 activate.fish lrwxrwxrwx. 1 vagrant vagrant7 Feb 3 08:31 python -> python3 lrwxrwxrwx. 1 vagrant vagrant 16 Feb 3 08:31 python3 -> /usr/bin/python3 > Is there a pip file? No. > Once you are inside your virtualenv and sourced the bin/activate > script, my advice to you is to either: > > - just run the command "pip" Since there is no pip command in virtualenv's bin/ directory, pip is the global Python 2 version of pip: [vagrant@tadej-zbook ~]$ pip --version pip 8.1.2 from /usr/lib/python2.7/site-packages (python 2.7) > - run the command "python -m pip" Yay, this works: (myvenv3) [vagrant@tadej-zbook ~]$ python -m pip install Django Collecting Django Using cached Django-1.10.5-py2.py3-none-any.whl Installing collected packages: Django Successfully installed Django-1.10.5 So, this apparently boils down to: 1) If one uses "python3 -m venv --system-site-packages myvenv3", then no pip executable is installed in myvenv3/bin/. As a consequence, "pip install foo" fails since it tries to install foo in system's global site-packages directory. Using "python -m pip install foo" works as expected. 2) If one uses "python3 -m venv myvenv3-no-system", then pip (and pip3) executables are installed in myvenv3-no-system/bin/. Both, "pip install foo" and "python -m pip install foo" work as expected. Is this something specific to Fedora's Python 3 packaging? If not, I'll post a question to the distutils mailing list. Thanks, Tadej ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Unable to install packages in a Python 3 virtual environment created with venv module with --system-site-packages option
Hi! If I create a Python 2 virtual environment with virtualenv and the -- system-site-packages option, installation of any subsequent package works as expected: [vagrant@tadej-zbook ~]$ rpm -q python2-virtualenv python2-virtualenv-15.0.3-2.fc25.noarch [vagrant@tadej-zbook ~]$ virtualenv --system-site-packages myvenv2 New python executable in /home/vagrant/myvenv2/bin/python2 Also creating executable in /home/vagrant/myvenv2/bin/python Installing setuptools, pip, wheel...done. [vagrant@tadej-zbook ~]$ source myvenv2/bin/activate (myvenv2) [vagrant@tadej-zbook ~]$ pip install Django Collecting Django Downloading Django-1.10.5-py2.py3-none-any.whl (6.8MB) 100% || 6.8MB 214kB/s Installing collected packages: Django Successfully installed Django-1.10.5 On the other hand, if I create a Python 3 virtual environment with venv and use the --system-site-packages option, installation of any subsequent package fails: [vagrant@tadej-zbook ~]$ rpm -q python3-libs python3-libs-3.5.2-4.fc25.x86_64 [vagrant@tadej-zbook ~]$ python3 -m venv --system-site-packages myvenv3 [vagrant@tadej-zbook ~]$ source myvenv3/bin/activate (myvenv3) [vagrant@tadej-zbook ~]$ pip3 install Django Collecting Django Using cached Django-1.10.5-py2.py3-none-any.whl Installing collected packages: Django Exception: Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/pip/basecommand.py", line 215, in main status = self.run(options, args) File "/usr/lib/python3.5/site-packages/pip/commands/install.py", line 326, in run strip_file_prefix=options.strip_file_prefix, File "/usr/lib/python3.5/site-packages/pip/req/req_set.py", line 742, in install **kwargs File "/usr/lib/python3.5/site-packages/pip/req/req_install.py", line 834, in install strip_file_prefix=strip_file_prefix File "/usr/lib/python3.5/site-packages/pip/req/req_install.py", line 1037, in move_wheel_files strip_file_prefix=strip_file_prefix, File "/usr/lib/python3.5/site-packages/pip/wheel.py", line 346, in move_wheel_files clobber(source, lib_dir, True) File "/usr/lib/python3.5/site-packages/pip/wheel.py", line 317, in clobber ensure_dir(destdir) File "/usr/lib/python3.5/site-packages/pip/utils/__init__.py", line 83, in ensure_dir os.makedirs(path) File "/usr/lib64/python3.5/os.py", line 241, in makedirs mkdir(name, mode) PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.5/site-packages/Django-1.10.5.dist-info' Apparently pip inside the virtual environment tried to install Django to the system-wide location (/usr/lib/python3.5/site-packages/) and failed (as expected). But why did it try to install Django in the system-wide location instead of virtual environment's site-packages directory? Taking a closer look to the created Python 3 virtual environment reveals that it doesn't contain it's own pip3 command: (myvenv3) [vagrant@tadej-zbook ~]$ ls -al myvenv3/bin/ total 20 drwxrwxr-x. 2 vagrant vagrant 4096 Feb 2 14:49 . drwxrwxr-x. 5 vagrant vagrant 4096 Feb 2 14:49 .. -rw-r--r--. 1 vagrant vagrant 2143 Feb 2 14:49 activate -rw-r--r--. 1 vagrant vagrant 1259 Feb 2 14:49 activate.csh -rw-r--r--. 1 vagrant vagrant 2397 Feb 2 14:49 activate.fish lrwxrwxrwx. 1 vagrant vagrant7 Feb 2 14:49 python -> python3 lrwxrwxrwx. 1 vagrant vagrant 16 Feb 2 14:49 python3 -> /usr/bin/python3 Which in turn means 'pip3 install Django' actually used the system-wide pip3 command which tried to install Django to the system-wide location and failed. Is there a reason this behavior has changed compared to Python 2 and virtualenv command or is it simply a bug that I should report? Thanks for help and regards, Tadej ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Add Gparted into Live's
On Thu, 2014-07-31 at 20:38 -0400, Corey Sheldon wrote: F20 has it If you mean the Desktop Live image [1], it doesn't include gparted. Regards, Tadej [1] http://download.fedoraproject.org/pub/fedora/linux/releases/20/Live/x86_64/Fedora-Live-Desktop-x86_64-20-1.iso -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Add Gparted into Live's
Hi! On Thu, 2014-07-31 at 16:40 +0200, drago01 wrote: On Thu, Jul 31, 2014 at 4:38 PM, Ankur Sinha sanjay.an...@gmail.com wrote: On Thu, 2014-07-31 at 12:43 +0100, Álvaro Castillo wrote: Could add Gparted please? I think the desktop/workstation live includes the disks utility which has most if not all functionality that gparted does. I'm not sure of the other live images. Well yum install gparted works just fine on the live media ... live media are not as static as people think. Maybe it's unfair to the Disks utility, but when I partition my SSD drives, I tend to trust GParted more, since it clearly shows the Align: MiB option when creating a new partition. Otherwise, I agree that one partitioning utility is enough for the Desktop Live image. Regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Copr and Playground plugin part of dnf-plugins-core?
On Mon, 2014-04-28 at 09:47 +0200, Miroslav Suchý wrote: The votes are equal (48% vs. 52%) so I forwarded it to EnvStack WG, which is probably more appropriate than FeSCo. We discussed the issue on today's Env and Stacks WG meeting [1] and agreed on the following: The Env and Stacks WG's suggestion to the dnf-plugins-core maintainers is to create a separate dnf-plugin-copr package with the dnf-plugin-playground subpackage. In addition, we suggest to defer moving copr.py out of the dnf-plugin-core upstream git repository until DNF's API stabilizes (+1:5, 0:0, -1:0) Regards, Tadej [1] http://meetbot.fedoraproject.org/fedora-meeting/2014-04-29/env-and-stacks.2014-04-29-12.04.log.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Playground repository
Hi, sorry for being a bit late to the discussion. On Tue, 2014-04-08 at 12:23 -0500, Rex Dieter wrote: Adding repos definitely should not be taken lightly. Frankly, if 2 is really something worth doing, then perhaps also the (overly?) stringent policies need rethinking. The initial idea for the Playground repository came up as a frequently encountered need for something between the current Fedora's main repository and the COPRs. The former is comprised of very high-quality peer-review packages adhering to the Packaging Guidelines and the latter are just user-contributed RPMs which have almost no restrictions (besides being buildable by Copr and complying with the Fedora Licensing guidelines), so they could be of very high quality, very low quality or anything in between. I think this Change brings some cool new opportunities, where Fedora can research some new concepts and innovate: 1) This will be the first more generally-targeted repository that will came out entirely from Copr so we'll be able to see how Copr handles that. 2) Packages destined to the Playground repository will go through automatic testing/gating to ensure that they are up to some basic level of quality. As the tests will be automatic, they could also be repeated on every package update to provide some sort of continuous integration at the package level. If this proves to be successful, we could look at porting this to the main repository. 3) After the Playground sets off and we learn the process of spinning another repository, we could look at creating Playground++, a more stable Ring 2 repository around the main repository. 4) This could also spur some new thoughts on the current Packaging Guidelines and review process (e.g. Which parts are too strict? Which parts take the longest?), and as a consequence, help in improving it. Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Workstation: Enable Software Collections
On Tue, 2014-04-15 at 13:18 +0200, Jaroslav Reznik wrote: The Software Collections repositories will be enabled by default. * Policies and guidelines: Allow the inclusion of the software collections repositories in Fedora products Does the above refer to the repositories available at https://www.softwarecollections.org/en/? Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ImageMagick 6.8.8-10 in rawhide. Soname change.
Hi!
On Tue, 2014-04-08 at 18:30 +0400, Pavel Alexeev wrote:
Packages for rebuild:
$ repoquery --repoid=rawhide --whatrequires --alldeps ImageMagick\* |
fgrep -v 'ImageMagick-' | sort -u
As Michael Schwendt already pointed out, your query missed some packages
that need rebuilding (BTW, I noticed this because my package, techne,
was not listed on your list).
Comparing:
repoquery --whatrequires 'libMagick*.so.*' --repoid=rawhide --source
--qf '%{name}' | sed 's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | sort -u
to:
repoquery --whatrequires 'ImageMagick*' --repoid=rawhide --source --qf
'%{name}' | sed 's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | sort -u
revealed that the first command catches some packages that the second
command doesn't. These are:
ale
imageinfo
php-magickwand
php-pecl-imagick
psiconv
q
ripright
techne
But it also goes the other way around. The second command catches a lot
more packages that the first one. These are:
a2ps
anyremote
caja-extensions
c-graph
dblatex
epix
fbida
freewrl
fvwm
gallery2
...
Best regards,
Tadej
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[CANCELED] Agenda for Env-and-Stacks WG meeting (2014-03-25)
On Mon, 2014-03-24 at 15:20 -0400, Marcela Mašláňová wrote: WG meeting will be at 16:00 UTC, 17:00 Central Europe, 12:00 (noon) Boston, 9:00 San Francisco, 1:00 Tokyo in #fedora-meeting on Freenode. Today's meeting was canceled since there were only hhorak, drieden and me present. == Topic == * work more on Open Questions: https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29 * obs-signd is probably the easier to deploy - add ad proposed solution? * conflicts within Playground repo - discussed a little on mailing list, but no final proposal * 1 Big repo vs multiple small ones - discussed on mailing list, no consensus reached Please, share your opinions/thoughts on these topics in the appropriate mailing-list threads. The Conflicts policy and the 1 big repo vs. multiple small ones is an important decision that will affect further planning of the Playground repository and hence it is important to voice your views. Regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Agenda for Env-and-Stacks WG meeting (2014-03-11)
Hi Marcela, On Tue, 2014-03-11 at 12:39 +0100, Marcela Mašláňová wrote: WG meeting will be at 17:00 UTC in #fedora-meeting on Freenode. you probably meant 16:00 UTC, right? Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes for Env-and-Stacks WG meeting (2014-03-03)
On Tue, 2014-03-04 at 18:24 -0800, Toshio Kuratomi wrote: Did anyone forward the playground repo proposal on to FESCo? I guess not yet. Marcela put out an activity report for the Env-and-stacks WG yesterday (https://fedorahosted.org/fesco/ticket/1221#comment:28), which mentions the Playground repository draft. Is that enough? Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes from today's Env-and-Stacks WG Meeting (2014-01-21)
= #fedora-meeting: Env and Stacks (2014-01-21) = Meeting started by tjanez at 13:03:19 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-01-21/env-and-stacks.2014-01-21-13.03.log.html . Meeting summary --- * init process (tjanez, 13:05:29) * PRD follow-up (tjanez, 13:07:26) * We will wait for FESCo's comments/suggestions on the PRD and then make further clean-ups and modifications to it. (tjanez, 13:15:20) * Making a plan for the tasks/goals set in the PRD (tjanez, 13:15:54) * ACTION: juhp_ will create a proposal for a dedicated IRC channel and sent it to the ML (tjanez, 13:55:35) * AGREED: : We will expand the tasks/goals' description in the PRD and create separate Wiki pages for their description and the summary of their status. For logging of progress we will use a ticketing system (e.g. Trac) (+6,-0,0) (tjanez, 14:00:33) * Next week's chair (tjanez, 14:01:32) * FESCo will discuss the PRD on Wednesday's meeting (2014-01-22) (tjanez, 14:03:49) * ACTION: mmaslano will chair next meeting (mmaslano, 14:04:38) * ACTION: juhp_ will chair the meeting the week after that (2014-02-04) (tjanez, 14:05:19) * Open Floor (tjanez, 14:06:10) Meeting ended at 14:16:21 UTC. Action Items * juhp_ will create a proposal for a dedicated IRC channel and sent it to the ML * mmaslano will chair next meeting * juhp_ will chair the meeting the week after that (2014-02-04) Action Items, by person --- * juhp * juhp_ will create a proposal for a dedicated IRC channel and sent it to the ML * juhp_ will chair the meeting the week after that (2014-02-04) * juhp_ * juhp_ will create a proposal for a dedicated IRC channel and sent it to the ML * juhp_ will chair the meeting the week after that (2014-02-04) * mmaslano * mmaslano will chair next meeting * **UNASSIGNED** * (none) People Present (lines said) --- * juhp_ (72) * tjanez (58) * mmaslano (18) * hhorak (16) * bkabrda (7) * zodbot (6) * samkottler (4) * hhorak1 (1) * pkovar (1) * abadger1999 (0) * juhp (0) * handsome_pirate (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Kevin, On Thu, 2013-11-07 at 04:12 +0100, Kevin Kofler wrote: So where's the strawman? please stop with this. Simo wrote a rather long email post and argued he's view on users' freedom and all you did in reply was to nitpick on a footnote. Or in Simo's words again: On Tue, 2013-11-05 at 23:12 -0500, Simo Sorce wrote: If this is all you have to say about what I wrote (strawman on a note and ignore completely the rest) you have nothing valid to say in this discussion. Regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Call for ideas] Defining the scope of the Environments and stacks WG
Hi! I would like to invite all of you who are interested in helping defining the scope (i.e. what we will do document) of the Environments and stacks WG to join the discussion [0] at our new env-and-stacks mailing list [1]. If you have an idea/expectation/suggestion, please write it up. We especially encourage members of other WGs to express their expectations with respect to our WG, so we can align them better. Best regards, Tadej [0] https://lists.fedoraproject.org/pipermail/env-and-stacks/2013-November/18.html [1] https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Working Groups: Call for Self-Nominations
Hi, On Thu, 2013-09-19 at 00:58 -0400, Jens Petersen wrote: ps I wasn't at Flock alas so I may have missed some of the earlier discussions that might already have covered some of this... some of your questions are answered in Matthew Miller's Flock presentation An Architecture for a More Agile Fedora: - video: https://www.youtube.com/watch?v=PqoE-tqAQro - slides: http://mattdm.org/fedora/next/ Best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
A new depedency of existing BuildRequires causes build failure - who to blame?
Hi! The techne package FTBFS during the recent F20 mass rebuild, which I fixed and pushed a new build: http://koji.fedoraproject.org/koji/buildinfo?buildID=455280 The same package failed to build yesterday: http://koji.fedoraproject.org/koji/taskinfo?taskID=5830172 Inspecting the log files, I discovered that some BuildRequires pulled in the shapelib package, which then caused the build to fail with: /usr/bin/ld: cannot find -lshp since shapelib-devel was missing. Who should I blame: - the techne package which detected shapelib and tried to build against it, or - the package which introduced this dependency and/or did not also put in a Requires on shapelib-devel? Regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: A new depedency of existing BuildRequires causes build failure - who to blame?
On Tue, 2013-08-20 at 13:22 +0200, Florian Weimer wrote: Probably the former. How does it detect shapelib support if linking to its library fails? It uses autoconf to check for dependencies, however, I couldn't find an explicit check for shapelib in configure.ac. Comparing the output of ./configure of both builds (failed and successful one) revealed no differences. Regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: A new depedency of existing BuildRequires causes build failure - who to blame?
On Tue, 2013-08-20 at 14:01 +0200, Florian Weimer wrote: Could you diff config.log instead, please? I'll have to get hold of a rawhide machine to do that, previously I just diffed the build logs from koji. Do you link something statically, by chance? This would be above my knowledge. How should I do that? Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: A new depedency of existing BuildRequires causes build failure - who to blame?
On Tue, 2013-08-20 at 16:11 +0300, Ville Skyttä wrote: In this case (and usually IME) it's the latter. -lshp was added to plplotd.pc in plplot-devel-5.9.9-18.svn12474.fc20 but the corresponding shapelib-devel package dep wasn't. I just discovered the same thing. Here is the diff of the config.log that Florian requested: http://paste.fedoraproject.org/33439/13770043/ The old one is with plplot-5.9.9-16.svn12281.fc20, which doesn't require shapelib, and the new one is with plplot-5.9.9-19.svn12479.fc20.x86_64, which requires shapelib. I'll fill a bug against plplot. Thanks for helping me resolve the issue! Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mass rebuild update
Hi! On Sun, 2013-08-04 at 21:35 -0500, Dennis Gilmore wrote: There is a large number of failures[1] that need to be addressed. I don't know if this is just a coincidence, but the links to log files in the filled FTBFS bug reports don't work. Here are two examples (from my FTBFS bugs): https://bugzilla.redhat.com/show_bug.cgi?id=992784 https://bugzilla.redhat.com/show_bug.cgi?id=992018 Best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: mass rebuild update
On Mon, 2013-08-05 at 11:37 +0200, Johannes Lips wrote: On Mon, Aug 5, 2013 at 11:22 AM, Peter Robinson pbrobin...@gmail.com wrote: Why don't you just go to koji and have a look at it directly there. Of course one could do that, but then if you put the links there, they should work. Yes, this is what I meant. I have no problem finding the log files myself, I just wanted to point this out so that Dennis (and others) are aware of it. Regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Headsup: soname changing ode-double build coming to rawhide and F-19
Hans, On Mon, 2013-03-18 at 17:17 +0100, Hans de Goede wrote: When I added the ode-double subpackage I hardcoded the soname, so it is not tracking the regular ode builds soname versioning, which also means that if upstream breaks abi the soname won't change (rhbz#922812) thank you for quickly taking care of this bug report! As a result of fixing this, the soname of ode-double is going to change in F-19 and rawhide, this means that alienarena, simspark and techne will need to be rebuild. I've rebuilt techne today. Best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 and F18: bugzilla, bugs and EOL
Jaroslav, On Mon, 2013-03-04 at 06:38 -0500, Jaroslav Reznik wrote: Btw. as asked frequently in the previous EOL thread and to make it easier for me and upcoming guys responsible for EOL - the script is now available in the GIT of Fedora Project Schedule hosted project [1]. thanks for putting this up! This will make it easier to understand what EOL script is doing and suggest improvements. Best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass closing EOL bugs should not close bugs with pending updates
On Tue, 2013-02-19 at 03:52 -0500, Jaroslav Reznik wrote: As Adam pointed out - Bugzilla is not a best tool. The script I was given is neither a state of the art. Definitely it could be enhanced - semi-atomic operations to avoid conflicts, more clever work with BZ states. But more complexity means more BZ resources and especially in the last times BZ performance sucks (script has a sleep after every 10 bugs, still the reporting takes a whole day). Thanks for explaining the reasons for the poor performance of the EOL script. I've heard before that BZ is slow, but this is still a shock: 1 day to close the F16 EOL bugs. Let me try another thing - at DevConf there are people responsible for BZ processes - maybe we can find a way how to make the EOL thing more doable and not destroying BZ experience for everyone ;-) Yes, this would great. And also, consider publishing the EOL script somewhere so it can be improved and worked upon. Best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass closing EOL bugs should not close bugs with pending updates
On Sun, 2013-02-17 at 12:02 +0100, Christoph Wickert wrote: I found that a couple of F16 bugs were closed by endoflife@fp.o even though there were pending updates for F17 and F18 to fix them. As a result, the bugs are now closed WONTFIX even they were or are going to be fixed. What you describe is another example of strange behavior of the Fedora EOL Closure script. I discovered two related problems that I described three days ago: http://lists.fedoraproject.org/pipermail/devel/2013-February/178649.html Since then I found a page that describes the Fedora 16 EOL Closure procedure: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora18#Fedora_16_EOL_Closure It says that the bugs with version == Fedora 16 and status != CLOSED are subject to automatic closure. Could you give an example of a bug that you described? Does anyone know where to see the source of the EOL Closure script? Best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 16 EOL Bugzilla Closure - strange behavior?
Hi! Here is an example: https://bugzilla.redhat.com/show_bug.cgi?id=736498 I filled this bug during the F-16 Graphics test week. After the Fedora EOL reminder and before the bug was closed, I tried to reproduce it on F-17 and I couldn't. Thus I marked the bug as CLOSED CURRENTRELEASE. After a couple of hours the Fedora EOL script changed the Resolution to WONTFIX: https://bugzilla.redhat.com/show_activity.cgi?id=736498 Another example: https://bugzilla.redhat.com/show_bug.cgi?id=739315 This is an ABRT bug report that was originally reported against gnome-shell on F-16. I encountered it with gnome-shell on F-17 (https://bugzilla.redhat.com/show_bug.cgi?id=739315#c72) and some people encountered it on F-18. I bumped the version to 18, however, after a couple of hours the Fedora EOL script closed it as WONTFIX. Could someone explain this behavior? Thanks and best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer Jef Spaleta - Unpushed security update for 91 days
On Sat, 2012-10-06 at 01:12 +0200, Till Maas wrote: I believe this was only the case with earlier updates. At least I did not notice the problem with the current update and there was no negative karma to the F17 update during 91 days saying otherwise. I was the the one who gave bad karma to the F16 update, because it didn't upgrade the gconf settings properly. This is not some earlier version of the update, but the same version that has been submitted to stable. In my opinion, we should weight the impact of the security issue (see: http://lists.fedoraproject.org/pipermail/devel/2012-June/168616.html) against manual intervention the user has to do to get Revelation usable again (manually deleting the ~/.gconf/schemas/apps/revelation folder). Therefore, I'm against pushing the update to stable. Regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: brp-python-hardlink fails on files that include spaces
Toshio, On Tue, 2012-09-25 at 09:39 -0700, Toshio Kuratomi wrote: The patch you provide looks like it would still be needed as it checks all of $RPM_BUILD_ROOT for .pyc files, not just site-packages. thank you for reviewing the patch. The redhat-rpm-config's upstream repository (http://git.fedorahosted.org/cgit/redhat-rpm-config) hasn't seen any commits since March 2010. Is it still maintained? Maybe the easiest way to fix this is to include the patch along other patches in http://pkgs.fedoraproject.org/cgit/redhat-rpm-config.git/tree/ ? Best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: brp-python-hardlink fails on files that include spaces
David,
On Tue, 2012-09-25 at 16:32 -0400, David Malcolm wrote:
Almost certainly a bad idea, but FWIW it is possible, using the
__import__ builtin:
# mkdir /usr/lib64/python2.7/site-packages/this module has a space
# echo print('hello world') /usr/lib64/python2.7/site-packages/this
module has a space/__init__.py
# ls /usr/lib64/python2.7/site-packages/this\ module\ has\ a\
space/__init__.py
/usr/lib64/python2.7/site-packages/this module has a space/__init__.py
# python -c __import__('this module has a space')
hello world
thank you for this detailed explanation.
But yeah, don't do that :)
I'm trying to package an open source data mining program Orange
(http://orange.biolab.si/).
Apparently, they are using spaces in one of their packages:
https://bitbucket.org/biolab/orange/src/3db591b97b0c/orange/OrangeWidgets/Visualize%20Qt
I couldn't find out how they made it to work.
Best regards,
Tadej
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
brp-python-hardlink fails on files that include spaces
Hello! I've reported this issue with brp-python-hardlink back in January: https://bugzilla.redhat.com/show_bug.cgi?id=783433 Could someone (a provenpackager) please look at the patch provided in the bug report and apply it? Thanks and best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
On Wed, 2012-06-06 at 21:27 +0400, Pavel Alexeev wrote:
With regard to the packages that depend on ImageMagick that you already
updated: will you revert those commits in git
I'm unsure I known how doing that correctly.
Does it enough do just:
git revert 56e05f..HEAD
or I must do something like:
git reset 56e05f
git reset --soft HEAD@{1}
git commit -m Revert to 56e05fced
git reset --hard
I'm not a git expert but I think you should use:
- git reset --hard HEAD^
- git push -f
to completely nuke the last commit and never see it again.
I tried doing that for my package (techne), however, it didn't work:
$ git push -f
Total 0 (delta 0), reused 0 (delta 0)
remote: error: denying non-fast-forward refs/heads/f16 (you should pull
first)
To ssh://ta...@pkgs.fedoraproject.org/techne
! [remote rejected] f16 - f16 (non-fast-forward)
error: failed to push some refs to
'ssh://ta...@pkgs.fedoraproject.org/techne'
Am I doing something wrong here?
and delete the
corresponding builds in koji?
Do you mean koji untag-pkg or something other? Could you please
provide link on such procedure description?
I couldn't find a procedure description for deleting unwanted builds in
koji. Since this purging issue is clearly above our heads, the
sensible thing would be to ask for help of those who have more
experience handling these issues.
Maybe file a ticket at https://fedorahosted.org/rel-eng/report for the
Release Engineering team and ask them how to handle the issue.
Regards,
Tadej
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
On Tue, 2012-06-05 at 13:55 +0400, Pavel Alexeev wrote: I'll plan unpush that update and work on patching ImageMagick to handle these issues locally. But I'm not security expert and can't guarantee something except mentioned patch apply (contrary leave it on upstream authors, as I was want do first). Even though this means a lot of your work has been waisted, I think it's the right decision to patch ImageMagick to fix the security issues instead of doing a large-scale update of Fedora 16. With regard to the packages that depend on ImageMagick that you already updated: will you revert those commits in git and delete the corresponding builds in koji? Regards, Tadej Janež -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
Pavel, On Tue, 2012-05-29 at 20:21 +0400, Pavel Alexeev wrote: It is main reason why I request provenpackager rights. In fedora 17 it was so painful because I several times asks build dependencies and then ask help to push updates too. I think in that turn now I can do all that myself, so it should be smoother. As there around 6 security issues, I think update upstream release is easiest, and furthermore robust way handle it. I've seen you didn't listen to Tomáš's or Kalev's advice on not bumping the ImageMagick's soname in a stable release. Furthermore, you didn't give any warning to the maintainers of the dependent packages (except for the message on this list). In my opinion, being a provenpackager is no excuse for not doing that. Please, use the packagename-ow...@fedoraproject.org addresses to send out emails to the appropriate package maintainers. For techne (one of the dependent packages which I maintain) you bumped the release from 0.2.3-2 to 0.2.3-3, which breaks upgrades to F-17 and rawhide. Is there a way to revert the change and make a 0.2.3-2.fc16.1 build? Best regards, Tadej Janež -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange rpath issue with F-16 and F-17
Kevin, On Sat, 2011-09-10 at 02:19 +0200, Kevin Kofler wrote: Tadej Janež wrote: What has changed between F-15 and F-16 so that -rpath,/usr/lib64 gets appended to g++ options? Looks like a regression somewhere, probably in sip (which also contains some build-system-type stuff). Something needs fixing for multilib. thanks for the tip! What is the best way to fix this? I'd start by filing a bug against sip in Fedora Bugzilla. I'll do that. Regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Strange rpath issue with F-16 and F-17
Hi, I just noticed a strange rpath issue with my PyQwt package. Building the latest git version on F-16 and F-17 results in -rpath,/usr/lib64 being appended to the g++ compiler options. Build logs of scratch builds are here: https://koji.fedoraproject.org/koji/getfile?taskID=3332309name=build.log https://koji.fedoraproject.org/koji/getfile?taskID=3332685name=build.log However, building the latest git version on F-15 doesn't exhibit this problem. See build log: https://koji.fedoraproject.org/koji/getfile?taskID=3332430name=build.log What has changed between F-15 and F-16 so that -rpath,/usr/lib64 gets appended to g++ options? What is the best way to fix this? Regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rebuilding against the new libobjc
On Mon, 2011-01-24 at 16:01 +0100, Jakub Jelinek wrote: Should I rebuild my package myself or wait for the GCC mass rebuild? Please rebuild it yourself. Ok, will do! -- Tadej Janež tadej.ja...@tadej.hicsalta.si -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
