2005-Dec-15

Another Linux system without using_dma. hdparm -d1 complained: "HDIO_SET_DMA failed: Invalid argument". dmesg says it is using "Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ". But this is an ALi Corporation M5229 IDE (rev c3). I need to build kernel with out using ALI15X3 as module since the ports are already claimed.

Output from a PKG_FAIL_REASON went to standard out instead of stderr and then became part of a variable that pkgsrc attempted to cd to and caused some strange errors. In my case, I removed a faulty PKG_OPTIONS that I had set, but the problem still exists. (I need to send-pr the details although I did send to tech-pkg.)

After discussion on tech-pkg, I started using -j2 and -j3 make switch to build packages in pkgsrc on Linux dual processor system. Both of my CPUs are getting used. I am building kdelibs on Linux. top (from wip/procps) shows me:

Tasks:  74 total,   3 running,  71 sleeping,   0 stopped,   0 zombie
Cpu0 :  95.5% user,   4.2% system,   0.0% nice,   0.3% idle,   0.0% IO-wait
Cpu1 :  95.5% user,   3.2% system,   0.0% nice,   1.3% idle,   0.0% IO-wait

And sometimes I have multiple shlibtool, cc1plus and g++ running at same time. Sometimes the Cpu1 jumps down to only near 0 percent though during same build, but that is okay. I should have recorded how long it took to build before (Later when I tried on DragonFly I had a few packages fail and so I stopped. Didn't look further yet.)

Found what I thought was a undefined MAXNAMLEN in dropbear (seen on DragonFly) and reported upstream. (I suggested using POSIX NAME_MAX. Later he told me that it was a typo and it was supposed to be some internal dropbear constant. (I wonder if using the longer size in that case when rest of code uses shorter constant could cause some security issue ...)

For some reason, I had an old CVS Tag in one pkgsrc directory and so I didn't see an update so I sent patch for it but was told it was already done :( No other CVS Tags in entire tree :)

So I updated a production machine with apache without thinking. It has a vulnerable apache on it. But I was using suexec and new package didn't include that. So as I build using pkgsrc a package with:

APACHE_SUEXEC_DOCROOT=/   PKG_OPTIONS.apache=suexec

Suggested (again) some ideas so we can have different packages with different names generated via our options framework.

Imported ltrace to pkgsrc-wip.