July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 304429] Package cache handling in yast
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature changed by: Eduardo Sotomayor (Easgs) Feature #304429, revision 16 Title: Package cache handling in yast openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 21:45:10 reject reason: Postponing. Zypper already provides the functionality. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Done Priority Requester: Important Requested by: Ladislav Slezak (lslezak) Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 Test Case: * check if the installed version of yast2-packager is 2.18.0 or later, with following command: $ rpm -q yast2-packager * add a new Software Repository: open YaST2 -> Software -> Software Repositories -> Add * during adding the new Software Repositories flag "Keep Downloaded Packages" * install or update a package: # zypper install <package name> * check if the package rpm file was saved in local cache (default: /var/cache/zypp/packages/) Discussion: #2: Ladislav Slezak (lslezak) (2009-01-08 13:47:14) Implemented in yast SVN trunk (will be in yast2-packager-2.18.0) There is a new check box, similar to 'Enabled' and 'Autorefresh' check boxes. (bnc#402617) #3: Eduardo Sotomayor (easgs) (2009-05-21 01:01:51) Will it work when installing a package with Yast not zypper command? #4: Rémy Marquis (spyhawk) (2009-05-23 08:36:50) (reply to #3) Yes. it is working. As specified above, there is a new checkbox in the UI for enabling cache handling. #5: Vincent Petry (pvince81) (2009-07-11 03:20:54) Will it also resume partially downloaded packages ? + #6: Eduardo Sotomayor (easgs) (2009-07-27 17:49:19) + With the zypper command is possible to only download the requiered rpm + files with all dependencies without affecting the system, this is + usefull to make a distributable CD so you can install the programs even + without an internet connection in another computer, in this way, you + can get all the files without affecting the source PC, it would be good + to add another check box "Download only" to acomplish that via Yast. + So you will have two options + "Keep Downloaded Packages" + "Download only" -- openSUSE Feature: https://features.opensuse.org/304429

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 20 Title: zypper: dist upgrade could error out if more than one repository with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) + #16: Ján Kupec (jkupec) (2009-07-27 17:30:09) (reply to #14) + Rudi, please look at c#14 and 15 -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 19 Title: zypper: dist upgrade could error out if more than one repository - exists + with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305403] Bootloader beep configuration
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305403, revision 17 Title: Bootloader beep configuration - Hackweek IV: Candidate + Hackweek IV: Done Priority Requester: Desirable Projectmanager: Desirable - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Desirable Projectmanager: Desirable Requested by: Jiri Srain (jsrain) Description: Allow to configure whether the acoustic signal should be used for installed bootloader. Acoustic signal is valuable for visually impaired people, while it may be disturbing e.g. in libraries. Discussion: #1: Jiri Srain (jsrain) (2008-11-12 15:58:43) Default can be set depending on whether braille display was found or whether text-to-speech in isolinux was used. #2: Stefan Behlert (sbehlert) (2008-11-12 17:15:07) Is this feature meant as 'allow atuomatic setting of'? The beep is afaik already configurable to be 'off'. If not, this would be a bug. #3: Stefan Seyfried (seife) (2008-11-12 18:09:40) Please reject this feature. This is seriously overengineered. The beep now defaults to off int the installed system. If somebody wants to enable it, he can do so with gfxboot --change-config "boot::beep=1" Marco only needs to document that for his customers and everything is fine. Please, no YaST module for that. #4: Jiri Srain (jsrain) (2008-11-13 09:39:44) (reply to #3) It's not about a new module, just about a check box in the bootloader configuration. #5: Jiri Srain (jsrain) (2009-06-01 11:38:11) (reply to #4) Jozo, please, find a reasonable location for the check box. #6: Jozef Uhliarik (juhliarik) (2009-06-25 10:37:14) Steffen how can I obtain info about status of "beep" from gfxboot? I know how to switch on/off option but I need also status. Please let me know. #7: Steffen Winterfeldt (snwint) (2009-06-25 11:40:48) (reply to #6) You can't. If you have an INF file parser, you can run 'gfxboot --show- config' and get the value from there. + #8: Jozef Uhliarik (juhliarik) (2009-07-27 16:54:15) + done in yast2-bootloader 2.18.11 -- openSUSE Feature: https://features.opensuse.org/305403

1 0

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #302159, revision 43 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Desirable Projectmanager: Important Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 and #305624 Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). #13: Jan Engelhardt (jengelh) (2009-03-01 17:02:04) (reply to #7) Broadband is actually a pretty broad term, and so the survey item probably did not have much value. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. #14: Elmar Stellnberger ATK (estellnb) (2009-03-26 13:04:40) One advantage will be that packages can be inspected by a prog. such as mc in advance to installation or to manually take them apart by rpm2cpio. Sometimes it is necessary to add special rpm-installation options as --excludepath or --excludedocs to install several versions of a single package for downward compatibility. Furthermore in combination with an upcoming --arch switch it may enable to download packages on a server to be installed on another system/machine. f.i. the ati repo can not be browsed via http so that it is necessary to download packages from it via zypper rather than a web browser. #17: Michael Andres (mlandres) (2009-07-21 12:30:27) libzypp-6.11.0 allows to set different download policies in ZYppCommitPolicy (DownloadOnly, DownloadInAdvance, DownloadInHeaps, DownloadAsNeeded). + #18: Ján Kupec (jkupec) (2009-07-27 15:22:59) + Done also in zypper (--download-only/-d added to several commands). To + be in zypper 1.2.3 -- openSUSE Feature: https://features.opensuse.org/302159

1 0

[openFATE 306850] Codestriker
by fate_noreply＠suse.de 27 Jul '09

27 Jul '09

Feature added by: Hemant Mohan (hemantm) Feature #306850, revision 1 Title: Codestriker Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Hemant Mohan (hemantm) Description: Codestriker is a code review tool (http://codestriker.sourceforge.net/), which is very useful to the developers. -- openSUSE Feature: https://features.opensuse.org/306850

1 2

[openFATE 305877] Popularity contest
by fate_noreply＠suse.de 25 Jul '09

25 Jul '09

Feature changed by: Carlos Gonçalves (cgoncalves) Feature #305877, revision 20 Title: Popularity contest openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Desirable Requested by: Vladimir Nadvornik (nadvornik) Description: We need a feedback about packages that are preferred by users and actively used. Debian already has a tool named Popularity contest (popcon) * reusing popcon will give us results that are directly comparable with Debian and Ubuntu * packagers team can take care of the package * we need a configuration dialog in YaST that is visible enough * we need a server infrastructure on opensuse.org. (There are certain privacy issues, see Debian FAQ for details) References: http://en.opensuse.org/BrainStorming_Prague#We_don.27t_know_which_packages_… http://popcon.debian.org/FAQ http://popcon.debian.org/ http://popcon.ubuntu.com/ Discussion: #1: Michal Vyskocil (mvyskocil) (2009-02-20 12:56:06) The pupularity-contest executable is a simple Perl script, which should be ported to rpm (replacing of dpkg calls by appropiate rpm alternative should be enough). #2: Pavol Rusnak (prusnak) (2009-03-11 15:53:13) (reply to #1) Replacing of dpkg calls with rpm is a no-go, because of the transactions in RPM. I started to work on a rewrite, will post results soon ... #3: Marek Stopka (m4r3k) (2009-03-13 09:28:08) (reply to #2) And here is a result... :-) http://stick.gk2.sk/blog/2009/03/popcorn-popularity-contest-for-rpm/ #4: Jay Mistry (zmdmw52) (2009-03-15 15:36:25) The software equivalent of Smolts Hardware profiler. Results can be uploaded to a dedicated website (such as is for Smolts- http://www.smolts.org/), so that users can see the relative weight/popularity of various commonly-used applications. + #7: Carlos Gonçalves (cgoncalves) (2009-07-25 19:03:58) (reply to #4) + There is a GSOC project (http://socghop.appspot.com/student_project/show/google/gsoc2009/gentoo/t124…) + which is addressing this (Smolt) feature to Gentoo, though the author + has been coding this aswell to Debian-based distros and more recently + considering RPM distros too. + I've been working with him on the client integration since I'm its + author, and from my side all I can say is that Smolt sooner or later + will be addressing this feature, too, but won't be ready in time for + openSUSE 11.2 since feature/version freeze is next week (July 31). #5: T. J. Brumfield (enderandrew) (2009-06-13 21:16:54) During install, there can be a simple checkbox such as "Share hardware/software details with openSUSE servers for profiling." #6: Stephan Kulow (coolo) (2009-06-24 11:29:15) first we need the package in and someone to maintain the server or contact debian if they host other distros too. -- openSUSE Feature: https://features.opensuse.org/305877

1 0

[openFATE 305584] Do not assume fixed and contiguous device numbers in installation and management tools for storage
by fate_noreply＠suse.de 24 Jul '09

24 Jul '09

Feature changed by: Arvin Schnell (aschnell) Feature #305584, revision 17 Title: Do not assume fixed and contiguous device numbers in installation and management tools for storage openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:25:13 reject reason: No resources in YaST team for this in 11.2. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Matthias Eckermann (mge1512) Requested by: Tejun Heo (teheo) Description: Subject: [Research] head up on upcoming extended block devt change From: Tejun Heo <tj(a)kernel.org> Date: Thu, 18 Dec 2008 12:59:21 +0900 Reply-To: research(a)suse.de Hello, all. From soon to be released 2.6.28, the kernel contains extended block devt support, which basically allocates block device numbers dynamically from major number 259 (might expand to other major numbers if ever necessary). This means that device numbers belonging to the same device become non-contiguous and can be on different major numbers. This will remove the 15 partition limit on /dev/sdX's and increase the total number of supported SCSI disks considerably. Also, it's used by md to allow partitioning of /dev/mdX's thus removing the distinction of partitionable and non-partitionable md devices. For example, /dev/sda with 60 partitions can look like as follows. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 8 1 8001 sda1 8 2 8032 sda2 8 3 8032 sda3 8 4 1 sda4 ... 8 15 8001 sda15 259 0 8001 sda16 259 1 8001 sda17 259 2 8001 sda18 ... 259 43 8001 sda59 259 44 8001 sda60 For detailed overview, please take a look at the following message. http://article.gmane.org/gmane.linux.kernel/701825 As device node creation is completely dynamic these days, installed systems usually can cope fine with this change; however, in installation and management tools, there seem to be many places which assume fixed and contiguous device numbers. To ease hunting down those areas, a debug option is available which forces every block device to be allocated on the dynamic major non-consecutively. With the debug option turned on, the above disk will look like the following. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 259 262144 8001 sda1 259 786432 8032 sda2 259 131072 8032 sda3 259 655360 1 sda4 259 393216 8001 sda5 259 917504 8001 sda6 259 65536 8001 sda7 ... 259 114688 8001 sda55 259 638976 8001 sda56 259 376832 8001 sda57 259 901120 8001 sda58 259 245760 8001 sda59 259 770048 8001 sda60 So, the installation / management tools need to follow /sys/block/*/device/driver to determine which type of device it is and use /sys/block/*/dev to determine its device number. I'll add a kernel parameter (say, block.force_ext_devt) so that this debug option can be turned on and off during boot so that people who don't work on related subsystems don't have to suffer. I'm not sure how and when to proceed with this yet but I definitely think we'll need plenty of time to sort this out completely. Any ideas on how to proceed on this? Thanks. -- tejun Discussion: #1: Tejun Heo (teheo) (2008-12-22 13:31:11) So... when and how do we proceed with things like this? I wanna enable it in HEAD but SLES11 hasn't branched out from HEAD yet but I don't think we should wait till SLES11 is released. #2: Matthias Eckermann (mge1512) (2008-12-22 10:24:58) (reply to #1) SLE 11 has precedence over anything else we currently do - with respect to focus and time spent on it. Thus we should concentrate on SLE 11 and wait with those changes after release of SLE 11. There are more than enough P1 and P2 issues with the SLE 11 kernel to work on, ... Vojtech? #3: Vojtech Pavlik (vojtech_pavlik) (2008-12-22 12:14:19) I agree, Matthias, and I see no reason why this couldn't wait until SLES11 branches out of HEAD. #4: Tejun Heo (teheo) (2008-12-23 11:52:19) Alright, then. I'll enable it when SLES11 branches out. Thanks. #5: Tejun Heo (teheo) (2009-05-29 16:55:23) Added genhd.mangle_devt parameter and enabled DEBUG_BLOCK_EXT_DEVT for all configs except for vanilla's and ppc/ps3. Ext major and mangled minor can be enabled by specifying "genhd.mangle_devt=1" as kernel parameter. Have fun. :-) #7: Christoph Thiel (cthiel1) (2009-06-03 08:26:09) (reply to #5) Tejun, IIUC the options you put in, don't break anything unless genhd. mangle_devt=1 on kernel cmdline? We won't be able to complete the YaST part of this for 11.2. #8: Tejun Heo (teheo) (2009-06-03 15:35:12) (reply to #7) Yeap, the kernel will behave exactly the same as before if the parameter isn't specified. Also, we can disable DEBUG_BLOCK_EXT_DEVT when we're nearing SL112 release (maybe when we enter beta). For now, I'll leave it there in case someone wants to play with it. Maybe it's wise to schedule dev resource so that SL113 can have it implemented? #9: Arvin Schnell (aschnell) (2009-06-03 10:30:47) (reply to #8) I don't expect major problems from the mangled node numbers in YaST. For the partitioner the main work is to change the maximal number of partitions for disks and handling it everywhere (from lib to UI). + #10: Arvin Schnell (aschnell) (2009-07-24 15:03:55) + During hackweek I have extended libstorage to read both "range" and + "ext_range". A few tests with genhd.mangle_devt=1 showed no problems + and I was able to create 20 partitions on sda using YaST. The range is + likely not handled correctly everywhere but testing should be possible + now. + Changes should be included in openSUSE 11.2 Milestone 5. -- openSUSE Feature: https://features.opensuse.org/305584

1 0

[openFATE 305150] Indicate automounted filesystems in YaST partitioner
by fate_noreply＠suse.de 23 Jul '09

23 Jul '09

Feature changed by: Arvin Schnell (aschnell) Feature #305150, revision 11 Title: Indicate automounted filesystems in YaST partitioner - openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) - reject date: 2009-06-03 08:20:42 - reject reason: No resources for 11.2. + openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.3: Evaluation - Priority - Requester: Mandatory - Projectmanager: Important Requested by: Arvin Schnell (aschnell) Description: Currently the partitioner does not indicate if a filesystem (e.g. NFS) is mounted via some automounting daemon. For these filesystems the "Edit" and "Delete" buttons do not make sense. Using them could even cause trouble. So these filesystems need special handling. Libstorage must be extended to detect and provide the information. The ignore_fstab flag can be used as a starting point for this. Relations: - Yast2 Partitioner shows NFS mounts from automounter (novell/bugzilla/id: 446502) https://bugzilla.novell.com/show_bug.cgi?id=446502 + Discussion: + #2: Arvin Schnell (aschnell) (2009-07-23 09:45:00) + Implemented during hackweek: The ignore_fstab flags is now also set for + non-NFS volumes and displayed in the UI. -- openSUSE Feature: https://features.opensuse.org/305150

1 0

[openFATE 306926] Launchpad for openSUSE
by fate_noreply＠suse.de 22 Jul '09

22 Jul '09

Feature added by: Pavol Rusnak (prusnak) Feature #306926, revision 1 Title: Launchpad for openSUSE Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Pavol Rusnak (prusnak) Description: Ubuntu released source code for their tool Launchpad. Modify it, so it is possible to run under openSUSE. Probably integrate with other openSUSE tools later (OBS, ...) -- openSUSE Feature: https://features.opensuse.org/306926

1 3