Re: Copr timeout on large KiCAD package
copr-cli has a --timeout option (in seconds). had the same issue with llvm. - Rudolf Kastl Am Mo., 30. Nov. 2020 um 19:24 Uhr schrieb Richard Shaw : > > On Mon, Nov 30, 2020 at 11:42 AM Steven A. Falco > wrote: >> >> KiCAD has a large package containing 3D component models. It takes a long >> time to compress with the new zstd compressor. So long in fact that the >> copr build system is throwing a timeout. You can see an example here: >> >> https://download.copr.fedorainfracloud.org/results/@kicad/kicad/fedora-33-x86_64/01795065-kicad/builder-live.log.gz >> >> Here is the text at the end of the above log - basically it times out when >> compressing the 3D models into the RPM file: >> >> ... >> Wrote: /builddir/build/RPMS/kicad-debuginfo-r23934-fc2bdc49.fc33.x86_64.rpm >> Wrote: /builddir/build/RPMS/kicad-r23934-fc2bdc49.fc33.x86_64.rpm >> Wrote: /builddir/build/RPMS/kicad-doc-r23934-fc2bdc49.fc33.noarch.rpm >> Wrote: /builddir/build/RPMS/kicad-debugsource-r23934-fc2bdc49.fc33.x86_64.rpm >> !! Copr timeout => sending INT >> Copr build error: Build failed >> >> The package is named kicad-packages3d. Compressed size is around 390 Mbytes >> and decompressed it is about 5.5 Gbytes. So far, only F33 is throwing the >> timeout; other targets are successfully building the package. But I have no >> idea how close to a similar problem those other targets may be. >> >> Is there a way to increase the Copr builder timeout? > > > I ran into the same problem with vtk. I'm sure there's a way to do it on the > front end, but I clicked the rebuild option and there was a box to change the > default timeout from 18000 seconds (5 hours). You can set it to a max of 20 > hours. > > Thanks, > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
f29 bootloader changes / raid1 installs + efi
Hello, I am curious if any of the upcoming changes also solve the following issue: Workstation setup where you want full disk redudancy with raid1 and efi boot. * Setting up the OS to be placed on raid1 leaves you with multiple options (mdadm/btrfs/...) * Setting up EFI only makes one of those disks bootable * The EFI partition contians the grub2-efi.cfg file which gets updated every time a new kernel is installed. -> Currently the efi partition content (specifically grub2-efi.cfg) has to be synced manually to the 2nd disk in the raid1 set, to allow booting from the 2nd disk in case of disk failure of the first disk that contains the original EFI partition that is mounted under /boot/efi. The only potential workaround to avoid manual syncing i know of currently, is to not use EFI but rather legacy bios boot. - Rudolf Kastl ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QTRRMZU6PORBTGSATUFUIEUKY7QYA3PV/
Re: COPR strategy
Hey, I am currently maintaining llvm trunk and mesa git snapshot repos for f25 and f26 at: https://copr.fedorainfracloud.org/coprs/che. One thing i would love to see is the ability to have a buildrepo and a release repo and beeing able to sync from build to release once a complete buildchain successfully built. More thorough description of the problem and a possible solution: * you have a dependency chain of 3 packages to build * you need to regen repos after each package because the next package in the tree depends on the first one. (like clang on llvm) * then after building the first 2 packages the 3rd package breaks ... you end up with a broken dep chain in the repo. Now a workaround would be to do scratch builds first and then final repo builds. But e.g. for llvm (only the llvm library) that means... over 100 minutes buildtime using 4 builders (32bit / 64bit for 2 distro versions). What i would love to see is to be able to build in one repository and then send (copy/rsync whatever) the built chain over to a release repository. This way also testing is possible before pushing the stuff to consumers. kind regards, Rudolf Kastl 2017-08-22 17:15 GMT+02:00 Kamil Dudka : > On Tuesday, August 22, 2017 5:03:06 PM CEST Michal Novotny wrote: > > On Tue, Aug 22, 2017 at 4:40 PM, Kamil Dudka wrote: > > > On Tuesday, August 22, 2017 1:51:44 PM CEST Michal Novotny wrote: > > > > Hey Kamil, > > > > > > > > On Tue, Aug 22, 2017 at 12:07 PM, Kamil Dudka > wrote: > > > > > On Tuesday, August 22, 2017 9:04:24 AM CEST Matthias Runge wrote: > > > > > > - the ability to directly upload srpms; that is, one can store > spec > > > > > > > > > > > > files etc. on the local machine. I'm undecided, if integrating > a > > > > > > distgit on copr would solve any issues or would introduce more, > > > > > > like > > > > > > > > > diverging specs. > > > > > > > > > > Building packages from dist-git is already possible via 'copr > > > > > buildfedpkg'. > > > > > The problem is that the last time I tried, it only worked for the > > > > > > official > > > > > > > > Fedora branches. All attempts to build something from a > > > > > > private-kdudka-* > > > > > > > > branch failed with the well known "Could not find the dist from > branch > > > > > name" > > > > > failure of fedpkg. Unless arbitrary dist-git branches are > suported, > > > > > > the > > > > > > > > 'copr buildfedpkg' command is pretty useless. > > > > > > > > Actually, we already support arbitrary dist-git branches in COPR > > > > > > Sounds good. I wanted to check this: > > > > > > % copr buildfedpkg --branch private-kdudka-libcurl-nss --clone-url > > > https://src.fedoraproject.org/rpms/curl.git kdudka/tmp > > > > > > Build was added to tmp: > > > https://copr.fedorainfracloud.org/coprs/build/592748/ > > > > > > Created builds: 592748 > > > Watching build(s): (this may be safely interrupted) > > > > > > 16:20:56 Build 592748: importing > > > > > > But the task hangs indefinitely in the "importing" state. You can see > > > that > > > http://copr-dist-git.fedorainfracloud.org/per-task-logs/592748.log > still > > > grows with obvious periodicity. > > > > > > Am I doing anything wrong? > > > > Uh, not really. fedpkg was not installed on the production machine thus > the > > import was failing. > > Note that this is still slightly under development but it should > definitely > > work as a feature in > > any case. > > OK. Thank you for working on it! I am looking forward to use it one > day... > > > > Kamil > > > > > > > and we also aim > > > > to be able to build from any dist-git (at least being based on > > > > https://src.fedoraproject.org/rpms/dist-git). > > > > > > > > Currently we also support building from copr-dist-git in addition to > > > > > > Fedora > > > > > > > DistGit but > > > > we need to reflect that in our API and in copr-cli interface by > renaming > > > > the subcommand. > > > > (or providing the new generic one while keeping the old one for some > > > > > > time) > > > > > > > Then there is actually also the new rpkg client (based on pyrpkg > lib): > > > > https://src.fedoraproject.org/rpms/rpkg-client > > > > that you can use for launching COPR builds from any dist-git repo > being > > > > locally checked out. > > > > > > > > > Kamil > ___ > 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
Re: Self Introduction
the crash happens because of a collision with libeio which is in the fedora main repository. 2012/11/29 Rudolf Kastl > After yum install enlightenment running enlightenment_start makes it crash: > > enlightenment_start > E - PID=22138, valgrind=0 > /usr/bin/enlightenment: symbol lookup error: /usr/lib64/libedje.so.1: > undefined symbol: EIO_MONITOR_FILE_CREATED > > > 2012/11/29 Rudolf Kastl > >> Another comment: while you keep that repository up id really welcome if >> you could sign the packages in your private repo. >> >> >> >> 2012/11/29 Rudolf Kastl >> >>> Actually the baseurl provided in your paste does not work for me. >>> >>> here is the fixed entry: baseurl= >>> http://www.edmann.com/Enlightenment/repo/Fedora/$releasever/x86_64/RPMS >>> >>> >>> >>> 2012/11/29 Edward Mann >>> >>>> ** >>>> >>>> On , Tom Callaway wrote: >>>> >>>> On 11/27/2012 02:47 PM, Edward Mann wrote: >>>> >>>> I would like to be the maintainer for the Enlightenment e17 for Fedora. >>>> I am sending this e-mail to seek guidance and also a sponsor. Getting e17 >>>> on Fedora i will need to build and install the following packages eina - >>>> Core data structure library. >>>> >>>> In Fedora as "libeina" (I own it) >>>> >>>> eet - Data encode/decode and storage library. >>>> >>>> In Fedora as "eet" (I own it) >>>> >>>> evas - Canvas and scenegraph rendering library. >>>> >>>> In Fedora as "evas" (I own it) >>>> >>>> ecore - Core mainloop, display abstraction and utility library. >>>> >>>> In Fedora as "ecore" (I own it) >>>> >>>> embryo - Small Pawn based virtual machine and compiler. edje - Abstract >>>> GUI layout and animation object library. efreet - Standards handling for >>>> freedesktop.org standards. e_dbus - Dbus wrapping and glue layer >>>> library. eeze - Device abstraction library. elementary - Elementary, the >>>> widget set... emotion - Emotion, video and audio codec API... ethumb - >>>> EThumb, thumbnail generation library... eio - Eio, async I/O library... >>>> >>>> I don't think any of these are in Fedora, so they'd be a great place to >>>> start. Let me know if you need any changes to the four packages I own, >>>> once you get in the packager group, I'd be happy to let you comaintain >>>> them. >>>> >>>> ~tom >>>> >>>> == >>>> Fedora Project >>>> >>>> Thanks for the response Tom. I had searched the packages, however i >>>> realized i needed to go one more page in the package list to find those >>>> that you own. E17 currently needs all packages to be at the 1.7.2 release. >>>> The Enlightenment team plans on keeping them all at the same version number >>>> even if some packages have no changes. You probably already know this. >>>> >>>> >>>> >>>> I think i remember removing libeina when i installed my build of eina. >>>> If we can get libeina up to 1.7.2 then i will adjust the packages to look >>>> for libeina and not eina. >>>> >>>> I have all the packages up on my website >>>> http://www.edmann.com/Enlightenment/repo/Fedora/17/ >>>> >>>> Also i have the yum repo >>>> >>>> [Enlightenment] >>>> name=Enlightenment for Fedora $releasever >>>> baseurl= >>>> http://edmann.com/Enlightenment/repo/Fedora/$releasever/X86_64/RPMS >>>> enabled=1 >>>> metadata_expire=7d >>>> gpgcheck=0 >>>> [Enlightenment - Sources] >>>> name=Enlightenment SRPMS for Fedora $releasever >>>> baseurl=http://edmann.com/Enlightenment/repo/Fedora/$releasever/SRPMS >>>> enabled=1 >>>> metadata_expire=7d >>>> gpgcheck=0 >>>> >>>> Right now it's only for x86_64, i will build another vm and do i386 >>>> packages. Not sure if that will be needed, but people might come across it >>>> and want those. I will also do 18 beta as well. >>>> >>>> >>>> >>>> Do i need to make a bug request for each package or is that premature >>>> for me to do right now? >>>> >>>> >>>> >>>> Thanks >>>> >>>> >>>> >>>> >>>> -- >>>> devel mailing list >>>> devel@lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/devel >>>> >>> >>> >> > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
After yum install enlightenment running enlightenment_start makes it crash: enlightenment_start E - PID=22138, valgrind=0 /usr/bin/enlightenment: symbol lookup error: /usr/lib64/libedje.so.1: undefined symbol: EIO_MONITOR_FILE_CREATED 2012/11/29 Rudolf Kastl > Another comment: while you keep that repository up id really welcome if > you could sign the packages in your private repo. > > > > 2012/11/29 Rudolf Kastl > >> Actually the baseurl provided in your paste does not work for me. >> >> here is the fixed entry: baseurl= >> http://www.edmann.com/Enlightenment/repo/Fedora/$releasever/x86_64/RPMS >> >> >> >> 2012/11/29 Edward Mann >> >>> ** >>> >>> On , Tom Callaway wrote: >>> >>> On 11/27/2012 02:47 PM, Edward Mann wrote: >>> >>> I would like to be the maintainer for the Enlightenment e17 for Fedora. >>> I am sending this e-mail to seek guidance and also a sponsor. Getting e17 >>> on Fedora i will need to build and install the following packages eina - >>> Core data structure library. >>> >>> In Fedora as "libeina" (I own it) >>> >>> eet - Data encode/decode and storage library. >>> >>> In Fedora as "eet" (I own it) >>> >>> evas - Canvas and scenegraph rendering library. >>> >>> In Fedora as "evas" (I own it) >>> >>> ecore - Core mainloop, display abstraction and utility library. >>> >>> In Fedora as "ecore" (I own it) >>> >>> embryo - Small Pawn based virtual machine and compiler. edje - Abstract >>> GUI layout and animation object library. efreet - Standards handling for >>> freedesktop.org standards. e_dbus - Dbus wrapping and glue layer >>> library. eeze - Device abstraction library. elementary - Elementary, the >>> widget set... emotion - Emotion, video and audio codec API... ethumb - >>> EThumb, thumbnail generation library... eio - Eio, async I/O library... >>> >>> I don't think any of these are in Fedora, so they'd be a great place to >>> start. Let me know if you need any changes to the four packages I own, >>> once you get in the packager group, I'd be happy to let you comaintain them. >>> >>> ~tom >>> >>> == >>> Fedora Project >>> >>> Thanks for the response Tom. I had searched the packages, however i >>> realized i needed to go one more page in the package list to find those >>> that you own. E17 currently needs all packages to be at the 1.7.2 release. >>> The Enlightenment team plans on keeping them all at the same version number >>> even if some packages have no changes. You probably already know this. >>> >>> >>> >>> I think i remember removing libeina when i installed my build of eina. >>> If we can get libeina up to 1.7.2 then i will adjust the packages to look >>> for libeina and not eina. >>> >>> I have all the packages up on my website >>> http://www.edmann.com/Enlightenment/repo/Fedora/17/ >>> >>> Also i have the yum repo >>> >>> [Enlightenment] >>> name=Enlightenment for Fedora $releasever >>> baseurl= >>> http://edmann.com/Enlightenment/repo/Fedora/$releasever/X86_64/RPMS >>> enabled=1 >>> metadata_expire=7d >>> gpgcheck=0 >>> [Enlightenment - Sources] >>> name=Enlightenment SRPMS for Fedora $releasever >>> baseurl=http://edmann.com/Enlightenment/repo/Fedora/$releasever/SRPMS >>> enabled=1 >>> metadata_expire=7d >>> gpgcheck=0 >>> >>> Right now it's only for x86_64, i will build another vm and do i386 >>> packages. Not sure if that will be needed, but people might come across it >>> and want those. I will also do 18 beta as well. >>> >>> >>> >>> Do i need to make a bug request for each package or is that premature >>> for me to do right now? >>> >>> >>> >>> Thanks >>> >>> >>> >>> >>> -- >>> devel mailing list >>> devel@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/devel >>> >> >> > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Another comment: while you keep that repository up id really welcome if you could sign the packages in your private repo. 2012/11/29 Rudolf Kastl > Actually the baseurl provided in your paste does not work for me. > > here is the fixed entry: baseurl= > http://www.edmann.com/Enlightenment/repo/Fedora/$releasever/x86_64/RPMS > > > > 2012/11/29 Edward Mann > >> ** >> >> On , Tom Callaway wrote: >> >> On 11/27/2012 02:47 PM, Edward Mann wrote: >> >> I would like to be the maintainer for the Enlightenment e17 for Fedora. I >> am sending this e-mail to seek guidance and also a sponsor. Getting e17 on >> Fedora i will need to build and install the following packages eina - Core >> data structure library. >> >> In Fedora as "libeina" (I own it) >> >> eet - Data encode/decode and storage library. >> >> In Fedora as "eet" (I own it) >> >> evas - Canvas and scenegraph rendering library. >> >> In Fedora as "evas" (I own it) >> >> ecore - Core mainloop, display abstraction and utility library. >> >> In Fedora as "ecore" (I own it) >> >> embryo - Small Pawn based virtual machine and compiler. edje - Abstract >> GUI layout and animation object library. efreet - Standards handling for >> freedesktop.org standards. e_dbus - Dbus wrapping and glue layer >> library. eeze - Device abstraction library. elementary - Elementary, the >> widget set... emotion - Emotion, video and audio codec API... ethumb - >> EThumb, thumbnail generation library... eio - Eio, async I/O library... >> >> I don't think any of these are in Fedora, so they'd be a great place to >> start. Let me know if you need any changes to the four packages I own, >> once you get in the packager group, I'd be happy to let you comaintain them. >> >> ~tom >> >> == >> Fedora Project >> >> Thanks for the response Tom. I had searched the packages, however i >> realized i needed to go one more page in the package list to find those >> that you own. E17 currently needs all packages to be at the 1.7.2 release. >> The Enlightenment team plans on keeping them all at the same version number >> even if some packages have no changes. You probably already know this. >> >> >> >> I think i remember removing libeina when i installed my build of eina. If >> we can get libeina up to 1.7.2 then i will adjust the packages to look for >> libeina and not eina. >> >> I have all the packages up on my website >> http://www.edmann.com/Enlightenment/repo/Fedora/17/ >> >> Also i have the yum repo >> >> [Enlightenment] >> name=Enlightenment for Fedora $releasever >> baseurl= >> http://edmann.com/Enlightenment/repo/Fedora/$releasever/X86_64/RPMS >> enabled=1 >> metadata_expire=7d >> gpgcheck=0 >> [Enlightenment - Sources] >> name=Enlightenment SRPMS for Fedora $releasever >> baseurl=http://edmann.com/Enlightenment/repo/Fedora/$releasever/SRPMS >> enabled=1 >> metadata_expire=7d >> gpgcheck=0 >> >> Right now it's only for x86_64, i will build another vm and do i386 >> packages. Not sure if that will be needed, but people might come across it >> and want those. I will also do 18 beta as well. >> >> >> >> Do i need to make a bug request for each package or is that premature for >> me to do right now? >> >> >> >> Thanks >> >> >> >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Actually the baseurl provided in your paste does not work for me. here is the fixed entry: baseurl= http://www.edmann.com/Enlightenment/repo/Fedora/$releasever/x86_64/RPMS 2012/11/29 Edward Mann > ** > > On , Tom Callaway wrote: > > On 11/27/2012 02:47 PM, Edward Mann wrote: > > I would like to be the maintainer for the Enlightenment e17 for Fedora. I > am sending this e-mail to seek guidance and also a sponsor. Getting e17 on > Fedora i will need to build and install the following packages eina - Core > data structure library. > > In Fedora as "libeina" (I own it) > > eet - Data encode/decode and storage library. > > In Fedora as "eet" (I own it) > > evas - Canvas and scenegraph rendering library. > > In Fedora as "evas" (I own it) > > ecore - Core mainloop, display abstraction and utility library. > > In Fedora as "ecore" (I own it) > > embryo - Small Pawn based virtual machine and compiler. edje - Abstract > GUI layout and animation object library. efreet - Standards handling for > freedesktop.org standards. e_dbus - Dbus wrapping and glue layer library. > eeze - Device abstraction library. elementary - Elementary, the widget > set... emotion - Emotion, video and audio codec API... ethumb - EThumb, > thumbnail generation library... eio - Eio, async I/O library... > > I don't think any of these are in Fedora, so they'd be a great place to > start. Let me know if you need any changes to the four packages I own, > once you get in the packager group, I'd be happy to let you comaintain them. > > ~tom > > == > Fedora Project > > Thanks for the response Tom. I had searched the packages, however i > realized i needed to go one more page in the package list to find those > that you own. E17 currently needs all packages to be at the 1.7.2 release. > The Enlightenment team plans on keeping them all at the same version number > even if some packages have no changes. You probably already know this. > > > > I think i remember removing libeina when i installed my build of eina. If > we can get libeina up to 1.7.2 then i will adjust the packages to look for > libeina and not eina. > > I have all the packages up on my website > http://www.edmann.com/Enlightenment/repo/Fedora/17/ > > Also i have the yum repo > > [Enlightenment] > name=Enlightenment for Fedora $releasever > baseurl= > http://edmann.com/Enlightenment/repo/Fedora/$releasever/X86_64/RPMS > enabled=1 > metadata_expire=7d > gpgcheck=0 > [Enlightenment - Sources] > name=Enlightenment SRPMS for Fedora $releasever > baseurl=http://edmann.com/Enlightenment/repo/Fedora/$releasever/SRPMS > enabled=1 > metadata_expire=7d > gpgcheck=0 > > Right now it's only for x86_64, i will build another vm and do i386 > packages. Not sure if that will be needed, but people might come across it > and want those. I will also do 18 beta as well. > > > > Do i need to make a bug request for each package or is that premature for > me to do right now? > > > > Thanks > > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fesco membership policies
how about supporters like e.g. the irc support group? * technical background: yes, * have to suffer the sins of others: yes, * have a different point of view on various changes and ideas: yes, * are closer to the user base and their common problems: yes kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned: vpnc
2011/9/4 Christian Krause : > Hi David, > > On 08/31/2011 09:37 AM, Woodhouse, David wrote: >> On Wed, 2011-08-31 at 02:42 +0200, Christian Krause wrote: > >>> I have looked at the list of open bugs for vpnc and it looks like that >>> there are a couple of packaging issues, some problems with the >>> vpnc-script and some other issues which may require some upstream >>> help. >> >> Are there any problems with vpnc-script that *aren't* fixed by simply >> updating to the one in >> http://git.infradead.org/users/dwmw2/vpnc-scripts.git ? > > I have looked at the git repository and I'm unsure about one change: > > The commit: > http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/ea98b094e8f75fcd696db81bc6c5160dc67b4e4f > > > seems to fix https://bugzilla.redhat.com/show_bug.cgi?id=693235 > (negative MTU) in case "ip route ... " does not report the mtu. > > However, at least on my systems, "ip route ..." does never return the > mtu in its output and so the script will always use the hard-coded > fallback value 1412 as MTU. > > The proposed patch attached to the bug report ( > https://bugzilla.redhat.com/attachment.cgi?id=515615 ) uses a different > approach: > It extracts the actual interface via "ip route" and retrieves the MTU > via "ip link show $interface". > > What do you think about this patch? What does upstream think about the patch? > > > Best regards, > Christian > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
mutter vs mutter-mbl
Heyyas, Actually since ever mutter conflicts with mutter-mbl. Isnt it about time to get that conflict resolved? Technically it shouldnt be a big issue to package one of them in a non conflicting way. I think it might be good for our users to be able to install both components in parallel to be able to test/try them on a single install. What is the plan about that? Is a merge going to happen sometime soon? Is there any plan to get rid of the conflicts? kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
f16 alpha rc5 softraided /boot
Hello! below are two bugs for getting softraided (raid level 1) /boot to work properly with f16 alpha rc5: https://bugzilla.redhat.com/show_bug.cgi?id=732164 https://bugzilla.redhat.com/show_bug.cgi?id=732441 left to test: * softraiding two disks as mirror and putting an lvm on top... then put /boot into logical volume that sits on a softraid. in theory that should work too. didnt have time to try it yet * checking if anaconda writes the bootloader to both disks (last time i tried it didnt) kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boot.fedoraproject.org (bfo)
2011/8/11 Vratislav Podzimek : > On Thu, 2011-08-11 at 06:46 -0700, John Reiser wrote: >> On 08/11/2011 05:26 AM, Vratislav Podzimek wrote: >> > On Wed, 2011-08-10 at 18:26 +0200, Rudolf Kastl wrote: >> >> >> Last time i tried an install via bfo it didnt really select mirrors >> >> close to me. (i think for the install it didnt use a mirrorlist but >> >> instead a hardcoded repo by default) Is this still the case? >> >> > AFAIK, mirrors are choosed by MirrorManager running on >> > mirrors.fedoraproject.org which is used by yum and it's repos' >> > configuration. It's quite easy to find out which repos' urls are used >> > during the installation. >> >> Anaconda itself does not disclose the identity of any mirrors it uses, >> and after the install there is no record of which mirrors were used. >> Please specify exactly what you use to identify the specific mirrors. > > What I meant is that you can get repos' configuration (at least for > default repos) during installation: > 1) switch to shell (with Ctlr+F2) > 2) ls /etc/anaconda.repos.d/ > 3) cat SOME_REPO_CONFIG_FILE > > When I use this for 'fedora.repo' file I can see following line: > mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch > > which reveals the fact that yum (ran during the installation) will use > MirrorManager running on mirrors.fedoraproject.org (which is the same as > in an already installed system). > >> >> > But I doubt there are any different from urls >> > used everywhere else. >> >> The tail of the path (the filename and last few directory names) is certainly >> the same, but each mirror is free to place the tree arbitrarily in its >> filesystem, and many do. > > As I mentioned before, the MirrorManager is responsible for returning > the right mirrorlist already sorted out from the best mirror to the > worst one (see [1] if you are interested). You can test it by entering > mirrorlist URL into your web browser. > > So I really doubt it's somehow specific for the bfo. > Vratislav Podzimek well then it isnt anymore. kind regards, Rudolf Kastl > > [1] https://fedorahosted.org/mirrormanager/wiki > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
boot.fedoraproject.org (bfo)
Hello, A bit of (hopefully) constructive feedback. It might help with testing and adoption of fedora if the rcs and alpha releases are made available in the bfo setup. Actually within the "experimental" folder there is only a tc1 of f15 currently. Potential ideas for bfo: * keep the "experimental" option more up to date in the future. * while simple to install make the lkrn available in a ready to use rpm Last time i tried an install via bfo it didnt really select mirrors close to me. (i think for the install it didnt use a mirrorlist but instead a hardcoded repo by default) Is this still the case? kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
2011/6/14 Rahul Sundaram : > On 06/14/2011 03:15 PM, Rudolf Kastl wrote: >> From experience... i prefer having two tools available atleast to do >> every single job (especially when they exist) because then i have an >> easy fallback if one fails. Having upstart installed on rawhide during >> the f15 rawhide cycles was quite helpful to work around boot bugs on >> the fly without having to debug stuff or ending up with a nonbooting >> system (which makes it hard to dig up ml threads with workarounds, or >> up or downgrading packages). As long as someone maintains it i see no >> reason to exclude upstart completly from the repos. > > What do you about glibc bugs? Do you want to get them fixed or > include alternatives? its been many years since i have seen a glibc bug that makes my system completly unbootable. i have had various issues during the last devel cycle where my system wouldnt boot anymore and upstart was a good shorttime fallback. having an alternative doesent mean that bugs should be covered instead fixed. i never proposed this and i am not sure why you start off like that on me. >Having alternatives for each of the core > components is a costly affair. it isn't just about maintaining > upstart. It is also having to deal with two different type of init > configuration scattered across the system, differences in handling many > things including /etc/iniittab and /etc/fstab, having to maintain init > scripts or upstart configuration files in all the different packages in > addition to the systemd unit files and testing them regularly in the > development cycle to ensure that changes we make for systemd doesn't > impact negatively on upstart and so on. This is just silly. > We have to draw the line somewhere I never proposed having alternatives for each of the core systems either... There is already a viable alternative that works. inittab contains atm exactly one line... the one with the default runlevel... and /etc/fstab can be parsed differently if there are changes. Also i do not understand the Argument with the unit files... they are systemd related. upstart isnt affected. Since upstart isnt installed by default anyways it also doesent matter for "critical path". Got a hard time to follow your argumentation there. SystemV init scripts are already present and work quite well aswell. > This is just silly. Not commenting that. > We have to draw the line somewhere Draw your line ;) kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fed-Devel] Re: SYSTEMD: Give us a option for upstart
2011/6/13 Kevin Kofler : > Reindl Harald wrote: >> and even on a new setup this should be a decision of the user >> at the very beginning what init-system he wants to us > > No, the choice of this kind of core under-the-hood system components should > be a decision of the distribution. To the user, it should be only an > implementation detail. To the software on the distribution, it should matter > that they can rely on the core system components being what they are and not > have a user replace something as central as the init system. > > I think it makes no sense whatsoever to even OFFER upstart in F15+ as we are > doing. I don't see any valid reason why you'd use it over systemd. From experience... i prefer having two tools available atleast to do every single job (especially when they exist) because then i have an easy fallback if one fails. Having upstart installed on rawhide during the f15 rawhide cycles was quite helpful to work around boot bugs on the fly without having to debug stuff or ending up with a nonbooting system (which makes it hard to dig up ml threads with workarounds, or up or downgrading packages). As long as someone maintains it i see no reason to exclude upstart completly from the repos. kind regards, Rudolf Kastl rhce rhca rhcss rhcx rhci Red Hat Inc. > > You complain about some bugs in systemd, those should be reported as bugs > and fixed. > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
autocc on review requests in bugzilla doesent work anymore.
Heyyas, Actually since my mailbox was filled recently and mail bounced for a short time period i do not get any review-request mails anymore from bugzilla. Can someone actually check the autocc on it? Other mails from bugzilla arrive (again). kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
meego session (fedora netbook) broken in rawhide
After installing the complete stack yesterday and trying to login i figured that it doesent work in the current state. Havent deeply analyzed it but the first errors in the logs are related to consolekit [00.67] [11545] user "rkastl", tty #2, session "/usr/bin/mutter --sm-disable" [00.014231] [11545] Error: Unable to open session with ConsoleKit: org.freedesktop.CkConnector.Error: Unable to open session: Rejected send message, 3 matched rules; type="method_call", sender=":1.285" (uid=501 pid=11545 comm="/usr/sbin/uxlaunch) interface="org.freedesktop.ConsoleKit.Manager" member="OpenSessionWithParameters" error name="(unset)" requested_reply=0 destination="org.freedesktop.ConsoleKit" (uid=0 pid=1857 comm="/usr/sbin/console-kit-daemon)) [00.014231] [11545] Error: Unable to open session with ConsoleKit: org.freedesktop.CkConnector.Error: Unable to open session: Rejected send message, 3 matched rules; type="method_call", sender=":1.285" (uid=501 pid=11545 comm="/usr/sbin/uxlaunch) interface="org.freedesktop.ConsoleKit.Manager" member="OpenSessionWithParameters" error name="(unset)" requested_reply=0 destination="org.freedesktop.ConsoleKit" (uid=0 pid=1857 comm="/usr/sbin/console-kit-daemon)) not sure if it is already reported or worth reporting with the current rawhide state (or any changes already pending fixing it) kind regards, Rudolf Kastl p.s. i hope that at some point mutter-mbl is either obsolete because the changes are finally upstream or atleast properly packaged so it is parallel installable. this issue is present since ages now and in fedora 15 it will lead to conflicts with the gnome-shell setup. both sessions wont be parallel installable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
issues with duplicate entries in /etc/mtab
Hello! As you can see with a current rawhide install you might end up with filesystems that have multible entries in mtab: http://fpaste.org/Z7Ne/ df also outputs the filesystems redundantly. If the system is to be changed and mtab is going to be removed all the tools writing to and reading from it have to be looked at as well i guess. I am not sure if the right people are already aware of the issue. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Feature - convert as many service init files as possible to the native SystemD services
2010/11/23 Michał Piotrowski : > W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski > napisał: >> We can create a list of all scripts in wiki and >> maintainers of individual packages would indicate that they want to >> convert scripts themselves. > > How can I get information about all packages that provides init scripts? > > When I do > rpm -qf /etc/init.d/* > I get only information about already installed packages. Any magic > switch to get informations about all packages from rpm database? no because only installed packages are part of the rpmdb. you could do yum install '/etc/init.d/*' then you have all the material to convert ;) kind regards, Rudolf Kastl > > Best regards, > Michal > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
boot.fedoraproject.org default repo on installation
Heyyas. I actually gave boot.fedoraproject.org a testrun and i realized that by default a repository called "installation" is selected with a static repo url. instead i have actually figured that selecting the usual standard fedora repositories work aswell and they point to the mirrorlist instead. Why is a seperate installation repo selected by default? kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request for intel driver update in rawhide
2010/11/9 Adam Jackson : > On Tue, 2010-11-09 at 08:00 -0600, Jason L Tibbitts III wrote: >> >>>>> "RK" == Rudolf Kastl writes: >> >> RK> http://koji.fedoraproject.org/koji/packageinfo?packageID=7794 >> RK> guess you pulled that somewhere else. >> >> fedpkg co xorg-x11-drv-intel; less xorg-x11-drv-intel/*spec > > 2.13.901 wasn't built yet because it required waiting for a libdrm > update. Should have that pushed out today. > > - ajax thanks ajax! kind regards, Rudolf Kastl > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: request for intel driver update in rawhide
2010/11/9 Jason L Tibbitts III : >>>>>> "RK" == Rudolf Kastl writes: > > RK> Hello, I wanted to point out that about a month and a half ago intel > RK> released a new driver version 2.13.0. Could we please have an update > RK> in rawhide? > > Currently rawhide seems to be at 2.13.901, a development version past > the one you are requesting. not really: http://koji.fedoraproject.org/koji/packageinfo?packageID=7794 guess you pulled that somewhere else. kind regards, Rudolf Kastl > > - J< > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
request for intel driver update in rawhide
Hello, I wanted to point out that about a month and a half ago intel released a new driver version 2.13.0. Could we please have an update in rawhide? kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
2010/10/13 Jesse Keating : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/13/10 2:04 AM, Rudolf Kastl wrote: >> Let me clarify. On the criteria page i read (have to dig out the link) >> it said that bugs regarding having /boot on softraid are ignored at >> this point, so no i didnt bother filing a report. sounded like a known >> issue. >> As for the test day. Really, i always try to help out on test days but >> i guess i was too busy/on the road when this one happened. Manually >> setting up softraids with mdadm works like a charm btw. What is >> problematic is setting up the correct partition layout manually with 2 >> drives because anaconda moves around and reenumberates the partitions >> when you add new ones. (that drove me to insanity.) also note that >> using kickstart works like a charm aswell. >> >> in the notes i only found: >> http://fedoraproject.org/wiki/Common_F13_bugs#Booting_from_an_mdraid_mirror_without_a_separate_.2Fboot_fails >> >> Atleast on the f12 install this also failed with a seperate boot. I >> am going to keep my eyes open for f14 and doing an install with the >> current f14 state soon to see which of those issues is still left and >> file appropriate reports regarding the open issues. I am really >> curious also if it will automatically make both disks of the mirror >> setup bootable (writing grub to both mbrs). >> > > Ok, so what you're saying is, that the specific case of having /boot on > softraid didn't work for you. I may have missed that clarification in > your first email. I do find it odd because I constantly test scenarios > where /boot is a small mirror and / is a large stripe and it seems to > work every time for me, often starting from blank disks. I'll test that > scenario again soon, maybe there is something I'm doing that you're not, > or vice versa? hmm could be. actually what i do is i create 2 partitions on each disk ( for /boot and the rest) and then i softraid each pair and put lvm on top of the non /boot md of course due to the limitations of legacy grub (raid 10 would be faster but... i like the lvm functionality). All raid setups are simple mirrors with 2 disks. I already had the trouble that the partition enumberation would change numbers and order during creating the partitions (to workaround that i precreated the partitions before starting the installer). after completing an install like that the system refused to boot (as far as i remember when it was supposed to read and handle the initrd.) i was assuming that it maybe doesent have the raid modules loaded or not available in the initramfs, but this is just a guess, i cannot remember really. what succeeded was... installing the os on one disk using lvm (/boot / /home swap). creating the mdraid with missing instead the first disk on the second physical hds partitions. then adding the md devices to the vg and pvmoving the first physical disk out... later adding the disk in the "missing" slot of the md and also mirror raiding the /boot partition followed by an update of the initramfs. kind regards, Rudolf Kastl > > - -- > Jesse Keating > Fedora -- Freedom² is a feature! > identi.ca: http://identi.ca/jkeating > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAky1e6IACgkQ4v2HLvE71NWecQCfYDJpbd3O69EMAKUGJZ6nM2dh > 56QAn1uSq+WNs9NzspcWU1zV/EGGwIXf > =MPSn > -END PGP SIGNATURE- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging dwm
2010/10/13 Petr Sabata : > Hey, > > I've been thinking about packaging dwm [1] since we already ship dmenu and > dzen2. I wonder if anybody would be interested in this fine window manager > (except for me). > > The problem here: dwm is configured solely in C and has to be recompiled > every time a user wants to change their settings (appearance, behavior, > shortcuts, etc). In my opinion, we could do it like this: > > - install a Fedora preconfigured version along with dwm sources > - copy its configuration (C header file) to some fixed location for > user to customize > - provide a script to recompile dwm locally using the local > configuration file > > Would this be acceptable for a window manager in Fedora? Would anybody be > interested in this? :) Well i have packages here of dwm and wmii. Personally i like both of them but the default configuration has the problem that the default key for triggering functionality doesent work in all keyboard mappings. wmii is probably easier to package. if you need help with that drop me an email. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
2010/10/12 Jesse Keating : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/12/10 7:20 AM, Rudolf Kastl wrote: >> I am doing the same setup, nice to see someone else with those >> requirements. actually without kickstart setting up softraid in >> anaconda was broken (try it manually without precreated partitions... >> it will drive you insane). out of the box booting didnt work when >> /boot was on a mirror raid and the mbr wasnt cloned either. not that >> great of an out of the box experience. i had those issues in f11 f12 >> and f13. >> but hey... instead of redundancy having some colored automatically >> selected flags and languages is probably more important after all. > > Have you been participating in the test days and filing bugs? We've > done many raid setups, it's part of our release criteria, and we haven't > ran into the issues you seem to be describing above. Let me clarify. On the criteria page i read (have to dig out the link) it said that bugs regarding having /boot on softraid are ignored at this point, so no i didnt bother filing a report. sounded like a known issue. As for the test day. Really, i always try to help out on test days but i guess i was too busy/on the road when this one happened. Manually setting up softraids with mdadm works like a charm btw. What is problematic is setting up the correct partition layout manually with 2 drives because anaconda moves around and reenumberates the partitions when you add new ones. (that drove me to insanity.) also note that using kickstart works like a charm aswell. in the notes i only found: http://fedoraproject.org/wiki/Common_F13_bugs#Booting_from_an_mdraid_mirror_without_a_separate_.2Fboot_fails Atleast on the f12 install this also failed with a seperate boot. I am going to keep my eyes open for f14 and doing an install with the current f14 state soon to see which of those issues is still left and file appropriate reports regarding the open issues. I am really curious also if it will automatically make both disks of the mirror setup bootable (writing grub to both mbrs). kind regards, Rudolf Kastl kind regards, Rudolf Kastl > > - -- > Jesse Keating > Fedora -- Freedom² is a feature! > identi.ca: http://identi.ca/jkeating > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAky0eG4ACgkQ4v2HLvE71NV3hACgq6Wuii5Vue4Kg7ZI4hkfFJ5J > qGMAoJ3/hd/jzljK+OUlgE/SbR9l1iaz > =lxeC > -END PGP SIGNATURE- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
2010/10/11 Gilboa Davara : > On Mon, 2010-10-11 at 12:09 -0400, Jon Masters wrote: >> On Mon, 2010-10-11 at 17:39 +0200, Gilboa Davara wrote: >> >> > Comparing the Ubuntu 10.04 DVD installer (which I use a couple of weeks >> > ago) to Fedora 13 DVD installer is like comparing the Cessna to a Boeing >> > 747. >> > Sure, both can accomplish the same task. Read: transporting people from >> > one airport to another, but lets see you try transporting 400 peoples >> > from London to NY using a Cessna... >> > >> > The same logic applies to the Ubuntu installer: As long as you require a >> > fairly basic -desktop- configuration (Read: No fancy storage, no LVM, no >> > fancy setup source [nfs, dvd, http], -very- basic encryption, standard >> > software set and repository selection, etc), the Ubuntu installer is a >> > great tool, but once you need something complex, you're screwed. >> >> That's all true. I've found the Ubuntu installer looks /very/ polished >> and nice for very common install cases, but I always use LVM on every >> install that I do, and last time I did a VM install of Ubuntu, I had to >> switch to a VT and get LVM sorted on the command line. Not super user >> friendly as compared with Anaconda. Other installers were even more of a >> joke doing this stuff. Tried doing LVM on Gentoo? :) Things like LVM and >> VNC do really matter, and not just for "Enterprise" users. You don't >> need to use LVM w/wo RAID, you can just do bare partitions if you don't >> care about being able to do anything useful with your disks at all :) > > Amen to that. > Given the absurdly cheap price of HD these days, I usually opt for LVM > over software RAID1 / RAID5 on each and every workstation machine I > install. > Achieving the same using the Ubuntu installer would have required a lot > of manual mdadm and lvm pv/vg/lv** commands. (Let alone their basic disk > partitioning tool) > > ... In their race for Joe-six-pack and Apple like polish, Ubuntu gave up > on many Linux core capabilities. Hopefully Fedora will -not- follow > suite. Hello, I am doing the same setup, nice to see someone else with those requirements. actually without kickstart setting up softraid in anaconda was broken (try it manually without precreated partitions... it will drive you insane). out of the box booting didnt work when /boot was on a mirror raid and the mbr wasnt cloned either. not that great of an out of the box experience. i had those issues in f11 f12 and f13. but hey... instead of redundancy having some colored automatically selected flags and languages is probably more important after all. kind regards, Rudolf Kastl > > - Gilboa > > - Gilboa > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ogre3d lagging behind more than half a year
heyyas, ogre3d, one of the most important 3d engines we have in fedora is already lagging behind over half a year in rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=576286 would be nice to see it finally updated atleast in rawhide so it can go atleast in f15... which means we are only 1 year behind by then. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter -> 1.3
2010/8/31 pbrobin...@gmail.com : > On Tue, Aug 31, 2010 at 8:16 PM, Colin Walters wrote: >> On Tue, Aug 31, 2010 at 2:57 PM, pbrobin...@gmail.com >> wrote: >>> On Tue, Aug 31, 2010 at 7:52 PM, Colin Walters wrote: >>>> Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 >>>> (master) branch. I've tested GNOME Shell and quadrapassel, feel free >>>> to CC me for other fallout. >>> >>> This will break meego. >> >> Okay, is there a schedule for meego supporting 1.3? That would give >> guidance about creating a temporary clutter-1.2 package or not. > > It not in MeeGo 1.1 and after that there's no published schedule. So > for 1.2 (or what ever its called) which should come around F-15 I > suspect it might happen but I've no idea. I also don't know about > backwards compatibility between the releases. > > Peter > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > you cannot install both gnome-shell and meego at once since a whole while because of: Error: mutter-mbl conflicts with mutter it would be really nice to have that conflict sorted out after ages now. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
2010/8/25 Adam Williamson : > On Tue, 2010-08-24 at 22:41 +0100, Matthew Garrett wrote: >> On Tue, Aug 24, 2010 at 11:52:45AM -0700, Adam Williamson wrote: >> >> > FWIW, I'm with Jon and Adam on this one. I just don't see how not having >> > an MTA by default is a win, except in disk space terms, and it takes up >> > a tiny amount of disk space (especially if we pick a lighter-weight one >> > than sendmail to be the default). I think it makes sense to keep one, >> > for all the good reasons they cited. >> >> Shipping an MTA by default just gives developers the expectation that if >> they pass something to sendmail then it'll be read by a human. Since >> that's plainly untrue we should stop doing it and replace it with >> something that's actually useful. > > By all means change the default MTA to something that 'works out of the > box' in some way, yes. That'd be great, and much more of a feature than > 'let's just remove it'. as i wrote before i am not religous at all about an mta itsself but rather about proper working notifications with history for raid failure and logwatch. so a clear +1 here. kind regards, rudolf kastl > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
2010/8/24 pbrobin...@gmail.com : > On Tue, Aug 24, 2010 at 9:36 AM, Rudolf Kastl wrote: >> my desktop runs on software mirror raid below an lvm. not for >> performance but for data recovery reasons. mdmonitor does mail >> notification. will this be fixed? how about logwatch, it is really >> useful to have to get an overview what happened on the system in a >> neat summary. also handy for desktops but just not recognized and >> presented in an end user compatible way. just my opinion. > > Neither of those need to run a MTA locally to work, you just need to > point them to a mail server, even then they need to be configured to > send the mail to something other than root anyway. Removing the > default MTA won't change these out of the box and if you still want to > run a local MTA its as simple as selecting it during install. I use > all of the above on dozens of servers and none of them run a mail > server locally. well yeah i am well aware of that and yup i can set that up i am just curious if i am the only one that prefers to have local delivery available for that kinda setups. i agree that local root notification isnt helpful for a datacenter. i also agree that /etc/aliases has to be adjusted for making the logwatch stuff for end users useful and the user would also need to have the default mail client preconfigured to have any out of the box use for it. but if you have a desktop/workstation that is standalone there is no such thing as an external mail server for raid failure notifications that makes any sense. i mean do you want to be dependent on a working networking to be notified of raid failures in an obvious way? i am not argueing for keeping the default mta necasserily, but as a user id expect that if i select raid setup in a clicky installer that the system is preconfigured in a by default useful manner. that includes obvious ways for notifying me about raid failure. the current functionality of mdmonitor requires an email address to be set. maybe for that kinda stuff using our desktop notification system would be something useable (if you want to discuss that please open a seperate thread though... i dont wanna hijack this one). > > Peter > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
2010/8/24 Lennart Poettering : > On Tue, 24.08.10 12:56, Mike McGrath (mmcgr...@redhat.com) wrote: > >> >> On Tue, 24 Aug 2010, Adam Williamson wrote: >> >> > On Tue, 2010-08-24 at 12:10 -0500, Mike McGrath wrote: >> > >> > > People like you and me would opt-in. (well I would on some hosts) >> > > because >> > > we know what we're doing. Expert eyes get a look at it before it's >> > > forced >> > > onto our users, who are already leaving in leaps and bounds. >> > >> > Again, Pulse/PolypAudio seems to suggest that this is not the case. Why >> > didn't expert eyes who knew what they were doing migrate to that before >> > it become default? Or, alternatively, if the expert eyes which knew what >> > they were doing did migrate, why didn't they catch the bugs that others >> > encountered when it became default? >> > >> >> If us experts aren't even willing to opt-in in modest enough numbers to >> test it, why on earth would we force it on people at all? > > Well, here's are two simple facts for you: > > 1) if things are not used they tend to have bugs > 2) if things have bugs they are not used i am pretty sure that matches with most peoples opinion. infact thats why i am personally a rawhide user where i expect to have the newest things first (though it would be nice of the maintainer did do some basic tests himself to ensure atleast a working system for him personally before he pushed it into rawhide as default) to be able to really test it before i have to support people in #fedora with actually less technical expertize. change management is usually not about things that go wrong but about things that can go wrong. aka proper testing and planning before having "live/production" systems. it really wouldnt have hurt to test out the "complete system" means also all the raised potential issues on the checklist you do not feel responsible for as systemd maintainer. while everything might look shiny from one single point of view, there are definitely more povs. and while you personally dont care about some technologies we have like e.g. iscsi and alot others that were named... they might be critical to others. what i miss a bit personally is simply seeing potential implications for the users that are not capable of switching back to something else because they lack the expertize. or do not understand some wierd workarounds published somewhere to get stuff working because there wont be many how tos when the new system will go live. maybe trying to think from the perspective of a potential user when it is about a release would be a good approach. i am really curious what all turns out to be broken in the end... and no matter which systems fault it is. if it is coming up because of a too quick change i will definitely blame the process and the lack of testing/time to get things straight. That said, thanks for your effort in trying to improve a system. > > Acknowledging this: if you want to innovate you have no other option > than pushing things to the people, and then fix what breaks. but pushing them to end users vs experienced people first and give them enough time to report their problems is the key difference. > > And if you never are willing to pass something to the users before it is > 100% stable and tested, then it will never be 100% stable and tested, > and you simply stop to innovate. But that wouldn't be Fedora anymore > then. software is never 100% done or bugfree. but it appears to me you have a rather narrow view of only focussing your single system. but that system has to properly interact with other systems... no matter which side is to blame. > > And I think so far things went really well with systemd, even though > this discussion might create the impression it didn't. no it doesent at all. it does create the impression that some people would rather have a better change management for such critical components than what it currently appears to be. like stated above... change management is not about what happens or about gut feeling or confidence... it is about risk management. in reality every non technical user wont care if it is systemd or component xyz which is to blame. if it doesent work it doesent work... but especially if it worked before they wont see any improvement just a regression. if a simple text editor fails it is one thing. if a kernel fails you can still boot an old one (after you figure out how to display the grub menu...) but if an init system fails it doesent boot and the conclusion would in most cases probably be that you just install something else if you dont have enough skills to actually get it to work somehow or analyze the problem. Rudolf - also working for Red Hat, Inc. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)
2010/8/24 Miroslav Lichvar : > On Mon, Aug 23, 2010 at 11:06:32PM -0400, Bill Nottingham wrote: >> SERVICE HANDLING >> - Running 'chkconfig <(null)|on|off>' on a service managed by systemd >> will return the correct code/perform an appropriate action. > > Also, if chkconfig --add called "systemctl enable" when the sysv > script is enabled, most of the current scriptlets probably wouldn't > need any changes. The status of systemd and sysv services would be > required to stay in sync though. keeping compatibility to chkconfig is in my opinion a key requirement to really find acceptance as a replacement. kind regards, Rudolf Kastl > > -- > Miroslav Lichvar > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
my desktop runs on software mirror raid below an lvm. not for performance but for data recovery reasons. mdmonitor does mail notification. will this be fixed? how about logwatch, it is really useful to have to get an overview what happened on the system in a neat summary. also handy for desktops but just not recognized and presented in an end user compatible way. just my opinion. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
2010/8/23 drago01 : > On Mon, Aug 23, 2010 at 11:22 PM, Mike McGrath wrote: >> On Mon, 23 Aug 2010, Bill Nottingham wrote: >> >>> Mike McGrath (mmcgr...@redhat.com) said: >>> > > My concern with this line of thinking is that you're asking us to >>> > > quantify >>> > > the unknown unknown, and define a time period of testing which is >>> > > 'long enough' for us to catch all the unknown unknowns. This seems >>> > > impractical, in as much as it doesn't give us any clear criteria to >>> > > define >>> > > success with. >>> > >>> > It's just risk management. I think we'd be better off acknowledging there >>> > are unknown unknowns and try to mitigate them. >>> >>> Sure, but when you say 'we should hold off X period of time' in order to >>> mitigate unknown unknowns, how do you define 'X'? How do you know when it's >>> ready? All I'm seeing are appeals to gut feelings. We can all say that 'more >>> time == more testing', but how do you claim 'good enough'? >>> >> >> I'd say one release is good enough for Fedora. >> >>> > ready. Unfortunately that's not the path we seem to be on. We unwisely >>> > seemed to declare it ready before anyone even saw it then we ignored what >>> > we didn't know as if we knew there were going to be no problems. The sad >>> > thing is that's such an easy fix by making brand new features for core >>> > components like this opt in, even if it's just for a single release. >>> >>> Having to support multiple boot paths for the system, making everyone >>> who gets odd bugs filed against kernel, dracut, plymouth, etc. triage them >>> isn't exactly an 'easy fix' - it *adds* complication to both paths. >>> >> >> I'd rather have multiple boot paths to choose from then only one boot path >> that is 2 months old. > > Being "2 months old" isn't a problem in itself ... bugs on the other > hand might be if they can't be fixed in time (this does not include > already fixed ones). it is, because 2 months for a critical system that is required for booting doesent provide enough time for testing at all. just note that after reinstalling systemd on rawhide it now boots again (the introduced bugs with linking havent been properly fixed by package updates but only with a reinstall since the workarounds published on the list didnt work for me at all) , but for some reason networkmanager didnt start automatically at boot. a problem found in a few seconds of looking at it. a change like that needs a longer testing period. i agree that fieldtesting is a really good way of finding alot bugs quickly and getting them fixed but that is really what rawhide is there for. Sorry for not beeing that optimistic after working with software for a rather long time. kind regards, Rudolf Kastl > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades
2010/8/11 "Jóhann B. Guðmundsson" : > On 08/11/2010 10:32 AM, Rudolf Kastl wrote: >> 2010/8/11 "Jóhann B. Guðmundsson": >>> On 08/11/2010 09:02 AM, Rudolf Kastl wrote: >>> >>> instead of trying to workaround the problem i actually tried to check >>> if a clean install of latest package would work properly with this >>> result: >>> >>> Installing : systemd-units-5-2.fc15.x86_64 >>> >>> This is far from being the latest packages ( the latest being 7.1 which is >>> in update ) and I do belive the bug you encountered got fixed in 6.1 and >>> with selinux-policy 3.8.8-10 which also is in update. >> wrong: >> http://koji.fedoraproject.org/koji/packageinfo?packageID=10477 >> >> the newer versions have only been built for f14 not rawhide. > > Given that this thread was for rawhide/F14 ( not rawhide/F15 ) and rawhide/f14 is pretty much interpretable as rawhide and/or f14 too... and i am on the devel not any test or other list. > everyone's being more or less pretty much focused on F14 at this point > dont be surprised rawhide being pretty much in an unusable state. i still expect the latest software to be available in rawhide atleast at the same time as in some branches, using rawhide longer than fedora exists because of that reason. for me it doesent make sense to report bugs for old software components... the alternative wouldnt be to use some branch but to build the system myself. > > I pinged Lennart and ask him to build the latest systemd for F15 untill > then I guess you have to replace the systemd packages with the ones in > F14 and exclude systemd for updates until the builds for F15 hit koji. i can build the software myself or exchange the init system ... the current state is still broken. thanks for pinging. kind regards, Rudolf Kastl > > JBG > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades
2010/8/11 "Jóhann B. Guðmundsson" : > On 08/11/2010 09:02 AM, Rudolf Kastl wrote: > > instead of trying to workaround the problem i actually tried to check > if a clean install of latest package would work properly with this > result: > > Installing : systemd-units-5-2.fc15.x86_64 > > This is far from being the latest packages ( the latest being 7.1 which is > in update ) and I do belive the bug you encountered got fixed in 6.1 and > with selinux-policy 3.8.8-10 which also is in update. wrong: http://koji.fedoraproject.org/koji/packageinfo?packageID=10477 the newer versions have only been built for f14 not rawhide. kind regards, Rudolf Kastl > > JBG > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades
instead of trying to workaround the problem i actually tried to check if a clean install of latest package would work properly with this result: Installing : systemd-units-5-2.fc15.x86_64 1/4 /var/tmp/rpm-tmp.sqw1k7: line 25: 19348 Segmentation fault (core dumped) /bin/systemctl enable ge...@.service prefdm.service getty.target rc-local.service remote-fs.target 2>&1 /var/tmp/rpm-tmp.sqw1k7: line 25: 19350 Segmentation fault (core dumped) /bin/systemctl enable dbus.service dbus.socket 2>&1 Installing : systemd-5-2.fc15.x86_64 2/4 Installing : systemd-gtk-5-2.fc15.x86_64 3/4 Installing : systemd-sysvinit-5-2.fc15.x86_64 also if there was that error introduced by a package (missing links) they also should be repaired by an update package. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: */bin and */sbin, command completion
2010/7/27 Matt McCutchen : > On Tue, 2010-07-27 at 09:49 +0200, Rudolf Kastl wrote: >> small addition: >> >> if you want to move stuff to /bin how about ifconfig and ip. > > I don't think so. ifconfig and ip administer the system-wide network > interfaces. All the write operations require root privileges. The read > operations don't, but if they are called by an unprivileged user, it is > still for the purpose of system administration and I don't think it's > unreasonable to expect the user to go to /sbin . well obviously it is else we wouldnt have to add */sbin to a regular users PATH. From an administrator using commandline id really expect to know the difference between su and su -. kind regards, Rudolf Kastl > > -- > Matt > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
2010/7/27 Matt McCutchen : > On Tue, 2010-07-27 at 09:42 +0200, Rudolf Kastl wrote: >> i do not understand how a daemon (like e.g. dbus-daemon) qualifies as >> "/bin : Essential user command binaries (for use by all users)" (taken >> from fhs 2.3). one could argue if a daemon qualifies as "command". >> especially since it seems it has to be run before /usr is mounted it >> is never getting executed by (all) the users. > > The next sentence says, "/bin contains commands that may be used by both > the system administrator and by users, but which are required when no > other filesystems are mounted (e.g. in single user mode)." systemd > qualifies on both counts: it may be used by users, and it is needed > before other filesystems are mounted. what about your dbus-daemon example? > >> From a usability point of view it is exactly those kinda commands i do >> not want in the user path because a user itsself should never have to >> execute it. > > Messing up the distinction between */bin and */sbin in the name of > cleaner path completion is not progress. what is progress from your point of view? unfortunately i just see that things break for no particular gain which doesent look like progress either. what exactly is the distinction for then? if we do not care about PATH i will agree with all the statements that have been made before in other threads that */bin and */sbin can be just merged because there is no real benefit anymore in separating them. How else can we fix autocompletion? There are plenty of users using shell and are relying on autocompletion for efficient usage of the terminal. > >> to me it sounds more like: /sbin : System binaries. If the system >> doesent need it why do we start it that early? > > The system does need systemd. Users also need it (that is, once the > envisioned user session-management capability is added). what about dbus-daemon... your example? for systemd: if a user is supposed to execute it (or it is executed as regular user upon login) then i agree completly, no questions asked. in its current state it is not the case though. > > -- > Matt > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
2010/7/27 Rudolf Kastl : > 2010/7/27 Matt McCutchen : >> On Mon, 2010-07-26 at 10:31 +0100, Bryn M. Reeves wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 07/24/2010 09:39 PM, Matt McCutchen wrote: >>> > On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: >>> >> On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: >>> >>>> Why is the systemd executable in /bin instead of /sbin? >>> >>> Without looking too closely I believe systemd eventually seeks to >>> >>> replace >>> >>> things like gnome-session daemon. It has session management in mind as >>> >>> well as system. >>> >> >>> >> Still belongs in /sbin, unless it's meant to actually be executed >>> >> directly >>> >> by end-users. >>> > >>> > No. If that were the criterion, update-mime-database would belong >>> > in /sbin . >>> > >>> >>> The FHS puts it like this: >>> >>> (a) "/bin contains commands that may be used by both the system >>> administrator and by users, but which are required when no other >>> filesystems are mounted (e.g. in single user mode). It may also contain >>> commands which are used indirectly by scripts." >>> >>> (b) "/sbin contains binaries essential for booting, restoring, >>> recovering, and/or repairing the system in addition to the binaries in >>> /bin." >>> >>> So if the intent is that systemd will eventually be invoked (indirectly >>> by some script/daemon) by users this seems justified by (a). On the >>> other hand the page has this to say on "init": >>> >>> "The following files, or symbolic links to files, must be in /sbin if >>> the corresponding subsystem is installed: ... >>> init" >>> >>> It's arguable though whether this refers to SysV's init or is intended >>> to be more general. >>> >>> http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES >>> http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES >> >> A hard link or symlink at /sbin/init is needed because tools look for it >> there. However, I think the main "systemd" executable belongs in /bin. >> I read (b) as a subdivision of the category established by the previous >> sentence: "Utilities used for system administration (and other root-only >> commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin." systemd >> is not (going to be) root-only, hence it doesn't go in */sbin. The >> right comparison would be to /bin/dbus-daemon. >> >> -- >> Matt > > i do not understand how a daemon (like e.g. dbus-daemon) qualifies as > "/bin : Essential user command binaries (for use by all users)" (taken > from fhs 2.3). one could argue if a daemon qualifies as "command". > especially since it seems it has to be run before /usr is mounted it > is never getting executed by (all) the users. > From a usability point of view it is exactly those kinda commands i do > not want in the user path because a user itsself should never have to > execute it. > > to me it sounds more like: /sbin : System binaries. If the system > doesent need it why do we start it that early? > > kind regards, > Rudolf Kastl > > kind regards, > Rudolf Kastl > > >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> > small addition: if you want to move stuff to /bin how about ifconfig and ip. in this regard our system is really a mess and instead of cleaning it up we worked around by polluting the users PATH and completion with */sbin. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
2010/7/27 Matt McCutchen : > On Mon, 2010-07-26 at 10:31 +0100, Bryn M. Reeves wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 07/24/2010 09:39 PM, Matt McCutchen wrote: >> > On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: >> >> On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: >> >>>> Why is the systemd executable in /bin instead of /sbin? >> >>> Without looking too closely I believe systemd eventually seeks to replace >> >>> things like gnome-session daemon. It has session management in mind as >> >>> well as system. >> >> >> >> Still belongs in /sbin, unless it's meant to actually be executed directly >> >> by end-users. >> > >> > No. If that were the criterion, update-mime-database would belong >> > in /sbin . >> > >> >> The FHS puts it like this: >> >> (a) "/bin contains commands that may be used by both the system >> administrator and by users, but which are required when no other >> filesystems are mounted (e.g. in single user mode). It may also contain >> commands which are used indirectly by scripts." >> >> (b) "/sbin contains binaries essential for booting, restoring, >> recovering, and/or repairing the system in addition to the binaries in >> /bin." >> >> So if the intent is that systemd will eventually be invoked (indirectly >> by some script/daemon) by users this seems justified by (a). On the >> other hand the page has this to say on "init": >> >> "The following files, or symbolic links to files, must be in /sbin if >> the corresponding subsystem is installed: ... >> init" >> >> It's arguable though whether this refers to SysV's init or is intended >> to be more general. >> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES >> http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES > > A hard link or symlink at /sbin/init is needed because tools look for it > there. However, I think the main "systemd" executable belongs in /bin. > I read (b) as a subdivision of the category established by the previous > sentence: "Utilities used for system administration (and other root-only > commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin." systemd > is not (going to be) root-only, hence it doesn't go in */sbin. The > right comparison would be to /bin/dbus-daemon. > > -- > Matt i do not understand how a daemon (like e.g. dbus-daemon) qualifies as "/bin : Essential user command binaries (for use by all users)" (taken from fhs 2.3). one could argue if a daemon qualifies as "command". especially since it seems it has to be run before /usr is mounted it is never getting executed by (all) the users. From a usability point of view it is exactly those kinda commands i do not want in the user path because a user itsself should never have to execute it. to me it sounds more like: /sbin : System binaries. If the system doesent need it why do we start it that early? kind regards, Rudolf Kastl kind regards, Rudolf Kastl > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
2010/7/26 Bryn M. Reeves : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/24/2010 09:39 PM, Matt McCutchen wrote: >> On Sat, 2010-07-24 at 16:36 -0400, Matthew Miller wrote: >>> On Sat, Jul 24, 2010 at 12:14:33AM -0400, Casey Dahlin wrote: >>>>> Why is the systemd executable in /bin instead of /sbin? >>>> Without looking too closely I believe systemd eventually seeks to replace >>>> things like gnome-session daemon. It has session management in mind as >>>> well as system. >>> >>> Still belongs in /sbin, unless it's meant to actually be executed directly >>> by end-users. >> >> No. If that were the criterion, update-mime-database would belong >> in /sbin . >> > > The FHS puts it like this: > > (a) "/bin contains commands that may be used by both the system > administrator and by users, but which are required when no other > filesystems are mounted (e.g. in single user mode). It may also contain > commands which are used indirectly by scripts." > > (b) "/sbin contains binaries essential for booting, restoring, > recovering, and/or repairing the system in addition to the binaries in > /bin." > > So if the intent is that systemd will eventually be invoked (indirectly > by some script/daemon) by users this seems justified by (a). On the > other hand the page has this to say on "init": > > "The following files, or symbolic links to files, must be in /sbin if > the corresponding subsystem is installed: ... > init" > > It's arguable though whether this refers to SysV's init or is intended > to be more general. > > http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES > http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES well an init system replacement probably has to do with booting the system hence it makes sense from my pov to move the binary to /sbin. it especially makes sense if one unbreaks the user PATH by removing /sbin from it since there is less irrelevant stuff in the PATH environment then for autocompletion. kind regard, Rudolf Kastl p.s. i am going to open a bug > > Regards, > Bryn. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxNVfQACgkQ6YSQoMYUY95UngCgxoS3//7yzpXZriKSCZMFnun+ > 1qoAn107myHo05jderCykLfKsSmqYAmS > =iYOx > -END PGP SIGNATURE- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
2010/7/15 Simo Sorce : > On Thu, 15 Jul 2010 16:59:40 +0200 > Lennart Poettering wrote: > >> Because it reverses everything. > > And this is a problem because ? > >> I.e. generally we have the rule that "native configuration breaks >> legacy configuration". > > Who's "we", what is the rationale of this rule ? Looks like it is a > rule made to break things on upgrades. Most upstream I know have the > inverse rule. Do not break things unless it is *necessary*. > > I do not see why it is necessary to break here. > >> However, to make the inittab stuff useful we'd >> have to turn that around, and say that "legacy breaks native". Why? >> Because the /etc/systemd/system/default.target symlink is created by >> the rpm in all cases and would hence make the inittab ignored anyway. >> >> If I added inittab parsing support even when keeping "native breaks >> legacy" around, then inittab would matter only if the default.target >> symlink doesn't exist. We could certainly inform the user to delete >> that symlink, via some blurb in inittab, however, if he goes and >> deletes it, wouldn't it be much easier to just fix properly and to >> the right boot target, and have a future-proof system? >> >> i.e. isn't this: >> >> # vi /etc/inittab >> ... user reads the blurb and changes a line, exits >> # rm /etc/systemd/system/default.target >> >> really that much better in your eyes, than this: >> >> # vi /etc/inittab >> ... user reads the blurb, quits right-away >> # ln >> -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target >> >> I don't think it is... > > You are assuming a human is doing these changes, in many cases it is > install (kickstart) scripts. And keeping compatibility means an admin > does not have to start making big exceptions because a subset of > machines now start needing a different way to change it. > > You can also add a blurb in inittab that says something about removing > the init line, and how this will activate the beautiful systemd > mechanism to handle runlevels. > > - Then admins can choose which one to use. > - Does not break on upgrades > - Does not break anaconda and anaconda devs have the time to do the > change to stop installing an inittab in new installations while keeping > what is there working on updates without having to do special case > handle. Otherwise anaconda will have to care about handling this change > too on distro upgrades. > > And so on. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > also there is the fact that current init scripts usually do alot more... like adding configtest (a generic way of syntax checking before trying to restart the daemon to avoid downtime with last minute changes that cannot be tested on another machine for one way or another...) and i also hope that this time restarting a service plays nice with using cluster software (restarting returns exit 0 if the daemon starts successful no matter if the shutdown failed.) kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
2010/7/11 drago01 : > On Sun, Jul 11, 2010 at 6:39 PM, Rudolf Kastl wrote: >> 2010/7/10 drago01 : >>> On Sat, Jul 10, 2010 at 12:35 PM, Roberto Ragusa >>> wrote: >>>> Al Dunsmuir wrote: >>>> >>>>> I would suggest doing PGO for the following: >>>>> >>>>> - Compression-type utilities (gz, zip, unzip, 7zip, etc), >>>>> especially those libraries used by RPM to generate/process deltas. >>>> >>>> and encryption stuff: openssl, openssh, md5sum, sha1sum, ... >>>> >>>> and data intensive stuff: rsync, gcc, grep, ... >>>> >>>>> - Helper routines used by yum to extract dependencies >>>>> >>>>> - X-Windows server and libraries used for 2D and 3D display such as >>>>> opengl, compiz, etc. >>>> >>>> and ghostscript, poppler, ... >>>> >>>> >>>> Everyone will easily suggest Firefox and OpenOffice.org. >>> >>> Not sure about firefox but atleast xulrunner and thus spidermonkey >>> should help any app that uses them. >> >> what about games like openarena tremulous etc? ;) > > Not easy to do in an automated build; besides I doubt it will gain > much as the performance largely depends on the graphics driver and > performance critical parts use hand optimized assembler anyway. the later argument isnt true for all 3d engines/scenegraphs though. also it probably largely depends on the application i guess, depending on how many cpu cycles you spend outside of the rendering (e.g. with simulations like flightgear e.g.) kind regards, Rudolf Kastl > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
2010/7/10 drago01 : > On Sat, Jul 10, 2010 at 12:35 PM, Roberto Ragusa > wrote: >> Al Dunsmuir wrote: >> >>> I would suggest doing PGO for the following: >>> >>> - Compression-type utilities (gz, zip, unzip, 7zip, etc), >>> especially those libraries used by RPM to generate/process deltas. >> >> and encryption stuff: openssl, openssh, md5sum, sha1sum, ... >> >> and data intensive stuff: rsync, gcc, grep, ... >> >>> - Helper routines used by yum to extract dependencies >>> >>> - X-Windows server and libraries used for 2D and 3D display such as >>> opengl, compiz, etc. >> >> and ghostscript, poppler, ... >> >> >> Everyone will easily suggest Firefox and OpenOffice.org. > > Not sure about firefox but atleast xulrunner and thus spidermonkey > should help any app that uses them. what about games like openarena tremulous etc? ;) kind regards, Rudolf Kastl > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug 531464 - why the WONTFIX?
2010/7/11 Rudolf Kastl : > 2010/7/11 Kevin Kofler : >> Matt McCutchen wrote: >>> If you're suggesting that an upstream bug report is information needed >>> to understand a Fedora bug, that's absurd. It's a step taken to resolve >>> the bug. Would you mark a bug INSUFFICIENT_DATA because the reporter >>> didn't provide a patch? >> >> Providing a patch is actually hard. Reporting a bug in the upstream bug >> tracker is just a matter of filling out the form, if the reporter refuses to >> do that, it's only pure laziness. > > well thing is... if you are constantly reporting bugs vs stuff we have > in it is not possible to maintain like a 1000 upstream bugzilla > accounts. thats why there is a maintainer that in the best case works > close with upstream anyways and has more insight on what happens with > the project. just my personal point of view. ... and a valid fix from my pov to lower the overhead for the maintainer would be to make it easier and less effort to get the stuff forwarded upstream for him. a one-click forward upstream button would be a nice thing and it is defintely technically possible. kind regards, Rudolf Kastl > > kind regards, > rudolf kastl > >> >> Kevin Kofler >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug 531464 - why the WONTFIX?
2010/7/11 Kevin Kofler : > Matt McCutchen wrote: >> If you're suggesting that an upstream bug report is information needed >> to understand a Fedora bug, that's absurd. It's a step taken to resolve >> the bug. Would you mark a bug INSUFFICIENT_DATA because the reporter >> didn't provide a patch? > > Providing a patch is actually hard. Reporting a bug in the upstream bug > tracker is just a matter of filling out the form, if the reporter refuses to > do that, it's only pure laziness. well thing is... if you are constantly reporting bugs vs stuff we have in it is not possible to maintain like a 1000 upstream bugzilla accounts. thats why there is a maintainer that in the best case works close with upstream anyways and has more insight on what happens with the project. just my personal point of view. kind regards, rudolf kastl > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
2010/5/26 Seth Vidal : > > > On Wed, 26 May 2010, Simo Sorce wrote: > >> While you don't edit them *all* the time, it is something that is done >> regularly, and it is something most admins can do with ease. >> Turn them in a C program and you left admins out in the cold, most of >> them. >> >> I would be very, very wary of accepting a C "init script". >> An unmanageable system is a useless system. > > +20 million. > > I couldn't agree more. They need to be scripts, considering how seldom > they actually run it makes even less sense to chase down optimization in > them by making them compiled. i strongly agree here aswell... what can be done and should be done is to clean the mess up making it even more standardized and removing the cruft and workarounds. thats what i basically liked about initng scripts. kind regards, Rudolf Kastl > > -sv > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
2010/5/7 Matěj Cepl : > Dne 7.5.2010 01:01, Rudolf Kastl napsal(a): >> one of the questions raised in the meeting posted by mcepl was... "why >> dont those people leave if they are unhappy". simple... they put alot >> sweat blood and tears into a project, and they have friends... with >> the development crowd and with the community in general. they are >> obviously feeling as a part of it with just a different pov and an own >> opinion. that isnt bad at all ... but healthy... "diversity is >> healthy" to a project. > > I didn't to continue in this thread, but here I have to defend myself. I > don't remember I would say anything like that, but it looks to me like > taken out of the context at least and expressing exactly opposite > position I think I held. Although I don't agree with many of them in a > lot of places, I strongly support Kevin's, Ralf's and others position > that the current development is very harmful to the development of > Fedora and I would love them to stay and defend this still nice project > we all work on. i didnt mean you said that. i was referring to the meeting log you posted. sorry for the confusion. kind regards, Rudolf Kastl > > Actually, http://skvidal.wordpress.com/2010/05/07/dissidents/ made me so > angry that I am just not able to write any response to it ... whatever I > would write would be too much personal half-libelous attack, so I will > rather write nothing. > > Matěj > > -- > According to the Franciscan priest Richard Rohr, spirituality is > not for people who are trying to avoid hell; it is for people > who have been through hell. In many ways, spirituality is about > what we do with our pain. And the truth is, if we don't > transform it, we will transmit it. > -- Al Gustafson > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
2010/5/7 Brian Pepple : > On Fri, 2010-05-07 at 00:26 +0200, Karel Zak wrote: >> On Thu, May 06, 2010 at 05:46:21PM -0400, Brian Pepple wrote: >> > >> > Normally, I'd be against it killing a thread, but the thread that >> > started this discussion had already been done awhile back and this new >> > thread added *nothing* new to the discussion. Frankly, it was more >> >> This all is your subjective opinion. There is not objective and >> unbiased way how evaluate any discussion, it's unmeasurable. That's >> the reason why Hall Monitor Policy is nonsense. > > Please enlighten me then on what new information was added to this > thread that wasn't in the prior thread that warranted keeping it alive? one could argue that even that is now a redundant question that hasnt anything to do with fedora development and doesent belong to this list and is therefor "redundant". thats the whole point that is beeing expressed here. it depends on the point of view if discussions are valuable, helpful, creative and have a positive outcome or not. and i want to add something else... sometimes if people come up with "stupid" ideas some other people read it... laugh... and develop a good idea out of some points of the basically "stupid" one. beeing creative requires to have input... the wilder the input the more innovative the output can be. as linux users we unfortunately are all a vocal minority in the world outside of the project. we are loud though and we get our ways. that might explain why some people are pretty loud and atleast try to drive their way... thats what alot older community members did the last 10 to 20 years. i dont want to find excuses or justify anything... just state a few facts to explain some discussed circumstances and some of the psychology behind it... since that seemed to be an open question in the meeting. one of the questions raised in the meeting posted by mcepl was... "why dont those people leave if they are unhappy". simple... they put alot sweat blood and tears into a project, and they have friends... with the development crowd and with the community in general. they are obviously feeling as a part of it with just a different pov and an own opinion. that isnt bad at all ... but healthy... "diversity is healthy" to a project. and lastly just a personal opinion... i think what drives this project (and i hope the people i give support to in #fedora on a daily basis forgive me) are the developers. they are the most important entity that keep the projects alive and going. If we are good in what we do the users will come on their own... i personally as much as i love this project do not really care how big our user base is... i care how big our developer base is... and i hope that in the future we are not ruling out or excluding people just because they express a different opinion and try to drive it. it is exactly those kind of people that use up their spare time and work unpaid on projects like fedora because their heart is just beating for the project... else theyd have left for good and just used their spare time for other purposes. kind regards, Rudolf Kastl p.s. i am not claiming to be objective, just trying to interpret what i see. > > Later, > /B > -- > Brian Pepple > > https://fedoraproject.org/wiki/User:Bpepple > gpg --keyserver pgp.mit.edu --recv-keys 810CC15E > BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: chrony as default NTP client?
2010/5/6 Miroslav Lichvar : > On Wed, May 05, 2010 at 09:39:52PM -0400, Tom Lane wrote: >> Mail Lists writes: >> > On 05/05/2010 09:35 AM, Miroslav Lichvar wrote: >> >> With the latest improvements in the chrony package related to >> >> NetworkManager and name resolving I think it is now good enough to >> >> replace ntpd in the default configuration and the configurations >> >> supported by system-config-date. >> >> > I think this is a terrible idea. >> >> Yes. I certainly wouldn't use it, and especially object to the proposed >> strong-arm tactics of eliminating all configuration support for ntpd. >> The case for making chrony default is weak enough, and the case for >> throwing roadblocks in the way of people who prefer ntpd is nonexistent. > > I'm not suggesting to remove the ntp support from s-c-d, just to add a > support for chrony and change the dependency to a name provided by > both packages and marking chrony as default in the comps. for the desktop/default/gnome spin... but not for the full dvd i hope. other than that having an option is a nice idea if it is less "expensive" on resources and enough for a certain group of users (desktop ones). removing support for ntpd would be a completly different deal. kind regards, Rudolf Kastl > > -- > Miroslav Lichvar > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Page flipping on intel (2.11 driver)
2010/5/2 Owen Taylor : > With the 2.11 update for xorg-x11-drv-intel in updates-testing we have a > couple of serious problems occurring with gnome-shell on Intel systems: > > A) A complete hang where the system can't even be pinged. > > B) A problem where the system continues to run fine but the GPU gets > "stuck" and no further drawing happens until the system is rebooted. > > We've also had similar reports for Compiz. > > These problems seem to be associated in particular with the "page > flipping" functionality that it enables. (The implementation is mostly > in the kernel, but the use is driven by the X server.) > > With considerable testing and experimentation, the biggest source of > hangs on my GMA3100 system turned out to be fixed by the kernel patch: > > http://lists.freedesktop.org/archives/intel-gfx/2010-April/006463.html > > However, that fix is "gen3" specific (i915, i945, and variants), > and we've also had reports of hard locks on newer chips like the i965 > and GM45, so it's probably not the only thing going on. The second > problem also is likely unrelated. > > My feeling is that we should disable page flipping for F13 - it's had > only a tiny bit of testing, and any fixes we put in at this point are > going to get a far tinier bit of testing. > > We could "disable" it by simply avoiding pushing the 2.11 update, but > since that leaves things broken for people who have updates-testing > enabled, I think it would be better to patch the functionality out the > 2.11 package. See the patch im: > > https://bugs.freedesktop.org/show_bug.cgi?id=27883#c3 > > for how to do that schematically, though it would be better to also > change the: > > "Kernel page flipping support detected, enabling" > > message. (It would be sort of neat to have some way to allow users to > enable it and test, but maybe the "way to enable it" is just installing > the F-14 rawhide package.) > > What do people think? Actually if you want people testing with i965 id volunteer. kind regards, Rudolf Kastl > > - Owen > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reasons for hall monitoring
2010/5/4 Kevin Kofler : > Seth Vidal wrote: >> * Hall monitors are allowed to send 'thread closure' posts to >> aggressive or problematic mailing list threads to curtail issues before >> they become serious enough to warrant an official warning. When this is >> done the subject line of the message will be prefixed with >> [HALL-MONITORED] and a link to this wiki page is included in the message. > > This vague paragraph can be abused to justify censoring pretty much > everything. > > Thank you for pointing out yet another undemocratic policy passed by one of > our committees (in this case the Board) against the wishes of a large part > of our community, restricting the usage of a mailing list for its very > purpose: discussion. You can arbitrarily censor any discussion you don't > like without even giving a reason. well there are a few potential solution to this: 1) try to get rid of this policy 2) use different lists/forums to continue the discussion. you pick which one is worth to go ahead with. this is not a democracy, and it has been stated often enough by all people involved, not even an indirect one. kind regards, Rudolf Kastl > > That's all I'm going to add to this subthread. > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
2010/5/4 Thomas Spura : > Am Montag, den 03.05.2010, 22:37 -0400 schrieb Orcan Ogetbil: >> On Mon, May 3, 2010 at 10:26 PM, Chris Adams wrote: >> > Once upon a time, Orcan Ogetbil said: >> >> The statistic talks. It doesn't only talk. It yells. Ignoring this >> >> test statistic in favor of the large pool of imaginary users, who >> >> supposedly think in the complete other direction, is not only >> >> non-scientific, stupid., but also self-conflicting. >> > >> > You claim you have taken grad-level statistics, but you don't appear to >> > understand how to select a sample. A self-selected sample on a web >> > forum (with no basis to show that forum members are representative of >> > the Fedora user base, much less that poll responders represent even the >> > forum users) does not lead to valid statistical results. It doesn't >> > matter how big the sample size is if the samples are not properly >> > selected. >> > >> > >> >> No, I exactly know how to select a sample. The forum based sample is >> "the" perfect sample. It is the users who talk. It is not the >> imaginary users, who you claim to exist. I do not care about your >> imaginary users. I do care about those who talk. Hence the statistic >> is significant. > > You assume here 'imaginary users' don't need to be heard or in your > words 'are stupid' and nobody should care about them. we can still imagine to hear the imaginary users but they wont manifest... and if they do... get your meds ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo
2010/5/4 Stephen John Smoogen : > On Mon, May 3, 2010 at 4:01 PM, Kevin Kofler wrote: >> Stephen John Smoogen wrote: >>> As I have pointed out in both public and private emails to you >> [snip] >> >> Why are you telling all this stuff to me? I'm ALREADY complaining about our >> processes being undemocratic. The points you make are very real. But I don't >> agree with you that the solution has to be some formal framework. If our >> representatives actually, well, REPRESENTED their electorate, things would >> work much better. Now of course none of the representatives knows who voted >> for them because the vote is anonymous, but as you explained, there are >> reasons to represent even those who did not vote for oneself, or at all, >> anyway. > > I have been telling you because I had hoped you would listen and > realize you were not just tilting at windmills but the wrong ones. > However it is clear to me that I am not able to communicate with you > or understand what you are trying to represent. After a year of > posting, all I can make out is some sort of quest towards some sort of > Anarchy/Anti-statist government in a place where it has little > possibility of occurring. if someone opposes some enforced order it doesent make him necasserily and anarchist... and as long as people in general need someone to vote and decide for them, we are still in the social and educational stone age. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
broken desktop files
Hello, i did a desktop-file-validate on all .desktop files in the current rawhide distro (note rpmfusion too). here is the result of only the errors grepped from a complete check: http://fpaste.org/5p23/ kind regards, Rudolf Kastl p.s. if someone needs help fixing an entry ask away. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: btrfs love-hate relationship
2010/4/30 Valent Turkovic : > http://blog.rot13.org/2010/04/btrfs_love-hate_relationship.html > > This is an interesting read. > > I personally use it only in testing, but Dobrica who wrote blog post > tried it in production. hopefully he analyzed and filed his bugs else the "field testing" was for nothing. somehow i am not really surprised that there are still issues... maybe that is the reason why it is yet not recommended to use it in a production environment or for anything else besides testing with noncritical systems and noncritical data. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
2010/3/1 Richard Hughes : > On 28 February 2010 18:39, James Antill wrote: >> I can't think of any reason why you'd need, or want, to have >> updates-testing checks block any other GUI operation. > > To show the list of newest updates to the user... > >>> If we could speed up the dep checking and downloading, I agree it >>> would be better for usability, and the exposure of updates-testing >>> generally. >> >> Dep. checking is pretty fast, upT¹ is roughly 10 seconds for 300 >> packages here and lsuT is like 2.5 seconds. I guess maybe that's worth >> caring about if you block everything else behind it, but... > > Sure, and 2.5 seconds _extra_ is a long time. > >> As to the downloads, if you know of a way to speed up a users internet >> connection ... feel free to spread your wisdom. > > Here's three: > > * Download from multiple mirrors simultaneously > * Do the transaction in parallel so that you're downloading the next > depsolved set of updates as you're installing the first > * Have better control of the cache format so you don't need to keep > three files in sync just to update the primary and then depsolve. > > Richard. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > that practically just doesent work (updates-testing) since updates-testing packages do not get built against updates-testing packages and therefor if you have 2 soname bumps it falls over and you end up resolving deps manually by try and error with the packagekit frontend. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora-release-rawhide, et. al.
2010/2/25 James Antill : > On Thu, 2010-02-25 at 16:29 -0500, Bill Nottingham wrote: > >> Going over the various usage cases: >> >> 1) Release has not yet branched, want to switch, or use rawhide packges >> >> Currently: >> yum install fedora-release-rawhide >> yum --enablerepo=rawhide ... >> >> New: >> yum --releasever= ... >> >> 2) Release has branched; want to pull from never-frozen rawhide devel >> stream. >> >> Currently: >> yum install fedora-release-rawhide >> yum --enablerepo=rawhide ... >> >> New: >> yum --releasever= ... > > $releasever just changes the variable, so the URLs are all the same ... > just with different variables. Specifically: > > mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch > > ...is never going to == > > https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=$basearch > > ...I guess if we make sure MM understands what the new numbers mean > pretty quickly (ie. before branching) this is fine. > I'm also not sure what apt/smart are going to do. > >> Am I missing something? Do people think this would be better, or worse? > > It removes the ability to have a machine be on rawhide forever, without > user intervention, but I'm not sure that's a bad thing (but then I don't > do that). thats exactly what i personally use since years... but then i just would drop another repo.conf on top... it would add the inconvenience of writing/changing the repo file myself and i guess i am not the only one. on the other hand... what would you really win? kind regards, Rudolf Kastl > > -- > James Antill - ja...@fedoraproject.org > http://yum.baseurl.org/wiki/releases > http://yum.baseurl.org/wiki/whatsnew/3.2.27 > http://yum.baseurl.org/wiki/YumMultipleMachineCaching > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intel GPU powersaving
still got hangs on a lenovo x301. with 2.6.32/31 the hangs are gone. 2010/2/23 Matthew Garrett : > We tried some new Intel powersaving code in the F12 cycle, but it caused > a range of problems including screen flickering and crashes. I've > reworked this a little and it seems to work on a machine that had > problems in the past, so I'd like to try it again. If anyone with an > Intel GPU (except GMA500, 810, 815 and 830) would like to give the F13 > kernels at http://koji.fedoraproject.org/koji/taskinfo?taskID=2009928 a > go and let me know if they result in graphical glitches or hangs that > you don't otherwise have with F13, that would be a great help. > > -- > Matthew Garrett | mj...@srcf.ucam.org > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: burning an iso with gnome defaults -> confusing
> I say we keep polling and find other ways of saving the planet. This is not about the change of default behaviour... keep on polling all the way you want... i just wanted to point out that the application gives confusing and partially wrong feedback to the user which confuses the user. Saving the planet doesent work anyways if no one actually listens to input, so as you can see we are already doomed. kind regards, Rudolf Kastl > > > -- > Christopher Brown > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: burning an iso with gnome defaults -> confusing
2010/2/1 Christopher Brown : > On 15 January 2010 11:03, Rudolf Kastl wrote: >> 2010/1/14 Matthew Garrett : >>> On Thu, Jan 14, 2010 at 01:46:52PM +0100, Rudolf Kastl wrote: >>> >>>> thats exactly what i am "complaining" about. it states that burning >>>> failed. id expect it to tell me that polling failed. thats not really >>>> "randomly" but a common way to tune systems for maximized battery >>>> lifetime. powertop e.g. recommends it, i guess that makes it less >>>> random. i do understand though that not every single possible setting >>>> can be tested before release, thats basically why i wrote that email. >>> >>> The power savings are minimal. While it's certainly a bug in Brasero >>> that should be fixed, I wouldn't bother disabling polling. >> >> the sum of various minimal savings makes a difference. > > ...when traded off against the numerous CDs that get thrown away when > the user thought they were bad? Yeah that is a bug that needs to be fixed. Just the burn isnt bad just because polling is off. The output of the program is plain wrong like in the other case above. Also just because it can poll the device it is not a proof that the burn was successful either so i am curious if that "test" even makes sense at all if you dont compare e.g. checksums instead of just beeing able to "poll" I am just curious if upstream doesent care about usability and doesent listen to input if it is wise to have it as the default burning tool on the default spin with the default desktop. kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: enlightenment 17 maintainer awol?
> On Tue, Jan 12, 2010 at 1:37 PM, Rudolf Kastl wrote: >> E17 components are outdated since a whole while and the maintainer >> doesent even respond: >> https://bugzilla.redhat.com/show_bug.cgi?id=514882 >> >> kind regards, >> Rudolf Kastl >> >> p.s. put the maintainers bz email on cc 16 days later trying to reach the maintainer again... hello where are you dear maintainer? kind regards, Rudolf Kastl -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: burning an iso with gnome defaults -> confusing
2010/1/14 Matthew Garrett : > On Thu, Jan 14, 2010 at 01:46:52PM +0100, Rudolf Kastl wrote: > >> thats exactly what i am "complaining" about. it states that burning >> failed. id expect it to tell me that polling failed. thats not really >> "randomly" but a common way to tune systems for maximized battery >> lifetime. powertop e.g. recommends it, i guess that makes it less >> random. i do understand though that not every single possible setting >> can be tested before release, thats basically why i wrote that email. > > The power savings are minimal. While it's certainly a bug in Brasero > that should be fixed, I wouldn't bother disabling polling. the sum of various minimal savings makes a difference. > > -- > Matthew Garrett | mj...@srcf.ucam.org > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: burning an iso with gnome defaults -> confusing
2010/1/14 Jud Craft : > On 1/14/10 6:30 AM, Bastien Nocera wrote: >> On Thu, 2010-01-14 at 12:09 +0100, Rudolf Kastl wrote: >>> Hello >>> >>> Burning an iso file with gnome is really confusing even for a technical >>> user: >>> >>> 1. i insert a blank >>> 2. i right click on an iso in nautilus and choose burn to cd/dvd >>> >>> -> so far so good >>> >>> 3. i get a new window stating how much free space the blank has (but >>> in reality it already substracted the space beeing used by the iso you >>> want to burn) >>> -> this leaves the impression that the cd/dvd isnt really a blank >>> because it doesent tell you that it is the free space _after_ the burn >>> > > In particular #3 is closed as notabug, #591393. > > Main developer likes that UI. :( the ui is fine the text is misleading. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: burning an iso with gnome defaults -> confusing
2010/1/14 Bastien Nocera : > On Thu, 2010-01-14 at 12:09 +0100, Rudolf Kastl wrote: >> Hello >> >> Burning an iso file with gnome is really confusing even for a technical user: >> >> 1. i insert a blank >> 2. i right click on an iso in nautilus and choose burn to cd/dvd >> >> -> so far so good >> >> 3. i get a new window stating how much free space the blank has (but >> in reality it already substracted the space beeing used by the iso you >> want to burn) >> -> this leaves the impression that the cd/dvd isnt really a blank >> because it doesent tell you that it is the free space _after_ the burn >> >> 4. after burning if device polling is disabled (a typical setting for >> laptops if you want to save power) it will tell you "burning failed" >> while the burning itsself didnt fail at all, all that fails is >> actually to poll the device... >> -> confusing > > I wouldn't expect it to tell you it failed, but certainly, things won't > work as well if you disable things (semi-)randomly. thats exactly what i am "complaining" about. it states that burning failed. id expect it to tell me that polling failed. thats not really "randomly" but a common way to tune systems for maximized battery lifetime. powertop e.g. recommends it, i guess that makes it less random. i do understand though that not every single possible setting can be tested before release, thats basically why i wrote that email. > >> there is lots to do on the usability front... like e.g. trying the stuff out >> ;) > > Both are bugs in brasero. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
burning an iso with gnome defaults -> confusing
Hello Burning an iso file with gnome is really confusing even for a technical user: 1. i insert a blank 2. i right click on an iso in nautilus and choose burn to cd/dvd -> so far so good 3. i get a new window stating how much free space the blank has (but in reality it already substracted the space beeing used by the iso you want to burn) -> this leaves the impression that the cd/dvd isnt really a blank because it doesent tell you that it is the free space _after_ the burn 4. after burning if device polling is disabled (a typical setting for laptops if you want to save power) it will tell you "burning failed" while the burning itsself didnt fail at all, all that fails is actually to poll the device... -> confusing there is lots to do on the usability front... like e.g. trying the stuff out ;) kind regards, Rudolf Kastl p.s. this is not a problem for me but for other potential users with less technical understanding -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
enlightenment 17 maintainer awol?
E17 components are outdated since a whole while and the maintainer doesent even respond: https://bugzilla.redhat.com/show_bug.cgi?id=514882 kind regards, Rudolf Kastl p.s. put the maintainers bz email on cc -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
