Re: architecture: all but ... (please add armel to architecture list)
On Sun, Jan 20, 2008 at 02:54:08AM +0900, Osamu Aoki wrote: > Thansk all for the comments. > > Since this is good info, I made a wiki page > > http://wiki.debian.org/PackageArchitectureAlmostAny > > based on the discussion here. > > On Sat, Jan 19, 2008 at 05:35:10PM +0100, Luk Claes wrote: > > > > > 4) wanna-build state dep-wait > > > > > > One option would be to put gsynaptics to dep-wait on > > > xfree86-driver-synaptics. Thus buildd would not try to build > > > it unless xfree86-driver-synaptics becomes some day available > > > on s390. While X on s390 might seem unlikely, stranger things > > > have happened. > > > > Perfectly reasonable IMHO. > > Is this what the conclusion is? and then xfree86-driver-synaptics should add armel to the Architecture list, I guess. BTW: I suppose the above is avlid for all the synaptics_drv dependent packages (ksynaptics and qsynaptics as well). thanks -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: architecture: all but ... (please add armel to architecture list)
Thansk all for the comments. Since this is good info, I made a wiki page http://wiki.debian.org/PackageArchitectureAlmostAny based on the discussion here. On Sat, Jan 19, 2008 at 05:35:10PM +0100, Luk Claes wrote: > > > 4) wanna-build state dep-wait > > > > One option would be to put gsynaptics to dep-wait on > > xfree86-driver-synaptics. Thus buildd would not try to build > > it unless xfree86-driver-synaptics becomes some day available > > on s390. While X on s390 might seem unlikely, stranger things > > have happened. > > Perfectly reasonable IMHO. Is this what the conclusion is? > > 5) packages-arch-specific [2] > > > > p-a-s makes package never appear in wanna-build. It will > > never by tried to be built on architectures defined there. > > It' maintained by three people who manually update it. > > Any technical advantage this approarch has over n-f-u > > is completly negated by the fact the people who are supposed > > to update it ignore my requests to update it... > > It is also not being built on other suites then the one were it > sometimes is meant not to build anymore... > > Some updates go quickly, others take time, I guess that's because there > are only a few persons who can update it... > > > 6) type-handling > > > > This is a kludge that has been written to workaround problems > > in rest of the architecture selection system. In practice it > > seems to work very well. > > > > Osamu, for short term, I suggest using type-handling to generate > > architecture strings. > > I guess one can see this as a dynamic case of 1) and 2)? Is this alternative generic solution? I am a bit confused. If people finalize this on wiki page, I will appreciate. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: architecture: all but ... (please add armel to architecture list)
> Now we have several overlapping mechanisms to avoid building packages > on selected architectures. Worse, we don't have any proper instructions > explaining which mechaism to use. > > 1) Architecture: list in package source > > This is what gsynaptics does now. wanna-build will still offer > the package to build (why?), but sbuild will fail it immeadetly. > Annoyingly maintainers can't define negations (!s390). It's still offered for building as it might only be temporary relevant and buildd maintainers and/or porters might want to look into it. sbuild will fail as that's what one expects it to do without changing the Arch-field. > 2) Architecture: list on binary section > > This is used on packages that build some binary on all archs and > some on only selected ones. This is very usefull unless misused. And probably should be used more often for particular kind of packages... > 3) Wanna-build state not-for-us. > > buildd maintainer sets this. From wanna-build docs[1]: > > there's need for a way to list packages for which even an attempt to > build isn't required. The first solution to this problem was > not-for-us; however, as that is difficult to maintain, not-for-us is > deprecated nowadays; autobuilder maintainers should use > packages-arch-specific instead. > > From my armel short buildd maintainance experience, I can't see why > n-f-u is more difficult to maintain. neither n-f-u or p-a-s have > any connection to what package maintainer defines in Architecture: > strings. You can't document why it's in n-f-u AFAICS and one can't easily have a listing of packages per issue probably. > 4) wanna-build state dep-wait > > One option would be to put gsynaptics to dep-wait on > xfree86-driver-synaptics. Thus buildd would not try to build > it unless xfree86-driver-synaptics becomes some day available > on s390. While X on s390 might seem unlikely, stranger things > have happened. Perfectly reasonable IMHO. > 5) packages-arch-specific [2] > > p-a-s makes package never appear in wanna-build. It will > never by tried to be built on architectures defined there. > It' maintained by three people who manually update it. > Any technical advantage this approarch has over n-f-u > is completly negated by the fact the people who are supposed > to update it ignore my requests to update it... It is also not being built on other suites then the one were it sometimes is meant not to build anymore... Some updates go quickly, others take time, I guess that's because there are only a few persons who can update it... > 6) type-handling > > This is a kludge that has been written to workaround problems > in rest of the architecture selection system. In practice it > seems to work very well. > > Osamu, for short term, I suggest using type-handling to generate > architecture strings. I guess one can see this as a dynamic case of 1) and 2)? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: architecture: all but ... (please add armel to architecture list)
Osamu Aoki wrote: > Hi Luk, > > I wish things were such simple. Here is the root cause etc. > > On Fri, Jan 18, 2008 at 06:58:40PM +0100, Luk Claes wrote: >> Osamu Aoki wrote: >>> Hi, >>> >>> Dear porter, please enlighten me. >>> >>> On Wed, Jan 16, 2008 at 02:26:20PM +, Martin Guy wrote: Package: gsynaptics Version: 0.9.7-3 Severity: wishlist User: [EMAIL PROTECTED] Usertags: eabi Please add "armel" to the architecture list in debian/control (or make it "any") (A new ARM port should be going into lenny to replace the old one in lenny+1; see wiki.debian.org/ArmEabiPort) >>> Since S360 build failure caused me to chose explicit arch list, I >>> think I have to add eabi to fix this bug. I wish if we can do >> s/s360/s390/ > > Yes. > >> What build failure do you mean? 0.9.7-1+b1 as well as 0.9.7-1+b2 built >> fine and 0.9.7-2 didn't have s390 listed anymore as a supported >> architecture... > > That is intentional because of Bug #397917. http://bugs.debian.org/397917 > > What I meant by "build failure" was that an uninstallable package was > created, I think. Ok, though it was still you that chose to go for option 3 which means you have to change the Arch-line every time a new supported arch is known... Changing the synaptics related packages is not going to happen as s390 has no support for it... So you can either still go for option 3 or change to option 4 now by changing it to Arch:any. As the binaries are already removed and it won't be built on s390 anymore anyway, this might be the best thing to do... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: architecture: all but ... (please add armel to architecture list)
block 461088 by 461551 thanks On Sat, Jan 19, 2008 at 09:58:08PM +0900, Osamu Aoki wrote: > > gsynaptics lists s390 as supported (Architecture: any) but > > xserver-xorg-input-synaptics is not available. This leads to > > uninstallable binary packages. > > Bastian > With serious tag and him being s390 buildd maintainer, I took situation > as that the s390 buildd maintainer (Bastian Blank) will not build > xserver-xorg-input-synaptics with some good reason thus the only way for > me is not to build gsynaptics. For me, it looked like that gsynaptic > being so much special as an input device aimed for consumer oriented > system hardware, s390 system being data server oriented may have some > hardware issues to support such thing. (You know that under the normal > situation, people access s390 system running X-client program from > external X-server. Not the other way.) Yes, it is clearly reasonable to avoid building gsynaptics on s390. However, it should not come with the expense of getting it not built on architectures where it could potentially be usefull. > The xserver-xorg-input-synaptics comes from source package > xfree86-driver-synaptics which has Architecture: alpha amd64 arm hppa > i386 ia64 m68k mips mipsel powerpc sparc > (See > http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=xfree86-driver-synaptics) > I do not see armel here either. So fixing my package only will cause the same > issue and response from the s390 buildd maintainer. I filed a bug against this, and made it blocker of this bug. I really don't like packages setting hardcoded lists of architectures. Now we have several overlapping mechanisms to avoid building packages on selected architectures. Worse, we don't have any proper instructions explaining which mechaism to use. 1) Architecture: list in package source This is what gsynaptics does now. wanna-build will still offer the package to build (why?), but sbuild will fail it immeadetly. Annoyingly maintainers can't define negations (!s390). 2) Architecture: list on binary section This is used on packages that build some binary on all archs and some on only selected ones. This is very usefull unless misused. 3) Wanna-build state not-for-us. buildd maintainer sets this. From wanna-build docs[1]: there's need for a way to list packages for which even an attempt to build isn't required. The first solution to this problem was not-for-us; however, as that is difficult to maintain, not-for-us is deprecated nowadays; autobuilder maintainers should use packages-arch-specific instead. From my armel short buildd maintainance experience, I can't see why n-f-u is more difficult to maintain. neither n-f-u or p-a-s have any connection to what package maintainer defines in Architecture: strings. 4) wanna-build state dep-wait One option would be to put gsynaptics to dep-wait on xfree86-driver-synaptics. Thus buildd would not try to build it unless xfree86-driver-synaptics becomes some day available on s390. While X on s390 might seem unlikely, stranger things have happened. 5) packages-arch-specific [2] p-a-s makes package never appear in wanna-build. It will never by tried to be built on architectures defined there. It' maintained by three people who manually update it. Any technical advantage this approarch has over n-f-u is completly negated by the fact the people who are supposed to update it ignore my requests to update it... Since it's manually updated, it has gathered a lot of cruft. %xfree86-driver-synaptics: !s390 # Needs %xserver-xfree86 For some unknown reason, this was not a acceptable solution for gsynaptics/ksynaptics, but was for xfree86-driver-synaptics. 6) type-handling This is a kludge that has been written to workaround problems in rest of the architecture selection system. In practice it seems to work very well. Osamu, for short term, I suggest using type-handling to generate architecture strings. [1] http://www.debian.org/devel/buildd/wanna-build-states [1] http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.731&root=dak&view=markup -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: architecture: all but ... (please add armel to architecture list)
Hi Luk, I wish things were such simple. Here is the root cause etc. On Fri, Jan 18, 2008 at 06:58:40PM +0100, Luk Claes wrote: > Osamu Aoki wrote: > > Hi, > > > > Dear porter, please enlighten me. > > > > On Wed, Jan 16, 2008 at 02:26:20PM +, Martin Guy wrote: > >> Package: gsynaptics > >> Version: 0.9.7-3 > >> Severity: wishlist > >> User: [EMAIL PROTECTED] > >> Usertags: eabi > >> > >> Please add "armel" to the architecture list in debian/control (or make it > >> "any") > >> > >> (A new ARM port should be going into lenny to replace the old one in > >> lenny+1; > >> see wiki.debian.org/ArmEabiPort) > > > > Since S360 build failure caused me to chose explicit arch list, I > > think I have to add eabi to fix this bug. I wish if we can do > > s/s360/s390/ Yes. > What build failure do you mean? 0.9.7-1+b1 as well as 0.9.7-1+b2 built > fine and 0.9.7-2 didn't have s390 listed anymore as a supported > architecture... That is intentional because of Bug #397917. http://bugs.debian.org/397917 What I meant by "build failure" was that an uninstallable package was created, I think. > Why would you remove the support for an architecture when it doesn't > build anymore, shouldn't you rather fix it to build on that architecture > again in that case? From looking at the binNMU version numbers, the > build failure was only temporary anyway... I hoped if it were so. > The best thing you can do is mark it Arch: any again and inform the s390 > buildd maintainer (Bastian Blank) about that unless you have a valid > reason not to build it on s390 anymore? Well, he is the one who told me as follows in the bug report for Bug #397917: > Package: gsynaptics > Version: 0.9.7-1 > Severity: serious > > gsynaptics lists s390 as supported (Architecture: any) but > xserver-xorg-input-synaptics is not available. This leads to > uninstallable binary packages. > > Bastian With serious tag and him being s390 buildd maintainer, I took situation as that the s390 buildd maintainer (Bastian Blank) will not build xserver-xorg-input-synaptics with some good reason thus the only way for me is not to build gsynaptics. For me, it looked like that gsynaptic being so much special as an input device aimed for consumer oriented system hardware, s390 system being data server oriented may have some hardware issues to support such thing. (You know that under the normal situation, people access s390 system running X-client program from external X-server. Not the other way.) The xserver-xorg-input-synaptics comes from source package xfree86-driver-synaptics which has Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc sparc (See http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=xfree86-driver-synaptics) So the root cause of trouble is the missing xserver-xorg-input-synapticis for s390 because the xfree86-driver-synaptics maintainer chose to use an explicit architecture list without s390 for some good reason. I do not see armel here either. So fixing my package only will cause the same issue and response from the s390 buildd maintainer. OK, let me dig more to get wider issue. I know it is funny but I have no such issue for tpconfig (3.1.3-9) although I never know if it works for s390. As I see qsynaptics and ksynaptics suffer the same problem due to missing xserver-xorg-input-synaptics. Another interesting hint was: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xfree86-driver-synaptics They do not even support powerpc per bug #334733 due to the kernel issue. (Strange to see it is build for that atchitecture, though.) I do not know the issue is s390 kernel code or not, but before asking gsynaptics, qsynaptics and ksynaptics, you should convince xfree86-driver-synaptics package maintainer first. Maybe before that, you may need to fix kernel issues. Osamu PS: CCing people involved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
