archive-org.com » ORG » N » NETBSD.ORG

Total: 1243

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • hgnb
    this is very cheap in Mercurial The following are the operations you need using libc13 as an example branch name Note that even if you re working on something nontrivial that will take a number of commits if you aren t intending to push the changes out before they re done you don t need to make a branch and there s nothing gained by doing so However if you expect to be working over a long period of time on a major effort such as the mythical libc version bump and or you want or expect other developers to contribute or at least test your changes before they re done go ahead and create a branch Create a new branch cvs update dP hg pull hg update if needed update doc BRANCHES update doc BRANCHES if appropriate cvs commit doc BRANCHES hg commit doc BRANCHES if needed cvs tag libc13 base hg tag libc13 base cvs ph tagn hg branch libc13 make first change make first change cvs commit hg commit hg push Mercurial warns you that branches are permanent and expensive this warning is aimed at git users who ought to be creating bookmarks instead and not something you need to be concerned about Check out a new tree on a branch cvs co P rlibc13 hg clone url cd src hg update r libc13 Switch to a new tree on a branch cvs up dP A rlibc13 hg pull if needed hg update r libc13 Note that if you have uncommitted changes Mercurial will balk at crossing from one branch to another because it doesn t know how to merge them In that case do this hg update r libc13 base resolve conflicts if needed hg update r libc13 resolve conflicts if needed Check which branch you re currently on cat CVS Tag hg branch See list of branches no can do reliably hg branches Note that unlike with CVS there s no version control related reason to get a new tree just to work on a branch Although of course it s still possible to commit to the wrong branch by accident Get a new tree if and only if you want to have a different tree for administrative reasons Sync your branch with the trunk HEAD in CVS cvs ph tagn hg merge default resolve conflicts resolve conflicts cvs commit hg commit hg push When you re done with your branch in Mercurial you can close it so it s no longer active This causes it to disappear from some reports reduces some internal management overheads and prevents accidental commits on it no can do hg commit close branch Don t forget to update doc BRANCHES too Vendor branches A vendor branch is one where code from a third party is committed in unmodified state so it can be updated easily from upstream later Note that in CVS vendor branches are magic in a bad way in Mercurial we ll just use an ordinary branch

    Original URL path: http://wiki.netbsd.org/users/dholland/hgnb/ (2016-02-01)
    Open archived version from archive


  • hgpath
    our own is not currently realistic One could write a lot of gung ho IT IS REALLY GR8 11 boosterism here too of course but I ll leave that for someone else Migration There are two categories of issues related to migrating a project the size of NetBSD first what the project and the world around the project will look like after the migration is done and second what things need to be done to get there The purpose of this page is to tackle the first what things in the project will be different and what they ll be like This includes not just user facing things like commit procedures but also backend considerations and administration There s a second page with a list of work that needs to be done Issues Technical concerns demands on the system s operational model atomic commits changesets rename support authenticating commits numbered versions branch handling tag handling partial checkouts partial trees partial history blacklist extension which is a legal requirement being able to migrate away in the future Conversion of CVS repository phenomena vendor branches conversion of repo copies and similar CVS horrors adding rename metadata to already done moves pkgsrc not really vendor imports developer usernames vs email addresses in log messages and commit metadata non ascii text in log messages version references in log messages retaining CVS file version numbers as metadata restoring the pre USL settlement history and or including the CSRG history Implementation concerns demands on the system as it exists general performance importing into base or not storage requirements vs small systems memory requirements vs small systems possible workarounds for small systems Community deployment issues what becomes of anoncvs making use of version numbers in mailing lists security advisories patches contributions commits from non developers collaborating with

    Original URL path: http://wiki.netbsd.org/users/dholland/hgpath/ (2016-02-01)
    Open archived version from archive

  • hgtodo
    HOWTOs The Guide Manual pages Wiki Support Problem report guide Report a bug Query bug database Security Community Blogs Mailing lists List archives Developers Browse source Cross reference Release engineering Projects list Ports History Emulators Packages Browse packages Release engineering Wiki Home Edit Comment Source History New RecentChanges NetBSD Wiki users dholland hgtodo To do list for Mercurial migration coming soon Add a comment Links hgpath Last edited late Saturday

    Original URL path: http://wiki.netbsd.org/users/dholland/hgtodo/ (2016-02-01)
    Open archived version from archive

  • mercurial
    MD kernel stuff or bootloaders sys arch is a good choice as it s also large You can always unignore stuff later so don t worry about remote possibilities Now commit the hgignore file hg add hgignore hg commit m add hgignore file hgignore Now add and commit the contents of the working tree hg add hg commit m HEAD of 20130101 or whatever date You are now in business Working If you re using a branch remember to change branches before you commit anything hg branch mystuff You want to keep the default branch an untouched CVS tree so you can use Mercurial to merge And also so you can use Mercurial to extract diffs against CVS HEAD and so forth Similarly if you re using a patch queue put everything in patches and don t commit There s a section below about working with mq if you aren t familiar with it You can edit and build and test as normal Use hg commit or hg qrefresh to sync stuff into Mercurial If you re using mq it s a good idea to checkpoint your patch queue periodically This is done as follows hg qcommit The patches directory hg patches is stored in its own Mercurial repository and this commits the patches to that repository If necessary you can then fetch older versions of the patches back and so forth Updating from CVS First make sure all your changes are committed If you have unfinished changes that aren t ready to commit there s a Mercurial extension for stashing them temporarily If you have stuff that you don t want to commit at all like debugging printouts or quick hacks it s often convenient to keep those in their own mq patch even if you aren t using mq for development Now go back to a clean CVS tree If using branches go back to the default branch hg update r default If using mq pop all the patches hg qpop a DO NOT run cvs update until unless you have done this it will make a mess When you eventually do this by accident see the section below on recovering from mistakes Now run cvs update from the top of the source tree cvs q update dP You should get no conflicts from CVS and nothing should show as modified It is usually a good habit to save the cvs update output to a file to be able to check this Tell hg to sync up hg addremove Use hg to check what it thinks has changed hg status Commit the changes to Mercurial hg commit m Updated to 20130202 Now you get to merge If you re using a branch you want to merge the changes into your branch rather than merge your branch into the changes hg update r mystuff hg merge default edit and resolve as needed hg commit m sync with HEAD If it tells you update crosses branches when trying to update back to your branch update to the parent changeset the previous version from CVS first as that s an ancestor of your branch If you re using mq the thing to do now is to push all your patches and if any reject clean up the mess and refresh them If patch tells you hunk N succeeded at offset MMM with fuzz Q it s a good idea to manually inspect the results patch being what it is sometimes this means it s done the wrong thing Edit if needed Then even if you didn t edit refresh the patch so it won t happen again As I said above it s quite likely that by now there s a better scheme for merging with mq that I don t know about yet Pushing back to CVS When you re ready to push your changes back to CVS so they re really committed first unless you re absolutely sure it s not necessary update from CVS as above and merge Then If you re using a branch go back to the default branch and merge your changes into it hg update r default hg merge mystuff hg commit m prepare to commit back to cvs Now cvs add any new directories and files be sure not to forget this It is a good idea to crosscheck with cvs diff and or cvs update cvs diff up less cvs nq update dP Then you can cvs commit cvs commit Because of RCSIDs committing into cvs changes the source files So now you need to do hg commit m cvs committed and if you intend to keep working in this tree you want to merge that changeset back into your branch to avoid having it cause merge conflicts later Do that as above If you re using a patch queue usually it s because you want to commit each patch back to CVS individually First pop all the patches hg qpop a Now for each patch hg qpush hg qfinish a cvs commit hg commit m cvs committed previous With a long patch queue you ll want to use the patch comments as the CVS commit messages Also running cvs commit from the top for every patch is horribly slow Both these problems can be fixed by putting the following in a script hg log v r sed 1 description d patch message cat patch message echo n cvs commit F patch message hg log v r grep files sed s files I call this dogetpatch sh and then the procedure is hg qpop a then for each patch hg qpush hg qfinish a dogetpatch sh cvs commit as directed hg commit m cvs committed previous This could be automated further but doing so seems unwise Using CVS within Mercurial You can successfully do any read only CVS operation in the hybrid tree diff annotate log update p etc Read write operations should be avoided if you mix upstream changes with your

    Original URL path: http://wiki.netbsd.org/users/dholland/mercurial/ (2016-02-01)
    Open archived version from archive

  • erh
    Foundation Advocacy Documentation FAQ HOWTOs The Guide Manual pages Wiki Support Problem report guide Report a bug Query bug database Security Community Blogs Mailing lists List archives Developers Browse source Cross reference Release engineering Projects list Ports History Emulators Packages Browse packages Release engineering Wiki Home Edit Comment Source History New RecentChanges NetBSD Wiki users erh Eric Haszlakiewicz Add a comment Last edited late Thursday afternoon February 24th 2011 Preferences

    Original URL path: http://wiki.netbsd.org/users/erh/ (2016-02-01)
    Open archived version from archive

  • haad
    Projects list Ports History Emulators Packages Browse packages Release engineering Wiki Home Edit Comment Source History New RecentChanges NetBSD Wiki users haad haad s wiki page Things to blame me for NetBSD LVM device mapper driver in kernel NetBSD ZFS port some changes in proplib NetBSD Kernel Debugger tutorial DDB Howto NetBSD ZFS porting guide NetBSD zfs howto ZFS Solaris in RUMP My own todo list TODO Add a comment

    Original URL path: http://wiki.netbsd.org/users/haad/ (2016-02-01)
    Open archived version from archive

  • NetBSD Developer Cheatsheet
    bug is When you get a crash in the kernel you want to translate the address from the backtrace to the line in the source code Stopped in pid 496 1 gdb at netbsd breakpoint 0x5 leave First you need to find the address of the breakpoint function in the running kernel image with the nm 1 command nm netbsd grep breakpoint Then add 0x5 to the address and use addr2line 1 to get the exact line in the kernel source code where you get the crash addr2line g netbsd sum address In gdb 1 this can be achieved with the command info line function name 0x5 What to do if ddb backtrace doesn t work The DDB backtrace command usually doesn t work when the EIP register was set to NULL e g via a bad function pointer In this case we can get part of the backtrace by using a different approach db show all reg eip 0 cs 0 eflags 0 esp 0xcb741b70 We need to find which address was set in the ESP register this is the stack pointer register on i386 When we have our address we need to use x Lx 0xcb741b70 20 to

    Original URL path: http://wiki.netbsd.org/users/haad/ddb_howto/ (2016-02-01)
    Open archived version from archive

  • porting zfs
    should be built by default now There are 2 modules used for ZFS solaris kmod and zfs kmod Solaris module provides solaris like interfaces to zfs on NetBSD The second module is zfs and provides zfs file system functions Configuration User need to modload solaris modload zfs After loading modules user can create zpool zfs version of volume manager and manage zfs file systems on it zpool create zpool name type device where type is mirror raidz raidz2 default is normal linear allocation device is blod device on NetBSD dev sd0a for example zpool create tank mirror dev sd0a dev sd1a creates mirrored zpool between 2 disk partitions With zpool created we can create zfs filesystems or zvols zfs logical volume disks zfs create V size tank zvol name creates zvol with zvol name from ZPOOL called tank Logical disk is created in dev zvol rdsk zpool name zvol name dev zvol dsk zpool name zvol name zfs create tank zfs name create zfs filesystem on a zpool called tank Administration After creating ZVOLS and filesystem they are saved in a etc zfs zpool cache file and loaded after nextzfs module load 3 Known Bugs Show stoppers amd64 i386 Both vnode reclaiming deadlocks Current code is quite a hack but it works until I will find some time to rework vnode reclaiming on NetBSD http nxr netbsd org xref src external cddl osnet dist uts common fs zfs zfs vnops c 4254 vnode fsync bug I think that we are hitting this bug too I have some patches in the tree which fixes deadlod in vnode reclaim but after that I m getting another deadlock in VOP FSYNC kmem cache alloc aka pool cache get panicsdue to KM NOSLEEP flag There are some problems in the NetBSD UVM subsytem when

    Original URL path: http://wiki.netbsd.org/users/haad/porting_zfs/ (2016-02-01)
    Open archived version from archive