ewaller wrote:As a counterpoint, if someone did this at $DAYJOB, I would be escorting them out the door. I am just saying....
Oh, don't be so dramatic. No one ever got fired for submitting a bad PKGBUILD to the AUR.
...but people who submit destructive PKGBUILD files, on the other hand, should be forced to write their own GNU Autotools scripts until they've learned their lesson.
Really? You test every upgrade of every package on several architectures?
Generally, if the software is know to work equally well on x86 and x86_64, then there shouldn't be any issue. If it's a -bin package, is hardware related, or has something special that would make you doubt, have someone test it first.
There's plenty of packages that don't really need that much testing on every arch (ie: thunderbird plugins, gtk themes). While kernel modules are on the other end of the arena. Self-updating packages, or java stuff with non-java dependencies.
]]>@jwm-art: thanks for our offer, speaking of that... could you please have a look at https://bbs.archlinux.org/viewtopic.php?id=146359, i got a special problem with your petri-foo code...
]]>My development environment for Petri-Foo is x86_64. 99% of compiling/testing goes on in a regularly updated Arch Linux. I'm dual booting Arch with a 64bit Debian stable and use the latter as a guide for identifying the oldest library versions I should ensure building does not fail for.
]]>I would say that unless you have tested the package on x86_64, or heard from someone who has, don't add it.
This. Don't make unsubstantiated claims (The sun revolves around the Earth).
]]>Recently i adopted some canon printer driver packages, and they were hard enough to get right for x86_64 .
I posted them on aur with a comment that they were only x86_64 for now, and asked for people with 32-bit systems to volunteer for testing.
Some users did come, and i adjusted the pkgbuild for 32-bit, send it to them and after confirmation it worked, uploaded a new package to aur with i686 included.
Personally, i prefer to add i686 to my packages only if i got confirmation it works.
]]>Awebb wrote:Let's assume the opposite: If I create a PKGBUILD on my 64bit platform, how can I know it'll compile and run fine on 32bit?
You install a 32-bit lightweight chroot and test it.
But you DO test it, you won't simply add i686, just because you feel it might compile as well as it does on 64bit. I'd make the wild claim, that most to almost all software compiling well on 64bit will also compile on 32bit, but we all know how well wild guesses work out in the end.
]]>@Tomk: You are correct, i probably should have clarified that the packages worked. I will make sure that I specify this to a packager if/when it comes up again.
On your other point of advice to 'lighten up' - I wasn't up in arms over anything, in fact it is quite the opposite. i was clarifying my position to Masuto (who by his own admission above) thought that i meant something which I did not. I think it is important to address miscommunications when they happen, wouldn't you agree?
@Masuto: No apology necessary, i just wanted to clear up any misunderstanding I can see what you are driving at though - as far as package maintainers may have good reasons to not include x86_64. I don't know the statistics of 32bit archers / 64bit archers, but i imagine you also understand what i was saying about a 64bit OS being common place. Anyways, as far as Ebumeter and Petri-foo ~ i can participate in testing for x86_64, i don't mind at all.
]]>I see a big difference in your interpretation of what i said vs. what was actually said
you're absolutly right, i have to apologize, guess i took your comment the wrong way. Sorry.
Anyway, it was more a general statement/question, because i see many comments like "hey, you _forgot_ to add x86_64" where my point was, that package maintainers might do that for a good reason.
Didn't know that you are able to run a 64bit vm on a 32bit host system (if your processor is a 64bit one which supports hardware virtualization, which mine does). Good news on one hand, on the other hand that means a lot of additional work...
]]>i use both of those packages, almost daily on my 64bit system and didn't ask you to add x86_64 without first making sure they worked okay.
Perfect - the system works
Oh, except for one little detail - you forgot to tell him that they worked:
*please* fix your pkgbuild;
==> ERROR: ebumeter is not available for the 'x86_64' architecture.
Note that many packages may need a line added to their PKGBUILD
such as arch=('x86_64').64bit CPUs are pretty much standard these days, so you should have x86_64 specified in there.
cheerz
Two bits of advice come to mind:
1. Lighten up. Surely it's obvious that masutu is just kidding with the "hey, fix your shit" stuff?
2. Follow the commonly accepted process fully, even if it's not yet fully documented. You were almost there, you just forgot that important detail.
Let's assume the opposite: If I create a PKGBUILD on my 64bit platform, how can I know it'll compile and run fine on 32bit?
You install a 32-bit lightweight chroot and test it.
]]>- a 32bit VM to test your packages against.
That is also true when you have a 32bit system. Depending on your processor you can have a 64bit guest on a 32bit host with VirtualBox, too. If your processor doesn't work, you can still use QEMU.
]]>Let's assume the opposite: If I create a PKGBUILD on my 64bit platform, how can I know it'll compile and run fine on 32bit?
Well, on a 64bit system you have options that are not available to a 32bit system. Some of these include;
- 32bit bundled system or multilib system on Arch64
- a 32bit VM to test your packages against.
- Asking for help via testers from within the Arch community
only the last option is available to someone packaging (for both x86/x86_64) using a 32bit system. But i think it in itself, is likely good enough.
my 2 cents
]]>I am one of the people who asked you to add x86_64 to pkgbuilds, more specifically - petri-foo && ebumeter - which both compile fine and work on x86_64. Which is exactly the reason i asked you to add x86_64. ie: i use both of those packages, almost daily on my 64bit system and didn't ask you to add x86_64 without first making sure they worked okay. Also, even if their was a (later) problem of x86_64 version not compiling - the problem would be reported upstream to the developer, as a problem like that should be reported upstream, rather than expecting the packager to have to fix the developers the code.
I'd also like to point something out here; I did not make any demands, nor did i say this;
hi, fix your shit, x86_64 is so common these day
Now here is actually what i said;
*please* fix your pkgbuild;
==> ERROR: ebumeter is not available for the 'x86_64' architecture.
Note that many packages may need a line added to their PKGBUILD
such as arch=('x86_64').64bit CPUs are pretty much standard these days, so you should have x86_64 specified in there.
cheerz
I see a big difference in your interpretation of what i said vs. what was actually said;
I politely asked you to fix your pkgbuild and 'cheerz' also indicates a salute / thanks / gratitude / appreciation...
Maybe i am wrong to assume you 'should' have x86_64, using the reasoning that 64bit CPUs dominate the market and are quite common place ~ but when both packages are working fine for 64bit and only require adding x86_64 to the arch=() in order for x86_64 users to use them - i can't imagine any reason to not add them.
do we really need to have separate x86_64 pkgbuilds/AUR for either of those packages?
food for thought.
]]>