Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 06:49:17PM -0400, "Jóhann B. Guðmundsson" wrote: > On 08/14/2013 06:04 PM, Matthew Garrett wrote: > >Some projects are objectively better than other projects. Some projects > >may not be objectively better but are more closely aligned with our > >release schedule and support cycles. Some projects are actively > >developed in Fedora and as such can be more cleanly integrated into the > >distribution. > > As soon as we slip that argument no longer stands and we always slip... "We suck, so we should keep on sucking"? Come on. Our inability to maintain a schedule is the result of a wide variety of factors that we can improve, not an inherent reality. > >Making it easier for users to obtain those projects is doing our users a > >service. It is not our responsibility to encourage growth and > >development of other projects that don't make things better for our > >users, and so it's inappropriate to provide equivalent promotion. > > > > You do realize that each sub community is trying to reach out to > their own target users, even an single application might be reaching > to a specific target audience so in that perspective there is no > such thing as "our users". If you visit fedoraproject.org and click on "Download now", you'll get a 64-bit x86 desktop live image. Those are our de-facto target users. The proposal under discussion actually broadens that slightly by making it clearer that we offer three separate first-class products for three different user-cases. You seem to be arguing for a different scenario, one where arbitrary subsets of the Fedora package set are advertised equally. That's not the status quo, and so I think you need to follow this proposal's lead and come up with a solid argument for how your position improves Fedora and what technical and policy changes are needed to get there. > So in other words what to take from your response is that you are > saying that you do not want increased participation in the project > as whole and or only for specific areas of the project? I want increased participation in the creation of Fedora, which is a product with a defined set of software shipped as default. I'm also happy with people working to make it practical to use Fedora as the basis for derived products (such as the spins and remixes), providing that they don't compromise the product that we're producing. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Suggestion: bmap files and bmaptool
On Wed, 2013-08-14 at 21:16 -0700, Samuel Sieb wrote: > On 08/14/2013 02:21 AM, Artem Bityutskiy wrote: > > I think I covered this part in the documentation. But here is a short > > description. > > > > 1. The bmap file should be created just after the image is generated. > > 2. The blocks where zeroes were explicitly written will be mapped to > > real sectors which will contain zeroes. > > 3. The blocks which were not explicitely written to, will be unmapped. > > 4. Creation of the bmap file is done using the FIEMAP ioctl > > 5. Only unmapped blocks will be omited in the bmap files. > > > > While on this, I should note that this works best on ext4 file-system. I > > did not test ext2/3, but they should work as well as ext4. Btrfs was > > also tested, but it is a little bit worse than ext4, I can explain why > > if someone is interested. > > Have you looked at partimage? It sounds like this except that it works > on many different filesystems and doesn't need the blocks to be unmapped > to compress it (i.e. it works on normal partitions as well as images). No, never saw this project before. Yeah, it sounds like it uses similar ideas to speed-up, but has different purposes and tries to know the file-system internal format, and hence, does not support ext4/btrfs simply because, as I guess, they are too complex and are developed too quickly. It is just too difficult to maintain a parallel implementation in user-space. Bmaptool does not know anything about the internals of the file-system. It does not care what is the FS underneath. bmaptool simply use the FIEMAP ioctl and ask the FS about which blocks are mapped (used). This would not work for partimage since it needs to know about all the blocks (superblock, all the other meta-data blocks), not just blocks belonging to a single file. Now, why I said that ext4 is the best one to use on the server (most probably ext2/3 are as good, but I did not verify). This is because ext4 is "perfect" in leaving the gaps. Even if you have one block gap, it still will account it as unmapped. I have a test where I create random mapped areas, and ext4 keeps all the gaps. But BTRFS sometimes maps small 1-block gaps. This is related to its internal structure. So with btrfs the bmap file becomes less ideal. Anyway, thanks for letting me know about partimage. -- Best Regards, Artem Bityutskiy -- 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: Suggestion: bmap files and bmaptool
On 08/14/2013 02:21 AM, Artem Bityutskiy wrote: I think I covered this part in the documentation. But here is a short description. 1. The bmap file should be created just after the image is generated. 2. The blocks where zeroes were explicitly written will be mapped to real sectors which will contain zeroes. 3. The blocks which were not explicitely written to, will be unmapped. 4. Creation of the bmap file is done using the FIEMAP ioctl 5. Only unmapped blocks will be omited in the bmap files. While on this, I should note that this works best on ext4 file-system. I did not test ext2/3, but they should work as well as ext4. Btrfs was also tested, but it is a little bit worse than ext4, I can explain why if someone is interested. Have you looked at partimage? It sounds like this except that it works on many different filesystems and doesn't need the blocks to be unmapped to compress it (i.e. it works on normal partitions as well as images). -- 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: RFC: Old packages remain on the mirrors for one week
On Wed, 2013-08-14 at 11:24 -0600, Kevin Fenzi wrote: > On Mon, 12 Aug 2013 11:07:43 -0400 > Mathieu Bridon wrote: > > ...snip... > > > It has an added benefit: it could make « yum downgrade » work better. > > This wouldn't work with yum downgrade would it? Doesn't yum downgrade > need to 'see' the packages in the metadata? Ah, maybe indeed. At the very least, if the user didn't refresh his cached metadata, it would work, but you're right, it's not as good as I thought originally. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
retiring gpointing-device-settings
The package currently fails to build and upstream appears to be dead. Even the working package does not save settings. https://wiki.gnome.org/GPointingDeviceSettings https://git.gnome.org/browse/gpointing-device-settings/ Problem: This is a useful package that controls touchpad settings. I have tried xfce4-mouse-settings from xfce4-settings but this obviously doesn't work since XFCE uses xfconf. Does anyone have any alternatives or suggestions? Otherwise we are losing some important functionality for GTK based desktops. One alternative is to fork xfce4-settings and migrate it to gsettings. Any feedback welcome. Thanks, Dan -- 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: BlueZ Status in Fedora.
On Tue, Aug 13, 2013 at 6:44 AM, Kalev Lember wrote: > On 08/13/2013 02:28 PM, Rave it wrote: >> Other probs are: >> 1. gnome-bluetooth upstream has removed the fallback icon for autostart in >> session,...no systray icon in other DE than gnome itself. >> 2. if gnome revert this change in upstream 'OnlyShowIn=MATE" needs to be >> added. >> 3. Also runtime dependencies needs to be checked, we don't want to be >> install more gnome as necessary in mate. > > I discussed this with raveit65 on IRC and we found a way forward with this. > > The issue with MATE switching from mate-bluetooth to gnome-bluetooth is > that gnome-bluetooth no longer ships the panel applet that MATE needs. > This was removed from gnome-bluetooth in commit > https://git.gnome.org/browse/gnome-bluetooth/commit/?id=c54e93e4310342ffce13e15b5a1b9a6ee9500a05 > when GNOME stopped shipping the fallback mode. > > However, the panel applet code is pretty self contained. The way to make > it work would be to move the panel applet code to a separate package. It > could be called mate-panel-bluetooth or gnome-panel-bluetooth or > similar. The package would then include the panel applet files that are > no longer part of gnome-bluetooth, and link with libgnome-bluetooth. > > Anyone interested in teaming up with raveit65 to create a separate > package for this? > > This package might also be useful for XFCE/LXDE. > > In any case, the best way forward is probably to go on with importing > BlueZ 5 into rawhide so that it can be used as a development platform. > Otherwise it's pretty hard to test the new code. > > -- > Kalev > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Could we reverse this commit? Everyone wins. Otherwise we are looking at possibly reforking gnome-bluetooth at this point in time. Dan -- 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: Rawhide Koji Errors (Requires: /sbin/ldconfig)
在 2013-8-15 AM1:23，"Rex Dieter" 写道：
> See
> https://fedoraproject.org/wiki/Packaging:Alternatives
>
> and use
> Requires(post): %{_sbindir}/update-alternatives
> ...etc...
Good, don't hardcode paths.
What about creating an RFE for all affected packages?
--
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: RFC: Old packages remain on the mirrors for one week
On 08/14/2013 12:26 PM, Kevin Fenzi wrote: > I guess I'm open to the idea, but I have long wished we could have some > way to always keep the previous version of a package for yum > downgrades. ;( > > Keeping all that in metadata would bloat it a lot. You could have an additional metadata package that contained these packages. It would only be downloaded/used when "yum downgrade" or "yum install foo-$oldversion" is called. -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/14/2013 06:04 PM, Matthew Garrett wrote: On Wed, Aug 14, 2013 at 05:32:15PM -0400, "Jóhann B. Guðmundsson" wrote: Putting one of those at a higher level by default, by recommendation or even just by placing it on the front web page puts the others at disadvantage and will hinder growth and participation in the relevant sub-communities which will result in worse product and in turn will have negative outcome for the project in whole. At least that is how I see it. Some projects are objectively better than other projects. Some projects may not be objectively better but are more closely aligned with our release schedule and support cycles. Some projects are actively developed in Fedora and as such can be more cleanly integrated into the distribution. As soon as we slip that argument no longer stands and we always slip... Making it easier for users to obtain those projects is doing our users a service. It is not our responsibility to encourage growth and development of other projects that don't make things better for our users, and so it's inappropriate to provide equivalent promotion. You do realize that each sub community is trying to reach out to their own target users, even an single application might be reaching to a specific target audience so in that perspective there is no such thing as "our users". So in other words what to take from your response is that you are saying that you do not want increased participation in the project as whole and or only for specific areas of the project? JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 05:32:15PM -0400, "Jóhann B. Guðmundsson" wrote: > Putting one of those at a higher level by default, by recommendation > or even just by placing it on the front web page puts the others at > disadvantage and will hinder growth and participation in the > relevant sub-communities which will result in worse product and in > turn will have negative outcome for the project in whole. At least > that is how I see it. Some projects are objectively better than other projects. Some projects may not be objectively better but are more closely aligned with our release schedule and support cycles. Some projects are actively developed in Fedora and as such can be more cleanly integrated into the distribution. Making it easier for users to obtain those projects is doing our users a service. It is not our responsibility to encourage growth and development of other projects that don't make things better for our users, and so it's inappropriate to provide equivalent promotion. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/14/2013 03:51 PM, Matthew Miller wrote: Would we be defaulting and or recommending one application over >another in "Fedora server" for example openldap vs 389ds, kvm vs >xen, postgresql vs mariadb if so why? Ideally, we avoid tying ourselves down, but I think any such recommendations would be based on the level of support we're able to give to those things, and, again, how how they fit the goals we define. As I see it both the labels of "default" and "recommendations" cannot be apply to a community which provides multiple application and solutions and "best effort" in maintaining that by an fluctuating number of any given contributors at any given time. >Given that the above proposal are not direct products of SIG's who's >in control of what goes in and what goes out of the Fedora >Workstation, Fedora Server, and Fedora Cloud and their target >audience ? I think it's reasonable to have more formally-structured Fedora teams for each of these things. What do you think? What I think in that regard is that the SIG or sub-community already have established an governing structure around themselves,their target audience and the product they have decided to deliver to their target audience so adding an additional layer on top of that will have negative effects on the ecosystem they have established for themselves and live in. >As I see it the above part of the proposal only splits the "default" >product into three different "products" without actually solving >anything. These particular suggestions came from looking at some of the different requirements the project has overall, and concluding that no single default really addresses them well, but that these three areas cover important areas, each worth investing resources in. Which areas are of importance is in the hand of the beholder. In other words each sub-community and what they are doing is important to them and those "three" areas by no means cover all the sub-communities that currently exist and might exist in the future of the project thus from my perspective this proposal thus is flawed and not future proof as the community continues to expand. With regards to resources investment pulling resources from one aspect of the project to put them into another will only cause imbalance within the overall existing ecosystem but you have to be a bit more clearer what you mean by "each worth investing resources in" as in where are those resources coming from or taken from and what are they? >Since I dont see how that you propose addresses and or solves any of >the issues we are faced with I argue the way forward for us should >be that Fedora "products" are the results/publication of each >sub-community but not creation of whom releng/fesco/board specific >Fedora individual or as an whole Fedora Workstation, Fedora Server, >and Fedora Cloud SIG? Can you rephrase this? I'm not sure I understand. If you can articulate what you mean by "issues we are faced with", that would help, too. We have competing projects,products or application if you will in the project that are aiming at and competing for the same user base. Putting one of those at a higher level by default, by recommendation or even just by placing it on the front web page puts the others at disadvantage and will hinder growth and participation in the relevant sub-communities which will result in worse product and in turn will have negative outcome for the project in whole. At least that is how I see it. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Criteria for adding new ARM boards to F20 support list
Hi everybody, In today's ARM meeting in #fedora-meeting-1 we started the discussion on the procedure for supporting new ARM devices in Fedora 20. Previously this was done in an ad-hoc manner by the ARM team. While we will continue to enable as diverse a set of devices as possible, this is specifically about what devices are considered supported in a GA release. As an example, in Fedora 19 we supported the Trimslice, but not the AC100, even though they are both Tegra 2 devices and in theory may both work. Many unsupported devices may work, but only a select few can be release blockers. Starting in Fedora 20 / kernel 3.11, we think the following devices may be newly supportable: Calxeda Midway with LPAE Wandboard (i.MX6) Utilite (i.MX6) AC100 (Tegra 2) BeagleBone Black & White More than anything, this is about minimum requirements for QE. Support implies testing, release blocking, etc, so growing the matrix needs to approached cautiously. There is also a question of timing- what is the cutoff for adding a new release blocking device? Alpha? Beta? Is it a feature request? Feedback appreciated. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora ARM Weekly Status Meeting Minutes 2013-08-14
Thanks to those that were able to join us for the status meeting today, for those unable the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-08-14/fedora-meeting-1.2013-08-14-19.30.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-08-14/fedora-meeting-1.2013-08-14-19.30.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-08-14/fedora-meeting-1.2013-08-14-19.30.log.html === #fedora-meeting-1: Fedora ARM weekly status meeting === Meeting summary --- * 0) Status of ACTION items from our previous meeting (pwhalen, 19:31:48) * LINK: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-08-07/fedora-meeting-1.2013-08-07-19.29.html (pwhalen, 19:31:48) * LINK: Peter's State of the ARM Union lists new boards: http://nullr0ute.com/wp-content/uploads/2013/08/Flock2013-ARM-StateOfTheUnion.pdf (bconoboy, 19:35:01) * Likely new devices in F20: Beaglebone, Wandboard, Utilite (bconoboy, 19:35:50) * Other possibilities include AC100, Tegra3/4 in general, Chromebook, Arndale, Odroid (bconoboy, 19:36:38) * ACTION: bconoboy to email the arm/devel mailing lists to begin supportable hw in f20 discussion (pwhalen, 19:46:13) * 1) Problem packages (pwhalen, 19:46:29) * LINK: glibc has neon instructions https://bugzilla.redhat.com/show_bug.cgi?id=985342 (bconoboy, 19:49:29) * 2) Kernel Status Update (pwhalen, 19:52:31) * No updated since last week (SIGFLOCK) (bconoboy, 19:54:04) * 3a) Aarch64 - Status Update (pwhalen, 19:55:32) * 11909/13606 packages built (bconoboy, 19:58:23) * Builders are idle, so we will requeue the failed 856 builds as dependencies may now be filled (bconoboy, 20:02:00) * 3b) F19 Remix (pwhalen, 20:02:28) * An F19 AArch64 remix is coming- including a Fedora 3.11 kernel/initramfs for use with foundation model. (bconoboy, 20:06:35) * livemedia-creator is capable of making these images even now (bconoboy, 20:07:49) * 4) Flock Wrap-up - Did you attend? Tell us about it! (pwhalen, 20:08:27) * Vulcan mind meld between kylem and pbrobinson for kernel maint plans (bconoboy, 20:12:49) * Possible development pursuits include enabling grub and the new smolt replacement- these are probably f21+ activities (bconoboy, 20:15:52) * LINK: FLOCK Talks - http://www.youtube.com/channel/UC_p--G_ebsrR4kA4zpqLSTw (pwhalen, 20:16:30) * 5) Open Floor (pwhalen, 20:17:19) Meeting ended at 20:19:16 UTC. Action Items * bconoboy to email the arm/devel mailing lists to begin supportable hw in f20 discussion Action Items, by person --- * bconoboy * bconoboy to email the arm/devel mailing lists to begin supportable hw in f20 discussion * **UNASSIGNED** * (none) People Present (lines said) --- * bconoboy (61) * pwhalen (38) * kylem__ (18) * dgilmore (14) * zodbot (7) * masta (6) * jcapik (1) * Guest80927 (1) * dmarlin (0) * ahs3 (0) * msalter (0) * ddd_ (0) * pbrobinson (0) * ctyler (0) * agreene (0) * handsome_pirate (0) * jonmasters (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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 02:26:55PM -0400, "Jóhann B. Guðmundsson" wrote: > >2. FESCO-created working group to draft Fedora Base Design as called for > >in that proposal. > Has fesco already created that working group if so who's on it? No. The proposal is to create such a group, through calling for volunteers. > Has fesco already created that working group if so who's on it? Ditto. > >* These products would be Fedora Workstation, Fedora Server, and Fedora > > Cloud (precise definitions to be developed), based around a common core [...] > For example what would be the default desktop in the "Fedora > workstation" and why ? We (community; FESCO, Board, SIGs, and Teams) will work to define a vision for what Fedora needs, independent of upstream projects, and then work with upstreams to best meet those needs. > Would we be defaulting and or recommending one application over > another in "Fedora server" for example openldap vs 389ds, kvm vs > xen, postgresql vs mariadb if so why? Ideally, we avoid tying ourselves down, but I think any such recommendations would be based on the level of support we're able to give to those things, and, again, how how they fit the goals we define. > Given that the above proposal are not direct products of SIG's who's > in control of what goes in and what goes out of the Fedora > Workstation, Fedora Server, and Fedora Cloud and their target > audience ? I think it's reasonable to have more formally-structured Fedora teams for each of these things. What do you think? > As I see it the above part of the proposal only splits the "default" > product into three different "products" without actually solving > anything. These particular suggestions came from looking at some of the different requirements the project has overall, and concluding that no single default really addresses them well, but that these three areas cover important areas, each worth investing resources in. > Since I dont see how that you propose addresses and or solves any of > the issues we are faced with I argue the way forward for us should > be that Fedora "products" are the results/publication of each > sub-community but not creation of whom releng/fesco/board specific > Fedora individual or as an whole Fedora Workstation, Fedora Server, > and Fedora Cloud SIG? Can you rephrase this? I'm not sure I understand. If you can articulate what you mean by "issues we are faced with", that would help, too. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Thursday's FPC Meeting (2013-08-15 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2013-08-15 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2013-08-15 09:00 Thu US/Pacific PDT 2013-08-15 12:00 Thu US/Eastern EDT 2013-08-15 16:00 Thu UTC <- 2013-08-15 17:00 Thu Europe/London BST 2013-08-15 18:00 Thu Europe/Paris CEST 2013-08-15 18:00 Thu Europe/Berlin CEST 2013-08-15 21:30 Thu Asia/Calcutta IST --new day-- 2013-08-16 00:00 Fri Asia/Singapore SGT 2013-08-16 00:00 Fri Asia/Hong_Kong HKT 2013-08-16 01:00 Fri Asia/Tokyo JST 2013-08-16 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = #topic #323 Web Assets .fpc 323 https://fedorahosted.org/fpc/ticket/323 #topic #326 Bundling exception for python-kapteyn .fpc 326 https://fedorahosted.org/fpc/ticket/326 = New business = #topic #327 Python shebangs should not point to /usr/bin/python .fpc 327 https://fedorahosted.org/fpc/ticket/327 #topic #328 Soft-static uid/gid allocation for Performance Co-Pilot daemons .fpc 328 https://fedorahosted.org/fpc/ticket/328 #topic #329 Packaging Guideline: libtool should be regenerated in SPEC .fpc 329 https://fedorahosted.org/fpc/ticket/329 #topic #331 ruby guidelines requiring ruby(release) causes depsolving headache .fpc 331 https://fedorahosted.org/fpc/ticket/331 #topic #332 Bundling exception for IQmol .fpc 332 https://fedorahosted.org/fpc/ticket/332 #topic #334 Create a macro for selecting the proper ruby-(abi|release) version .fpc 334 https://fedorahosted.org/fpc/ticket/334 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
Colin Walters (walt...@verbum.org) said: > On Wed, 2013-08-14 at 13:00 -0400, Matthew Miller wrote: > > > * These products would be Fedora Workstation, Fedora Server, and Fedora > > Cloud (precise definitions to be developed) > > Why not derive these definitions from the current Red Hat Enterprise > Linux products? In terms of content and differentiation, likely because those are actually fairly poorly delineated products. Bill -- 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: Broken dependencies: python-osmgpsmap
On Tue, Aug 13, 2013 at 8:06 AM, Richard Shaw wrote: > On Sun, Aug 11, 2013 at 8:46 AM, Michael Schwendt > wrote: >> >> On Sun, 11 Aug 2013 07:58:37 -0500, Richard Shaw wrote: >> >> > Ok, I've been getting these messages for a while but I'm not the package >> > owner for I didn't worry about it, however, it's been a couple of weeks >> > so >> > I decided to take a look to see how much work it would be. >> >> You are listed as a co-maintainer: >> https://admin.fedoraproject.org/pkgdb/acls/name/python-osmgpsmap > > Exactly, I wasn't sure if the owner had a fix in the works so I didn't want > to muck anything up. > >> > Now I'm really confused... There are two separate packages in Fedora: >> > osm-gps-map >> > python-osmgpsmap >> > >> > Both point to the same upstream URL. The description from upstream of >> > osm-gps-map says it includes python bindings but there is not currently >> > a >> > separate sub-package generated... >> > >> > So what's the deal? Do one of these packages need to be retired? >> >> No. The wrong %description has been pointed out in the review request. >> >> Review Request: osm-gps-map - A Gtk+ widget for displaying OpenStreetMap >> tiles >> https://bugzilla.redhat.com/show_bug.cgi?id=701982 >> >> Blocks: 702103 >> >> Bug 702103 - Review Request: python-osmgpsmap - Python bindings for >> osm-gps-map GTK+ widget >> https://bugzilla.redhat.com/show_bug.cgi?id=702103 > > More than that, although the description on the upstream site still says > there are python bindings, the whole python directory in the source seems to > have been removed... Sorry, just seeing this discussion now. What happened was that the newest version of osm-gps-map added gobject introspection, so Python bindings can be automatically generated. The older python-osmgpsmap bindings I believe are deprecated now. I haven't had the time to set up a rawhide system to do any testing though but probably what needs to happen is make sure that anything that used the older bindings get ported and then the old bindings be retired. AFAIK the only thing that used the bindings is Gramps, but I haven't used that in a long time and turned over ownership. -- Jeff Ollie -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On 08/14/2013 01:00 PM, Matthew Miller wrote: On Wed, Aug 14, 2013 at 10:04:41AM -0600, Kevin Fenzi wrote: I don't see any harm I guess in fesco deciding that we are in favor in general of this plan and ask the Board if we are going down a path they don't want us to before writing up concrete proposals. Yeah, I was hoping to have discussion from Flock written up nicely for us to talk about at this meeting, but given the time and that I haven't eaten _breakfast_ yet, I don't think that's going to happen. For this meeting, I have several separate proposals: 1. In order to build what we need for the future of Fedora, FESCO endorses the idea of moving from a one-policy-fits-all-software policy to a tiered model as roughly laid out in http://mattdm.org/fedora/next, and recommends this to the board as the technical underpinning of our strategic direction. 2. FESCO-created working group to draft Fedora Base Design as called for in that proposal. Has fesco already created that working group if so who's on it? 3. FESCO-created working group to draft Ring 2 policies and infrastructure needs. Has fesco already created that working group if so who's on it? Also, not yet ready for a proposal but maybe for discussion: * These products would be Fedora Workstation, Fedora Server, and Fedora Cloud (precise definitions to be developed), based around a common core shared wherever possible and with infrastructure for other groups based around other possible products to develop. The above does not solve historic problem and differences in our community and arguably gives us no benefits of implementing over what we currently have. For example what would be the default desktop in the "Fedora workstation" and why ? Would we be defaulting and or recommending one application over another in "Fedora server" for example openldap vs 389ds, kvm vs xen, postgresql vs mariadb if so why? Given that the above proposal are not direct products of SIG's who's in control of what goes in and what goes out of the Fedora Workstation, Fedora Server, and Fedora Cloud and their target audience ? As I see it the above part of the proposal only splits the "default" product into three different "products" without actually solving anything. Since I dont see how that you propose addresses and or solves any of the issues we are faced with I argue the way forward for us should be that Fedora "products" are the results/publication of each sub-community but not creation of whom releng/fesco/board specific Fedora individual or as an whole Fedora Workstation, Fedora Server, and Fedora Cloud SIG? JBG -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, 2013-08-14 at 13:00 -0400, Matthew Miller wrote: > * These products would be Fedora Workstation, Fedora Server, and Fedora > Cloud (precise definitions to be developed) Why not derive these definitions from the current Red Hat Enterprise Linux products? -- 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: Rawhide Koji Errors (Requires: /sbin/ldconfig)
Sérgio Basto wrote: > I take a look in "my" Virtualbox.spec and it use /sbin/ldconfig but not > in Requires, is not a error use Requires: /sbin/ldconfig ? depends, see https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Shared_libraries whether an explicit dependency is needed (or not). -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora ARM Weekly Status Meeting 2013-08-14
Good day all, Please join us today (Wednesday, August 14th) at 4PM EDT (8PM UTC) for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode. On the agenda so far.. 0) Status of ACTION items from our previous meeting 1) Problem packages 2) Kernel Status Update 3) Aarch64 - Status Update - F19 Remix 4) Flock Wrap-up - Did you attend? Tell us about it! 5) Open Floor If there is something that you would like to discuss that isn't mentioned please feel free to bring it up at the end of the meeting or send an email to the list. -- 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: RFC: Old packages remain on the mirrors for one week
I guess I'm open to the idea, but I have long wished we could have some way to always keep the previous version of a package for yum downgrades. ;( Keeping all that in metadata would bloat it a lot. kevin signature.asc Description: PGP signature -- 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: RFC: Old packages remain on the mirrors for one week
On Mon, 12 Aug 2013 11:07:43 -0400 Mathieu Bridon wrote: ...snip... > It has an added benefit: it could make « yum downgrade » work better. This wouldn't work with yum downgrade would it? Doesn't yum downgrade need to 'see' the packages in the metadata? kevin signature.asc Description: PGP signature -- 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: Rawhide Koji Errors (Requires: /sbin/ldconfig)
Sérgio Basto wrote:
> On Qua, 2013-08-14 at 18:59 +0800, Christopher Meng wrote:
>> Seems another victim appeared in test list.
>>
>> This time is for /sbin/alternatives.
>
> rpm -qf /sbin/alternatives
> chkconfig-1.3.60-3.fc19.x86_64
>
> once again , I think Requires: /sbin/alternatives is wrong
> should be Requires: chkconfig
See
https://fedoraproject.org/wiki/Packaging:Alternatives
and use
Requires(post): %{_sbindir}/update-alternatives
...etc...
-- rex
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Titanium] Perl 5.18 re-rebuild of bootstrapped packages
commit f84af9893ca38354812e1aedea205dd5c8f24c87
Author: Jitka Plesnikova
Date: Wed Aug 14 19:08:31 2013 +0200
Perl 5.18 re-rebuild of bootstrapped packages
perl-Titanium.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Titanium.spec b/perl-Titanium.spec
index c9e4553..fbfa5ce 100644
--- a/perl-Titanium.spec
+++ b/perl-Titanium.spec
@@ -1,6 +1,6 @@
Name: perl-Titanium
Version:1.04
-Release:13%{?dist}
+Release:14%{?dist}
Summary:Strong, lightweight web application framework
License:GPL+ or Artistic
Group: Development/Libraries
@@ -63,6 +63,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2>/dev/null \;
%{_mandir}/man3/*
%changelog
+* Wed Aug 14 2013 Jitka Plesnikova - 1.04-14
+- Perl 5.18 re-rebuild of bootstrapped packages
+
* Tue Aug 06 2013 Emmanuel Seyman - 1.04-13
- Rebuild against perl 5.18
- Fix spelling mistake in the summary
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CGI-Emulate-PSGI] Perl 5.18 re-rebuild of bootstrapped packages
commit 58c944d0ed6ba5221e2c856a1b0ab8042a86a4ea
Author: Jitka Plesnikova
Date: Wed Aug 14 19:04:04 2013 +0200
Perl 5.18 re-rebuild of bootstrapped packages
perl-CGI-Emulate-PSGI.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-CGI-Emulate-PSGI.spec b/perl-CGI-Emulate-PSGI.spec
index 544d52b..3eb5b16 100644
--- a/perl-CGI-Emulate-PSGI.spec
+++ b/perl-CGI-Emulate-PSGI.spec
@@ -1,6 +1,6 @@
Name: perl-CGI-Emulate-PSGI
Version:0.15
-Release:4%{?dist}
+Release:5%{?dist}
Summary:PSGI adapter for CGI applications
License:GPL+ or Artistic
Group: Development/Libraries
@@ -48,6 +48,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Aug 14 2013 Jitka Plesnikova - 0.15-5
+- Perl 5.18 re-rebuild of bootstrapped packages
+
* Sat Aug 03 2013 Fedora Release Engineering
- 0.15-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 10:04:41AM -0600, Kevin Fenzi wrote: > I don't see any harm I guess in fesco deciding that we are in favor in > general of this plan and ask the Board if we are going down a path they > don't want us to before writing up concrete proposals. Yeah, I was hoping to have discussion from Flock written up nicely for us to talk about at this meeting, but given the time and that I haven't eaten _breakfast_ yet, I don't think that's going to happen. For this meeting, I have several separate proposals: 1. In order to build what we need for the future of Fedora, FESCO endorses the idea of moving from a one-policy-fits-all-software policy to a tiered model as roughly laid out in http://mattdm.org/fedora/next, and recommends this to the board as the technical underpinning of our strategic direction. 2. FESCO-created working group to draft Fedora Base Design as called for in that proposal. 3. FESCO-created working group to draft Ring 2 policies and infrastructure needs. 4. Ask SCL team and FPC if they can find a way for SCL to be included in Fedora in F20 timeframe, within a special area of the current guidelines as a trial for ring 2 tech in Fedora. Also, not yet ready for a proposal but maybe for discussion: * We recommend Fedora move to a product-centered approach for designing, building, and marketing Fedora. * These products would be Fedora Workstation, Fedora Server, and Fedora Cloud (precise definitions to be developed), based around a common core shared wherever possible and with infrastructure for other groups based around other possible products to develop. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Test-Synopsis] Perl 5.18 re-rebuild of bootstrapped packages
commit 9f48f58058e0770c5c164c6961a2dca3e748d115
Author: Jitka Plesnikova
Date: Wed Aug 14 18:50:24 2013 +0200
Perl 5.18 re-rebuild of bootstrapped packages
perl-Test-Synopsis.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-Synopsis.spec b/perl-Test-Synopsis.spec
index 6a3cc1a..3d509f1 100644
--- a/perl-Test-Synopsis.spec
+++ b/perl-Test-Synopsis.spec
@@ -1,6 +1,6 @@
Name: perl-Test-Synopsis
Version: 0.06
-Release: 18%{?dist}
+Release: 19%{?dist}
Summary: Test your SYNOPSIS code
Group: Development/Libraries
License: GPL+ or Artistic
@@ -64,6 +64,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::Synopsis.3pm*
%changelog
+* Wed Aug 14 2013 Jitka Plesnikova - 0.06-19
+- Perl 5.18 re-rebuild of bootstrapped packages
+
* Sun Aug 04 2013 Fedora Release Engineering
- 0.06-18
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Config-Tiny] Perl 5.18 re-rebuild of bootstrapped packages
commit 3d103d1283cfaf0636ff4ae8d8867bdfd857b64a
Author: Jitka Plesnikova
Date: Wed Aug 14 18:50:55 2013 +0200
Perl 5.18 re-rebuild of bootstrapped packages
perl-Config-Tiny.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Config-Tiny.spec b/perl-Config-Tiny.spec
index 286ad96..d0b05bb 100644
--- a/perl-Config-Tiny.spec
+++ b/perl-Config-Tiny.spec
@@ -1,6 +1,6 @@
Name: perl-Config-Tiny
Version: 2.14
-Release: 9%{?dist}
+Release: 10%{?dist}
Summary: Perl module for reading and writing .ini style configuration
files
Group: Development/Libraries
License: GPL+ or Artistic
@@ -54,6 +54,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Config::Tiny.3pm*
%changelog
+* Wed Aug 14 2013 Jitka Plesnikova - 2.14-10
+- Perl 5.18 re-rebuild of bootstrapped packages
+
* Sat Aug 03 2013 Fedora Release Engineering
- 2.14-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-autodie] Perl 5.18 re-rebuild of bootstrapped packages
commit 9b6764d9aa6822c1dd7addebf172ea8c7f9db887
Author: Jitka Plesnikova
Date: Wed Aug 14 18:50:25 2013 +0200
Perl 5.18 re-rebuild of bootstrapped packages
perl-autodie.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-autodie.spec b/perl-autodie.spec
index 6696dfc..8383b21 100644
--- a/perl-autodie.spec
+++ b/perl-autodie.spec
@@ -1,6 +1,6 @@
Name: perl-autodie
Version:2.20
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Replace functions with ones that succeed or die
License:GPL+ or Artistic
Group: Development/Libraries
@@ -82,6 +82,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Aug 14 2013 Jitka Plesnikova - 2.20-4
+- Perl 5.18 re-rebuild of bootstrapped packages
+
* Sun Aug 04 2013 Fedora Release Engineering
- 2.20-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-SubCalls] Perl 5.18 re-rebuild of bootstrapped packages
commit 6891c5a831aa2ce188637a17412deefe7a306463
Author: Jitka Plesnikova
Date: Wed Aug 14 18:50:12 2013 +0200
Perl 5.18 re-rebuild of bootstrapped packages
perl-Test-SubCalls.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-SubCalls.spec b/perl-Test-SubCalls.spec
index e45f9f4..0f7e88f 100644
--- a/perl-Test-SubCalls.spec
+++ b/perl-Test-SubCalls.spec
@@ -1,6 +1,6 @@
Name: perl-Test-SubCalls
Version:1.09
-Release:16%{?dist}
+Release:17%{?dist}
Summary:Track the number of times subs are called
Group: Development/Libraries
License:GPL+ or Artistic
@@ -58,6 +58,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/Test::SubCalls.3pm*
%changelog
+* Wed Aug 14 2013 Jitka Plesnikova - 1.09-17
+- Perl 5.18 re-rebuild of bootstrapped packages
+
* Sun Aug 04 2013 Fedora Release Engineering
- 1.09-16
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: FYI: F20 Feature: Migrate to Bluez5
On 08/14/2013 06:29 PM, Than Ngo wrote: > it's effected in KDE (libbluedevil). someone is working on this, but > it's not expected the bluez5 support will be ready for F20! > > So f21 is Ok as goal, but f20 is definitely to early for KDE! I brought this up at a KDE meeting [1] last month and Kevin Kofler and other people who were there said it should be possible to ship a git snapshot of BlueDevil. And Kevin repeated the same in the bluez5 ticket [2] as well. Can you bring this up at a KDE meeting again? Currently it looks like all the KDE maintainers aren't on the same page with this. [1] http://meetbot.fedoraproject.org/fedora-meeting/2013-07-09/kde-sig.2013-07-09-15.03.log.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=974145#c10 -- Thanks, Kalev -- 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: F20 System Wide Change: Web Assets
On Wed, Aug 14, 2013 at 5:23 AM, T.C. Hollingsworth wrote: > I wasn't aware Debian already exported a directory for this. (But > "/javascripts", really?) It would be nice if they wrote that into > their policy. I was slightly wrong: it's "/javascript" (singular). I couldn't find any formal Debian packaging policy for this, but the alias is set here: http://sources.debian.net/src/javascript-common/latest/javascript-common.conf > I wasn't aware Debian already exported a directory for this. (But > "/javascripts", really?) It would be nice if they wrote that into > their policy. Agreed! > The httpd maintainer would really prefer if we didn't use something > that could potentially conflict as easily as "/javascripts" though. > Not sure if "Debian does it" is a good enough reason to override > that... I just read over http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553173 , which makes me wonder if this URL is indeed going to cause problems or even change altogether. I've emailed the Debian pkg-javascript-devel list for clarification. http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2013-August/005888.html - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Crypt-CBC] Perl 5.18 re-rebuild of bootstrapped packages
commit e9edae4dce276bc61c22e6232587f5257753cdf0
Author: Jitka Plesnikova
Date: Wed Aug 14 18:39:46 2013 +0200
Perl 5.18 re-rebuild of bootstrapped packages
perl-Crypt-CBC.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Crypt-CBC.spec b/perl-Crypt-CBC.spec
index 7b5f16f..56dd96b 100644
--- a/perl-Crypt-CBC.spec
+++ b/perl-Crypt-CBC.spec
@@ -1,7 +1,7 @@
Summary: Encrypt Data with Cipher Block Chaining Mode
Name: perl-Crypt-CBC
Version: 2.33
-Release: 2%{?dist}
+Release: 3%{?dist}
# Upstream confirms that they're under the same license as perl.
# Wording in CBC.pm is less than clear, but still.
License: GPL+ or Artistic
@@ -61,6 +61,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Wed Aug 14 2013 Jitka Plesnikova - 2.33-3
+- Perl 5.18 re-rebuild of bootstrapped packages
+
* Sat Aug 03 2013 Fedora Release Engineering
- 2.33-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Compress-Raw-Zlib] Perl 5.18 re-rebuild of bootstrapped packages
commit c037aab6563890609d2db1d6a61daaeb169b0041
Author: Jitka Plesnikova
Date: Wed Aug 14 18:37:41 2013 +0200
Perl 5.18 re-rebuild of bootstrapped packages
perl-Compress-Raw-Zlib.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Compress-Raw-Zlib.spec b/perl-Compress-Raw-Zlib.spec
index 3665ab1..7f0cacc 100644
--- a/perl-Compress-Raw-Zlib.spec
+++ b/perl-Compress-Raw-Zlib.spec
@@ -1,6 +1,6 @@
Name: perl-Compress-Raw-Zlib
Version:2.062
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Low-level interface to the zlib compression library
License:GPL+ or Artistic
Group: Development/Libraries
@@ -61,6 +61,9 @@ make test
%{_mandir}/man3/Compress::Raw::Zlib.3pm*
%changelog
+* Wed Aug 14 2013 Jitka Plesnikova - 2.062-2
+- Perl 5.18 re-rebuild of bootstrapped packages
+
* Mon Aug 12 2013 Paul Howarth - 2.062-1
- Update to 2.062
- Typo fix (CPAN RT#86417)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Class-Load] Perl 5.18 re-rebuild of bootstrapped packages
commit 206bf1c4893fce9e665b345adda25cd1c15f5921
Author: Jitka Plesnikova
Date: Wed Aug 14 18:36:35 2013 +0200
Perl 5.18 re-rebuild of bootstrapped packages
perl-Class-Load.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Class-Load.spec b/perl-Class-Load.spec
index 9201844..220d179 100644
--- a/perl-Class-Load.spec
+++ b/perl-Class-Load.spec
@@ -1,6 +1,6 @@
Name: perl-Class-Load
Version: 0.20
-Release: 5%{?dist}
+Release: 6%{?dist}
Summary: A working (require "Class::Name") and more
Group: Development/Libraries
License: GPL+ or Artistic
@@ -99,6 +99,9 @@ make test
%{_mandir}/man3/Class::Load.3pm*
%changelog
+* Wed Aug 14 2013 Jitka Plesnikova - 0.20-6
+- Perl 5.18 re-rebuild of bootstrapped packages
+
* Sat Aug 03 2013 Fedora Release Engineering
- 0.20-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Scala package owner unresponsive
On Wed, Aug 14, 2013 at 07:12:32AM -0400, Ricky Elrod wrote: > I would like to take over this package and update it to 2.10.x for > Fedora 21 (or possibly 20, though it wouldn't be an official "Change", > because we're past the proposal deadline). If you have a working package for scala you may send me it, so I may commit it into the repository and initiate the update for F19. As a co-maintainer I have tried to create a package for scala-2.10.x without success. I was able to built the package locally, but the build failed on koji. That is the reason, that the current state of the scala git repository on Fedora is in a accident state. Best Regards: Jochen Schmitt -- 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: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Wed, Aug 14, 2013 at 12:04 PM, Kevin Fenzi wrote: > On Tue, 13 Aug 2013 22:41:37 -0700 > Toshio Kuratomi wrote: > >> Additional agenda item: >> >> Mattdm, sgallagh, and I were talking about the general fesco sentiment >> towards mattdm's fedora future direction proposal and the multiple >> fedora products idea at post-flock breakfast. My understanding is >> that the sentiment was that it would be a board decision whether to >> go that route, that fesco would be on charge of implementing it, and >> that fesco was generally in favour of it. >> >> The three of us thought it would be a good idea for fesco to >> officially vote on whether we can get behind the idea and then send >> it to the board so that we can start putting some proposals together. >> >> (Sorry for top-posting... on my phone.) > > Well, or would it be better to have a concrete proposal to take to > them? > > I don't see any harm I guess in fesco deciding that we are in favor in > general of this plan and ask the Board if we are going down a path they > don't want us to before writing up concrete proposals. Right. Less worrying about what the Board thinks, more worrying about what FESCo thinks. If those two entities wind up not agreeing, then we can discuss that. As for the Board, I'm hoping to bring up the future direction stuff as a topic we should at least be paying close attention to in the next meeting. Having something from FESCo to review would be great too. josh -- 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: FYI: F20 Feature: Migrate to Bluez5
Am Freitag, 21. Juni 2013, 17:16:09 schrieben Sie: > 2013-05-06 11:13, Peter Robinson skrev: > > On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera wrote: > >> Heya, > >> > >> In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices. > >> > >> Bluez5 uses a D-Bus API that's not compatible with Bluez4[1] and as > >> such, management applications and a number of libraries and daemons will > >> need to be ported. > >> > >> For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to > >> be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. > >> Packages for BlueZ5 will be available as soon as we figure out how to > >> integrate a few downstream features that were in the Fedora packages. > >> > >> Bluez4 and Bluez5 are not parallel-installable, and incompatible, so > >> other applications relying on Bluez4 will need to be ported by their > >> respective maintainers. > > > > Any analysis to what packages are affected, how many are yet to > > support the new API and how hard it will be for them to be ported > > over. > > I took a look to see what the impact would be. I am not a BlueZ expert, > so Bastien, please correct me if I am wrong somewhere. > > BlueZ ships a daemon and provides two main interfaces for applications > to use it: > > 1) libbluetooth shared library > > 2) org.bluez DBus API > > The TL;DL version is that in my findings, the only package that still > needs porting to bluez 5 is blueman. Others should either just continue > working, or need new versions packaged up. > > > Applications that use the libbluetooth shared library > - > > The library ABI hasn't changed and the soname in 5.x is still the same > as was in 4.x: libbluetooth.so.3, so the impact should be minimal. > Everything should be able to continue working without needing even a > simple rebuild. > > Affected packages: > > $ repoquery -q --whatrequires bluez-libs -s | sort | uniq > amora-1.1-10.fc19.src.rpm > anyremote-6.3.1-1.fc20.src.rpm > asterisk-11.4.0-2.fc20.src.rpm > bluecove-2.1.1-0.5.20101024snap63.fc19.src.rpm > blueman-1.23-6.fc19.src.rpm > bluemodem-0.7-9.fc19.src.rpm > bluez-4.101-6.fc19.src.rpm > bluez-hcidump-2.5-2.fc19.src.rpm > btkbdd-1.3-2.fc19.src.rpm > cwiid-0.6.00-21.20100505gitfadf11e.fc19.src.rpm > dolphin-emu-3.0-12.fc19.src.rpm > fawkes-0.5.0-7.fc20.src.rpm > foxtrotgps-1.1.1-5.fc19.src.rpm > gammu-1.26.1-10.fc19.src.rpm > gnokii-0.6.31-6.fc20.src.rpm > gnome-phone-manager-0.68-10.fc19.src.rpm > gpsd-3.9-1.fc20.src.rpm > gvfs-1.17.2-1.fc20.src.rpm > gypsy-0.9-1.fc20.src.rpm > kismet-0.0.2013.03.R1-1.fc20.src.rpm > libbtctl-0.11.1-13.fc20.src.rpm > libopensync-plugin-irmc-0.22-6.fc19.src.rpm > nxtrc-2.3-7.fc19.src.rpm > obexd-0.46-5.fc20.src.rpm > obex-data-server-0.4.6-5.fc19.src.rpm > obexfs-0.12-6.fc19.src.rpm > obexftp-0.23-13.fc20.src.rpm > openobex-1.5-8.fc19.src.rpm > pilot-link-0.12.5-16.fc20.src.rpm > pulseaudio-4.0-1.fc20.src.rpm > pybluez-0.18-6.fc19.src.rpm > qemu-1.5.0-9.fc20.src.rpm > syncevolution-1.3.99.3-2.fc20.src.rpm > vfrnav-20130510-1.fc20.src.rpm-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Filter] Perl 5.18 re-rebuild of bootstrapped packages
commit f190e2cd1466ee93197d7f2fead3ba100a7a94ea
Author: Jitka Plesnikova
Date: Wed Aug 14 18:10:13 2013 +0200
Perl 5.18 re-rebuild of bootstrapped packages
perl-Filter.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Filter.spec b/perl-Filter.spec
index c7bc0b3..dd116d2 100644
--- a/perl-Filter.spec
+++ b/perl-Filter.spec
@@ -1,7 +1,7 @@
Name: perl-Filter
Epoch: 1
Version:1.49
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Perl source filters
License:GPL+ or Artistic
Group: Development/Libraries
@@ -61,6 +61,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Aug 14 2013 Jitka Plesnikova - 1:1.49-5
+- Perl 5.18 re-rebuild of bootstrapped packages
+
* Sat Aug 03 2013 Fedora Release Engineering
- 1:1.49-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)
On Tue, 13 Aug 2013 22:41:37 -0700 Toshio Kuratomi wrote: > Additional agenda item: > > Mattdm, sgallagh, and I were talking about the general fesco sentiment > towards mattdm's fedora future direction proposal and the multiple > fedora products idea at post-flock breakfast. My understanding is > that the sentiment was that it would be a board decision whether to > go that route, that fesco would be on charge of implementing it, and > that fesco was generally in favour of it. > > The three of us thought it would be a good idea for fesco to > officially vote on whether we can get behind the idea and then send > it to the board so that we can start putting some proposals together. > > (Sorry for top-posting... on my phone.) Well, or would it be better to have a concrete proposal to take to them? I don't see any harm I guess in fesco deciding that we are in favor in general of this plan and ask the Board if we are going down a path they don't want us to before writing up concrete proposals. kevin signature.asc Description: PGP signature -- 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: Rawhide Koji Errors (Requires: /sbin/ldconfig)
On Qua, 2013-08-14 at 18:59 +0800, Christopher Meng wrote: > Seems another victim appeared in test list. > > This time is for /sbin/alternatives. rpm -qf /sbin/alternatives chkconfig-1.3.60-3.fc19.x86_64 once again , I think Requires: /sbin/alternatives is wrong should be Requires: chkconfig > Sorry for no contexts, but what about removing /sbin or /bin from > every spec? I think RPM can handle this without fullpath. > > Thanks. > > Sent from Note I > -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] Please review 2nd (fix regression) ticket 512: improve performance of vattr code
This review takes into account remarks done by Ludwig and Rich https://fedorahosted.org/389/attachment/ticket/512/0006-Ticket-512-improve-performance-of-vattr-code.patch https://fedorahosted.org/389/ticket/512 -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Broken chkconfig in rawhide?
Rex Dieter wrote: > Mario Ceresa wrote: > >> Dear all, while trying to rebuild InsightToolkit in rawhide I get the >> following error ( >> http://kojipkgs.fedoraproject.org//work/tasks/3964/5813964/root.log): >> >> DEBUG util.py:264: Error: Package: 1:mariadb-5.5.32-9.fc20.x86_64 >> (build) >> DEBUG util.py:264: Requires: /sbin/update-alternatives > > Looks like a bug in mariadb packaging not following > http://fedoraproject.org/wiki/Packaging:Alternatives > > chkconfig provides /usr/sbin/update-alternatives Should (hopefully) be fixed in mariadb-5.5.32-10 build underway now. -- rex -- 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: Broken chkconfig in rawhide?
Mario Ceresa wrote: > Dear all, while trying to rebuild InsightToolkit in rawhide I get the > following error ( > http://kojipkgs.fedoraproject.org//work/tasks/3964/5813964/root.log): > > DEBUG util.py:264: Error: Package: 1:mariadb-5.5.32-9.fc20.x86_64 (build) > DEBUG util.py:264: Requires: /sbin/update-alternatives Looks like a bug in mariadb packaging not following http://fedoraproject.org/wiki/Packaging:Alternatives chkconfig provides /usr/sbin/update-alternatives -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F20 System Wide Change: Migrate to Bluez 5
= Proposed System Wide Change: Migrate to Bluez 5 = https://fedoraproject.org/wiki/Changes/Bluez5 Note: post deadline exception to coordinate BlueZ 5 effort as upstreams were not clear to move to it in the time of submission deadline. Change owner(s): Bastien Nocera, Kalev Lember, and the desktop SIG BlueZ is the Linux Bluetooth stack for managing wireless Bluetooth devices. In Fedora 20, we are going to switch from BlueZ version 4 to version 5. == Detailed description == The BlueZ project recently released BlueZ version 5. Compared to BlueZ version 4, the new release brings new features and improvements, however it is also accompanied by a significant API change. The BlueZ versions 4 and 5 are not parallel installable, and we need coordination between various parts of Fedora to switch over at the same time. This is coming late after the Change Proposals Submission Deadline. As this affects various critical parts of the distribution (KDE, GNOME, NetworkManager, pulseaudio), we wanted to be sure it is feasible to switch everything over at the same time, and were considering postponing it to Fedora 21. However, upstreams have made good progress with porting over to BlueZ 5 and we feel it would be beneficial for Fedora to switch over during the Fedora 20 timeframe. == Scope == BlueZ 5 uses a D-Bus API that's not compatible with BlueZ 4 and as such, management applications and a number of libraries and daemons need to be ported. * Proposal owners: This is a change affecting many parts of the distribution. The proposal owners, supported by the rest of the Desktop SIG, are going to take care of updating the BlueZ package to version 5 and porting over gnome-bluetooth, NetworkManager, and PulseAudio packages. * KDE SIG: The bluetooth stack for KDE is BlueDevil. It has a git branch with BlueZ 5 support and the Fedora KDE SIG will handle updating the package to a git snapshot. * Desktop SIG: For GNOME 3.10, Gustavo Padovan and Bastien Nocera have been porting gnome- bluetooth, NetworkManager and PulseAudio to BlueZ 5, and the Fedora Desktop SIG will ensure these get updated to the BlueZ 5 versions in Fedora. * NetworkManager team: ... will ensure the relevant NetworkManager changes land in Fedora 20. * MATE team: mate-bluetooth has not received much upstream attention recently and is likely to not get ported to BlueZ 5 in time for F20. However, the Fedora MATE maintainers are looking into switching back to using gnome-bluetooth, and creating a panel applet for MATE that uses gnome-bluetooth underneath. An initial prototype is available at https://github.com/NiceandGently/bluetooth-panel-applet * Other developers: Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers. * Release engineering: No release engineering coordination required. * Policies and guidelines: No changes needed in the packaging guidelines. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: F20 System Wide Change: Web Assets
On 08/14/2013 07:34 AM, T.C. Hollingsworth wrote:
On Mon, Aug 12, 2013 at 1:05 PM, Robert Marcano
wrote:
On 08/12/2013 03:23 PM, Robert Marcano wrote:
This is a better explanation of why the use /usr/share/javascript: We
want to be compatible with others distribution that have the legacy idea
that JavaScript is a browser only thing, so in this directory we will
only store JavaScript that run on the browser
Sorry, I missed this:
"If a JavaScript library can be executed locally or consists purely of
JavaScript code, it must be installed into a subdirectory of %{_jsdir}."
and the Feature says:
"Additionally the following symlinks will be provided:
/usr/share/web-assets/javascript points to /usr/share/javascript"
So non browser JavaScript code will be shared via HTTP?, all those pages are
out of sync that it is difficult to understand what will go to each place
So one possible option that would address your concerns would be to
require every js-foo package to also provide a webjs-foo subpackage or
so that just contains a symlink in /usr/share/web-assets/js to the
appropriate location in /usr/share/javascript.
Or not sharing js, fonts and other assets from a shared directory? I was
checking an application like Roundcube. Patching it requires change a
few files because web apps have no standard way to use those files, It
is easy to find assets files than locating where it is used and test if
you aren't missing something after you patch it. There is need to update
the patches every time a new version make the patch invalid. or check if
a new file is linking to them
What about replace the files on the application directory (/roundcube)
using the webserver related configuration for that like Alias
Alias /roundcube/path_to_jquery/jquery.min.js
/usr/share/javascript/jquery/jquery.min.js
The list of the files should be generated anyways, the Java guidelines
explicitly say that the packager should remove other bundled software
and upload a modified source package (I think this makes easier to say
an application is GPL and not GPL + Apache + BSD... on the spec license
field), probably web application should do the same
We can add rpm macros to generate roundcube-httpd, roundcube-cherokee,
roundcube-nginx, taking the mapping list and generating the equivalent
of the Alias of Apache for those web servers, a lot of the current
packaged applications have a dependency on Apache, and sometimes there
is no need for that
The spec authors have expressed that they have no intentions of
mandating that the packager must use the shared directory, that they can
import the files to the application namespace, so why not make the later
it the standard way?
That would provide a way for dependent packages to express "hey, I
just need you on the server-side" and another way to say "hey, I need
you served over HTTP".
But then, what do we want to do about fonts? Adding *-webfonts
subpackages to every font package would be a lot of work, and makes
that awesome WordPress usecase I mentioned much, much harder. What
about CSS? Do we really need a css-bootstrap for when someone wants
to create a locally run HTML5 application with something like
node-webkit and another webcss-bootstrap for when they really want it
served over HTTP?
It's really a lot of work optimizing for what is an edge case. I'm
not convinced it's necessary, but I'll mention this to FPC during my
meeting with them on Thursday for their input anyway.
-T.C.
--
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: Rawhide Koji Errors (Requires: /sbin/ldconfig)
On 08/14/2013 12:59 PM, Christopher Meng wrote: Seems another victim appeared in test list. This time is for /sbin/alternatives. Sorry for no contexts, but what about removing /sbin or /bin from every spec? Not a clever idea. Very oversimplified, in RPM-provides/requires, "full paths" symbols refer to files, while "non-full-path" symbols refer to packages. As files/binaries may be moved between packages, there is no strict connection at all between a package's name and a binary. > I think RPM can handle this without fullpath. RPM is pretty much irrelevant here. Using full paths assures using the correct binary independently from whatever environment variables might be set and from packages. Ralf -- 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: [dnf] dnf-0.3.11
On 08/14/2013 11:46 AM, poma wrote: Summ. yum - kernel-PAE-modules-extra - Installing - OK dnf - kernel-PAE-modules-extra - Upgrading - ? poma Hi, this looks like a new bug related to Yum's installonly feature which is still a bit problematic in DNF, for instance see [1]. Please open a bugzilla for this. Thank you, Ales [1] https://bugzilla.redhat.com/show_bug.cgi?id=880524 -- 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: F20 System Wide Change: Web Assets
On Mon, Aug 12, 2013 at 1:05 PM, Robert Marcano
wrote:
> On 08/12/2013 03:23 PM, Robert Marcano wrote:
>>
>>
>> This is a better explanation of why the use /usr/share/javascript: We
>> want to be compatible with others distribution that have the legacy idea
>> that JavaScript is a browser only thing, so in this directory we will
>> only store JavaScript that run on the browser
>
>
> Sorry, I missed this:
>
> "If a JavaScript library can be executed locally or consists purely of
> JavaScript code, it must be installed into a subdirectory of %{_jsdir}."
>
>
> and the Feature says:
>
> "Additionally the following symlinks will be provided:
>
> /usr/share/web-assets/javascript points to /usr/share/javascript"
>
> So non browser JavaScript code will be shared via HTTP?, all those pages are
> out of sync that it is difficult to understand what will go to each place
So one possible option that would address your concerns would be to
require every js-foo package to also provide a webjs-foo subpackage or
so that just contains a symlink in /usr/share/web-assets/js to the
appropriate location in /usr/share/javascript.
That would provide a way for dependent packages to express "hey, I
just need you on the server-side" and another way to say "hey, I need
you served over HTTP".
But then, what do we want to do about fonts? Adding *-webfonts
subpackages to every font package would be a lot of work, and makes
that awesome WordPress usecase I mentioned much, much harder. What
about CSS? Do we really need a css-bootstrap for when someone wants
to create a locally run HTML5 application with something like
node-webkit and another webcss-bootstrap for when they really want it
served over HTTP?
It's really a lot of work optimizing for what is an edge case. I'm
not convinced it's necessary, but I'll mention this to FPC during my
meeting with them on Thursday for their input anyway.
-T.C.
--
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: F20 System Wide Change: Web Assets
On Mon, Aug 12, 2013 at 12:53 PM, Robert Marcano wrote: > This is a better explanation of why the use /usr/share/javascript: We want > to be compatible with others distribution that have the legacy idea that > JavaScript is a browser only thing, so in this directory we will only store > JavaScript that run on the browser No, we want to be compatible with the real world where that's where 99% of JS is used. > This sounds like you think there aren't JavaScript libraries that aren't > tied to an specific runtime, there are > > So, where do I put the code for a reusable, non web based, or runtime > dependent JavaScript library? like [1] or [2], these examples doesn't have > Node.js, GNOME Shell, nor GNOME JavaScript applications dependencies, pure > and simple JavaScript. I don't see it on the "JavaScript Packaging > Guidelines". If this is a general "JavaScript Packaging Guidelines", it > should standardize something for them, if it is "JavaScript for browser > Packaging Guidelines" it should be renamed Just because JS is obstensibly browser-specific doesn't mean it's useless to any of the other runtimes either. jQuery gets used a lot in the node universe too. (You get a server-side implementation of the DOM with node's jsdom package which is very useful in certain situations.) That means the set of JavaScript that is only ever useful for sending to browsers is the empty set, so it's completely pointless to partition off a space for only that. > If everything else apply to them, I don't see why a Node.js application or a > GNOME Shell extension need to pull a package named web-assets, it is a wrong > name, plain and simple, and worse If they don't store anything on > /usr/share/javascript because they aren't browser code, why pull them? You only need "web-assets-filesystem" if you need /usr/share/javascript. Clarified in: https://fedoraproject.org/w/index.php?title=User:Patches/PackagingDrafts/JavaScript&diff=349388&oldid=348671 -T.C. -- 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: Tcl/Tk 8.6
在 2013-8-14 PM7:16，"Georgios Petasis" 写道： > What is the problem? Perhaps I can help (as I also need Tcl/Tk 8.6). Hi, You should ask the maintainer, maybe problems related to rebuild(FTBFS, fault to bump soname and so on), or maybe problems related to himself(day job, family and so on). I also need tcl as many packages I haven't submitted are tcl related. I need help. -- 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: Tcl/Tk 8.6
在 2013-8-14 PM7:01，"Matěj Cepl" 写道： [omit] It's a friendly note, although I said it's not appropriate for most cases, I still help point out the bug URL. And the main cause is the tcl maintainer's problem, he didn't update it for almost a year. Thanks. -- 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: F20 System Wide Change: Web Assets
On Sat, Aug 10, 2013 at 11:34 PM, Ken Dreyer wrote: > On Fri, Aug 9, 2013 at 5:23 PM, T.C. Hollingsworth > wrote: >> Debian already uses /usr/share/javascript for this purpose, and it >> would be really nice if we both could coordinate on getting some >> upstream support for this in certain cases. I'm very strongly -1 >> against pointless Fedoraisms here. > > Speaking of Fedoraisms, could we please serve Javascripts through > "/javascripts" ? Debian already has a long precedent of doing this. > I'm concerned that if Fedora invents "_sysassets", we're setting > ourselves up to make the upstream advocacy task that you mentioned > much harder. I wasn't aware Debian already exported a directory for this. (But "/javascripts", really?) It would be nice if they wrote that into their policy. We still need something for CSS frameworks and such, but maybe we could drop the underscore and have: /sysassets/ -> for CSS, theming, etc. /javascripts/ -> for JS The httpd maintainer would really prefer if we didn't use something that could potentially conflict as easily as "/javascripts" though. Not sure if "Debian does it" is a good enough reason to override that... > Speaking as a web app package maintainer, I think this policy has > great intentions, and I think there's advantages to following Debian's > URL precedent. -T.C. -- 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: Tcl/Tk 8.6
Στις 14/8/2013 12:55, ο/η Christopher Meng έγραψε: There are some issues of 8.6, people are trying to fix it. Please search carefully and choose users list next time. http://bugzilla.redhat.com/889201 What is the problem? Perhaps I can help (as I also need Tcl/Tk 8.6). George -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Scala package owner unresponsive
I would like to begin following the policy for nonresponsive package maintainers with regard to the 'scala' package. I have attempted emailing the maintainer several times offering to co-maintain the package and have heard nothing in return. There is an open bug on the package for upgrading it to 2.10.x, which has been open since 03/14/2013 as well as other people stating they have been unable to contact the maintainer: https://bugzilla.redhat.com/show_bug.cgi?id=673971#c16 I'm somewhere between steps 4 and 5 right now, in the outline on this page: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers It's been well over 3 weeks, but this is my first message to devel about it. I would like to take over this package and update it to 2.10.x for Fedora 21 (or possibly 20, though it wouldn't be an official "Change", because we're past the proposal deadline). -Ricky -- 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: Tcl/Tk 8.6
On 2013-08-14, 09:55 GMT, Christopher Meng wrote: > There are some issues of 8.6, people are trying to fix it. > > Please search carefully and choose users list next time. > > http://bugzilla.redhat.com/889201 Sending the original poster to the users list doesn't sound like fair to me. Everybody can make a mistake and not finding the issue both here in the archives of this list and in the bugzilla seems quite simple. Moreover this bugzilla report seems like saying so nothing (the only relevant comment from the maintainer is from May that he will investigate), that asking for more information on this list (or Mr. Škarvada) seems quite appropriate. Best, Matěj -- 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: [dnf] dnf-0.3.11
Besides, librepo-0.0.5-3.fc19.i686 curl-7.29.0-7.fc19.i686 /etc/dnf/dnf.conf exclude=kernel*modules-extra # dnf upgrade kernel\* … Is this ok [y/N]: y Downloading Packages: Error Downloading Packages: kernel-PAE-3.10.5-201.fc19.i686: Problem with repo 'updates': An Curl handle error: Unsupported protocol kernel-headers-3.10.5-201.fc19.i686: Problem with repo 'updates': An Curl handle error: Unsupported protocol kernel-PAE-devel-3.10.5-201.fc19.i686: Problem with repo 'updates': An Curl handle error: Unsupported protocol With curl-7.32.0-1.fc20.i686 & libmetalink-0.1.2-4.fc20.i686 still no love. poma -- 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: Rawhide Koji Errors (Requires: /sbin/ldconfig)
Seems another victim appeared in test list. This time is for /sbin/alternatives. Sorry for no contexts, but what about removing /sbin or /bin from every spec? I think RPM can handle this without fullpath. Thanks. Sent from Note I -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken chkconfig in rawhide?
Dear all, while trying to rebuild InsightToolkit in rawhide I get the following error ( http://kojipkgs.fedoraproject.org//work/tasks/3964/5813964/root.log): DEBUG util.py:264: Error: Package: 1:mariadb-5.5.32-9.fc20.x86_64 (build) DEBUG util.py:264: Requires: /sbin/update-alternatives DEBUG util.py:264: You could try using --skip-broken to work around the problem DEBUG util.py:264: You could try running: rpm -Va --nofiles --nodigest Does it mean that update-alternative (chkconfig) is currently broken? It seems it built okay in koji: http://koji.fedoraproject.org/koji/packageinfo?packageID=308 Thanks for any help, Mario -- 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: BlueZ Status in Fedora.
Am Tue, 13 Aug 2013 23:59:15 + schrieb devel-requ...@lists.fedoraproject.org: > - Original Message - > > On 08/02/2013 10:15 AM, Jaroslav Reznik wrote: > > > Let me know - I'd like to have this one as a Change if it's going to F20 > > > > I have been coordinating with various people and looks like all teams > > are go. NetworkManager and PulseAudio changes are slightly lagging > > behind, but it's probably best if we move forward and try to integrate > > everything together in Rawhide before branching F20. > > > > I've cleaned up the feature page and marked it as ready for wrangler: > > > > https://fedoraproject.org/wiki/Changes/Bluez5 > > The page looks good, thanks for coordination. Just could you please extend > the scope with resolution for mate bt? Also for contingency plan, I'd like > to see a real deadline - Beta as a point to revert things as a coordination > would be needed. Once done, pls let me know and I'll announce it and report > to FESCo to get an exception. > I don't see that adding a bluetooth-panel-applet package is easy for mate/xfce/lxde. First tests shows me that the removed panel code from gnome-bluetooth isn't independent from the the rest of the code. I quess for this reason the gnome dev didn't remove /usr/lib64/gnome-bluetooth/libgnome-bluetooth-applet.so.0, which is in latest upstream. Ok, i need really help to create such a package. But there is also another simple solution gnome-bluetooth dev should add the removed (fallback) panel applet code back. I'm pretty shure that is more easier for someone who knows the code to do that. If gnome-bluetooth is the only client after the bluez5 switch which is working in fedora, than it should be work for all desktops, imo. So adding the applet back would be a noble gesture from gnome to other desktops ;) PS: i think cinnamon is also affected, because so far i know use cinnamon blueman code in the momment. But i'm not shure in this point. -- 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: Suggestion: bmap files and bmaptool
On Wed, 2013-08-14 at 12:24 +0200, Björn Persson wrote: > Speaking of security, how is the integrity of the bmap file itself > verified? This is not implemented, unfortunately. This is another thing which I probably would need to do, and this is a very good point. I will look at this, after I do the SHA256 thing. > A checksum is of no use if you don't know who generated the > checksum. Fedora's checksum files are OpenPGP signed, as you can see > in > the one that Till linked to. Right, bmap file could also contain such a signature. > I don't see a cryptographic signature in > your example file. Are there detached signatures for the bmap files? Well, of course detached signatures can be generated. > And does Bmaptool verify the signatures? But no, bmaptool does not verify them. And again, if there is real interest from Fedora community, I will try to implement this faster (or accept someone's contribution :-)) Thanks for the feed-back! -- Best Regards, Artem Bityutskiy -- 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: Suggestion: bmap files and bmaptool
Artem Bityutskiy wrote: >On Wed, 2013-08-14 at 11:44 +0200, Till Maas wrote: >> On Wed, Aug 14, 2013 at 12:21:23PM +0300, Artem Bityutskiy wrote: >> > On Wed, 2013-08-14 at 10:37 +0200, Till Maas wrote: >> > > On Wed, Aug 14, 2013 at 09:31:22AM +0300, Artem Bityutskiy wrote: >> > > >> > > > Other things like reading from remote sites, progress >> > > > indicator, protecting your mounted disks, uncompressing >> > > > on-the-fly, checking sha1 of the data ond of the bmap file >> > > > itself - are goodies, although important ones. >> > > >> > > Why sha1? If the check is there for security reasons, please use >> > > at least sha256. >> > >> > Should not be difficult to implement if there is demand. >> >> SHA-256 is used to create the signatures of other distributed files: >> https://fedoraproject.org/static/checksums/Fedora-19-i386-CHECKSUM >> >> Therefore if bmap is used it should also use at least SHA 256. It is >> recommended against using SHA-1 for more than 7 years now: >> http://csrc.nist.gov/groups/ST/hash/policy_2006.html > >Sure, good point, thank you, I'll implement sha-256 support. Speaking of security, how is the integrity of the bmap file itself verified? A checksum is of no use if you don't know who generated the checksum. Fedora's checksum files are OpenPGP signed, as you can see in the one that Till linked to. I don't see a cryptographic signature in your example file. Are there detached signatures for the bmap files? And does Bmaptool verify the signatures? -- Björn Persson Sent from my computer. signature.asc Description: PGP signature -- 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: Tcl/Tk 8.6
There are some issues of 8.6, people are trying to fix it. Please search carefully and choose users list next time. http://bugzilla.redhat.com/889201 -- 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: [dnf] dnf-0.3.11
On 13.08.2013 12:50, Ales Kozumplik wrote: > Hi, > > There is a new bugfix release of DNF available in F19[1] and Rawhide > today. The most visible change is that the package downloads slowdown > has been fixed. For the full release notes please see [2] > > [1] https://admin.fedoraproject.org/updates/dnf-0.3.11-1.git7d717c7.fc19 > [2] http://akozumpl.github.io/dnf/release_notes.html#id10 > > Ales # yum --version 3.4.3 Installed: rpm-4.11.1-1.fc19.i686 at 2013-07-09 02:13 Built: Fedora Project at 2013-07-05 08:34 Committed: Panu Matilainen at 2013-07-05 Installed: yum-3.4.3-105.fc19.noarch at 2013-08-08 10:14 Built: Fedora Project at 2013-08-06 15:51 Committed: Zdenek Pavlas at 2013-08-06 # yum update kernel\* Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies --> Running transaction check ---> Package kernel-PAE.i686 0:3.10.5-201.fc19 will be installed ---> Package kernel-PAE-devel.i686 0:3.10.5-201.fc19 will be installed ---> Package kernel-PAE-modules-extra.i686 0:3.10.5-201.fc19 will be installed ---> Package kernel-headers.i686 0:3.10.4-300.fc19 will be updated ---> Package kernel-headers.i686 0:3.10.5-201.fc19 will be an update --> Finished Dependency Resolution Dependencies Resolved Package Arch VersionRepository Size Installing: kernel-PAE i686 3.10.5-201.fc19updates 28 M kernel-PAE-devel i686 3.10.5-201.fc19updates 8.2 M kernel-PAE-modules-extra i686 3.10.5-201.fc19updates 2.0 M Updating: kernel-headers i686 3.10.5-201.fc19updates 873 k Transaction Summary Install 3 Packages Upgrade 1 Package Total download size: 39 M Is this ok [y/d/N]: y # dnf --version 0.3.11 Installed: dnf-0:0.3.11-1.git7d717c7.fc19.noarch at 2013-08-14 09:18 Built: Fedora Project at 2013-08-13 10:34 Installed: rpm-0:4.11.1-1.fc19.i686 at 2013-07-09 02:13 Built: Fedora Project at 2013-07-05 08:34 # dnf update kernel\* Setting up Upgrade Process Resolving Dependencies --> Starting dependency resolution ---> Package kernel-PAE.i686 3.10.5-201.fc19 will be installed ---> Package kernel-PAE-devel.i686 3.10.5-201.fc19 will be installed ---> Package kernel-PAE-modules-extra.i686 3.10.4-300.fc19 will be upgraded ---> Package kernel-PAE-modules-extra.i686 3.9.9-302.fc19 will be upgraded ---> Package kernel-PAE-modules-extra.i686 3.9.9-301.fc19 will be upgraded ---> Package kernel-PAE-modules-extra.i686 3.10.5-201.fc19 will be an upgrade ---> Package kernel-headers.i686 3.10.4-300.fc19 will be upgraded ---> Package kernel-headers.i686 3.10.5-201.fc19 will be an upgrade --> Finished dependency resolution Dependencies Resolved Package Arch VersionRepository Size Installing: kernel-PAE i686 3.10.5-201.fc19updates 28 M kernel-PAE-devel i686 3.10.5-201.fc19updates 8.2 M Upgrading: kernel-PAE-modules-extra i686 3.10.5-201.fc19updates 2.0 M kernel-headers i686 3.10.5-201.fc19updates 873 k Transaction Summary Install 2 Packages Upgrade 2 Packages Total download size: 39 M Is this ok [y/N]: N Summ. yum - kernel-PAE-modules-extra - Installing - OK dnf - kernel-PAE-modules-extra - Upgrading - ? poma -- 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: Suggestion: bmap files and bmaptool
On Wed, 2013-08-14 at 11:44 +0200, Till Maas wrote: > On Wed, Aug 14, 2013 at 12:21:23PM +0300, Artem Bityutskiy wrote: > > On Wed, 2013-08-14 at 10:37 +0200, Till Maas wrote: > > > On Wed, Aug 14, 2013 at 09:31:22AM +0300, Artem Bityutskiy wrote: > > > > > > > Other things like reading from remote sites, progress indicator, > > > > protecting your mounted disks, uncompressing on-the-fly, checking sha1 > > > > of the data ond of the bmap file itself - are goodies, although > > > > important ones. > > > > > > Why sha1? If the check is there for security reasons, please use at > > > least sha256. > > > > Should not be difficult to implement if there is demand. > > SHA-256 is used to create the signatures of other distributed files: > https://fedoraproject.org/static/checksums/Fedora-19-i386-CHECKSUM > > Therefore if bmap is used it should also use at least SHA 256. It is > recommended against using SHA-1 for more than 7 years now: > http://csrc.nist.gov/groups/ST/hash/policy_2006.html Sure, good point, thank you, I'll implement sha-256 support. -- Best Regards, Artem Bityutskiy -- 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: Suggestion: bmap files and bmaptool
On Wed, Aug 14, 2013 at 12:21:23PM +0300, Artem Bityutskiy wrote: > On Wed, 2013-08-14 at 10:37 +0200, Till Maas wrote: > > On Wed, Aug 14, 2013 at 09:31:22AM +0300, Artem Bityutskiy wrote: > > > > > Other things like reading from remote sites, progress indicator, > > > protecting your mounted disks, uncompressing on-the-fly, checking sha1 > > > of the data ond of the bmap file itself - are goodies, although > > > important ones. > > > > Why sha1? If the check is there for security reasons, please use at > > least sha256. > > Should not be difficult to implement if there is demand. SHA-256 is used to create the signatures of other distributed files: https://fedoraproject.org/static/checksums/Fedora-19-i386-CHECKSUM Therefore if bmap is used it should also use at least SHA 256. It is recommended against using SHA-1 for more than 7 years now: http://csrc.nist.gov/groups/ST/hash/policy_2006.html > > It works well for unassigned file > > systems blocks, but if there is a file containing zeroes in the file > > system (that is not a sparse file) it might not contains zeroes > > afterwards as far as I understand bmap. > > It will, those blocks will be explicitly specified in the bmap file. And > the zeroes will be copied. > > And this is exactly why I said that 'cp --sparse=always' does not > generate the correct bmap file, I used it only for demosntration > purposes. I see. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Tcl/Tk 8.6
Hi all, I noticed that Tcl/Tk 8.6 isn't landed in Fedora yet, what's wrong? 8.5.13 is definitely outdated, even 8.5.14 is released. Sincerely, Mike Manilone signature.asc Description: This is a digitally signed message part -- 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: Suggestion: bmap files and bmaptool
On Wed, 2013-08-14 at 16:35 +0800, Christopher Meng wrote: > 在 2013-8-13 PM9:52，"Artem Bityutskiy" 写道： > > > > Hi Fedora developers, > > > > I would like suggest you to take a look at bmaptool, which you can > use > > for flashing Fedora ISO images to USB sticks (or other block > devices). > > I've read an article about this tool in Chinese months ago. > > I can help submit a package review tomorrow if you want, then let us > test it. > Sure, please. The packaging may not be entirely correct, I am open to fix it, of course. Also, please, use the tip of the 'devel' branch in your experiments so far. -- Best Regards, Artem Bityutskiy -- 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: Suggestion: bmap files and bmaptool
On Wed, 2013-08-14 at 10:37 +0200, Till Maas wrote: > On Wed, Aug 14, 2013 at 09:31:22AM +0300, Artem Bityutskiy wrote: > > > Other things like reading from remote sites, progress indicator, > > protecting your mounted disks, uncompressing on-the-fly, checking sha1 > > of the data ond of the bmap file itself - are goodies, although > > important ones. > > Why sha1? If the check is there for security reasons, please use at > least sha256. Should not be difficult to implement if there is demand. > You can also encode the checksum as base64, base85 or > base91 to reduce the size of the bmap file. May be, this was not a problem for sha1, but for sha256 it would probably make sense, thanks for suggestions. > > > But the base principle is to utilize the inherent sparseness most raw > > images have a lot of, record this in the bmap file before it is lost, > > then publish the image in any form (compressed or not), and use the bmap > > file for fetching the sparseness information and writing/copying only > > the real data, and leaving out the zeroes. > > This does not sound safe, because it does not ensure that all data that > should be zero actually is a zero. I think I covered this part in the documentation. But here is a short description. 1. The bmap file should be created just after the image is generated. 2. The blocks where zeroes were explicitly written will be mapped to real sectors which will contain zeroes. 3. The blocks which were not explicitely written to, will be unmapped. 4. Creation of the bmap file is done using the FIEMAP ioctl 5. Only unmapped blocks will be omited in the bmap files. While on this, I should note that this works best on ext4 file-system. I did not test ext2/3, but they should work as well as ext4. Btrfs was also tested, but it is a little bit worse than ext4, I can explain why if someone is interested. > It works well for unassigned file > systems blocks, but if there is a file containing zeroes in the file > system (that is not a sparse file) it might not contains zeroes > afterwards as far as I understand bmap. It will, those blocks will be explicitly specified in the bmap file. And the zeroes will be copied. And this is exactly why I said that 'cp --sparse=always' does not generate the correct bmap file, I used it only for demosntration purposes. In bmap-tools project we have the 'BmapCreate' python module, which implements bmap file creation, you can use it in the Fedora image build tool for generating the correct bmap file just after the raw image is created. > This does not sound like > something that is safe to do. It is safe, we are using it for a year already in Tizen IVI, so it is somewhat tested as well. Of course, Tizen IVI community is a lot smaller, but still, this is some indication of safeness already. -- Best Regards, Artem Bityutskiy -- 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: Notion of Sea (Simon A. Erat)
Am Mittwoch, den 14.08.2013, 10:40 +0200 schrieb Till Maas: > Welcome aboard! > > On Wed, Aug 14, 2013 at 10:32:29AM +0200, Simon A. Erat wrote: > > > This is the 3rd selfintroduction, as its the 3rd packagereview request, > > thank you Mario Besser, but therefor i dont know what to write further, as > > it feels like everything been said before. > > Are your packages already reviewed and have you been sponsored? If not, > it might help to post links to your review requests. > > Regards > Till Welcome from me, too! I'm currently reviewing his package and ITS. Cheers, Björn -- 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: Notion of Sea (Simon A. Erat)
Welcome aboard! On Wed, Aug 14, 2013 at 10:32:29AM +0200, Simon A. Erat wrote: > This is the 3rd selfintroduction, as its the 3rd packagereview request, > thank you Mario Besser, but therefor i dont know what to write further, as > it feels like everything been said before. Are your packages already reviewed and have you been sponsored? If not, it might help to post links to your review requests. Regards Till -- 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: Suggestion: bmap files and bmaptool
On Wed, Aug 14, 2013 at 09:31:22AM +0300, Artem Bityutskiy wrote: > Other things like reading from remote sites, progress indicator, > protecting your mounted disks, uncompressing on-the-fly, checking sha1 > of the data ond of the bmap file itself - are goodies, although > important ones. Why sha1? If the check is there for security reasons, please use at least sha256. You can also encode the checksum as base64, base85 or base91 to reduce the size of the bmap file. > But the base principle is to utilize the inherent sparseness most raw > images have a lot of, record this in the bmap file before it is lost, > then publish the image in any form (compressed or not), and use the bmap > file for fetching the sparseness information and writing/copying only > the real data, and leaving out the zeroes. This does not sound safe, because it does not ensure that all data that should be zero actually is a zero. It works well for unassigned file systems blocks, but if there is a file containing zeroes in the file system (that is not a sparse file) it might not contains zeroes afterwards as far as I understand bmap. This does not sound like something that is safe to do. Regards Till -- 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: Suggestion: bmap files and bmaptool
在 2013-8-13 PM9:52，"Artem Bityutskiy" 写道： > > Hi Fedora developers, > > I would like suggest you to take a look at bmaptool, which you can use > for flashing Fedora ISO images to USB sticks (or other block devices). I've read an article about this tool in Chinese months ago. I can help submit a package review tomorrow if you want, then let us test it. Cheers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Notion of Sea (Simon A. Erat)
Greetings to everyone My name is Simon (Arjuna), but i also listen to the name of my FAS account "sea". In IRC i listen to the name seasc. I'm a hobby coder more than half of my life and a computer enthusiast in general. Not beeing a specialst for anything, i'm a generalist for everything. I've been selfemployed 10 years ago as a Computersupporter for KMU/SMC, later worked for an insurance and an international production company as Senior VIP Supporter. I love using Fedora as it matches (almost) my natural cycle of setting up my computers with a fresh installation of an OS. About 2¼ years ago i've joined the linux community dropping Windows usage to an absolute minimum, Fedora hasnt disapointed me a bit! :) This is the 3rd selfintroduction, as its the 3rd packagereview request, thank you Mario Besser, but therefor i dont know what to write further, as it feels like everything been said before. Anyway, i'm happy to join and hope to learn alot along the way. Have a nice day. -- Simon A. Erat (sea) Switzerland FAS: sea IRC: seasc -- 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: [Owner-change] Fedora packages ownership change
> rubygem-railties [devel] was retired by jstribny > Rails internals: application bootup, plugins, generators, and rake tasks. > https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-railties This is a mistake and should be changed back to original owner. https://fedorahosted.org/rel-eng/ticket/5710 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
