Re: OpenH264 in Fedora
Do the codes only apply to WebRTC consumers, or can these be used in other context? For example Gnome has ctrl+alt+shift+R to screen-cast, which saves in webM format. Could that switch to whatever h.264 format with Cisco bits? Maybe get the lawyers to look at this? -Jon Disnard irc: masta fas: parasense On Sat, Nov 2, 2013 at 11:23 AM, Bruno Wolff III br...@wolff.to wrote: On Sat, Nov 02, 2013 at 08:11:48 -0700, Gregory Maxwell gmaxw...@gmail.com wrote: I personally believe it would probably be helpful to the discussion if Fedora is able to reach a (preliminary?) decision on if OpenH264 (as described) will be able to be used by Fedora systems (e.g. by having something analogous to codec buddy go install the codec to give all Fedora systems H.264 support) in order to provide feedback to the working group. If a decision to mandate H.264 in WebRTC means that Fedora systems would be unable to comply with the specification, that would be unfortunate. I don't see mandating H.264 in WebRTC as a good thing. So I'd rather not see Fedora people spend time supporting it, as opposed to doing other Fedora related work. And for people that don't need to worry about software patents or who don't worry about practising them without proper licensing, they can use x264 from RPMFusion. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora Base Design WG] Committee FESCO approved, next steps
On Nov 4, 2013 12:01 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/04/2013 11:07 AM, Phil Knirsch wrote: Hi everyone. A quick update from my side regarding the Base Design WG: - My proposed committee was approved by FESCO last Wednesday. One negative vote came from Stephen Gallagher that he would have very much preferred to have Lennart instead of Harald or Josh on the committee. To be completely clear, I said I would have preferred having Lennart on the WG. I did not state that I thought Harald or Josh should not be members. That's an important distinction, I think :) I felt strongly enough that Lennart belonged on this group that I chose to cast a token vote, knowing that it would not affect the outcome. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ34PkACgkQeiVVYja6o6MrUwCgpYhhbnQ2eFX/c4Eb8bSAbBVs fB4AoIKJyckoVozKnZyh03E0MfMzmpxy =L79V -END 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 Howdy folks. Looking forward to getting to work on base design. Regarding the voting members I feel we have a great group. Everyone intersted (voting or not) should participate in our discussions. My vote will certainly be influenced by anyone in the community willing to participate. :-) One thing I would like to talk about is embedded Fedora, mostly as that is my personal area of involvement with the project. There is not an embedded working group, and it's my agenda to hopefully have the base design double as embedded. It makes sense to me in the sense that base ring-zero is sort of the embedded core into cloud, server, or workstation. By itself base would be suitable for the smallest deployment. Another item I'd like to consider for the initial discussion is the release cycle for the base design. My feeling is that base is small enough and simple enough to allow a more frequent release, perhaps even continuously. My guess is the other WGs will have their own ideas for how frequently they output. So base WG would need to be the lowest common denominator in that way. Obviouly rel-eng and qa need to represent for this topic. :-) Thanks, -Jon Disnard -- 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: hardlink command
In my opinion the -c option is the most rational use of hardlink, except where the files are empty. In the later case touch can be used align the timestamps before you decide to combine the inode. $ touch -r test1 test2 Regards, -Jon Disnard On Sun, Nov 10, 2013 at 2:27 PM, Brendan Jones brendan.jones...@gmail.com wrote: On 11/10/2013 09:07 PM, Sergio Belkin wrote: hardlink -n -v -v I would look at the modification datetime. studiodesktop:/tmp $ echo test test1 (wait at least a second) studiodesktop:/tmp $ echo test test2 studiodesktop:/tmp $ hardlink -n -v -v tes* Directories 0 Objects 2 IFREG 2 Comparisons 0 Would link 0 Would save 0 studiodesktop:/tmp $ cp -rp test1 test2 studiodesktop:/tmp $ hardlink -n -v -v tes* Would link test1 to test2, would save 5 Directories 0 Objects 2 IFREG 2 Comparisons 1 Would link 1 Would save 4096 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- 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: [Base] Proposal for buildrequires cleanup janitorial initiative
If not, what's the point of this initiative? To reduce size, complexity, save time. What do you mean by *enforcing*, or how would you imagine that happening? On Fri, Dec 20, 2013 at 4:10 PM, Colin Walters walt...@verbum.org wrote: On Thu, 2013-12-12 at 18:50 +0100, Phil Knirsch wrote: Hi everyone. During last weeks Base WG discussion about package set and self hosting of Base we came to a point where especially the self hosting of Base would currently look absurd as we'd require more than 2000 components to do so. Once you reduce the size of this set, do you forsee actually *enforcing* this in some way? For example, by having separate package repositories? If not, what's the point of this initiative? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- 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
On Mon, Jan 6, 2014 at 4:00 AM, nob...@fedoraproject.org wrote: Change in ownership over the last 168 hours === 3 packages were orphaned rdesktop [devel] was orphaned by ssp X client for remote desktop into Windows Terminal Server https://admin.fedoraproject.org/pkgdb/acls/name/rdesktop audacity [devel,f18,f19,f20] was orphaned by manpaz Multitrack audio editor https://admin.fedoraproject.org/pkgdb/acls/name/audacity imapfilter [EL-6,devel,f18,f19,f20] was orphaned by dsommers A flexible client side mail filtering utility for IMAP servers https://admin.fedoraproject.org/pkgdb/acls/name/imapfilter I have taken ownership of rdesktop. Thanks -Jon Disnard fas:parasense irc: masta [snip] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 2:30 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apologies for the slightly alarmist $SUBJECT, but I want to make sure that this gets read by the appropriate groups. [snip] 1) Are Spins useful as they currently exist? There are many problems that have been noted in the Spins process, most notably that it is very difficult to get a Spin approved and then has no ongoing maintenance requiring it to remain functional. We've had Spins at times go through entire Fedora release cycles without ever being functional. Putting on my rel-eng hat I can say that any spin that fails to compose will be dropped. I believe we also encourage or even require the spin maintainers to test their spin as functional. (To work out if the spin succeeds to compose but fails to actually work) The idea is to encourage active spin process, inactive spins will auto retire by policy if they fail. Another aspect I worry about is the mirroring stuff. With the coming WGs I fear the rsync mirroring will grow very large, and spins are an attractive piece of fat to cut. Reducing size is something we worry about on the infra, rel-eng side of things. 2) Should Spins be eliminated entirely in favor of Fedora Remixes[1]. The effect here would be that Spins are no longer an official part of The Fedora Project but are instead projects unto themselves which are permitted to consume (possibly large) portions of our tools, packages and ecosystem. Maintenance and upkeep of these spins then becomes entirely the responsibility of the downstream community that constructs them and has no mandatory draw on Fedora's marketing, ambassadors or quality assurance resources. Again, from the rel-eng perspective... this proposal sounds nice. (removing spins in favor of remix) It would reduce the complexity of my work flow. So selfishly speaking removing spins sounds great. However, they are an important part of our community, and I'd feel sad to see them disappear. There is a nice aspect of them being partially hooked into the rel-eng process that adds value. The community comes together, spin maintainers have a list they talk to each other. We push them to provide quality product, etc. In my view a remix is something that contains stuff that Fedora cannot. Say for example, my chromebook remixes in F19... those broke with Fedora principles by using evil vendor tree kernels. So in my thinking that is what a remix is for. but spins 100% stay with the Fedora way of things, our four foundations or whatever. In my opinion the WGs are big giant uber-spins. [snip] ... -Jon Disnard FAS: parasense IRC: masta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 5:48 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 5:19 PM, Stephen John Smoogen smo...@gmail.com wrote: On 29 January 2014 15:49, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 4:39 PM, Jon jdisn...@gmail.com wrote: Putting on my rel-eng hat I can say that any spin that fails to compose will be dropped. I believe we also encourage or even require the spin maintainers to test their spin as functional. (To work out if the spin succeeds to compose but fails to actually work) The idea is to encourage active spin process, inactive spins will auto retire by policy if they fail. Another aspect I worry about is the mirroring stuff. With the coming WGs I fear the rsync mirroring will grow very large, and spins are an attractive piece of fat to cut. You probably didn't mean for that to sound so negative but a piece of fat to cut is how rel-eng thinks of spins? I recall being assured at the beginning that some interested company was willing to provide the necessary support for us to give this a fair try. How long is a fair try? It would help to define that before people go on a rant about doing it for a couple of years now. I meant giving our new adventure a fair try, not giving spins a fair try. I also really did not mean to go on a rant. I think we have a group that sees little benefit to spins and another that sees a lot of benefit to spins. The former wants to get rid of them, the latter wants to keep them. We won't ever quantify the amount of benefit they bring so we are probably at a stalemate on the benefit question. On the resources question we can either ask for them in order to allow us to do both or we can look for new ways to reduce the cost of spins to those complaining about the burden they impose. I'm open to either of those approaches. Getting rid of them to me would be an admission that are unwilling or unable to continue supporting something that is valuable to our users and our community (just my subjective opinion and I know not everyone shares it). John There is a lot of value in the desktop spins. Most of the folks I know personally use one spin or another. I myself REMIX all of the desktop spins for my embedded stuff, and I personally use MATE and/or XFCE. It would be disappointing to drop the spins now that we have got them to such a lofty place in our community. We now hold them accountable to ensure quality, and the composes are mostly automated into koji, so burden to keep them going is not much. Mostly the space they consume is a thing to consider. I'd like to imagine a day when the KDE spin replaces gnome3 as our default desktop! Or even XFCE or whatever Do not believe Gnome3 should have lock to the default desktop offering. I would even go so far to propose a vote from the community every once in a while to decide what is our so-called default. And repeat that vote every once in a while... based on merits. So I'd rather not see the desktop spins go away. Not sure about the other spins, the pen testing, or software-stack type things Since the burden is mostly storage, and storage is cheap... I tend to think we can keep them going for now. There is the part about mirroring, and the time it takes to compose these things. My two cents. -Jon Disnard FAS: parasense IRC: masta -- -Jon -- 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: Unresponsive maintainer: Steven Pritchard (steve)
On Thu, Jan 30, 2014 at 6:00 AM, Juan Orti Alcaine j.orti.alca...@gmail.com wrote: I'm trying to get the bug #695589 from the package amavisd-new fixed. I got an email from Steven in 2013-11-04 saying he was very busy and didn't have his FAS login at hand, but I haven't got any news since that. The bug dates from 2011-04-12, and several attempts have been made to contact Steven: - 2012-03-14: https://bugzilla.redhat.com/show_bug.cgi?id=695589#c11 - 2012-04-03: https://bugzilla.redhat.com/show_bug.cgi?id=695589#c12 - 2013-09-12: https://bugzilla.redhat.com/show_bug.cgi?id=695589#c19 I emailed the co-maintainer kanarip, but didn't get any reply. I wish to take over that package, or at least, have commit rights to fix this issue. Thank you. This looks to be step 4 or 5 of the policy [1]: 4. After 2 failed attempts (2 weeks of no response from the maintainer), the reporter posts to the Fedora devel list with a link to the bug report and asks if anyone knows how to contact the maintainer. 5. After other 7 days (now 3 weeks total), the reporter posts a formal request to the Fedora devel list with the bug link, indicating all reasonable efforts to contact the maintainer have failed and that they wish to take over the package. In your case it's been years now waiting can you wait one more week to complete step five? NOTE: I'm not in FESCo, just my two cents... [1] http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Outline -- -Jon Disnard FAS: parasense IRC: masta -- 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: How do I remove my bugzilla.redhat account?
I don't believe mere mortals posses the capability to remove a Bugzilla account once established. The administrator might be able. I guess you could change the email associated with your username in BZ to some bogus address, effectively disabling the account. good luck, -Jon Disnard On Sun, Feb 2, 2014 at 7:30 PM, poma pomidorabelis...@gmail.com wrote: Thanks. 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 -- -Jon -- 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: Adjust wiki for ARM BeagleBone Black
This was well intention wiki edit, and possibly unaware of in-flight changes about to land in Fedora u-boot implementation. We are transitioning to extlinux which has better integration with other parts of Fedora, and is arguably more user friendly. It works similar to syslinux, the menu system on our ISO images, etc. No problem, the edit is probably fine until we have the time to go through the site and mass edit for the stuff. Thanks Marcelo. -Jon Disnard FAS: parasense IRC: masta On Fri, Feb 7, 2014 at 12:30 AM, Dennis Gilmore den...@ausil.us wrote: That's not necessary abcboard is not used and has been removed from newer uboot builds uEnv.text files. Dennis On February 7, 2014 3:13:27 AM CET, Marcelo Barbosa fireman...@fedoraproject.org wrote: Peter, Changed in this part: Change one option in this file(only BeagleBone Black): vi /run/media/$USER/uboot/uEnv.txt abcboard=am335x-bone abcboard=am335x-boneblack Added. firemanxbr On Thu, Feb 6, 2014 at 9:32 PM, Peter Robinson pbrobin...@gmail.com wrote: I adjusted this documentation in wiki: https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black Added this important step to create image of Fedora 20 for BeagleBone Black board. this important step being what exactly? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- 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: The F20 Network Bridge is Failing down!
I've also noticed a regression in my network bridge setup. Use bridging for both virt-manager, and development work with aarch64 bringup (emulated ARMv8). Have seen this happen on two recently updated f20 systems. I'm using traditional network-scripts, and what happens is the physical interface appears to not be added to the bridge interface, E.G. 'brctl addif br0 em1'. Will investigate more as time allows, but wanted to confirm the problem with me too. Thanks, -Jon Disnard fas: parasense irc: masta On Tue, Feb 11, 2014 at 2:11 PM, Steve Dickson ste...@redhat.com wrote: Hello, I have two fully updated F20 boxes running VMs. The bridging on one box was working but not on the other... It appeared the only real difference was the names. The working bridge was call 'br0' and the non-working was called 'bridge0' I also notice that 'br0' showed virt-manager's list of viable network interfaces and 'bridge0' did not. Obviously that was the problem. So tried to rename bridge0 to br0 by changing the names of the ifcfg files... no luck... the bridge would not come up. Next I just remove 'bridge0' and create a new 'br0'. This is where I hit the wall. 1) Network setup will no longer gives an option to create a bridge as it once did. The only option I get is VPN. 2) I am able to create a bridge with nm-connection-editor but Network setup still can't see it to bring it up 3) Using the nmcli command to bring the bridge up, I get the following error: # nmcli con up br0 slave 1 still errors out with Error: Connection activation failed: No compatible disconnected device found for master connection 157112b2-aea3-4b03-b91e-186bcffbb3f4. So I went from a functioning bridge not being recognized by virt-manager to not being able bring a bridge up or have it recognized by Network Setup. Any ideas what is going on here? Again, this is on a fully updated F20 box... tia! steved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- 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: Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release
Propose the unit file be packaged.
* Releng does not want this in fedora-release.
* Going in kickstart files is not happy.
We could call the package:
fedora-systemd-defaults-{base,workstation,server}
spins would call the file:
fedora-systemd-[spin]
remix would call the file:
[remix]-systemd-defaults
This is my opinion, perhaps bad idea?
Let me know...
In particular, would like to know if anybody has any ideas how to
create an override?
E.G. drop a file into a folder and those settings clobber the default.
Would perhaps eliminate the need for so many separate packages for
WGs, spins, or remix.
--
-Jon Disnard
FAS: parasense
IRC: masta
--
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: Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release
As far as two (or more) fedora-presets' being installed at once, I would say we allow the user to resolve the problem via .rpmnew The implication is users would have to pick a -config/-preset package and then e.g. adjust things This only works if the preset file has the same name across all the product lines. Thanks, -Jon On Wed, Feb 19, 2014 at 1:49 PM, Miloslav Trmač m...@volny.cz wrote: On Wed, Feb 19, 2014 at 8:28 PM, Colin Walters walt...@verbum.org wrote: On Wed, Feb 19, 2014 at 1:58 PM, Miloslav Trmač m...@volny.cz wrote: I think it's perfectly fine to have them conflict. You didn't reply to the part of my mail where I was describing the Workstation on a Server case. Sorry, i read that as Server on Workstation which seemed really easy. The opposite is indeed more difficult. Are you saying that you do not believe this case is valid? Or that such users would have to pick a -config/-preset package and then e.g. adjust things so that gdm is enabled if they want that? I'm leaning towards yes to both, but it's really not an easy call to make. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- 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: exclude people from giving karma?
My apologies on the slow bodhi updates last week. There were a number of complications the past week related to the work flow of bodhi updates. Took me a while to resolve some problems, and see the updates to completion. At least twice the updates push failed due to older NVR's in updates-testing being given sufficient karma to update along with a newer NVR of the same package. This makes Bodhi unhappy, and abort... requiring somebody to help bodhi choose which stable NVR to tag stable (usually always the newer/latest version). Will try to be more resilient in the future. However, it would be super awesome if package maintainers would unpush or whatever it takes (increase karma threshold of) older NVRs in updates-testing tags when pushing new updates to testing. (so they don't mistakenly tag into stable after a higher NVR) Regarding the problem of people giving karma, I'm not sure there is a solution. Perhaps a meta-moderation system a la slashdot, we randomly let testers rate the karma given by other testers formalize the path to ascending the ranks of tester. However, I'd like to keep the community as honest and cooperative as possible, so I'm not very keen on ideas that make people unhappy to test packages. (positive reinforcement wins) -Jon Disnard fas: parasense irc: masta On Sun, Feb 23, 2014 at 11:33 AM, Christopher Meng cicku...@gmail.com wrote: Let's test this one asap to prevent epoch(if you want): https://admin.fedoraproject.org/updates/libcmis-0.4.1-2.fc20,mdds-0.10.2-1.fc20 Last weekend bodhi seemed very slow on processing updates, so I downloaded and installed from koji by myself. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- 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: default file system, was: Comparison to Workstation Technical Specification
The inability to shrink or reduce XFS is rather disappointing. I've seen a few sarcastic remarks along the lines of (paraphrased): why would anyone ever want to shrink a volume? People do shrink volumes, and this lack of flexibility is an important consideration I feel was ignored in the Server WG decision. for me personally, I'm not sure any performance gains are enough to compensate for the lack of flexibility. Considering that LVM has the ability to resize volumes, ext4 pairs very well, and I'm skeptical thin provisioning does enough make-up for the lack of XFS shrinking. I've seen a number of presentations on XFS and I'm personally very happy about the raw gains in performance and resilience. So in that respect XFS is a good choice for the Server WG. So my question to the Server WG, did anybody consider this aspect of XFS (lack of shrinking) before making the decision? What were the highest reasons for NOT staying with EXT4? Thanks, -Jon Disnard fas: parasense irc: masta -- 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: default file system, was: Comparison to Workstation Technical Specification
On Sat, Mar 1, 2014 at 3:18 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 1, 2014, at 1:19 PM, Jon jdisn...@gmail.com wrote: The inability to shrink or reduce XFS is rather disappointing. I've seen a few sarcastic remarks along the lines of (paraphrased): why would anyone ever want to shrink a volume? In the context of server, and default installs, why is a valid question. People do shrink volumes, and this lack of flexibility is an important consideration I feel was ignored in the Server WG decision. What is the use case for volume shrinking in a server context? Dual boot is a total edge case for servers. In the context of Fedora-ARM, people would regularly shrink ext4 filesystem images to fit on different size storage. We would release an 8GiB image, but the ARM board might only have 4GiB eMMC or somebody has a smaller sdcard (stuff like that). We no longer release Fedora ARM rootfs tarballs, too hard to educate people to do the right thing with ACL's, xattrs, selinux, etc... Anyhow, it's actually a great way to ship a Fedora rootfs... just shrink the filesystem down to the smallest size, and allow the user to simply resize2fs the image into their storage. This would not be possible with XFS for the server variant of Fedora-ARM, and I feel represents a significant challenge to the ARM team. As for the real world examples of shrinking, well drawing upon my experiences in the past at a managed hosting company: * VG consisted of ten 100 GiB san luns, customer asks one be removed, and provisioned to another server. We shrunk the filesystem, and removed the lun per request. Shrinking support significantly reduced the time needed for that maintenance window! Or put another way, shrinking is much faster than formatting and restoring data from tape to achieve smaller sized volumes. * customer over estimated the requirements for one mount (lets say /opt for example), and underestimated the requirements of another (say /var/log for example). This classic example of where customers fail to properly anticipate the storage requirements of their work-flow at the time of install, and they shrink one to grow another. (this might be solved by the thin provisioning idea) * customer wanted to shrink the SAN luns to a smaller size, but was averse to significant down time to restore from tape. ext4 shrinking to the rescue! In the context of HP-UX I've been in the situation to perform online shrinking with database running on the storage mount. The point is that shrinking is an important feature in a server OS!! for me personally, I'm not sure any performance gains are enough to compensate for the lack of flexibility. Considering that LVM has the ability to resize volumes, ext4 pairs very well, Unless you use system-storage-manager, you might refresh the steps required to do an ext4 on LVM resize. I don't think the person who understands how to do that is really the target audience for default installs. I would disagree on the basis that people who do default install probably are the same group of folks who might not plan ahead for their future storage needs, which usually involves growing storage (something XFS is great at doing), and other times involves shrinking. However these are my 2-bit opinions, all I'm say is we advocate for those consumers who make mistakes, and that we please consider recongnize that XFS has less tolerance for when the mistake happens to be provisioning too much storage. and I'm skeptical thin provisioning does enough make-up for the lack of XFS shrinking. It even makes up for ext4 shrinking in two ways. 1. Instead of making an LV smaller than possibly needed, make it the size it probably should be from the start. It only consumes extents from the thinpool as needed. 2. Upon significant file deletion, fstrim returns unused extents back to the thinpool. This is faster, more efficient, and less fragile than file system shrink. Again, the problem is that commands are a bit esoteric, but maybe system-storage-manager can help out with this once it support thin provisioning. Thin provisioning sounds great, but I'm not sure it replaces the ability to shrink in all situations, but it appears to negate many of the situations I've mentioned, but not all. So my question to the Server WG, did anybody consider this aspect of XFS (lack of shrinking) before making the decision? What were the highest reasons for NOT staying with EXT4? I realize the thread has well over 100 emails in it, but it was considered. The simple explanation why XFS was chosen is because it was well vetted by Red Hat storage experts for use as the default in RHEL 7 - and I understand that sgallagh is working on a summary of those reasons, which would apply here as well. I'd say top on the list is XFS is scales linearly as more threads are thrown at it, it's very good at parallelism, and it support project quotas which often obviates the need
Re: Server Technical Specification: Agenda and First Draft
The base wg has been wondering the same for containers, and at this point we may follow this guidance regarding libvirt too. I'll probably advocate this at our next meeting. Thanks On Mar 3, 2014 6:09 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/28/2014 07:19 PM, Lennart Poettering wrote: On Fri, 28.02.14 15:37, Daniel J Walsh (dwa...@redhat.com) wrote: drago01 sgallagh: systemd-nspawn will be used to manage containerization capabilities. did I miss something or doesn't upstream say that it should not be used for anything that needs secruity? sgallagh drago01: Last I heard, the Dans (Walsh and Berrange) had SELinux working with it now. mclasen dargo01: I think that statement may be evolving ? sgallagh And Docker is moving to systemd-nspawn and away from lxc mclasen but certainly valuable to raise the question on the list, and see if lennart, dan or dan want to chime in drago01 sgallagh: Note that even though these security precautions are taken systemd-nspawn is not suitable for secure container setups. Many of the security features may be circumvented and are hence primarily useful to avoid accidental changes to the host system from the container. The intended use of this program is debugging and testing as well as building of packages, distributions and software involved with boot and systems mana drago01 gement. [1] sgallagh So it's definitely the way forward. drago01 sgallagh, mclasen : ok makes sense So I am not sure if that has changed yet or not but if it has we should at least get the man page updated. 1: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html (man page) Well this has changed again. Docker is now going native. It will support containers directly and not require a different set of tooling like lxc, systemd-nspawn or libvirt-lxc. This will be the default, and I guess people could experiment with others. Originally, nspawn was mostly just a debugging tool for us, since that way we could boot up a systemd instance in an environment that is pretty much like a real system but allows us to attach gdb easily. We never intended it really to be more than that. That said, it considerably grew in features over time (espcially, after Dan asked us to add a couple of features for them), and it is quite a powerful tool now. At this time I am aware of some people using it in production, simply because it is much easier to use as you don't need to set up any configuration for it. However, I personally am very much of the opinion that libvirtd is the right choice if you want to deploy something. It has all those management features, APIs, and tries to be general purpose, and nspawn doesn't have or try anything of that. Hence it should be libvirt-lxc that Fedora should advertise for deployment on its server edition. People are of course welcome to use nspawn, but it appears wrong to me to advertise it for servers, nspawn is not specifically designed to be deployed or to be server tool. The container hook-up work we are doing within the systemd project is always designed to be compatible with any container manager people choose as long as it follows these guidelines: http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ http://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/ Both libvirt-lxc and nspawn implement these interfaces, you will get the same level of integration with them. Docker is will use its own containerization code soonishly. I am pretty sure that that's actually the right choice for them. They are following the container guidelines too, to provide the same level of integration. (And regarding the comments on security from the man page: yes, with nspawn we do not make any claims about being secure, but that's mostly inherent to the underlying technologies and hence mostly applies to the other container managers in the same way too). So, from my PoV that wiki text should really just say libvirtd, and nothing else. For both VM and container virtualization. Thank you very much for this detailed response, Lennart. It's much appreciated. With this in mind, I'm going to revise the document to recommend libvirt as the preferred container management tool. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMUcSAACgkQeiVVYja6o6MdygCfYhBWlOQkLXqNJ1PEPE4kncFl gUEAniBac8H2rMi3vZxodq4kib8LlNtD =T5Mz -END 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct:
Re: F21 Self Contained Change: Allwinner sunxi (A10 / A13 / A20) ARM SoC support
Does the u-boot piece require a new package or sub package of existing u-boot we already have? Just curious. Suppose I'm asking if the sunxi support is upstream in denx? Looking forward to this feature. :-D Thanks On Mar 3, 2014 8:05 AM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: Allwinner sunxi (A10 / A13 / A20) ARM SoC support = https://fedoraproject.org/wiki/Changes/AllwinnerSunxiSupport Change owner(s): Hans de Goede hdego...@redhat.com, Peter Robinson pbrobin...@fedoraproject.org Allwinner A10 / A13 / A20 SoCs are used in a number of popular low cost arm development boards and arm mini computers. Currently Fedora ARM is supported on these devices through a Remix [1]. Allwinner kernel support is progressing rapidly upstream, and with this upstream kernel support it should be possible to support Allwinner SoCs in the official Fedora ARM images, without the need for a remix. == Detailed description == The linux-sunxi community is currently working hard to get Allwinner SoCs supported in the upstream kernel. A big part of this should land in the 3.14 kernel. The plan is to support Allwinner SoCs in headless mode for now, and carry patches for mmc, ahci and usb support for 1-2 kernel releases (until they land upstream). == Scope == Supporting Allwinnner SoCs ootb will require kernel and u-boot support. Kernel support is landing upstream and we will add patches to the Fedora kernel for 1-2 kernel releases to supplement this. u-boot support currently lives in a u- boot fork upstream, this fork is tracking / merging u-boot upstream and does intent to get sunxi support merged into the official u-boot packages, but there is no timeline for this atm. For u-boot we will create a separate u-boot-sunxi package, which can be dropped once u-boot support has been merged into u-boot upstream. Proposal owners: Will try to get as much kernel support upstream as possible, supplement with patches in the Fedora kernel package. Will create a u-boot- sunxi package with sunxi specific u-boot. Will look into adding a config tool to the sdcard images to easily select and install the correct u-boot and dtb, like the Allwinner Remix images have. Other developers: N/A Release engineering: N/A Policies and guidelines: N/A [1] https://fedoraproject.org/wiki/Changes/AllwinnerSunxiSupport ___ 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: default file system, was: Comparison to Workstation Technical Specification
On Mon, Mar 3, 2014 at 9:01 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 3, 2014, at 4:57 PM, Jon jdisn...@gmail.com wrote: We no longer release Fedora ARM rootfs tarballs, too hard to educate people to do the right thing with ACL's, xattrs, selinux, etc... Anyhow, it's actually a great way to ship a Fedora rootfs... just shrink the filesystem down to the smallest size, and allow the user to simply resize2fs the image into their storage. Well unfortunately it's not default ready yet, so it's a bit off-topic. But I see your example as a particularly good use case for several features including btrfs send to a file (restored with btrfs receive onto a new file system of whatever size); and btrfs seed device. This would not be possible with XFS for the server variant of Fedora-ARM, and I feel represents a significant challenge to the ARM team. I'm a bit lost, but I think this is important to understand. Does the Server product anaconda default somehow affect the armv7hl raw.xz images you release? Is there a way to decouple this? Because Fedora ARM doesn't really use anaconda at all, do you? On the rel-eng side we are not using anaconda to compose the ARM images because we cannot put Anaconda into koji tasks, so instead we use appliance-tools for ARM images. (we used to use Anaconda to compose the ARM images until recently) We still use kickstart, and for the ARM case we will do our best to have 1:1 parity with the x86_64 server variant defaults. Part of becoming PA is a commitment to keep things the same, as much as possible, in all the places. So it's important to consider the impact of XFS on ARM. That said, my example about resizing the rootfs into the target system will probably still work. But our process on the rel-eng side might be complicated slightly... more of an annoyance than a major blocker. If the anaconda default fs somehow binds your images to using the same thing, does it make sense to consider making XFS the default also contingent on using lvmthinp? I would characterize lvm thin provisioning as a great way to balance the situation, given the facts about XFS shrinking. Not sure about making it contingent. Thin provisioning sounds great, but I'm not sure it replaces the ability to shrink in all situations, but it appears to negate many of the situations I've mentioned, but not all. For example? When people remove FC san luns from a over-subscribed VG, and are then forced shrink the LV's and ext4's. I would imagine people turning their ARM dev board into a home NAS or some similar storage kit, and the linear scale-up of XFS is really appealing. ARM gluster cluster :-) Yes! Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- 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: Integrating AIDE to RPM
On Mar 9, 2014 11:05 PM, Philip Prindeville philipp_s...@redfish-solutions.com wrote: I notice that after having set up AIDE, and then doing an RPM or YUM update of a package, I then get spew about the contents of files related to that update having changed. How difficult would it be to have a plugin for YUM that allows you to update the AIDE database with the new values (hashes, modes, owners, sizes, etc.) for the touched files? Also, sometimes when you install a package that maintains a cache, logs, or a spool area, it’s not sufficient to have AIDE do a snapshot (via --update) right after installation, because the contents of those areas grow or change over time. Immediately following installation, for instance, I might not have any new contents in /var/log/foobar, but some minutes or hours (or days) later a log file might have been created. It’s unfortunate that AIDE can’t leverage the RPM %files section to figure out which directories (or patterns within directories, such as /var/log/package-x.log) change over time but should be ignored as non-anomalous. Maybe a task for 'rpm -V ' to verify installed files, which should handle config files but not sure logs or cache. I use both aide and rpm to track file changes. For aide I've always thought change control includes database init. Just saying. How feasible would this be? -- 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: Help understanding Anaconda source - walk through needed.
On Wed, Mar 12, 2014 at 4:16 PM, Aaron Gray aaronngray.li...@gmail.com wrote: Okay think I have got a handle on it now, the main python file in the root does not have a .py extension. Very helpful ! Another interesting thing is there is no ARM support which I will be needing at some point. Aaron On 12 March 2014 20:07, Aaron Gray aaronngray.li...@gmail.com wrote: Hi, I am looking for someone to walk me through the Anaconda source as I need to understand it and cannot find where its 'main' is and how it launches X Windows as I need to work out why the main installer is not working on my HP D140 G3's with MCA video controllers. https://git.fedorahosted.org/cgit/anaconda.git/tree/?h=f20-branch Hope someone kind person has time to help me. Regards, Aaron What kind of ARM support will you be looking to have? -Jon Disnard fas: parasense irc: masta -- -Jon -- 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: Retired update still showing in updates-testing
On Thu, Mar 13, 2014 at 3:50 AM, Mathieu Bridon boche...@fedoraproject.org wrote: On Thu, 2014-03-13 at 09:41 +0100, Simone Caronni wrote: On 13 March 2014 09:33, Mathieu Bridon boche...@fedoraproject.org wrote: The solution is for you to untag the builds: $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 $ koji untag-pkg f20-updates-testing guacamole-client-0.8.3-5.fc20 Then at the next mash, they will be gone. I have no idea why they are still tagged, though. Maybe you removed the updates while the builds were being pushed, which tends to trip Bodhi up. Or maybe you hit a Bodhi bug. Thanks, I've already tried it but I can't tag/untag packages in Bodhi: $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 ActionNotAllowed: tag requires admin permission I think some admin intervention is needed. Ah, right... Open a rel-eng ticket, then. :) https://fedorahosted.org/rel-eng/newticket -- Mathieu Done! $ koji untag-build --force f19-updates-testing guacamole-client-0.8.3-5.fc19 $ koji untag-build --force f20-updates-testing guacamole-client-0.8.3-5.fc20 -- -Jon -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
I would like to mention that DE spins are very important with regard to the ARM7 arch. Gnome shell may or might not be working in arm so kde and the other DE spins are really important. Mostly kde from a QA perspective. As a primary architecture I feel this deserve extra considering. Arm QA is based on the KDE spin right now. Hopefully gnome will work soon, it all depends on 3d gpu support, so... depending on software rendering or open-source gpu rendering... kde is a must-have. The implication is because gnome require 3d that a software rendering situation should be happy for all primary architecture. Thanks -Jon -- 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: Senior Fedora OS position open
Graham, I've been interested to revive the fedora-mips project myself, mostly to get Fedora usable on my home firewall/router. Very excited to see Imagination get involved! Do you have any recommendations for cheap MIPS dev boards? [1] I've been eyeing the Ubiquity board. [1] http://www.imgtec.com/mips/developers/development-platforms.asp On Wed, Apr 2, 2014 at 5:48 AM, Graham Whaley graham.wha...@gmail.com wrote: Hi, Imagination/MIPS is hiring Fedora engineers. Please see: http://www.imgtec.com/corporate/vacancy_detail.asp?VacancyID=2286 for details, and feel free to pm me if you have any questions. All applications have to go via the website. The role presently says location 'Leeds,UK', but should say 'worldwide', and will be fixed. Imagination has 22 offices across the globe, and the present kernel/distro group is spread across 4 continents. Graham -- Graham Whaley Software Engineering Manager, MIPS platforms Imagination Technologies www.imgtec.com graham.wha...@imgtec.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 -- -Jon -- 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: [Base] Base Design WG agenda meeting 25. Apr 2014 15:00 UTC on #fedora-meeting
Regrets. Likely won't be able to attend this meeting today. -Jon On Fri, May 9, 2014 at 9:05 AM, Phil Knirsch pknir...@redhat.com wrote: Apologies for the late agenda, was out of office the last few days and didn't get to it before today. Agenda: - Follow up / status update merge reviews - Open floor Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- 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: Detecting unnecessary build requirements
I've always thought it would be super great to make a distinction of BuildRequires, and things required to perform build tests... say TestRequires. Stepping through the BRs is probably not enough, tests could also be disabled through this process. Say for example perl or python scripts are used to run a test suite, but not any part of build/compilation process. Stuff to think about. Thanks, -Jon Disnard -- 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: Computational chemistry softwares orphaned in F20
On Fri, May 16, 2014 at 3:35 PM, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 05/16/2014 12:02 PM, Susi Lehtola wrote: On Fri, 16 May 2014 08:26:23 -0300 Henrique Junior henrique...@gmail.com wrote: MOPAC7 is still in good shape despite the age. Also, I'm active in the field of computational chemistry myself. So is MOPAC7 viable for Fedora? it's been dormant since 2006; is there a better alternative that you (Susi) can recommend? Actually, there's something strange going on: Sourceforge advertises version 1.11 from 2006, but the Fedora package seems to include version 1.15 from 2009 which I am not seeing anywhere I looked, compiled by Carl Byington. What exactly is version 1.15? Indeed, something strange: $ cd /tmp $ fedpkg clone mopac7 $ cd mopac7 $ spectool -g mopac7.spec Getting http://www.uku.fi/~thassine/projects/download/current/mopac7-1.15.tar.gz to ./mopac7-1.15.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (22) The requested URL returned error: 404 Not Found The maintainer of the mopac7 package should fix the source0, or retire the package. Good luck, -- -Jon Disnard -- 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: koji: page encrypted but downloads not
I would imagine a load-balancer or whatever proxy type thing could sit in front of koji to provide ssl/tls offload. I'm not sure we have one, or could even afford one but nice to have. =) -Jon -- 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: Correct way to unpush an update?
On Thu, May 29, 2014 at 8:35 PM, Richard Shaw hobbes1...@gmail.com wrote: Ok, so I don't get bit again by bodhi letting me do something I shouldn't... Do I just unpush the update but NOT delete it? I have a newpackge update and one of the three packages has a problem so obviously I don't want to push it to stable. Once I get the email that's it's been successfully unpushed, so I just create a new update with the two packages that are fine and a new build of the problem package? Thanks, Richard maybe just untag from whatever tag it's sitting in right now. -- -Jon -- 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: Is redis orphaned?
On Wed, Jun 18, 2014 at 10:41 AM, Christopher Meng cicku...@gmail.com wrote: I'm asking the original owner of redis to see why he chose tcmalloc as memory allocator, as I couldn't find any strong opinion to introduce gperf dependency just because of some negligible(not sure, though) performance improvement. Moreover, jemalloc is the default option for redis on Linux. Unless there is a really great reason to use tcmalloc, I would say the default jemalloc should happen. My experience with the two is JEmalloc has less issues long term bloating memory heaps, with comparable performance. But my reason to support JEmalloc is purely a releng driven thing, reducing BR's and R's is always preferable. My two-bits, but it would be nice to have a test suite to measure the two. But that requires effort and time, which are always low supply. I'd say give the maintainer time to chime in, otherwise make it happen after reasonable time-out. -- -Jon Disnard -- 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: why does it refresh metadata all the time
On Thu, Jun 19, 2014 at 12:46 PM, Reindl Harald h.rei...@thelounge.net wrote: that's not the question the question is why such traffic wasting *defaults* I might be way off base here, but in an effort to make DNF go faster compared to YUM, the idea was made to have it pre-fetch metadata ahead of time, so when DNF command is finally run by the user, it skips a costly step... and *seems* faster. Although I believe YUM could do that also with a simple crontab. It is actually a nice feature of DNF or YUM, and I would suggest you embrace. Also, I'm skeptical there is very much network traffic, unless it downloads file lists by default? It's arguable if file lists should be pre-fetched, to do things like determine what package provides something... I would say no, but bandwidth is cheap. So there really is a benefit, and it mostly leads to continuously update metadata. -- -Jon -- 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: why does it refresh metadata all the time
and BTW i am not playing around that much on my Rawhide VM but had *two times* today by type dnf whatever the there is already an instance, wating for PID... nonsense caused by the background metadata refresh do you *really* think that's a good user-expierience? No, that is unfortunate, and probably user unfriendly. It would be great if the metadata were fetched, and put into place atomically. Something where the downloading step of the fetching would block on YOUR pid as a user you should never lose the battle, and if you happen to get not a race with the finally atomic save, it would briefly make you wait while the stdio took place. This is one thing I've always though was unfortunate with yum, and would like to see improve with DNF. More resilient handling of tasks, or more concurrency, or whatever. I guess if you were doing a clearing of metadata, and in the back ground metadata were already being fetched... the two tasks could be combined, and you really wouldn't need to be blocked too much. Perhaps someday that will be implemented. =) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Fedora Base Design Working Group (2014-06-20) meeting minutes and logs
=== #fedora-meeting: BaseWG === Meeting started by masta at 15:13:52 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-06-20/basewg.2014-06-20-15.13.log.html . Meeting summary --- * === BaseWG Roll Call === (masta, 15:14:22) * === Announcements === (masta, 15:18:41) * === Open Floor === (masta, 15:21:23) * ACTION: all, think of people, ask if interested and bring to the meeting next week for discussion (dgilmore, 15:31:27) Meeting ended at 15:32:55 UTC. Action Items * all, think of people, ask if interested and bring to the meeting next week for discussion Action Items, by person --- * **UNASSIGNED** * all, think of people, ask if interested and bring to the meeting next week for discussion People Present (lines said) --- * masta (24) * zodbot (5) * dgilmore (5) * jreznik_q10 (4) * danofsatx-work (3) -- -Jon Disnard -- 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: repodata - xz
because thats how createrepo works!? :) I'm talking in general, why not use the same improved compression for all! I haven't mentioned an interactive, rpm based, package managers, at all. :) But when you mention them, it is obvious that we need features and performance of the delta repodata, which is currently lacking. Rather than listen to a dandified hullabaloo. :) I think it would be great to XZ all the things. For now createrepo still defaults to something else, not XZ. -Jon -- -Jon -- 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: repodata - xz
On Sat, Jun 21, 2014 at 11:25 AM, Tim Lauridsen tim.laurid...@gmail.com wrote: On Fri, Jun 20, 2014 at 3:44 PM, Dennis Gilmore den...@ausil.us wrote: because thats how createrepo works. the gzipped files are not ones you download. yum and dnf use the sqlite files. yum is using the sqlite files, dnf uses the .xml.gz files Would it be too much trouble to use the sqlite data in DNF? I suppose it would be a step backwards to have our primary (future) tool using gzip metadata. -- -Jon -- 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: repodata - xz
On Sun, Jun 22, 2014 at 6:26 AM, drago01 drag...@gmail.com wrote: On Sun, Jun 22, 2014 at 8:11 AM, Tim Lauridsen tim.laurid...@gmail.com wrote: On Sat, Jun 21, 2014 at 8:28 PM, Jon jdisn...@gmail.com wrote: Would it be too much trouble to use the sqlite data in DNF? I suppose it would be a step backwards to have our primary (future) tool using gzip metadata. the information in the sqlite files is orded i a way the yum is using the data, dnf parses the .xml files into another format used by libsolv. the sqlite was invented because the yum .xml to sqlite format was slow and has to happen on every client out there, so it was moved serverside to speed up things. Well can't we change create repo to create xml.xz files (in addition to .gz to preserve backwards compatibility) ? -- Perhaps we should make createrepo default to XZ in Fedora rawhide, and make all the tools do the right thing? Would be nice if createrepo was influenced by a system-wide config file, so we could easily implement that idea. Otherwise we are forced to work around createrepo in our release engineering. Regardless we should strive to make all repo metadata XZ compressed, unless there is a good reason not to do that? -- -Jon -- 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: delta rpms - can we turn them off
I personally tend to agree with Troy. We should consider defaulting to disable delta rpm at most, and at least comment the configs, or make things intelligent. For me, it takes longer to process delta rpm files than to download the actual full rpm, even on high end systems, or low end. I suppose in a way this goes back to the flame fest about the package updater knowing about network conditions. * With great network conditions, downloading full rpm might be optimal to the deltas. * With poor network conditions, deltas might be nice, but perhaps not with low end computer. -Jon -- 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: delta rpms - can we turn them off
On Fri, Jun 27, 2014 at 11:07 AM, Troy Dawson tdaw...@redhat.com wrote: Cool, I'm glad it's in the man pages now. It isn't in the man pages of my older versions of yum. And it's actually a very good section, talking about how it determines how many threads to use. Now that we've established that, what about the problem with running deltarpm on ARM or Atom based machines? Looking at the man page, it might not even be a problem with the CPU, but the IO of the machine. Almost all the machines in my tiny sever rack are running off slow disks, USB, or SD cards. All that being said, what is the criteria for getting a default configuration line put into yum.conf? I'd really like to get the deltarpm= line put in there. Troy Sorta like how the OpenSHH daemon config files are. Every default option is listed, commented... but listed in the config. Easy to find, and fix. -- -Jon -- 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: /media - /run/media???
Fedora's recent tendency to override the published file system hierarchy specs, at whim, and replace them with symlinks is problematic, unnecessary, and is breaking things. In this case, /media is defined in the upstream specs as the location for removable media. Not /run/media. Not /whither/my/love/piñata/wanders/media. Are you referring to the File System Hierarchy (FHS 2.3) spec [1], published in 2004, or the FHS 3 (beta) spec from 2011 [2] ? Regardless, those specs (according to my reading) do not imperatively [3] require a /media directory for removable media. It would appear /media is preferable to legacy places like /mnt/cdrom, etc. They also do not disallow for /run/media/$UID, only stipulating that these areas be sensibly protected, which Fedora does. Perhaps It would be nice to retain /media for situations where seated users choose to mount media in an insecure (world accessible) way? [1] http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html [2] http://www.linuxbase.org/betaspecs/fhs/fhs.html [3] https://www.ietf.org/rfc/rfc2119.txt -- -Jon Disnard -- 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: /media - /run/media???
On Fri, Aug 15, 2014 at 9:21 PM, Nico Kadel-Garcia nka...@gmail.com wrote: ... *sigh*. Then the default should have been to set UDISKS_FILESYSTEM_SHARED to 1. Let people who *want* it in the new /run/media/$USER/mountdir select it. And it's *still* a violation of even the most recent filesystem hierarchy standards, which discuss the use of /run and /var/run for pid files, not for removable media. Not a violation. From the beta spec: Programs may have a subdirectory of /run; this is encouraged for programs that use more than one run-time file. Users may also have a subdirectory of /run, although care must be taken to appropriately limit access rights to prevent unauthorized use of /run itself and other subdirectories. [1] The rationale here is that media mounts for a seated user are part of that users run-time, or session. By placing them in an area exclusive to the seated user, the system as a whole is more secure. Files in /run are supposed to be scrubbed or truncated at boot time!!! $ findmnt /run TARGET SOURCE FSTYPE OPTIONS /run tmpfs tmpfs rw,nosuid,nodev,seclabel,mode=755 Think I can get any traction getting that default reset at this point? Unlikely. [1] http://www.linuxbase.org/betaspecs/fhs/fhs.html#runRuntimeVariableData -- -Jon Disnard -- 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: No more deltarpms by default
On Mon, Oct 6, 2014 at 8:07 AM, Stephen Gallagher sgall...@redhat.com wrote: [ . . . ] It would be nice to see if we can find ways to improve the performance of the deltarpm reconstruction instead. Much of the time is spent on compression/decompression tasks which *should* be massively parallel; we should be able to speed this up by taking advantage of additional cores (and hyperthreading) on the system, for example. Another option might be not to bother recompressing the RPMs but instead just install an uncompressed RPM (and possibly recompress it out of band if we needed to keep it in the cache). export XZ_OPT=T0 If that were enabled in the environment the XZ compression phase would be significantly faster. -- -Jon Disnard -- 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: [Base] Base Design WG agenda meeting 20 March 2015 14:00 UTC on #fedora-meeting
My regrets. I'm in transit and may be late at best or miss the meeting. On Mar 19, 2015 7:37 AM, Harald Hoyer har...@redhat.com wrote: THIS TIME at 14:00 UTC because of US summer time. Agenda: - Interview candidates for new memberships - Optionally accept new members - Open Floor Please add items by replying to this mail. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: Non-responsive Maintainer - itamarjp
On Wed, Apr 29, 2015 at 6:45 PM, Eric Christensen spa...@fedoraproject.org wrote: Does anyone know how to contact itamarjp? I've been trying to contact him through BZ[0] regarding a security flaw in ytnef that's been open for going on five years. I've seen him on Facebook. https://www.facebook.com/itamarjp [0] https://bugzilla.redhat.com/show_bug.cgi?id=632537 Thanks. --Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon Disnard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora on Android
On Wed, May 13, 2015 at 7:03 PM, Les Howell hlhow...@pacbell.net wrote: Hi, guys, I created a new UI for GRBL using Python with tkinter. Not bad, but it won't work on an Android Notepad (GX10 from a company called EKEN), which was my target. Quit laughing, I know every one of you has had some similar experience where a language wouldn't port someplace... Anyway, I had seen some reports of Fedora on Android. I have been searching for over an hour and cannot for the life of me find Fedora for Android. I have seen links to various apps that will sort of be linux, and some that have some functionality, but reading the reviews has left me wondering if my favorite group of developers has given up on these little useful devices? Looking at the new Fedora offerings, I get Workstation, Server, and Cloud. But I could not for the life of me figure out which would work on Android A20 processors?? Please Help. This little pad has but one destination, driving my own milling machine, so rooting it is definitely an option, but I would prefer if there were some way to boot from the SD card with linux to verify that it works first. Just to keep it simple... Can someone please point me in a good direction to start. Regards, Les H -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct You can extract the Fedora armhfp bits onto Android, and then chroot. Similar setup to how Busybox works on Android, but much more heavy weight. -- -Jon Disnard -- 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: Docker base image naming for non-x86_64
On Mon, Jul 6, 2015 at 12:27 PM, Pradipta Kumar Banerjee bpra...@in.ibm.com wrote: On 06/02/2015 08:32 PM, Adam Miller wrote: Hello all, There was recently a thread on the Fedora ARM mailing list[0] about getting a Fedora ARM image into the official Docker Hub. That discussion lead down the trail of how to best handle the naming for all of this. The current questions are either using Fedora's namespace and just making a new image (using Fedora ARM as an example), this would be the FROM line for a Dockerfile FROM fedora/armhfp Which would then contain all the standard tags for latest, rawhide, f22, etc. Or alternatively, have each architecture maintain their own namespace within the Hub which would look a little more like: FROM fedora-arm I'm personally a fan of the first option because it keeps things under the Fedora umbrella and also allows for flexibility of aarch64, POWER, etc as Docker supports more architectures. However the one thing I see there that could be problematic is the possibility for users to be confused if they don't search on the Docker Hub webUI and see the associated documentation highlighting that the base image is for a different architecture but instead just search from the docker command line and end up with an image that won't run. Looking forward to feedback on the topic. Is there any agreement on the naming scheme ? The first form seems to have the most support. Thanks, -AdamM [0] - https://lists.fedoraproject.org/pipermail/arm/2015-June/009526.html -- Regards, Pradipta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon Disnard -- 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: Hosting End-Of-Life Fedora Base images?
If they are out of support, I don't think they should be easy to access. On Tue, Jul 21, 2015 at 8:16 AM, Neal Gompa ngomp...@gmail.com wrote: On Mon, Jul 20, 2015 at 3:33 PM, Chris Murphy li...@colorremedies.com wrote: Isn't it true the install media ISOs are available indefinitely? And if so the security cat is already out of the bag, so that's not a very good argument. I'd say if we wanted to do something better it would be an image that's usable for both VM and containers, and would be the state of that version at the time it went EOL, i.e. it has all available updates baked into it. And then de-emphasize the original ISO as the way to run older versions of Fedora. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct I tend to agree with the rest of the choir here in saying we shouldn't make it easier for people to use EOL releases. It will likely add unnecessary burdens onto us and our systems when people come to ask about EOL Fedora releases in Docker. Not to mention, we should be encouraging people to move up, not stay put. Honestly, I think if people need a platform that lasts a long time, they should be looking at CentOS with EPEL, SCLs, and/or other repos depending on what they need. -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon Disnard -- 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: RPM Weak Dependencies and the install media compose process
is not bad, but needs to be tested! Besides that, I'd like to see how comps.xml handles these new relationships. Thanks! -- -Jon Disnard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Ring 0 definition
On Tue, Sep 15, 2015 at 8:48 AM, Brendan Conoboy <b...@redhat.com> wrote: > On 09/14/2015 11:40 PM, Miroslav Suchy wrote: > >> Dne 14.9.2015 v 23:10 Brendan Conoboy napsal(a): >> >>> /Then/ we could start thinking about /truly minimal/ concepts, >>>> perhaps “container minimal” = “the minimal set needed to start and >>>> run an executable dependent on Fedora ABI” (e.g. kernel version >>>> requirement +glibc+locale data+Python 3 interpreter+…, useful for >>>> building containers), “VM minimal” could be “the minimal contents of a >>>> VM needed to start and run…” (e.g. kernel >>>> implementation+init+container minimal, useful for single-app VM), “CLI >>>> minimal”, … >>>> Mirek >>>> >>> >>> Right, so I don't think minimal is the end goal, I think the OS (not the >>> distribution) is the end goal- minimal is presumably a subset of the OS. >>> >> >> And how we call this "truly minimal concept"? Ring -1? >> >> I would like to have those Rings zero based, where zero is absolute >> minimum to run. Somewhere. Not necessary on bare metal. >> The whole "OS" can be Ring 1. There is still plenty of numbers remaining. >> > > How is this useful? > > Semantics count for something :-) But anyways, I'd say it's fine for ring0 to have a composition of Required & Recommended packages, but a more minimal minded person may opt to go without recommended things to achieve "minimal". (weak dependencies?) I would hope ring0 were small as an effect making it suitable for broader consumption by the variants/spins, but not as a goal in of itself. This seems like the OS being the goal, not minimization. Though keeping things small should not be ignored, it's a nice to have thing. However, If folks get hung-up on semantics I've no problem accommodating their concept of ring0 == minimal. Though it's kinda bikeshed... -- -Jon Disnard -- 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: [Koji] Re: [Koji] #333: no login button in web interface
On Fri, Jul 22, 2016 at 12:04 PM, Dave Love <d.l...@liverpool.ac.uk> wrote: > Charalampos Stratakis <cstra...@redhat.com> writes: > >> Hi. >> >> Doesn't 'koji list-tasks --mine' work for scratch builds? > > I couldn't find a way to show either scratch build tasks or finished > tasks of any sort with the cli. There doesn't seem to be any separate > documentation. > -- You can still use the web ui to see "scratch = True" for any given scratch build. > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- -Jon Disnard -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: glibc subpackage changes
On Wed, Aug 10, 2016 at 2:40 PM, Kevin Fenzi <ke...@scrye.com> wrote: > On Wed, 10 Aug 2016 12:56:47 +0200 > Florian Weimer <fwei...@redhat.com> wrote: > >> My suspicion at this point is that the past FPC/Fesco guidelines wee >> wrong, and the present tooling restriction is not just about >> rich/Boolean dependencies, but also about weak dependencies. > > Could be. >> >> Zero support for weak dependencies would actually be okay, sort of. >> The problem is that something treats the Recommends: as a Requires:, >> like yum does (bug 1360781). > > Yeah, so we have 2 paths here: > > 1. pungi does the rawhide and branched composes. These are running on > Fedora instances. I think it also uses createrepo_c. These composes do > have the rich/weak/etc deps. > > 2. bodhi does the updates / updates-testing repos. Currently this is > running on a rhel7 instance. It uses mash and mash uses createrepo > which uses yum. In this case the rich deps actually break the compose > and it won't work with them in the updates set, and weak deps are > likely treated the way yum would since createrepo uses yum. > I remember writing a patch for Mash that enabled createrepo_c support. [1] Maybe it's time to cleanup that patch, get it tested, and move it forward. [1] https://pagure.io/fork/parasense/mash/c/80d55f0b15345d2f8893b303731a144e6be402dc?branch=master > One short term thing we can try out is moving the bodhi instance to > Fedora24 and see if the newer rpm can handle things better. I'm not > sure if this will work fully, but we can give it a try and see. > > If that fails we could possibly wait for the > https://fedoraproject.org/wiki/Changes/KojiSignedRepos > change to finally land, as those will be generated on Fedora builders. > > It's unclear to me if we need just a newer rpm or need to switch away > from createrepo. If some folks wanted to do some testing that would be > great. ;) Just make a repo of packages with weak/rich/whatever deps and > build it on rhel7 and fedora24 and see if the correct metadata is > there and then again with createrepo_c. > > kevin > > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- -Jon Disnard -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Thu, Aug 4, 2016 at 10:27 AM, Stephen John Smoogen <smo...@gmail.com> wrote: > On 4 August 2016 at 11:07, Peter Robinson <pbrobin...@gmail.com> wrote: > >> All the details of the proposal along with FAQ have been put on a wiki >> page here[1] >> so please go and read it and ask any questions that aren't answered in >> the FAQ here. >> >> Regards, >> Peter >> >> [1] >> https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitectures >> -- > > What is the update for this statement: > > Q: When will the new ARMv7 builders be in place? > > A: Soon! The current plan is mid to late July. This proposal isn't > impacted by this as ARMv7 is already a primary architecture. > > > since we are past July.. is it July 2017 :)? > > That wiki was only setup July 21st (Mid to Late July), so probably go with "Soon!" instead of any approximate date. Setting up a number of m400 aarch64 nodes to provide ARMv7 virtual builders is pretty cool. So I certainly appreciate infra taking their time to get it right. :-) -- -Jon Disnard -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: /sbin/nologin in /etc/shells
On Fri, Sep 30, 2016 at 5:16 AM, Toby Goodwin <t...@paccrat.org> wrote: > As a member of the "remove nologin from /etc/shells" faction, I have 2 > technical reasons for my position. I don't think either of these points > have been addressed by the "leave it in" faction. [...] > > 2. Can anyone provide further detail on the "Shell variable pre-load > attack" mentioned in that original ticket? It's surely far too old to be > the "Shellshock" bug. > Unable to find any archive of the testers-list from 2001, the BZ references. However, one could reasonably speculate based on the information given. """ R P Herrold 2001-09-24 11:37:54 EDT Please add a SAFE no-login type shell to the base /etc/shells -- safe in the sense that it is immune from the Shell variable pre-load attack. It needs to be here, so that 'chsh' and other tools will allow its use without manual edit of /etc/passwd Nalin suggested /sbin/nologin on testers-list, but unlike all the other 'default' shells, this is not in /bin ... Doesn't bother me, but ... """ Lets break it out... "Immune from the Shell variable" Presumably the $SHELL variable? From the Bash manual: """ SHELL The full pathname to the shell is kept in this environment variable. If it is not set when the shell starts, bash assigns to it the full pathname of the current user's login shell. """ Okay, so the SHELL variable in bash has logic to deal with before & during shell startup. So presumably the "testers-list" email with Nalin could have been about fuzzing the $SHELL variable prior to login? Maybe back in those days one could set the SHELL variable to /usr/bin/MY-AWESOME-SCRIPT and it would actually make that the login shell? Or perhaps by "pre-load attack" we mean something more along the lines of LD_PRELOAD and static Vs dynamic shells. Back in the old days Unix folks were pesky about their statically built login shell which were more resilient to problems, compared to linked binaries. For example statically build shell would survive the absence of libc, or whatever system library. That was handy back in old days when system libraries were placed in a (I.E. corrupted) /usr/lib/ filesystem. Anyhow... with linked binaries it's theoretically possible to pre-load adversarial things, right? I have no idea if bash these days is static or otherwise, so if you know please chime in? Regardless, I am unable to think of any good reason to oppose Toby Goodwin's proposal around removing the nologin shell from /etc/shells. His reasoning seems solid. -Jon Disnard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mp3 encoding now ok
From the source: """ On April 23, 2017, Technicolor's mp3 licensing program for certain mp3 related patents and software of Technicolor and Fraunhofer IIS has been terminated. """ https://www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html --Jon On Wed, May 3, 2017 at 1:29 PM, Denise Dumas <ddu...@redhat.com> wrote: > Congratulations!!! > >> On May 3, 2017, at 1:45 PM, Christian Schaller <cscha...@redhat.com> wrote: >> >> Hi, >> So just wanted everyone to know that we now have the go ahead to ship mp3 >> encoding in Fedora too. So anyone involved with packaging >> mp3 encoders can now start migrating them to the Fedora repositories. We are >> still in the process of evaluating other codecs. >> >> Christian >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Jon Disnard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: mp3 encoding now ok
Normally Spot would revel these kind of topics. Where are you Spot? Have you run this topic through RH legal? Presumably one does not need legal sign-off when patents legally expire, but this topic is significant. We can now package mp3 encoding software. That is a big thing. --Jon On Wed, May 3, 2017 at 3:13 PM, Christian Schaller <cscha...@redhat.com> wrote: > Thanks, hadn't seen that. Ok, well I guess they do deserve some credit for > owning up to > their patents having expired. I am sure there are others out there who would > keep > claiming they still had IP in the hope of creating enough uncertainty to get > at least > some people to keep paying. > > Christian > > > > - Original Message - >> From: "Jon" <jdisn...@gmail.com> >> To: "Development discussions related to Fedora" >> <devel@lists.fedoraproject.org> >> Sent: Wednesday, May 3, 2017 2:59:32 PM >> Subject: Re: mp3 encoding now ok >> >> From the source: >> >> """ >> On April 23, 2017, Technicolor's mp3 licensing program for certain mp3 >> related patents and software of Technicolor and Fraunhofer IIS has >> been terminated. >> """ >> >> https://www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html >> >> --Jon >> >> On Wed, May 3, 2017 at 1:29 PM, Denise Dumas <ddu...@redhat.com> wrote: >> > Congratulations!!! >> > >> >> On May 3, 2017, at 1:45 PM, Christian Schaller <cscha...@redhat.com> >> >> wrote: >> >> >> >> Hi, >> >> So just wanted everyone to know that we now have the go ahead to ship mp3 >> >> encoding in Fedora too. So anyone involved with packaging >> >> mp3 encoders can now start migrating them to the Fedora repositories. We >> >> are still in the process of evaluating other codecs. >> >> >> >> Christian >> >> _______ >> >> devel mailing list -- devel@lists.fedoraproject.org >> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> > ___ >> > devel mailing list -- devel@lists.fedoraproject.org >> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> >> >> >> -- >> >> -Jon Disnard >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Jon Disnard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Starting a SIG for package reviews
Jason L Tibbitts III wrote: SO == Stanislav Ochotnicky sochotni...@redhat.com writes: SO I believe you forgot to set whenisgood to use timezones :-) My understanding is that you have to log in in order to set your timezone, or that choosing a timezone was something the responder had to do. When I created the form, Use timezones was checked. Not that I'm at all an expert at using that system. - J I just assumed, that since I'm an American, that everyone used my timezone. Right? ;) -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intent to package GNOME Shell frippery
On Fri, 2011-07-29 at 10:57 +0200, drago01 wrote: Well in gnome 3.2 (which should be out for F16) extensions will be like firefox extensions i.e you go to extensions.gnome.org and click install to install an extension. Distro packaged extensions are frowned upon upstream. So, just so I understand, the requirement/assumption is that all machines will be online and pulling bits down directly from GNOME? That won't map at all to enterprise or non-fully connected environments. It needs to be possible to install/provision a system with this kind of functionality because users are going to want to get these extensions. David: on the subject of your followup...my advice, by the way, is that life is too short to continue to try to explain why GNOME Shell is unusable for folks like you and I. I'd just switch to XFCE and be done with it. My machines are a lot happier for having made the switch :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer: gresistor
Richard Shaw wrote: I have submitted a bug report[1] for a bundled library I found in the gresistor package while working on a review request of my own. Both my package, and the bundled library, have been accepted which now means there are two packages that provide the same file. I have not gotten a response from the maintainer. Does anyone know how to get a hold of him? Chitlesh GOORAH chitl...@gmail.com Thanks, Richard [1] https://bugzilla.redhat.com/show_bug.cgi?id=710199 Email I have is chitlesh.goo...@gmail.com, don't know if that's right. CCd. http://www.facebook.com/chitlesh http://chitlesh.wordpress.com http://twitter.com/chitlesh http://chitlesh.fedorapeople.org http://chitlesh.fedorapeople.org -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abiword
Adam Miller wrote: On Tue, Aug 02, 2011 at 11:00:43AM -0600, Kevin Fenzi wrote: Abiword is currently broken in f16/rawhide due to the retiring of link-grammar (a FTBFS retiree). This is currently breaking the Xfce, LXDE, and soas spins. Would someone be interested in reviving link-grammar and possibly helping out updating/maintaining abiword? I've also sent email to the abiword maintainer, but they haven't commited to abiword in almost a year. Others have been fixing it. ;( I'd guess the next steps would be: * update link-grammar and get it building/working. * submit a review for it and get it back in. * update abiword and rebuild to use that version of link-grammar. kevin Would an option be to just retire abiword? Its slowly gotten less useful in most cases because it doesn't handle formats near as well as it once did (even .odt ... going from libreoffice to abiword is ... well, painful) and if upstream isn't contuning development on it is there much motivation to keep it alive? (I'm not entirely familiar with its user base so my suggestion might be heavily greated with OMG NOES! replies and if that's the case then by all means keep the train moving forward ... I just hate to unnessecary work done.) Also, I think with the new compression on the Live images all the spins have the spare space for LibreOffice. Just my $0.02. -AdamM I'd like to see abiword stick around, my $0.02. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer: gresistor
Richard Shaw wrote: On Tue, Aug 2, 2011 at 7:44 AM, Jon Ciesla l...@jcomserv.net wrote: Email I have is chitlesh.goo...@gmail.com, don't know if that's right. CCd. http://www.facebook.com/chitlesh http://chitlesh.wordpress.com http://twitter.com/chitlesh http://chitlesh.fedorapeople.org http://chitlesh.fedorapeople.org I tried messaging him on Facebook too but no response yet. I have provided a git diff to fix the problem and even checked to make sure the package functions with the new BR and the bundled library removed. I'm not really interested in taking the package over so a proven packager could take care of it. I don't think the package needs to be orphaned. Thanks, Richard I'm a PP, I'll have a peek. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer: gresistor
Jon Ciesla wrote: Richard Shaw wrote: On Tue, Aug 2, 2011 at 7:44 AM, Jon Ciesla l...@jcomserv.net wrote: Email I have is chitlesh.goo...@gmail.com, don't know if that's right. CCd. http://www.facebook.com/chitlesh http://chitlesh.wordpress.com http://twitter.com/chitlesh http://chitlesh.fedorapeople.org http://chitlesh.fedorapeople.org I tried messaging him on Facebook too but no response yet. I have provided a git diff to fix the problem and even checked to make sure the package functions with the new BR and the bundled library removed. I'm not really interested in taking the package over so a proven packager could take care of it. I don't think the package needs to be orphaned. Thanks, Richard I'm a PP, I'll have a peek. -J Committed, built, and Bodhi'd. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps
Tom Callaway wrote: I have two packages that need to be reviewed: * gambas3 - IDE based on a basic interpreter with object extensions ( This one is a bit colorful, but it should be easy enough to review. ) https://bugzilla.redhat.com/show_bug.cgi?id=710203 * freewrl - X3D / VRML visualization program https://bugzilla.redhat.com/show_bug.cgi?id=726210 Happy to trade reviews or other favors. ~tom == Fedora Project gambas3 for https://bugzilla.redhat.com/show_bug.cgi?id=596461 ? -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
Steve Grubb wrote: On Tuesday, August 09, 2011 07:51:07 AM Matthew Garrett wrote: On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote: This list is woefully incomplete. I would advocate a much larger list. For example, sudo is a very important program that we make security claims about. It is not on that list. Because it's SUID. ? Its one in the target group. I think there should have been some discussion about this on the FESCO request I submitted. I have some concerns about what was implemented. Are there bz filed for this or more discussion about it somewhere? We spent weeks discussing this. Where were you during the meetings? Taking RHEL6 through common criteria and FIPS-140, filing dozens of security bugs after studying some problems and sending patches. I am monitoring the FESCO ticket, but I don't monitor fedora-devel all the time because there are way too many arguments for my taste. Regardless, should there not have been some hint about anything on the ticket? I responded to any review request for the wiki page and such. My main concern is that the macro will be misapplied and overall performance will take a hit. I don't know how a macro can tell the intent of an application as it links it. The macro can't, but the maintainer can. The maintainer is presumably capable of, and responsible for, assessing whether her package would be a good candidate for this, and if so, testing builds done with the macro. Then if, performance is fine, on it goes. If performance sucks, it doesn't. -J There has not been a chmod so that it knows this is setuid and needs more protection. For example, if coreutils was built with this (and coreutils seems to be correct as is) because it has setuid programs, then would all apps get the PIE/Full RELRO treatment? If so, many of coreutils apps are called constantly by shell scripts. If this were used on tcpdump, would full relro leak to the libpcap? I suppose I could test this as soon as I set up a rawhide vm...but this is what concerns me about the approach. -Steve -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Which db should I build this package against?
On 08/10/2011 07:32 PM, Ankur Sinha wrote: Hello, I'm working on packaging conquest[1] for fedora which can be built against dbase,mysql, postgresql *and* mysql. Which one should I build it against? Should I build it against all of them and make different subpackages?? Did you talk to upstream and figure out if all these options are equally well supported? That would determine if you want to build sub packages for all or not Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel See also bacula. It rebuilds 3 times for sqlite, mysql and postgresql support. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need input for creating new icon
Richard Shaw wrote: I'm working on packaging the spacenav group of programs one of which is a gui app to setup the configuration of the spacenav daemon. It currently doesn't provide an icon so I thought I'd try my hand at it. Which resolutions do I really need to provide? Since I'm a CAD guy I used Unigraphics to model and export a high resolution image. Unfortunately the only export option was tiff. I then opened it in GIMP and set the background as transparent and saved it as a PNG. Of course with this method SVG is not an option Any advice would be appreciated. Thanks, Richard I've always made 48x48 PNGs. I don't really know why, but no one's ever complained. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need input for creating new icon
Richard Shaw wrote: On Wed, Aug 17, 2011 at 10:27 AM, Jon Ciesla l...@jcomserv.net wrote: I've always made 48x48 PNGs. I don't really know why, but no one's ever complained. I think that's the Gnome 2 default but the icons in gnome shell seem bigger so I saved 128x128 and 256x258 ones as well. I am not an artist so I would appreciate any feedback. I've uploaded the icons here[1]. For those who are not familiar with the spacenav project it provides a free library/driver alternative to the proprietary 3Dconnexion drivers for 3D input devices, also known as space balls or space pilots, etc. Thanks, Richard [1] http://hobbes1069.fedorapeople.org/spnavcfg/ Taking into account my total unfamiliarity with the project, is there anything about that image that says Oh, look, it's spacenav! to those who are familiar? Otherwise they look fine. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need input for creating new icon
Richard Shaw wrote: On Wed, Aug 17, 2011 at 11:10 AM, Jon Ciesla l...@jcomserv.net wrote: Taking into account my total unfamiliarity with the project, is there anything about that image that says Oh, look, it's spacenav! to those who are familiar? Otherwise they look fine. Yes, anyone who wanted the app would know what they're looking at. To see what I based it off of try: http://www.google.com/search?q=3Dconnexion+spacenavigator Thanks, Richard OIC, I think that's good then. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Fwd: Broken dependencies: vym]
I do some macro gymnastics with vym to prevent it Requiring a perl module that's named one thing in SuSE and another in Fedora. With my latest f17 build, that stopped working, while builds of the same code and spec on f15 and f16 seem to be ok. Did rpm's behaviour change? -J -- in your fear, seek only peace in your fear, seek only love -d. bowie ---BeginMessage--- vym has broken dependencies in the rawhide tree: On x86_64: vym-1.13.39-1.fc17.x86_64 requires perl(BugzillaClient) On i386: vym-1.13.39-1.fc17.i686 requires perl(BugzillaClient) Please resolve this as soon as possible. ---End Message--- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fwd: Broken dependencies: vym]
Iain Arnell wrote:
On Thu, Aug 18, 2011 at 3:42 PM, Iain Arnell iarn...@gmail.com wrote:
On Thu, Aug 18, 2011 at 3:22 PM, Jon Ciesla l...@jcomserv.net wrote:
I do some macro gymnastics with vym to prevent it Requiring a perl module
that's named one thing in SuSE and another in Fedora. With my latest f17
build, that stopped working, while builds of the same code and spec on f15
and f16 seem to be ok. Did rpm's behaviour change?
The perl_default_filter macro changed with perl 5.14. We're now using
rpm's native __requires_exclude macro (and friends) instead of the
slightly hacky filter_setup stuff. Ideally, we'd drop the
filter_setup/filter_from_requires entirely, but to keep a single spec
compatible with all current fedora branches, you can do:
--- vym.spec.orig 2011-07-20 19:58:57.0 +0200
+++ vym.spec2011-08-18 15:37:06.427529132 +0200
@@ -22,6 +22,7 @@
%filter_from_requires /^perl(BugzillaClient)$/d
%?perl_default_filter
}
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}perl\\(BugzillaClient\\)
^ That should be one line, of course.
And I noticed that you already have a __requires_exclude. But at the
minute, it *must* come after perl_default_filter.
Worked like a charm, thanks very much!
-J
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd in F15 orphaned?
Am 20.08.2011 20:49, schrieb MichaÅ Piotrowski: 2011/8/20 Reindl Harald h.rei...@thelounge.net: Am 20.08.2011 19:58, schrieb Lennart Poettering: On Sat, 20.08.11 16:25, Reindl Harald (h.rei...@thelounge.net) wrote: WHY do F16 and F17 get permanently updated and nobody cares about the beta-release called F15 GA any longer? F15 is SEVEN versions behind! Like most packages in Fedora systemd in released distributions is only updated when bugs need to be fixed. Feature additions are only done in the development version of Fedora. the problem is that wat you call as intedned, a bug and users call the same is mostly a different thing, so if it was decided to include systemd in a way too few state in systemd it should be mandatory that it will be optimized in the same rlease and not a year later If you want a new features just build it or use F16 branch. Most F15 users don't want to deal with new systemd bugs in stable system. jokingly? nobody wanted a text-desert at boot nobody wanted a systemctl anything service without feedback nobody wanted a /sbin/service-wrapper which ALWAYS says OK even on fail nobody wanted to fire up services with sockets after systemctl stop something.service nobody wanted a bott with no progress while fs-check is active if you release this crap way too soon in a production release you are responsible to fix this bad attitudes in the same fedora-release or consider BEFORE the GA not spit in the users face with making perfectly working things worser because YOU are thinking that all is better (in theory) Ignoring the pace at which this discussion is approaching incivility, in what way would bleeding-edge updates to systemd address any of the above? For games, many would argue the pushing the latest and greatest to every release is good. I might agree in most cases. But for something like systemd, most admins I've worked with would like nothing to change in the middle of a stable release unless it fixes a bug. Of course, I don't like this, it's different isn't a bug, and there's a substantial amount of backwards-compatibility built in here. I've been restarting services with /etc/rc.d/init.d/foodaemond restart for ages. It's what my fingers like. And it still works. Better and Worse are not things that anyone can take action on. Specific problems introduced are. If you can say, This used to be A, and now it's B, and when it changed, it broke C, and nothing in the documentation tells me how to make C work with B, file a bug. You may have to make changes to make C work with B. You may not. I actually found that I did, but oddly all the things I needed to learn made things easier. The move from SysV initscripts to unit files alone is wonderful. In this case, there have been real benefits to changing A to B, and the kinks remaining to be worked out are becoming fewer daily. It's not perfect, but it's a lot better than it could be. Additionally, it's not like the move to systemd was announced on 15GA day. The volume of discussion, troubleshooting, flaming, and problem resolution that went on on lists, in BZ, and email prior to that is impressive. /cranky_rant -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd in F15 orphaned?
Am 21.08.2011 22:07, schrieb Jon Ciesla: Ignoring the pace at which this discussion is approaching incivility, in what way would bleeding-edge updates to systemd address any of the above? For games, many would argue the pushing the latest and greatest to every release is good. I might agree in most cases. But for something like systemd, most admins I've worked with would like nothing to change in the middle of a stable release unless it fixes a bug most admins will not be NOW at F15, they wait until F14-EOL for production use to get most bad behavior and bugs away before update servers Fedora? Production? I do that, but I'm mental. i am one of them and i am seeing NOTHING happen in F15 now to make things better until Dec/Jan and the wrapper you noticed about /etc/init.d/servicename is the dumbest thing i saw the last years because it hides the real output of the script It's less than ideal, yes, so I use service whateverd restart now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd in F15 orphaned?
Am 22.08.2011 16:36, schrieb Jon Ciesla: Am 21.08.2011 22:07, schrieb Jon Ciesla: Ignoring the pace at which this discussion is approaching incivility, in what way would bleeding-edge updates to systemd address any of the above? For games, many would argue the pushing the latest and greatest to every release is good. I might agree in most cases. But for something like systemd, most admins I've worked with would like nothing to change in the middle of a stable release unless it fixes a bug most admins will not be NOW at F15, they wait until F14-EOL for production use to get most bad behavior and bugs away before update servers Fedora? Production? I do that, but I'm mental yes - from F9 to F14 this was really easy VMware-Cluster with snapshots, some backup-machines as test all machines using the same internal cache-repo and no external per server 4-6 minutes and 30 seconds for reboot no problem maintain 23 servers this way with a little brain and helper-scripts Agreed. But it's not for everyone. ;) but F15 is the first release where this feels really ugly with no benefit anywhere until now Feels? So. . .you have to change your helper scripts? I'm confused. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd in F15 orphaned?
Am 23.08.2011 15:36, schrieb Jon Ciesla: Fedora? Production? I do that, but I'm mental yes - from F9 to F14 this was really easy VMware-Cluster with snapshots, some backup-machines as test all machines using the same internal cache-repo and no external per server 4-6 minutes and 30 seconds for reboot no problem maintain 23 servers this way with a little brain and helper-scripts Agreed. But it's not for everyone. ;) maybe, but i am not everyone - i know exactly what i do and something goes terrible wrong if the really expierienced users have more troubles as some standard desktop-user but F15 is the first release where this feels really ugly with no benefit anywhere until now Feels? So. . .you have to change your helper scripts? I'm confused my self written watchdog which detects reboot/shutdown and calls of /sbin/service doe snot work any longer and this script is simply perfect restarting services and giving the result of /sbin/service out results in a perfectly cron mail with systemd - not possible, if systemd is reastrting a service you get NOT notfied - this is essential because it is one thing a service is fired up again automatically but if you are not notified and this happens to often you will not recognize this below a example Betreff: Cron root@myhost php /scripts/rh_watchdog.php Datum: Tue, 5 Jul 2011 17:38:01 +0200 (CEST) Von: Cron Daemon root@mydomain An: root@mydomain httpd not running, waiting 5 seconds and restart if it not comes back httpd beenden: [FEHLGESCHLAGEN] httpd: no process found httpd starten: [ OK ] ___ services with .socket-files are NOT stopped with systemctl stop name.service and suddenly fired up and the missing feddback of systemctl is bad below a example-mail of a weekly job stopping two mysqld-instances on a machine (one of them replication-slave) and let rsync backup# the replication into the other one - this have to be totally changed Betreff: Cron root@myhost nice -n 19 bash /opt/scripts/backup-mysql.sh Datum: Sat, 2 Jul 2011 03:10:01 +0200 (CEST) Von: Cron Daemon root@mydomain An: root@mydomain Sat Jul 2 03:10:01 CEST 2011 mysqld beenden: [ OK ] replication beenden: [ OK ] replication starten: [ OK ] mysqld starten: [ OK ] Sat Jul 2 03:24:33 CEST 2011 there are tons of such scripts running perfectly since years and all of that has to be changed/replaced/retested because of systemd So they need to be changed, yes. A pain, but. . . without any real benefit at this time . . .to you, perhaps. For many, however. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
Folks, We are hosting another one of our regular Fedora 15 hardfp Virtual Fedora Activity Day today Friday August 26th 2011, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this session is to co-ordinate the continued bootstrap of F15 hardfp (hardware floating point). Previously, we performed initial bootstrap (stage1), then proceeded to get RPM working natively within an ARMv7 hardfp environment (stage2), then got yum and mock working (stage3). We are now in what we are calling stage4 in which we are rebuilding the world of packages using mock, but are not yet using Koji to do so - that will be stage5, the final stage before we are able to say that we have completed bringup. We need helping building packages within a mock environment for F15. To do this, we have made your life as a (potential) volunteer somewhat more straightforward through the creation of a standard image that you can install onto an ARMv7 compatible board (tested on Panda, we believe this should also work on Beagle, and can be made to run on Tegra-2 boards like Trimslice with a replacement kernel - ask us for assistance). Once you have done this, the resulting system will contain a simple script that you can use to randomly retrieve a package that needs building and have it build without you having to even issue a single mock command :) To participate, visit the following link: http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ Follow the instructions contained within the readme file to extract the uboot, boot, and root archives onto an SD Card for your device. These instructions will destroy whatever is already installed. If you are familiar with using chroots, you can also retrieve the root image and chroot into it if you would prefer (after bind mounting /proc, /dev, etc.). We generally prefer not using chroots at this stage however. Once you have followed the setup instructions: 0). Configure /etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcfg-eth* according to your setup. The ones in that image statically assign tenaya.bos.jonmasters.org. 1). Login to your board as root (password is fedora). Change the password if you would like to do so. 2). Become the builder user. You can either su - builder or you can passwd builder, and then login remotely/on the console. 3). Optional, but recommended, use screen -S builder or similar to start a screen session that you can leave running. 4). Run the simple building script: ./arm-rebuild.sh 5). Monitor the arm mailing list. It is likely that a newer version of the builder script will be posted later today or before Monday. When that happens, we may change the SSH keys used in the build image, which would have the effect of forcing everyone to update. The purpose of that being to prevent any existing builders running the older script version. Instructions will be posted for updating a couple files will be posted. Please join us on IRC: #fedora-arm on irc.freenode.org. Further documentation will be provided on the Fedora ARM wiki today, however this email should provide sufficient setup information now. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Fri, 2011-08-26 at 09:51 -0400, Jon Masters wrote: To participate, visit the following link: http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ Follow the instructions contained within the readme file to extract the uboot, boot, and root archives onto an SD Card for your device. These instructions will destroy whatever is already installed. If you are familiar with using chroots, you can also retrieve the root image and chroot into it if you would prefer (after bind mounting /proc, /dev, etc.). We generally prefer not using chroots at this stage however. NOTE: The readme has been updated as of 1pm EDT today to correct a few issues. Please reload it. The current version should work on all OMAPs using x-loader, no matter how finnicky they are about partitioning. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Fri, 2011-08-26 at 09:51 -0400, Jon Masters wrote: To participate, visit the following link: http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ Just a quick update that we've had mock builders running around the clock and that, at last count we had built almost 9,000 native ARMv7 RPMs for the Fedora 15 bootstrap effort. I'll keep everyone updated. If you would like to contribute build cycles, please see my earlier mail, and ping us on #fedora-arm (irc.freenode.org) if you need assistance. Hopefully, within a week or so we can consider switching to a full Koji environment, at which point we'll just have to do one more mass rebuild (stage5) before we /should/ have everything built correctly in Koji. We can do a preliminary alpha release of F15 soon thereafter. Folks are working on Anaconda, but I've no status update on that front yet. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Monday, August 29, 2011, 7:54:10 AM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Why does it matter to you? Why make this change, which will at best inconvenience that very small minority of Feedora users.? If it is maintained, and works then it should stay. +1. I don't use vim or rythmbox or play tremulous, and their presence doesn't hurt me or my mirror. :) -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote: On 08/29/2011 02:54 PM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage. Someone? A single Discordian follower already, for example? Perhaps that person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution? Based on http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius the ddate command and its manual's level of relationship to a religion (or a joke religion) enters a grey area with regard to the packaging policies: | Some examples of content which are not permissable: | | Comic book art files | Religious texts | ... https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content The Julian and Gregorian calendars are also of religious origin. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 08:32:01 -0500, JC (Jon) wrote: On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote: On 08/29/2011 02:54 PM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage. Someone? A single Discordian follower already, for example? Perhaps that person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution? Based on http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius the ddate command and its manual's level of relationship to a religion (or a joke religion) enters a grey area with regard to the packaging policies: | Some examples of content which are not permissable: | | Comic book art files | Religious texts | ... https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content The Julian and Gregorian calendars are also of religious origin. Apples and oranges. Do you find anything like in the SEE ALSO section of man ddate also in man date? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel That may be (both are human constructs, it's like say hey, that's made up word!, but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On 08/29/2011 05:24 PM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? IIRC, you are upstream for this and could do this change upstream and then, there wouldn't be a debate about this here. Otherwise, make ddate a sub package and don't install it by default. Solved? Acceptable to me, but is the extra metadata for another RPM worth the space savings? -J Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram methe...@gmail.com wrote: Â Otherwise, Â make ddate a sub package and don't install it by default. Â Solved? As an upstream the willingness of distributions to strip out commands which I wanted to provide and don't offer a build option to disable via sub-packaging will simply encourage me to pack more functionality into single binaries that the distributions won't strip. So I think Fedora shouldn't be more willing to strip ddate than it would be willing to patch out ddate functionality if it were embedded in 'hwclock'. There is a reasonable argument that util-linux ought to go on a diet: Right now it appears to take up 6424k on disk. (Though, most of that is localizationsâ and several of the various NEWS/readme files it includes are bigger than ddate, as is its copy of the GPL. This silly thread has probably taken up more disk space than ddate, or it soon will) I think it has. :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Chris Adams wrote: Why does util-linux have two floppy disk formatters (/usr/bin/floppy and /usr/sbin/fdformat)? Why does it have any floppy tools any more? The kernel maintainers don't support the floppy module and the module hasn't been auto-loaded for several releases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Because there are still people with floppy drives? -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, Aug 29, 2011 at 08:47:40AM -0500, Jon Ciesla wrote: That may be (both are human constructs, it's like say hey, that's made up word!, but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. That's simple, I'm upstream maintainer. The command has been disabled by default in the last stable release. And yes, one I day I'll drop it... If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit. - it's joke rather than anything useful - it's installed on all systems, but almost nobody uses this crap Really? How do you know that? -J Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 08:47:40 -0500, JC (Jon) wrote: The Julian and Gregorian calendars are also of religious origin. Apples and oranges. Do you find anything like in the SEE ALSO section of man ddate also in man date? That may be (both are human constructs, it's like say hey, that's made up word!, but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit. With that point of view, it's probably impossible to convince you. I won't try. I just encourage Karel to get rid of ddate somehow. A valid reason IMO is to build a base distribution, a product -- our product -- which does not consist of extremely silly code and which does not advertise dubious religions. Not even with links as found in the manual. There are several scenarios where we divert from upstream due to various circumstances. Sure, for sufficient reasons. Whether it's harmful to distribute ddate, I don't know. Isn't it enough reason to not offer something because it's considered silly/crazy crap? Or if it doesn't make sense to ship it as part of a default OS environment? I'm not suggesting ddate is mission-critical, I just want reasons for it's removal or re-packaging to be well thought-out, not simply gosh, I don't sue that, so. . .. Otherwise we'll start dropping games. http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar | Most common Linux operating system-distributions have the command ddate | to show the current Discordian date. Strange people these Linux people. http://en.wikipedia.org/wiki/Discordian_calendar#Implementations | ddate, a program that prints the current date in the Discordian calendar, | is part of the util-linux package of basic system utilities.[6] As such, | it is included in nearly all Linux distributions, despite some | resistance.[7] There are many other programs with similar functionality. - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149321 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Jos Vos wrote: We just have to wait till people come up with the argument that serial or parallel ports don't exist anymore. No. You're making an apples to orange comparison. Just like Jon has done this whole thread. This bike shedding as gone on long enough. Playing devil's advocate != bikeshedding. But, I agree that this discussion is aging rapidly. Remove ddate. Karel, you're upstream. Do it. Now *this* makes sense. I never advocated ddate being preserved in lucite forevermore. I just wanted a sane reason to deviate from upstream. if upstream drops it, the point is moot, and I think that's fine. P.S. Your argument will be moot when the kernel drops the floppy module. Is there actually a plan for this to happen? Curious, not arguing here. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 10:27:40 -0500, JC (Jon) wrote: I'm not suggesting ddate is mission-critical, I just want reasons for it's removal or re-packaging to be well thought-out, not simply gosh, I don't sue that, so. . .. Otherwise we'll start dropping games. Sure (and not limited to games, which are in optional packages, however). We do that all the time, if a package maintainer no longer considers a game (or package in general) worthwhile, and if nobody else volunteers to take over a package. Of course, you're free to adapt as many orphans as you like, whether actively maintained upstream or ancient. Eventually, you'll be in the same situation, where you would like to drop something, be it a completely optional package or a plugin [*] you consider useless, close to useless, or just broken. [*] or a program with alternative user-interfaces Absolutely! I've been there. It's not the retirement of software I object to in this case, though I prefer to avoid that, it's the arbitrary deviation from upstream. If the deviation isn't arbitrary, I generally support it. All that aside, I'd be sad to see ddate go, but that's totally beside the point. :) -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Mon, 2011-08-29 at 19:13 +0100, Peter Robinson wrote: On Mon, Aug 29, 2011 at 4:06 AM, Jon Masters j...@redhat.com wrote: On Fri, 2011-08-26 at 09:51 -0400, Jon Masters wrote: To participate, visit the following link: http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ Just a quick update that we've had mock builders running around the clock and that, at last count we had built almost 9,000 native ARMv7 RPMs for the Fedora 15 bootstrap effort. I'll keep everyone updated. If you would like to contribute build cycles, please see my earlier mail, and ping us on #fedora-arm (irc.freenode.org) if you need assistance. Why don't we just get it running in koji? Once we can get a armv5tel/armv7hl running in koji we don't need to have people off doing their own thing and we can start moving forward as a group. We need a provisional set of repos to populate Koji. Arguably we might have enough now to get away with it, but we'd still wind up with lots of buildroot and false FTBFS type failures as Koji couldn't find deps. For better or worse, Dennis and I felt it was better to do a mock run first. The Koji build will happen soon. We need to do one more build to make sure we have every build dep in place during builds. Although we suspect we're good even with stage4, we'd like to make sure we don't have packages failing to enable features during build by doing it again in what we call stage5. Then, we're done. Lots of nice things could be done to improve this in the future, like bootstrap deps, etc. We'll keep an eye on builds this week. Some packages need huge resources to build, so they might be removed from the general list and built on a box we have that has a lot more RAM than many of the other builders. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundle question
Hello. I'm review jreen library and there found [1] very interesting issue - psi and kdenetwork bundle iris, jdns [2] and simplesasl. For example: $ find kdenetwork-4.6.5 psi-0.14 -iname simplesasl\* kdenetwork-4.6.5/kopete/protocols/jabber/libiris/iris/xmpp/xmpp-core/simplesasl.h kdenetwork-4.6.5/kopete/protocols/jabber/libiris/iris/xmpp/xmpp-core/simplesasl.cpp psi-0.14/iris/src/xmpp/xmpp-core/simplesasl.h psi-0.14/iris/src/xmpp/xmpp-core/simplesasl.cpp Should I fill bugs about it against both? iris (simplesasl its part) is psi [3] library, and as I understand released in it. So I think it may contain it. But how deal with kdenetwork? Patch jreen to use system versions. See: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries for guidance. 1 https://bugzilla.redhat.com/show_bug.cgi?id=731456#c8 2 http://delta.affinix.com/jdns/ 3 http://psi-im.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
Hi, Owing to limited time recently I have been unable to look into my packages and so I am orphaning the following packages: agave gnujump mausezahn moe peppy gnurobots It would be nice if someone can pick them up. Done, except for agave. Does it need to stay dead? I only see the FTBFS bug, which looks like it has a fix in the BZ. Thanks and Regards, Vivek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [X-Post] Fedora medical needs package maintainers
Hello all, If you've been following the planet[1], you'd know that my GSoC project this year was packaging for the Fedora Medical SIG. I packaged quite a few of them during the GSoC period[2]. The issue here is that I cannot maintain these packages: I do not use them. Are any maintainers here interested in these packages? Please apply for co-maintainer-ship if you are, and I will hand the packages over to you. I am going to orphan these packages in the next few weeks so others can take them over. This is the best path to take in the interests of fedora medical in the long term. If it's important to you that these packages stay in Fedora, it would be better not to orphan them, but to hang onto ownership until someone requests it, so that they don't get dropped from the distribution in a few cycles. -J If you are interested in maintaining these packages but are not a sponsored maintainer, please have a look at this link[3]. I will gladly mentor anyone who is interested in contributing to fedora as a package maintainer. [1] http://planet.fedoraproject.org [2] http://dodoincfedora.wordpress.com/2011/08/20/fedora-gsoc-report/ [3] http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer -- Thanks, Regards, Ankur: FranciscoD http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
Hi, Owing to limited time recently I have been unable to look into my packages and so I am orphaning the following packages: agave gnujump mausezahn moe peppy gnurobots It would be nice if someone can pick them up. Done, except for agave. Does it need to stay dead? I only see the FTBFS bug, which looks like it has a fix in the BZ. . . .which I tried, and it works, but gnome-vfsmm26 is retired. Thanks and Regards, Vivek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 - font point sizes now scaled?
On Mon, 2011-10-03 at 12:56 -0400, Adam Jackson wrote: More to the point, your DPI numbers would be per-output anyway, so there's no picking a single point size preference, the same size in pixels would be different sizes in millimeters on each output. In fairness, for my dual head setup I did what I always do: I bought a matched pair of monitors from the same batch. EDID seems sane, too. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Tue, 2011-10-04 at 13:54 -0400, Adam Jackson wrote: On Tue, 2011-10-04 at 11:46 -0400, Kaleb S. KEITHLEY wrote: Grovelling around in the F15 xorg-server sources and reviewing the Xorg log file on my F15 box, I see, with _modern hardware_ at least, that we do have the monitor geometry available from DDC or EDIC, and obviously it is trivial to compute the actual, correct DPI for each screen. I am clearly going to have to explain this one more time, forever. Let's see if I can't write it authoritatively once and simply answer with a URL from here out. (As always, use of the second person you herein is plural, not singular.) EDID does not reliably give you the size of the display. How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 16:20 +0100, Matthew Garrett wrote: On Thu, Oct 06, 2011 at 11:14:56AM -0400, Jon Masters wrote: How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? The specification provides everything needed to express this data accurately, and proves the worth of specifications by virtue of approximately nobody actually implementing it correctly. How about an actual DPI value? Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why EDID is not trustworthy for DPI
On Thu, 2011-10-06 at 12:12 -0400, Adam Jackson wrote: On Thu, 2011-10-06 at 11:14 -0400, Jon Masters wrote: On Tue, 2011-10-04 at 13:54 -0400, Adam Jackson wrote: EDID does not reliably give you the size of the display. How about EDID as it exists today. Since you're able to so beautifully explain what the pitfalls are, I'd assume you've raised this with the VESA and asked that they revisit this in the future to accurately provide DPI information that Operating Systems can rely on? Given that successive revisions of the spec have gone out of their way to make it acceptable for displays to provide _less_ useful information, on the grounds of manufacturing cost reduction, I think the momentum is quite in the other direction. More pragmatically, VESA are not the people with any influence here. The only thing that matters to a monitor vendor is what Windows does when you plug it in. Linux can stamp its little foot all it wants. No one will care. If you want to be a big enough player in that market to have some influence, you have to start by playing in the sandbox that's already built, and in that sandbox physical dimensions are just not reliable and never will be. Cope. Ok. I can cope, and not to flog a dead horse here...but has any effort been made anywhere on the Open Source side of things to influence future EDID specs? I'm sure Linux can stamp all it wants and nobody will care, but it probably doesn't hurt to raise this for discussion next time there's an update to the standard - or, shock, reach out to MSFT and see if they have any interest in working together on fixing this experience which perhaps also causes problems they care about on Windows. Just a suggestion. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review SIG dead?
RS == Richard Shaw hobbes1...@gmail.com writes: RS After some initial interest there doesn't appear to be any activity RS unless I'm missing something. Never could gather enough interest for anyone to actually do anything. Basically I stopped after I called for a couple of folks to help me with some things and there was no response whatsoever. RS I am still interested. Anyone else? These days my interest is only occasional. If someone else is actually willing to do something, then I'm willing to participate on some level. But I'm not enough of an organizer, and I don't have enough free time, to be the person who makes it happen. I'm interested, but I'm also not a great people wrangler. All I've managed to do is organize and somewhat increase my own reviewing. Which is great, but doesn't scale. :) -J - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning pida
Hello all, I am planning to orphan pida, I haven't used it since probably mid F14 cycle and I feel it needs a maintainer that will give it more attention. If I can get 0.6.2 to build, I'll take it. -J -AdamM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning pida
Hello all, I am planning to orphan pida, I haven't used it since probably mid F14 cycle and I feel it needs a maintainer that will give it more attention. If I can get 0.6.2 to build, I'll take it. I did. Anyone interested in having pida 0.6.2 would be welcome to review the following, which it needs: https://bugzilla.redhat.com/show_bug.cgi?id=745233 https://bugzilla.redhat.com/show_bug.cgi?id=695022 Thanks! -J -J -AdamM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 10:51 -0700, Adam Williamson wrote: On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote: On 12 October 2011 17:44, Kevin Fenzi ke...@scrye.com wrote: All existing users of the Fedora Account System (FAS) at https://admin.fedoraproject.org/accounts are required to change their password and upload a NEW ssh public key before 2011-11-30. I have to upload a *new* public key? Why should I have two sets of keys? Meant 'replacement'. You can only have one key in FAS, afaict. You can have more than one. Just paste them in place all together. And we're verifying key changes by checking the fingerprint of the pubkeys vs your prior ones. It's really not a huge hassle. I've already done it. I configured the .ssh/config files where I needed to, and it doesn't conflict with any other keys I have. I don't get what the big deal is. The disruption is, like, five minutes of work. The potential benefit is unknown, but certainly not zero. Why wait for a breach to do this? This is a perfect time. Doing it after the 2008 breach was wise. This is better. -J -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 13:06 -0500, Jon Ciesla wrote: On Wed, 2011-10-12 at 10:51 -0700, Adam Williamson wrote: On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote: On 12 October 2011 17:44, Kevin Fenzi ke...@scrye.com wrote: All existing users of the Fedora Account System (FAS) at https://admin.fedoraproject.org/accounts are required to change their password and upload a NEW ssh public key before 2011-11-30. I have to upload a *new* public key? Why should I have two sets of keys? Meant 'replacement'. You can only have one key in FAS, afaict. You can have more than one. Just paste them in place all together. And we're verifying key changes by checking the fingerprint of the pubkeys vs your prior ones. It's really not a huge hassle. I've already done it. I configured the .ssh/config files where I needed to, and it doesn't conflict with any other keys I have. I don't get what the big deal is. The disruption is, like, five minutes of work. The potential benefit is unknown, but certainly not zero. Why wait for a breach to do this? This is a perfect time. Doing it after the 2008 breach was wise. This is better. A breach won't compromise my actual keys even if it happened now or a year ago. Unless the breach alters a package that gets pushed to your machine and snarfs your keys. /devilsadvocate Plus there are limitations on how many keys (and passpharases I can remember, especially for stuff I use less often). keepassx. Plus there are limitation about how many keys ssh/ssh-agent can use before failing to log you in no matter what. If your client config knows what key to use for what host, and you know the password, I fail to see the problem. Plus, you could have multiple keys, all with the same passphrase, for different things, should you so desire. Compound all this. Simo. -- Simo Sorce * Red Hat, Inc * New York -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 13:25 -0500, Jon Ciesla wrote: On Wed, 2011-10-12 at 13:06 -0500, Jon Ciesla wrote: On Wed, 2011-10-12 at 10:51 -0700, Adam Williamson wrote: On Wed, 2011-10-12 at 18:41 +0100, Richard Hughes wrote: On 12 October 2011 17:44, Kevin Fenzi ke...@scrye.com wrote: All existing users of the Fedora Account System (FAS) at https://admin.fedoraproject.org/accounts are required to change their password and upload a NEW ssh public key before 2011-11-30. I have to upload a *new* public key? Why should I have two sets of keys? Meant 'replacement'. You can only have one key in FAS, afaict. You can have more than one. Just paste them in place all together. And we're verifying key changes by checking the fingerprint of the pubkeys vs your prior ones. It's really not a huge hassle. I've already done it. I configured the .ssh/config files where I needed to, and it doesn't conflict with any other keys I have. I don't get what the big deal is. The disruption is, like, five minutes of work. The potential benefit is unknown, but certainly not zero. Why wait for a breach to do this? This is a perfect time. Doing it after the 2008 breach was wise. This is better. A breach won't compromise my actual keys even if it happened now or a year ago. Unless the breach alters a package that gets pushed to your machine and snarfs your keys. /devilsadvocate That's possible, at which point I will have to change all my keys. But unless the machine is reinstalled first, it will make no difference, new keys will be snarfed again as soon as they are created. Plus there are limitations on how many keys (and passpharases I can remember, especially for stuff I use less often). keepassx. By rule ssh and gpg keys passphrases exist only in my memory. No chance of writing them down. Plus there are limitation about how many keys ssh/ssh-agent can use before failing to log you in no matter what. If your client config knows what key to use for what host, and you know the password, I fail to see the problem. Plus, you could have multiple keys, all with the same passphrase, for different things, should you so desire. Using the same passphrase for different keys is the same as using the same password for different websites. If I am protecting the keys the same way I can as well use the same keys everywhere, unless projects set up insane rules about how to handle my own keys. I wasn't suggesting it was a good idea, I was suggesting that it was a tradeoff one could make in favor of convenience. I don't, personally. -J Simo. -- Simo Sorce * Red Hat, Inc * New York -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
