On Tue, 2016-07-12 at 23:52 -0700, Adam Williamson wrote:
>
> Of course, we don't *have* to pick one thing or the other necessarily;
> we can certainly provide all the appropriate hooks for packages to do
> automated update testing, this is something folks are already looking
> at, and there's no
On Tue, Jul 12, 2016 at 11:52:45PM -0700, Adam Williamson wrote:
> FWIW, as someone who is working on this, I don't think we can
> realistically aim to do distribution-level automated testing with per-
> package granularity. We actually have all the bits in place to do
> something like that if we w
Rust uses LLVM for codegen, so in theory, yes. This excludes any potential
platform-specific bugs that may affect rustc, which are certainly a possibility.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Rust supports dynamic linking, would it be worth investigating that route
instead of copying the proposed Go guidelines? I'm not against static linking
at all costs, but it would make package maintenance (especially security
updates) a lot more pleasant.
--
devel mailing list
devel@lists.fedorap
On Wed, Jul 13, 2016 at 8:45 AM, Dan Horák wrote:
> On Wed, 13 Jul 2016 06:18:17 +0200
> Jan Kurik wrote:
>
>> = Proposed Self Contained Change: Rust Compiler =
>> https://fedoraproject.org/wiki/Changes/RustCompiler
>>
>> Change owner(s):
>> * Josh Stone
>>
>> Introduce packages for the Rust com
On Tue, Jul 12, 2016 at 02:34:04PM -0400, Przemek Klosowski wrote:
> On 07/12/2016 06:15 AM, Lennart Poettering wrote:
> >That's hardly useful, as "screen" alone is useless as it's just a
> >frontend to other programs (such as a shell that is run inside the
> >"screen" instance), and if we kill tho
Currently it's not possible for dynamic linking...
On Wed, Jul 13, 2016 at 9:29 AM, Stefan Nuxoll wrote:
> Rust supports dynamic linking, would it be worth investigating that route
> instead of copying the proposed Go guidelines? I'm not against static linking
> at all costs, but it would make
On Wed, 13 Jul 2016, Igor Gnatenko wrote:
Currently it's not possible for dynamic linking...
Why?
Dynamic linking is supported by Rust and according to its documentation,
is enabled for system libraries on Linux by default.
Can you explain why you are claiming it is not possible to enable
dyna
I meant that rust itself links dynamically to system libraries. But
libraries built by rust are not supposed to be dynamically linked by
programs.
At least at this moment. So for now I don't see alternatives to have same
packaging guidelines as for Go.
-Igor Gnatenko
On Jul 13, 2016 11:05 AM, "
On 13/07/16 08:21 +0530, Siddhesh Poyarekar wrote:
On Tue, Jul 12, 2016 at 03:45:54PM -0700, Adam Williamson wrote:
Bodhi works at the source package level, not binary package level.
That's irrelevant. If a source package only provides a library for
other packages to link against then testing
On Wed, Jul 13, 2016 at 11:11 AM, Igor Gnatenko wrote:
> I meant that rust itself links dynamically to system libraries. But
> libraries built by rust are not supposed to be dynamically linked by
> programs.
Hello,
Since 1.10 (the target of this change) it has become possible to
create "cdylib"
Dne 12.7.2016 v 18:49 Adam Williamson napsal(a):
>
> The idea is this: there could be a requirement for all packages to
> provide at least *some* kind of 'how to test' information.
If the package should be tested by human, I'd expect that there will be
some additional value, i.e. the human can s
Hello,
Just a heads-up: I have just build the 2.6.2 version of storaged that should
replace udisks2 in Fedora 25. The upgrade should be seamless: Cockpit and
Blivet would need to be rebuilt too to use the new API. The rest of the system
should just work as usually.
Thanks and regards,
--
Tomáš
On 07/13/2016 08:17 AM, Siddhesh Poyarekar wrote:
But then we're setting the bar too low by allowing *anyone* to set
karma for the sake of it. You might as well just let developers push
packages to stable if they're 'confident' about it.
That is painting with too broad of a brush for one or t
Missing expected images:
Kde live i386
Workstation live i386
Server dvd i386
Server boot x86_64
Server dvd x86_64
Kde live x86_64
Cloud_base raw-xz x86_64
Cloud_base raw-xz i386
Server boot i386
Atomic raw-xz x86_64
Kde raw-xz armhfp
Minimal raw-xz armhfp
Workstation live x86_64
Failed openQA tes
Il 13/07/2016 05:01, Siddhesh Poyarekar ha scritto:
On Tue, Jul 12, 2016 at 09:23:26PM +0200, Reindl Harald wrote:
nonsense - it's enough to give a sign that a potential fix don't break
things wich worked before
hi
this should break at least wildfly ... and if they run/build in
https://apps.
On 07/12/2016 05:01 AM, Bastien Nocera wrote:
>
>
> Huh, the phone should still be getting mounted, but as a camera, and just as
> a camera, and you can remove photos there without botching the phone's
> internal
> photo database.
>
> That definitely works here.
> --
Yeah All I see are "docu
- Original Message -
>
>
> On 07/12/2016 05:01 AM, Bastien Nocera wrote:
> >
> >
> > Huh, the phone should still be getting mounted, but as a camera, and just
> > as
> > a camera, and you can remove photos there without botching the phone's
> > internal
> > photo database.
> >
> > Th
On 07/13/2016 08:49 AM, Bastien Nocera wrote:
>
>
> - Original Message -
>>
>>
>> On 07/12/2016 05:01 AM, Bastien Nocera wrote:
>>>
>>>
>>> Huh, the phone should still be getting mounted, but as a camera, and just
>>> as
>>> a camera, and you can remove photos there without botching the
Huh, the phone should still be getting mounted, but as a camera, and just
as
a camera, and you can remove photos there without botching the phone's
internal
photo database.
That definitely works here.
--
>>>
>>> Yeah All I see are "documents on dusty's iphone
Just a note more than anything, since I don't see this problem
discussed anywhere in the packaging guidelines ...
If a package uses libtool, then sometimes libtool generates bash
scripts instead of executables. These libtool wrapper scripts can be
run from the build directory and run the real exe
On Wed, 2016-07-13 at 11:43 +0200, Tomáš Smetana wrote:
> Hello,
> Just a heads-up: I have just build the 2.6.2 version of storaged
> that should
> replace udisks2 in Fedora 25. The upgrade should be seamless: Cockpit
> and
> Blivet would need to be rebuilt too to use the new API. The rest of
> t
On 07/12/2016 10:07 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jul 12, 2016 at 11:04:53PM +0200, Jan Kurik wrote:
>> = Proposed Self Contained Change: GNS3 =
>> https://fedoraproject.org/wiki/Changes/GNS3
>>
>> Change owner(s):
>> *Athmane Madjoudj
>>
>> Graphical Network Simulator 3
>>
>>
>
On Wed, 2016-07-13 at 07:26 +, Stefan Nuxoll wrote:
> Rust uses LLVM for codegen, so in theory, yes. This excludes any
> potential platform-specific bugs that may affect rustc, which are
> certainly a possibility.
At the moment llvm has codegen support for every Fedora architecture,
primary an
On Wed, 2016-07-13 at 10:21 +0100, Jonathan Wakely wrote:
> On 13/07/16 08:21 +0530, Siddhesh Poyarekar wrote:
> >
> > On Tue, Jul 12, 2016 at 03:45:54PM -0700, Adam Williamson wrote:
> > >
> > > Bodhi works at the source package level, not binary package level.
>
> That's irrelevant. If a sourc
On Wed, 2016-07-13 at 11:34 +, Fedora compose checker wrote:
> Missing expected images:
>
> Kde live i386
> Workstation live i386
> Server dvd i386
> Server boot x86_64
> Server dvd x86_64
> Kde live x86_64
> Cloud_base raw-xz x86_64
> Cloud_base raw-xz i386
> Server boot i386
> Atomic raw-xz
On 07/12/2016 11:45 PM, Dan Horák wrote:
> How does the new language (and compiler) affect secondary architectures?
> Will it just work?
Rust has their own tier system of architecture support:
https://doc.rust-lang.org/book/getting-started.html#platform-support
Only i686 and x86_64 are Tier 1 at
On 07/13/2016 12:29 AM, Stefan Nuxoll wrote:
> Rust supports dynamic linking, would it be worth investigating that
> route instead of copying the proposed Go guidelines? I'm not against
> static linking at all costs, but it would make package maintenance
> (especially security updates) a lot more p
On 07/13/2016 02:24 AM, Dridi Boukelmoune wrote:
> Since 1.10 (the target of this change) it has become possible to
> create "cdylib" (C dynamic library) crates, basically shared objects
> that can be linked to by non-Rust programs.
>
> It isn't supported by cargo yet, but it's available..
Yes, y
ABI stability is entirely dependent on compiler version, AFAIK. Within the same
version of rustc there should be no issues with dynamic linking, of course
whenever we upgrade rustc we'd need a mass rebuild of every rust package but
we'd have to do the same thing with static linking.
--
devel mai
On 07/12/2016 09:18 PM, Jan Kurik wrote:
> Rust 1.10.0 was released on July 7 along with Cargo 0.11.0. These will
> be the initial targets to package. Rust's next release is scheduled
> for August 18 on a 6-week cycle. Backwards compatibility is taken very
> seriously, so it should be possible to k
On Wed, 2016-07-13 at 11:41 +0200, Vít Ondruch wrote:
>
> Dne 12.7.2016 v 18:49 Adam Williamson napsal(a):
> >
> >
> > The idea is this: there could be a requirement for all packages to
> > provide at least *some* kind of 'how to test' information.
>
> If the package should be tested by human,
On 07/13/2016 09:10 AM, Stefan Nuxoll wrote:
> ABI stability is entirely dependent on compiler version, AFAIK.
> Within the same version of rustc there should be no issues with
> dynamic linking,
I suspect that may true in general, but I don't think it's promised, and
I don't really trust it. We
On Wed, 13 Jul 2016 09:02:06 -0700
Josh Stone wrote:
> On 07/12/2016 11:45 PM, Dan Horák wrote:
> > How does the new language (and compiler) affect secondary
> > architectures? Will it just work?
>
> Rust has their own tier system of architecture support:
>
> https://doc.rust-lang.org/book/gett
On 07/13/2016 01:38 AM, Siddhesh Poyarekar wrote:
On Tue, Jul 12, 2016 at 10:26:20PM -0700, Adam Williamson wrote:
It would not be 'a lot of work', it would be a gigantic, totally
unsustainable burden. I honestly think you're shooting *way* too high
here. Even with all the recent volunteers, we
In my opinion the proposal needs to be amended in the following ways:
Scope:
Understanding the scope of this Change requires understanding how many
programs there are that will have to be adapted to avoid getting killed.
Therefore the Scope section should contain a complete list of affected
pack
On Wed, Jul 13, 2016 at 11:28 AM, Björn Persson wrote:
> In my opinion the proposal needs to be amended in the following ways:
>
>
> Scope:
>
> Understanding the scope of this Change requires understanding how many
> programs there are that will have to be adapted to avoid getting killed.
> Theref
I'm a co-maintainer for the python-sphinx package. There's a bug [1] I'd
like to address, but I'd like some input on what I was thinking. There was
some discussion about this on FPC ticket [2], but nothing workable really
came out of that. I also attempted to get input [3] from the Sphinx
community
On 07/13/2016 07:50 AM, Adam Jackson wrote:
> On Wed, 2016-07-13 at 07:26 +, Stefan Nuxoll wrote:
>> Rust uses LLVM for codegen, so in theory, yes. This excludes any
>> potential platform-specific bugs that may affect rustc, which are
>> certainly a possibility.
>
> At the moment llvm has code
On Wed, 2016-07-13 at 12:42 -0700, Josh Stone wrote:
> On 07/13/2016 07:50 AM, Adam Jackson wrote:
> > On Wed, 2016-07-13 at 07:26 +, Stefan Nuxoll wrote:
> > > Rust uses LLVM for codegen, so in theory, yes. This excludes any
> > > potential platform-specific bugs that may affect rustc, which
Sayan Chowdhury wrote:
> I recently packaged and pushed an update for
> fedmsg-meta-fedora-infrastructure to bodhi and exactly 40 secs[1] later I
> got a +1 to the update. I am sure that testing a package surely takes more
> than 40 secs. This makes me really curious that are the packages really
>
On Tue, 12 Jul 2016 08:28:01 +0530
Parag Nemade wrote:
> After long time I see this script results on devel list. Last few
> maintainers have tried to update this script but I think whenever
> bugzilla gets updated this script got broken.
> But I really don't see any need to send these weekly res
On Mon, 11 Jul 2016 13:18:25 -
"Raphael Groner" wrote:
> Can that information be used to award badges? There's an old open
> issue to implement badges for doing package reviews. Maybe get in
> contact with the badges team.
> https://fedorahosted.org/fedora-badges/ticket/101
Yep. It could, b
Hi,
On Wed, Jul 13, 2016 at 2:56 PM, Cole Robinson wrote:
> Googling around, it doesn't sound like this is something that needs work on
> the qemu side, more that it can use a properly configured qemu VM as a node in
> the network topology. I'm not positive though...
No special integration is ne
Budgie desktop is doing a very good job using GNOME technologies keeping things
simple.
It is now officially offers from the Solus project through OBS, but it would be
good to have in the official repositories of Fedora and perhaps in the future
as Spin.
Cheers
--
devel mailing list
devel@list
On Tuesday, July 12, 2016 7:56:41 AM EDT Chris Murphy wrote:
> I have KillUserProcesses=yes set in Fedora 24 for some time now. I'm
> noticing that I still often have 90 second delays if I restart or
> shutdown, more than half the time.
Yup. Me too.
[snip]
> I have no idea how to collect
> more
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2016-07-14 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. rktime):
2016-07-14 09:00 Thu US/Pacific PDT
2016-07-14 12:00 Thu US/Eastern EDT
2016-07-14 1
On Wed, Jul 13, 2016 at 01:23:04PM -0400, Przemek Klosowski wrote:
> I think the functionality you're talking about (checking correctness of bug
> fixes, etc) should be left to the original bug reporters. After all, they
> raised the issue so they are invested in the result.
Agreed.
> Automation
48 matches
Mail list logo
